− значень у ряду багато;

− потрібно передати користувачам ранжируємість зна-

чень;
− необхідно дати можливість користувачам швидко виб-
рати значення з великої їх кількості (у таких випадках повзунок
виявляється найефективнішим елементом).

Рисунок 6.8 Приклади повзунків

Повзунки мають цікавий аспект. Їх можна також викорис-
товувати для вибору текстових параметрів, але лише у випад-
ках, коли ці параметри можна зрозумілим чином відраджувати.
ТЕМА 7. ПОНЯТТЯ «ВІКНО ПРОГРАМИ»
7.1. Що таке вікно програми
7.2. Головні елементи вікон
7.3. Структура та побудова вікна
7.3.1. Вкладки
7.3.2. Термінаційні кнопки
7.3. Майстри
7.1. Що таке вікно програми
У сучасному програмному забезпеченні розрізняють декі-
лька типів вікон, відповідно до їх функціонального призна-
чення:
− головні вікна програми;
− вікна документа;
− режимні діалогові вікна;
− безрежимні діалогові вікна;
− палітри;
− вікна браузера.
95
 При цьому частина окремих типів у загальній сукупності з
часом змінюється: вікна документів, відмирають, замінюючись
вікнами програм; режимні діалогові вікна зміняються безрежи-
мними, а безрежимні, у свою чергу, палітрами. Ідея палітр теж
хилиться до зникнення (палітри заміняються панелями інстру-
ментів). Так що в майбутньому, скоріше за все, в ПЗ залишаться
тільки вікна програм, панелі інструментів і безрежимні діало-
гові вікна.
Цікаво те, що порівняно недавно ніяких вікон не було, на-
віть діалогових вікон, які вже почали сприйматися як даність.
Замість них якась частина екрану виділялася під меню, яке в ті
часи було функціонально багатшим, ніж меню теперішнє. Так,
наприклад, нормою були поля введення в меню.
Зупинимося на структурі вікон різних типів. На (рис. 7.1)
найбільше вікно є вікно програми MS Word 2013. Всередині
нього два вікна документів (в останніх версіях Word їх вже не-
має). Зліва зверху розташовується режимне діалогове вікно (Аб-
зац), під ним справа - безрежимне (Знайти і замінити). Зліва
внизу розташовується палітра (Форматування, отримана відді-
ленням відповідної панелі інструментів від краю вікна). Зверху
і справа дві панелі інструментів (колишні палітри).

Рисунок 7.1 Типи вікон на прикладі MS Word 2013

З появою графічного режиму стало можливим реалізувати
в інтерфейсі метафору робочого столу: з'явилися вікна програм,
96
вікна документів і діалогові вікна, які спочатку були всі режи-
мні.
Поняття «Режимне діалогове вікно» («Модальне діалогове
вікно») здається досить специфічним. Насправді все просто.
Якщо вікно, що відкрилося, блокує доступ до решти частини
системи, відбувається, фактично, запуск нового режиму роботи
(оскільки функціональність окремого діалогового вікна ніколи
не збігається з функціональністю системи в цілому). Після того,
як вікно закрите, відбувається повернення попереднього (осно-
вного) режиму. У цьому і є все значення терміну «режимний».
З розвитком можливостей інтерфейсу наявність режиму в
діалогових вікнах стало недоцільним. По-перше, всіх дратує,
що викликавши діалогове вікно і виявивши, що воно викликано
передчасно, доводиться закривати вікно і відкривати його на-
ступного разу заново. По-друге, що важливіше, в системах, орі-
єнтованих на документи, режим відволікає увагу користувача і
взагалі позбавляє його відчуття керованості. По-третє, сама ідея
зближення інтерфейсу з реальним світом (зокрема, з метафорою
робочого столу) вступала в протиріччя з ідеєю режимів в будь-
якому їх прояві, оскільки в реальному світі взагалі не буває ре-
жимів, аналогічних інтерфейсним. А оскільки «дизайн користу-
вачів» був орієнтований на функціонування в реальному світі,
вирішили не переробляти користувачів, а переробити інтер-
фейс. Так з'явилися безрежимні діалогові вікна, тобто вікна, які
можна було необмежений час тримати на екрані, перемикаю-
чись в міру потреби між ними і документом. На жаль, і тут не
без проблем. Річ у тому, що такі діалогові вікна не можна ро-
бити «тонучими», тобто дозволяти користувачеві перекривати
їх вікнами документа або програми. Причина проста - користу-
вачі забувають, що вони колись відкривали відповідне вікно і
намагаються відкрити його заново. Тому вирішили зробити такі
вікна «вспливаючими», тобто такими, які перекриваються
тільки іншими плаваючими вікнами цієї ж програми або ін-
шими програмами. Зрозуміло, деякі діалогові вікна неможливо
зробити безрежимними: наприклад, повідомленнями про поми-
лки. У цілому з переведенням вікна в безрежимний стан немає
особливої проблеми.
97
 Але і тут виявилася проблема. Річ у тому, що просто діало-
гове вікно, навіть будучи безрежимним, малокорисне, оскільки
перекриває дуже багато інформації у робочій області. Вирішення
цієї проблеми було еволюційним: були придумані палітри, тобто
вікна, з яких вилучили все порожнє місце. Виявилось, що палі-
три, окрім малих розмірів, мають одну велику перевагу: користу-
вачі дуже люблять їх розставляти на екрані індивідуальним по-
рядком. Це істотно підвищує суб'єктивне відчуття контролю над
системою. На жаль, візуальний дизайн палітр, як правило, досить
складний і тривалий, так що суто економічні причини заважають
переробити в палітри всі діалогові вікна (рис. 7.2).

Рисунок 7.2 Приклад палітри з програми Adobe PageMaker

На жаль, через малі розміри палітр у них ніколи не поміща-
ються повноцінні підписи до елементів, що істотно уповільнює
швидкість навчання. Існує неформальний, але на подив вірний
закон: суб'єктивна важливість інформації, що перекривається
діалоговим вікном (палітрою зокрема), не залежить ні від роз-
мірів, ні від положення вікна, а залежить тільки від периметра.
У результаті постійно виявляється, що користувачі, прагнучи
відкрити потрібну інформацію, перекладають вікна з місця на
місце, що знижує продуктивність (неістотно) і суб'єктивне за-
доволення (істотно). При цьому, якщо зробити палітру малень-
кою, понизиться вірогідність її вимушеного перетягування, але
виросте суб'єктивне незадоволення від її перетягання («така ма-
ленька, а так дратує»). Більш того, палітра перекриває не всю
потрібну інформацію, а її частину; при цьому все одно палітру
доводиться переміщати. Єдиним способом позбавитися від
цього ефекту є зменшення периметру палітри, а досягнути
цього можна, тільки прикріпивши палітри до краю екрану.
Так зявилися панелі інструментів, які містять не тільки пік-
тограми інструментів, а й не дуже складні елементи управління.
У деякому сенсі, це повернення до початку, до часів, коли один

98
з країв екрану був зайнятий величезним і дуже функціональним
меню. З іншого боку, виявилось, що це найефективніше.
Паралельно з народженням складних панелей інструментів
вікна документів вимирають. Вимирають вони з двох простих
причин. По-перше, вони погано узгоджуються з ментальною
моделлю більшості користувачів. По-друге, неможливо приду-
мати скільки-небудь ефективного способу перемикання між
ними. Найефективніший, з погляду розробників операційної си-
стеми, це спосіб перемикання між програмами, відповідно, пе-
ремиканню документів дістається свідомо гірший спосіб. Так у
Windows, через різнобій у способах перемикання між докумен-
тами, виникають казуси: у MS Word, наприклад, для клавіатур-
ного перемикання між документами використовується комбіна-
ція клавіш Ctrl+F6. Ця комбінація є фізично дуже складною для
користувача (спробуйте використовувати цю комбінацію кла-
віш однією рукою, і ви зрозумієте, що це неможливо). Головне
ж в іншому: з самого початку вікна документів були не стільки
бажаною властивістю системи, скільки хаком. Для того, щоб за-
пустити дві однакові програми, кожну з одним документом все-
редині, не вистачало ресурсів комп'ютера, ось і доводилося за-
пускати одну програму з двома документами. Зараз, навпаки,
пам'яті досить, до того ж з'явилися технології програмування.
Отже вікна документів вмирають.
7.2. Головні елементи вікон
Вікна, окрім областей з елементами управління, мають де-
які загальні елементи, головними з яких є рядок заголовка вікна,
рядок статусу, панелі інструментів і смуги прокрутки. Панелі
інструментів та смуги прокрутки були розглянуті вище (тема
6.). Зупинимося більш детально на поняттях рядок заголовка та
рядок статусу.
Біля кожного вікна є рядок заголовка, але користувачі цим
рядком цікавляться дуже мало. Людині не властиво звертати
увагу на повсякденність, особливо якщо ця повсякденність не
знаходиться в фокусі його уваги. У результаті, користувачі зве-
ртають увагу на рядок заголовка тільки навчаючись користува-

99
тися комп'ютером або в ситуації, коли вони зовсім нічого не ро-
зуміють в системі. З цього, однак, не слідує, що рядком заголо-
вку можна нехтувати. Річ у тому, що текст і, в меншій мірі, пік-
тограма заголовку грають важливу роль у ПЗ (вони керують пе-
ремиканням завдань) і дуже важливу в Інтернеті (керують наві-
гацією) (рис. 7.3).

Рисунок 7.3 Вплив рядка заголовка вікна на перемикання між завдан-

нями
Оскільки ширина екрану обмежена, при збільшенні кілько-
сті запущених програм розміри кнопок скорочуються, відпо-
відно в ці кнопки поміщається менше тексту. У результаті ко-
ристувач зберігає здатність пізнати програму за її піктограмою
і уривком тексту, але втрачає можливість впізнавати документи.
Проблеми можна було б уникнути, якби назва програми на кно-
пці (і в рядку заголовка вікна) була б коротша або назва доку-
мента виводилася б до назви програми.
З перемиканням завдань все просто і складно одночасно.
Просто, оскільки правило тут просте: «релевантне виводиться в
першу чергу». Оскільки користувачеві потрібний саме конкре-
тний документ конкретної програми, а зовсім не програма про-
сто, назви документів, як більш релевантні, потрібно виводити
насамперед. Складність полягає у тому, що через жорсткість ін-
терфейсу Windows багато не зробиш. Проте, скорочувати назву
програми потрібно безумовно.
Інша ситуація в Інтернеті. Оскільки піктограма в рядку за-
головка приходить від браузера, немає особливої можливості
оптимізувати переключення завдань. З іншого боку, якість
цього заголовка має істотний вплив на навігацію, оскільки при
показі результатів пошуку в пошукових системах заголовком
елементу стає вміст тега Title. Який і потрапляє в звичайному
режимі вгору екрана.
Натиснення на піктограму в рядку заголовка викликає
меню, що розкривається, є зручним місцем для виклику функ-
цій.
100
 Правило релевантності діє і тут - на початку рядка має бути
більш релевантна інформація, ніж в її кінці. Оскільки зв'язку
«програма-документ» в Інтернеті немає, найефективніше пока-
зувати адресу поточної сторінки в навігаційній системі сайту
(якщо сайт ієрархічний). У даному випадку релевантність вима-
гає, щоб спочатку йшла назва поточного документа, потім роз-
ділу, в якому він розміщений, потім розділу більш високого рі-
вня і так далі. Не треба також забувати, що розмір рядка обме-
жений, так що більше 70-80 символів у ньому бути не може.
Отже, важливо розуміти те, що нехтування користувачем
заголовка вікна, зовсім не означає, що йому заголовок не потрі-
бний. Навпаки, змістовний заголовок може полегшити розу-
міння роботи діалогу. Тому наявність на екрані помітного і аде-
кватного заголовка вікна часто виявляється дуже корисною. На
жаль, у звичайному Windows-інтерфейсі місця під нього немає.
Рядок статусу є, мабуть, самим недооціненим елементом ін-
терфейсу. Поширена думка, ніби рядок статусу призначений
для того, щоб інформувати користувачів про значення тих або
інших елементів інтерфейсу. Мається на увазі, що якщо корис-
тувач підводить курсор до якого-небудь елементу, в рядку ста-
тусу з'являється короткий його опис. Насправді цей рядок не
може цього робити взагалі: річ у тому, що курсор розміщений в
одному місці, а підказка з'являється зовсім в іншому, користу-
вачеві при цьому доводиться читати підказку або переводячи
погляд, або периферійним зором. Насправді рядок статусу при-
значений для двох речей: він може бути або власне рядком ста-
тусу, тобто відображати поточний стан системи, або бути па-
неллю інструментів для досвідчених користувачів (або ж ро-
бити і те, й інше).
Відображення поточного стану системи. Практично кожна
система має властивості, що залежні від документа або зміню-
ються з часом. Наприклад, в ілюстративних програмах об'єкти
мають які-небудь властивості, причому не всі ці властивості по-
казуються. Інший приклад: коли система довгий час зайнята,
вона повинна показувати користувачеві індикатор ступеня ви-
конання. І, нарешті, найпростіший приклад: користувач тексто-
вого процесора має право знати, на якій сторінці документа він
101
зараз розміщений. Найефективніше виводити все це в рядку ста-
тусу (рис. 7.4).

Рисунок 7.4 Рядок статусу Adobe PhotoShop

На рисунку зліва відображається поточний масштаб відо-
браження документу, далі за ним обсяг пам'яті, що займає доку-
мент, потім індикатор ступеня виконання, а справа - контекстна
підказка.
Рядок статусу особливо цікавий як місце виведення індика-
тора ступеня виконання. Існує закономірність по місцю виве-
дення індикатору виконання можна визначити якість інтер-
фейсу системи: якщо індикатор виводиться в рядку статусу, то
система володіє в цілому якісним інтерфейсом, якщо ж індика-
тор виводиться у іншому місці – неякісним.
Рядок статусу включає в себе деякі важливі елементи з па-
нелі інструментів, які дозволяють досвідченому користувачеві
підвищити ефективність роботи системи, а недосвідченому
уникнути помилкових дій, а саме помилкового перемикання
(наприклад, кнопки ЗАП, ІСПР, ВДЛ і ЗАМ в статусному рядку
MS Word).
7.3. Структура і будова вікна
Структура і сама будова вікна або екрану є найістотнішими
чинниками, що впливають на якість інтерфейсу. Наприклад,
продуктивність користувачів деколи можна підвищити вдвічі,
просто змінивши розташування елементів управління, не змі-
нюючи самі ці елементи.
Більшість керівництва з проектування інтерфейсів, перера-
ховуючи вимоги до структури вікна, обмежуються зауважен-
ням, що термінаційні кнопки (тобто командні кнопки, керів-
ники вікном, наприклад OК або Закрити) мають бути або знизу
вікна, або в правій його частині. Це добре, але мало.
По-перше, вікно повинне добре скануватися поглядом,
тобто його основні частини мають бути відразу помітні. Як пра-
вило, у вікнах з малою кількістю елементів управління проблем

102
з скануванням не виникає. Проблеми з'являються у великих ві-
кнах, що дають доступ до багатьох функцій. Зрозуміло, що обє-
днювати ці функції в купу неефективно, для цього інтерфейсні
елементи мають бути організовані в блоки. У ПЗ для цього ви-
користовуються в основному рамки угрупування, в Інтернеті -
пустоти, що розмежовують окремі функції. При цьому рамки
зручніше у виробництві, але оскільки вони є візуальним шумом,
однозначно рекомендувати їх не можна. У цілому, розмежову-
вати блоки пустотами більш бажано, але і складніше.
По-друге, вікно повинне читатися, як текст. При інших рів-
них умовах, вікно в якому всі елементи управління можна без
зусиль зв'язано прочитати, краще запам'ятовується і швидше
обробляються мозком (оскільки не доведеться перетворювати
граматику вікна в граматику мови) (рис. 7.6).

103
 Рисунок 7.6 Приклад вікна яке читається: текст центрується
по лівому краю, рівень п'ятий, відступ зліва 3 см. справа 0 см
По-третє, воно повинне задовольняти великому закону «ре-
левантне вперед». Найчастіше використовувані елементи ма-
ють бути розташовані в лівій верхній частині екрану, рідше ви-
користовувані - в правій нижній частині. Зауважимо, що вікно
сканується поглядом точно так, як і відбувається процес чи-
тання - спочатку погляд переходить в лівий верхній кут, потім
переміщається вправо, потім переходить на наступний «рядок»
і так далі. Тому, наприклад, вертикальний елемент управління,
який розриває ці уявні рядки на частини, завжди уповільнюва-
тиме сканування вікна і викликатиме незадоволення у користу-
вачів.
Термінаційні кнопки мають бути розташовані внизу або
справа. Річ у тому, що в інтерфейсі завжди повинно бути реалі-
зовано правило: спочатку вибір параметрів, а потім дія. Пору-
шення цього правила істотно підвищує кількість людських по-
милок і послаблює відчуття контролю користувача (що загро-
жує низьким суб’єктивним задоволенням). Це правило, будучи
застосованим до діалогових вікон, примушує поміщати термі-
наційні кнопки знизу або справа, тобто в області, яка сканується
останньою.
7.3.1. Вкладки
Площа екрана обмежена, а кількість елементів управління,
які може знадобитися вмістити в єдиному функціональному
блоці (тобто вікні), не обмежено нічим. У цьому випадку дово-
диться використовувати вкладки. Щоб правильно їх використо-
вувати, потрібно дотримуватися певних вимог.
Окрім розміщення максимальної кількості елементів управ-
ління в діалоговому вікні, вкладки можуть виконувати ще одну
роль, а саме: обмежувати інформаційність недосвідчених кори-
стувачів про не дуже потрібну їм функціональність. У той са-
мий час коли потрібно умістити більше елементів виникає про-
блема приховування від користувачів можливо потрібної їм фу-
нкціональності.

104
 Колись у Windows були два способи помістити в діалогове
вікно більше, чим в нього могло вміститися. Можна було ско-
ристатися вкладками, а можна було натиснути на спеціальну
кнопку, яка збільшувала розмір вікна і відкривала приховані
елементи управління. У Microsoft ці кнопки не функціональні і,
починаючи з Windows 95, і компанія планомірно видалила їх з
всіх своїх продуктів, замінивши вкладками.
Діалогове вікно, представлене на (рис. 7.6), цікаве тим, що
для відкриття повного вікна користувачам доводилося декілька
разів натискати на кнопку. Це незручно, оскільки, щоб дізна-
тися про існування додаткових критеріїв пошуку, користувачам
доводилося здійснювати дуже багато дії. Недивно, що в остан-
ніх версіях MACOS ця утиліта була повністю перероблена.

Рисунок 7.6 Діалогове вікно, що збільшується. Зверху початковий

стан вікна, знизу - кінцеве. Натиснення на кнопку More Choices збільшує
вікно
Це і породило проблему. Раніше різні вкладки містили при-
близно однаково важливі елементи, просто не всі поміщалися в
105
одне вікно, а кнопка з трикутником приховувала елементи, про
які користувач-початківець напевно знав, що вони йому не пот-
рібні або користуватися ними небезпечно. Тепер користувач ча-
сто переконаний, що те що невидне відразу у вкладках небезпе-
чно.
У результаті деякі користувачі на початку уникають корис-
туватися елементами, розташованими на закритих вкладках, на-
віть якщо це нічим їм не загрожує. Тому небажано розміщувати
на закритих вкладках елементи, які користувачам обов'язково
знадобляться, навіть якщо ці елементи і не потрібні постійно. У
цьому випадку правило про релевантність повинно відступати.
В Інтернеті і в решті операційних систем, окрім Microsoft,
кнопки, що збільшують розмір вікна і відкривають елементи уп-
равління, збереглися в повному обсязі. Враховуючи той факт,
що жодних користувацьких проблем з ними не відмічено, мо-
жна рекомендувати їх і для використання в Windows, тим бі-
льше, що вони дозволяють добитися певного брэндингу.
Мicrosoft усвідомила шкоду від втрати вікон, що збільшу-
ються та почала використовувати дещо ускладнений елемент
управління Tree View, що також дозволяє затиснути багато еле-
ментів в обмежений простір. На жаль, Tree View, якщо вміщати
в нього додаткові елементи управління, вкрай незручний у ко-
ристуванні.
Теоретично число вкладок може бути скільки завгодно ве-
ликим. На практиці воно обмежується двома чинниками: по-пе-
рше. об'ємом КВН, а по-друге, розміром області, в які ярлики
вкладок можуть поміщатися. Справа в тому, що якщо ширина
всіх ярликів буде більше ширини вікна, доведеться або робити
декілька рядків ярликів, або приховувати частину з них, поки
користувач не натисне спеціальну кнопку.
Якщо користувач клацає по ярлику з верхнього ряду (рис.
7.7), весь цей ряд стає нижнім, а нижній переміщається вгору.
При цьому два рядки є зовсім не межа - іноді бувають діалогові
вікна з більшою кількістю рядів ярликів. Декілька рядків ярли-
ків погано з двох причин. По-перше, через велику кількість дрі-
бних деталей (меж ярликів), вся конструкція досить складно
сканується, тобто важко знайти потрібну вкладку. По-друге,
106
при послідовному зверненні до декількох вкладок з різних ря-
дів, ці ряди міняються місцями, тобто кожного разу потрібно
знову шукати потрібну вкладку. Все це вкрай негативно позна-
чається на суб'єктивному задоволенні і швидкості роботи.

Рисунок 7.7 Приклад декількох рядків ярликів

Приховувати частину ярликів також недоречно (рис. 7.8).
Нехай, користувач натиснув на стрілку вправо, що показує на-
ступну частину ярликів: якщо при цьому повністю перегорту-
ється рядок з ярликами, то користувач втрачає контекст; якщо
ж перегортувати рядок послідовно по одному елементу, то кон-
текст не загубиться, але переміщення між вкладками буде дуже
повільним.

107
 Рисунок 7.8 Приклад частково прихованих ярликів вкладок
Існує і третій спосіб вирішення проблеми. Можливо просто
прибрати вкладки, замінивши їх списком, що розкривається.
Цей спосіб теж не дуже результативний, оскільки не візуальний
і до того ж порівняно повільний.
Очевидно, що найефективнішим рішенням переміщення по
ярликам є комбінація другого і третього способів: основні ек-
рани реалізуються у формі вкладок, а додаткові викликаються
через список, що розкривається. Це дозволяє забезпечити мак-
симальну наочність і швидкість роботи.
Фактично, кожна вкладка є окремим діалоговим вікном усе-
редині іншого діалогового вікна. Тому дивними виглядають
спроби (що зустрічаються прикро часто) розсортувати елементи
управління так, щоб у всіх вкладках їх було порівну. Робити це
у жодному випадку не можна: один екран повинен містити
тільки ті елементи, які в ньому потрібні і які користувач може в
цьому екрані чекати.
7.3.2. Термінаційні кнопки
У діалоговому вікні з вкладками термініційні кнопки обов'-
язково повинні розташовуватися поза областю вкладок.
Окрім навігації між екранами, існує ще і навігація всередині
окремих екранів. Користувачам необхідно дати можливість ма-
ксимально швидко переходити до необхідних елементів управ-
ління. Для цього у них є два засоби - миша і клавіатура.
З мишкою все більш-менш зрозуміло: оптимізація інтер-
фейсу за законом Фітса. Тому оптимізація діалогового вікна, що
зменшує дистанцію переміщення курсору, завжди приводить до
зростання (хоч і незначному) продуктивності користувачів.
З клавіатурою складніше. Користувач може переміщатися
між елементами управління двома різними способами: кла-
вішею Tab і «гарячими» клавішами. Переміщення клавішею Tab
здійснюється поволі, зате для цього не потрібно звертатися до
108
пам'яті або шукати клавіатурну комбінацію для потрібного еле-
менту. Навпаки, «гарячі» клавіші дозволяють швидше перемі-
щатися вглибину екрану, але вимагають запам'ятовування кла-
віш. На практиці, користувачі, які часто вводять дані в будь-
який екран, прагнуть використовувати клавішу Tab і лише зрі-
дка користуються «гарячими» клавішами. Відповідно, будь-яка
форма введення, якою часто користуються, зобов'язана корек-
тно працювати з Tab, при цьому бажано, щоб вона працювала і
з «гарячими» клавішами.
Робота користувачів з клавішею Tab може бути ускладнена
з двох причин. По-перше, на екрані можуть бути елементи, що
не спрямовані на взаємодію з користувачем (наприклад, прихо-
вана або заблокована кнопка, поле виводу), але по яких перемі-
щення здійснюється. Позбавитися від цієї проблеми легко - по-
трібно лише явно вказати, щоб до списоку об'єктів, між якими
можна переміщатися, ОС їх не вносила. По-друге, бувають си-
туації, коли візуальний порядок елементів управління (що від-
бувається через те, що користувачі читають екрани) не збіга-
ється з порядком переміщення. У цьому випадку потрібно про-
сто змінити місце в послідовності переходу за елементами.
7.4. Майстри
Особливим варіантом вікон є дії, що виконуються за допо-
могою певної послідовності вікон, що змінюються одне за од-
ним. Ці дії називаються майстрами (рис. 7.9).
Для розуміння правил, що до них, корисно визначити при-
чини, які обумовили появу таких вікон.
По-перше, існують дії, для яких або притаманна, або ба-
жана жорстка послідовність. Для таких дій єдиний екран, в
якому виконується вся послідовність, не дуже ефективний: він
загрожує людськими помилками, до того ж, щоб його викорис-
товувати, вимагається побудувати ментальну модель екрану
(щоб, як мінімум, знати, що потрібно зробити на початку, а що
в кінці). Тому ефективніше розбити дію на декілька різних ек-
ранів.

109
 Рисунок 7.9 Приклад майстра
По-друге, існують дії, які завжди викликатимуть проблеми
у користувачів або тому, що ці дії складні, або тому, що вико-
ристовуються вони рідко (отже користувачам немає резону вчи-
тися). При цьому єдине вікно для виконання дії також виявля-
ється неефективним, оскільки обсяг довідкової інформації, яку
в нього потрібно вміщати, невеликий. У таких випадках розді-
лення дії на послідовність екранів дозволяє понизити насиче-
ність окремих екранів і тим самим звільнити місце для довідко-
вої інформації.
Як правило, одної причину досить, щоб виправдати вико-
ристання майстра. Коли ж діють обидві причини, майстер стає
обов’язковим. Отже, тепер, коли визначені причини виник-
нення майстрів, можна перейти до конкретних правил їх ство-
рення.

110
 Зрозуміло, що користувачі повинні мати можливість пере-
ходити не тільки на наступне вікно в послідовності, але й на по-
передні вікна. Менш очевидним є інша вимога до майстрів: пе-
рехід має бути максимально легким.
Завдання розкладається на дві складові: перша - потрібно
реалізовувати можливість вільного переміщення по послідовно-
сті. Якщо екранів небагато (3-5), то цілком можна обмежитися
стандартними кнопками Назад і Далі. Якщо ж екранів багато,
перехід по цих кнопках буде, як мінімум, повільним. У таких
випадках доцільно доповнювати кнопки списком (при цьому,
можливо, виключаючи з нього ще не пройдені екрани), що роз-
кривається, або, якщо є місце, забезпечувати майстра списком
всіх екранів (помічаючи поточний та пройдені екрани). Незале-
жно від числа екранів у послідовності, необхідно інформувати
користувачів про обсяг дії, що залишився (щоб дати їм можли-
вість оцінити кількість роботи і тим самим підвищувати їх від-
чуття контролю над системою). У довгих послідовностях показ
обсягу екранів, що залишився, може понизити мотивацію кори-
стувачів на початку дії, але підвищити мотивацію в кінці.
Друга складова - чіткість переходу. Для користувачів майс-
тер, тобто послідовність екранів, здається єдиним екраном,
вміст якого міняється. Цю ілюзію потрібно підтримувати, оскі-
льки вона дозволяє не збивати направленість дій користувача і
підтримувати увагу на «сюжетно-важливій» області екрану.
Для цього розмір і розташування вікна майстра, а також розта-
шування і зовнішність всіх елементів (таких як термінацінні
кнопки), що повторюються, потрібно витримувати незмінними
впродовж всієї послідовності.
Відміну від єдиного вікна, в якому виконується дія, в майс-
трах необхідно підтримувати контекст дій користувача. Оскі-
льки раніше зроблена робота прихована, користувачі можуть
втратити контекст, що може уповільнити дію (контекст дове-
деться відновлювати). Ступінь втрати контексту залежить від
кількості екранів, часу, який користувачі проводять за окре-
мими екранами і від часу реакції системи. У більшості існуючих
майстрів ОС кількість екранів іноді перевищує шість, але час,

111
проведений на пройдених екранах і, особливо реакція системи,
є досить значним.
Єдиним засобом підтримки контексту це є виведення пото-
чного стану даних в процесі виконання майстра. Як правило,
звичайний текстовий список із попередньо встановленими па-
раметрами працює погано (до того ж рідко вміщається в екран),
візуалізувати зміни важко, якщо взагалі можливо. Отже, краще
уникати довгих послідовностей (тим більше, що рівень мотива-
ції користувачів при збільшенні тривалості дії знижується).
Майстер чудово підходить до виведення довідкової інфор-
мації в самому інтерфейсі. Довідкову інформацію потрібно ви-
водити двох типів, а саме: короткий опис більш розгорнений
опис поточного кроку.
З розгорненим описом все просто. Будь-де внизу екрану
(щоб не збивати фокус уваги користувачів) виводиться один або
два абзаци, що надають стандартний набір інформації: що, на-
віщо і чому. З коротким описом складніше. На жаль, існуюче
представлення майстрів не має великого і помітного заголовка.
Наприклад, навіть такий прогресивний майстер, як використа-
ний в прикладі (рис. 7.9), не має явно помітного заголовку.
Шрифт дрібний, до того ж його розбірливість ослаблена фоном.
Закономірно, що біля кожного вікна послідовності має бути до-
бре видимий заголовок, який впадає у вічі. При цьому на від-
міну від звичайних заголовків вікна, він має бути написаний не
описово, а командно (зробіть те і те). Microsoft у деяких своїх
продуктах, що широко використовують майстра (називаючи це
спонукаючим призначеним для користувача інтерфейсом), вза-
галі рекомендує вважати заголовки за найважливіші елементи
майстрів. Особливо підкреслюється, що заголовки екранів по-
винні бути створені і сформульовані до початку проектування
екранів, при цьому вміст екранів не повинен виходити за рамки
сенсу заголовків.

112