людинно-машинна взаємодія / HCI_Labs / HCI_lab10

1

Лабораторна робота №10

Тема: Сучасні інструменти проектування користувацьких інтерфейсів.

Мета: Ознайомиться із сучасними системами проектування користувацьких інтерфейсів. Навчитися створювати основні компоненти інтерфейсу з урахуванням ергономічних вимог.

Теоретичні відомості

Загальні вимоги до проектування інтерфейсів

Ергономіка (від др. -грец. ἔργον — «робота» и νόμος — «закон» ) – у

традиційному розумінні наука про пристосування посадових обов’язків,

робочих місць, обладнання та комп’ютерних програм для найбільш безпечної та ефективної праці робітника, виходячи з фізичних та психічних особливостей людського організму.

Більш широке визначення ергономіки прийнято в 2010 році Міжнародною Організацією Ергономіки (IEA). Звучить так: «Наукова дисципліна, яка вивчає взаємодію людини та інших елементів системи, а

також сфера діяльності що до застосування теорії, принципів, даних і методів цієї науки для забезпечення благополуччя і оптимізації загальної продуктивності системи».

Оскільки існує велика кількість правил норм та законів проектування користувацьких інтерфейсів – неможливо привести навіть приблизний перелік вимог до створення інтерфейсу. Але існують узагальнені правила, які необхідно застосовувати в процесі розробки. Одним з таких наборів є евристичні правила Якоба Нільсена

:

2

Видимість стану системи (правило зворотного зв'язку). Система (в

даному випадку - комп'ютерна програма) повинна завжди інформувати користувача про стан своєї роботи за допомогою відповідних засобів, в

розумний час. При розгляді цього правила потрібно враховувати кілька аспектів:

Інформованість користувача. Користувач завжди повинен мати інформацію про поточний статус роботи програми – наприклад, скільки часу пройшло від початку процесу копіювання файлів, коли буде завершено кодування звукової доріжки CD-диска в МРЗ-файл і т. п. Крім цього,

користувач обов'язково повинен бачити, до чого призвела будь-яка його дія:

введення даних, натискання кнопки і т. п.

Засоби забезпечення зворотного зв'язку. Вибір конкретного засобу зворотного зв'язку залежить від типу інформації, яку потрібно донести до користувача, а також типу дії, яке викликає потребу в зворотному зв'язку.

Що стосується залежності вибору засобу зворотного зв'язку від типу дії,

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

Часто реакція на одну і ту ж дію розрізняється в залежності від того, ким ця дія зроблена. Наприклад - функція автоматичного завантаження своїх нових версій через Інтернет наявна в багатьох програмах. Якщо користувач самостійно віддає команду перевірити наявність оновлень, то звичайно після цього користувачеві демонструється діалогове вікно, де відображаються результати перевірки - незалежно від того, були результати перевірки негативними чи позитивними. Якщо ж така перевірка виконується

3

автоматично (наприклад, при кожному запуску програми), то зазвичай користувачеві повідомляється інформація, що виявлена нова версія продукту.

Повідомлення про те, що нова версія програми не знайдена, або повідомлення про помилки зазвичай не виводяться, щоб не відволікати користувача від роботи і не дратувати його.

Окрім текстових повідомлень, які виводяться у вікні програми, для організації зворотного зв'язку можуть бути використані і інші засоби.

Найпопулярніше з них - звук. Звукове сповіщення може бути корисним в самих різних ситуаціях. Також звуковий супровід надасть допомогу користувачам з обмеженими можливостями (наприклад, з поганим зором).

Важливо пам'ятати, що звукове сповіщення не повинно бути основним засобом організації зворотного зв'язку. Звук повинен лише доповнювати текстові повідомлення.

Серед інших засобів організації зворотного зв'язку можна згадати запис повідомлень в log-файл, відправку повідомлень по e-mail. Природно, вони застосовуються в якості додаткових способів оповіщення - наприклад, для збору статистики або доступу віддалених користувачів, що підключаються до системи по каналах зв'язку.

Час оповіщення. Проміжок часу, в який користувач отримує інформацію про реакцію на його дію або про подію, повинен бути мінімальним. Це особливо важливо, тому що від наявності або відсутності у користувача інформації про поточний стан системи визначає його подальші дії. Якщо він не буде знати, що остання операція була завершена невдало, то подальші дії можуть викликати нові помилки.

При розробці більшості додатків забезпечення миттєвої реакції на події та дії користувача не представляє ніякої складності. Проте в деяких випадках це може бути складним. Наприклад, багато користувачів просять доповнити існуючий Web-інтерфейс e-mail-інтерфейсом – тобто можливістю управляти системою за допомогою повідомлень електронної пошти. Технічна реалізація цього не представляє ніякої складності, однак це ставить під загрозу

4

стабільність роботи системи. Справа в тому, що при управлінні серверним програмним забезпеченням за допомогою e-mail, минає чимало часу між моментом відправки листа і моментом його обробки на сервері. При виявленні помилки (наприклад, запит користувача був сформульований неправильно) сервер висилає користувачеві лист, який буде отримано користувачем ще через деякий час. Таким чином, час оповіщення стає занадто великим, щоб можна було впевнено працювати зі складним серверним додатком, де будь-яка операція повинна здійснюватися тільки з урахуванням того, що всі попередні завершені успішно.

Рівність між системою і реальним світом. Система повинна розмовляти з користувачем на його мові. Мається на увазі не мову його країни, хоча це теж має значення. У даному випадку мається на увазі використання понять, образів і цілих концепцій, які вже знайомі користувачеві по реальному світу, до яких він звик. Представлення інформації і об'єктів у програмі має бути організовано в природному і логічному порядку.

Ні в якому разі не можна використовувати спеціалізовані терміни.

Багато авторів навіть при розробці додатків, орієнтованих на широку аудиторію, застосовують поняття, які годяться тільки для професійних довідників з програмування.

Найпоширеніший приклад реалізації цього принципу - побудова інтерфейсів, що імітують об'єкти реального світу. Годинники, калькулятори,

програвачі компакт-дисків, записні книжки - більшість із програм, що здійснюють ці функції, виглядають майже так само, як їхні матеріальні аналоги

Однак таке запозичення ідей з навколишнього світу потрібно робити дуже обережно. Справа в тому, що програми, які вже знайомі користувачеві -

теж частина його світу, частина його знань, навичок і звичок. Тому деякі деталі комп'ютерних інтерфейсів є для користувачів більш звичними, ніж об'єкти реального світу - це особливо стосується елементів інтерфейсу, що

5

реалізують функції, які не мають прямих аналогів у реальному світі. Як приклад можна навести відомий мультимедійний програвач WinAmp. Для управління відтворенням музичних композицій програма використовує кнопки Play, Stop, Pause і ін, дуже нагадують аналогічні за призначенням кнопки на програвачах, що стоять в наших квартирах. Але от кнопка,

розташована праворуч від них, яка на "справжньому" апараті відкриває лоток

CD-плеєра, в WinAmp, всупереч очікуванням, не відкриває лоток CD-ROM-

дисководу, а викликає вікно Відкрити файл. Це дещо збиває з пантелику,

тому що в дуже багатьох аналогічних комп'ютерних програмах така кнопка якраз служить для відкриття / закриття лотка дисковода CD-ROM.

Тому інтерфейси, які повністю, тобто без будь-яких винятків, копіюють об'єкти реального світу, майже завжди в результаті виходять не дуже зручними, тому що користувач витрачає досить багато часу, намагаючись освоїти абсолютно новий інтерфейс. Наприклад, експеримент компанії IBM в

області інтерфейсів, які використовують в якості своєї основи моделі реальних матеріальних об'єктів - програма RealPhone, вважається повним провалом: число проблем, що виникають при освоєнні "реального телефону",

дуже велике.

Свобода дій користувача. Користувач повинен мати контроль над системою і можливість змінити поточний стан програми. Дуже часто користувач дає різні команди помилково (наприклад, випадково натиснувши ту кнопку або "промахнувшись" мишею повз потрібного пункту меню), і у нього повинен бути "аварійний вихід" з цієї ситуації, чітко позначений у програмі. Найчастіше такий "вихід" реалізується у вигляді кнопки Cancel (Скасувати), розташованій в діалоговому вікні і дозволяє припинити виконання поточної операції або закрити це діалогове вікно. Крім цього,

натискання на клавіші Клавіатурі <Escape> є традиційним і тому звичним для більшості користувачів засобом "аварійного виходу". Характерно, що

"escape" у перекладі з англійської означає "втеча, догляд". Вона також незамінна тоді, коли кнопка Cancel (Скасувати) недоступна - найчастіше за

6

все в Головному вікні програми, адже розміщення кнопок OK, Cancel, Help і

інших тут, на відміну від діалогових вікон, не допускається. Зокрема, Microsoft Word при виконанні трудомістких і тривалих за часом операцій,

наприклад читання дуже великих файлів, виводить у рядок стану індикатор,

що відображає хід процесу і повідомлення:

"Для скасування натисніть <Escape>. Клавіша <Escape> аналогічно працює і в Adobe Photoshop, дозволяючи перервати завантаження великого файлу або виконання складного фільтра, і в багатьох інших додатках.

Гарним тоном вважається, якщо дозволяє поточна ситуація, поєднувати обидва ці способи - кнопку Cancel (Скасувати) і клавішу <Escape> : Сучасні системи розробки додатків для Windows при проектуванні форм діалогових вікон дозволяють призначити кнопці властивість спрацьовування при натисканні клавіші <Escape>. Як наслідок, для користувача звичайною дією при попаданні в ситуацію, з якої йому скоріше хочеться вибратися, є саме натискання клавіші <Escape>. Що може бути простіше: не потрібно шукати очима якусь там кнопку Cancel (Скасувати), досить вдарити по клавіші у верхньому лівому куті клавіатури - і готово!

Ще один, причому важливий, засіб виходу з помилкової ситуації -

функції Undo (Скасувати) і Redo (Повторити). Вони є настільки зручними і підтримуються такою великою кількістю програм, що користувачі вже звикли до них і підсвідомо очікують, що будь-яке вироблене дію можна відмінити, повернувшись до попереднього стану. Функція Undo (Повторити)

навіть стала предметом багатьох жартів та історій про те, як звик до комп'ютера людина, в реальному світі розбивши далеко не віртуальну вазу,

або зробивши помилку в простому, "паперовому", листі, мимоволі шукає кнопку Undo (Скасувати).

Все це просто зобов'язує розробника якісного інтерфейсу комп'ютерної програми підтримувати функції Undo і Redo. Якщо ж з яких-небудь причин дію, на виконання якого дав команду користувач, не можна буде скасувати,

7

то на екран повинне буде виведено відповідне попередження, а також прохання підтвердити виконання команди.

Послідовність і стандарти. Принцип послідовності означає використання одних і тих же засобів для вираження схожих образів і виконання дій, що мають однакову природу. Принцип послідовності при розробці інтерфейсів повинен дотримуватися буквально у всьому.

По-перше, послідовність при виборі засобів оповіщення про події і дії.

Наприклад, інформація про поточний статус програми, як вже говорилося при розгляді принципу "Видимість стану системи", звичайно виводиться в статусному рядку у нижній частині екрана, а повідомлення з результатами запитів користувача - в окремому діалоговому вікні. Повідомлення про критичні помилки при цьому повинні сильно відрізнятися від звичайних інформаційних повідомлень: наприклад, вони можуть супроводжуватися різким звуком.

По-друге, послідовність при оформленні елементів інтерфейсу. Якщо дизайн форм вашої програми заснований на класичному інтерфейсі Windows-

додатків, що характеризується строгою колірною гамою, прямими лініями та кутами, то дуже дивним виглядало би рішення надати одному з вікон програми овальну форму і розфарбувати його яскравими квітами. На жаль,

але такі випадки не рідкість.

По-третє, послідовність при виборі термінів. Користувачів не повинно збивати з пантелику те, що три різні поняття, що використовуються у вашій програмі, на самому ділі означають одне і те ж. І справа навіть не в тому, щоб підібрати найбільш точне визначення якого-небудь терміну. Головне -

вирішити для себе, що для позначення якогось конкретного дії або події ви будете застосовувати один конкретний термін, при цьому будете використовувати його чітко певним способом (наприклад, слово "Інтернет"

ви будете писати з великої літери і схиляючи),і в ході роботи над програмою від цього правила не відступати.

8

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

Попередження помилок. Цей принцип широко поширений і в звичайному житті, поза сферою комп'ютерів та інтерфейсів для них.

"Пожежу легше попередити, ніж загасити" - був такий один з плакатів,

виданих наприкінці дев'яностих років Міністерством внутрішніх справ для навчання людей техніці пожежної безпеки. "Злочин легше попередити, ніж розкрити" - говорить одне з правил науки кримінології.

Стосовно теми проектування інтерфейсів комп'ютерних програм,

принцип попередження помилок означає наступне: "Дизайн, який попереджає виникнення проблем, краще, ніж саме хороше повідомлення про помилку".

Інтерфейс, що попереджає виникнення помилок і пов'язаних з ними проблем, образно називають "послужливим". Програма, як би піклується про користувача, будучи завжди готовою запропонувати користувачеві допомогу,

дати підказку.

Крім того, зменшення ймовірності виникнення помилок користувача при роботі з програмою досягається ретельною обробкою всіх елементів інтерфейсу і його концепції в цілому відповідно до правил проектування інтерфейсів. Інтуїтивно зрозумілий, легкий для освоєння інтерфейс у більшості користувачів не викликає ніяких труднощів.

Принцип попередження помилок, хоча й згадується Якобом Нільсеном в списку його евристичних правил п'ятим за рахунком, на мою думку, повинен

9

бути зазначений в ньому останнім, тому що він має значення принципу,

узагальнюючого всі інші правила. Адже інтерфейс, що попереджає виникнення помилок і проблем, повинен інформувати користувача про статус програми, давати йому контроль над роботою додатка, спілкуватися з користувачем на зрозумілій йому мові, відповідати принципу послідовності і т. д.

Розуміння краще, ніж запам'ятовування. При розробці інтерфейсу потрібно робити всі об'єкти, функції, дії видимими і легко доступними користувачеві. Мінімізуйте запам'ятовування - користувач не повинен постійно намагатися утримати в пам'яті інформацію з однієї частини програми, щоб застосувати її в іншій. У будь-який момент користувачу повинно бути ясно, що потрібно робити в даний момент. У хорошому інтерфейсі інструкції з використання системи завжди видимі чи легко доступні для виклику в будь-який час, коли це потрібно. Це може бути реалізовано як у вигляді продуманої організації елементів інтерфейсу, так і безпосередньо у вигляді підказок користувачеві. Хороший і дуже відомий приклад - анімований напис, який з'являється на панелі завдань Windows і "під'їжджає" до кнопки Пуск:

"Почніть роботу з натискання цієї кнопки".

Це правило відображає принцип прозорого інтерфейсу - інтерфейсу,

який зрозумілий і не змушує користувача згадувати, яку ж кнопку потрібно натиснути або який пункт меню вибрати в даний момент.

Гнучкість і ефективність використання. Правило цілком закономірне, адже програма в першу чергу повинна вирішувати задачу, над якою працює користувач. Однак при проектуванні інтерфейсу перед розробником часто постає така проблема: потрібно, щоб інтерфейс був однаково зручний і для новачків, і для досвідчених користувачів. Але потрібно враховувати, це багато в чому різні споживачі, з різними вимогами до програми та різним стилем роботи. Якщо зробити простий інтерфейс з мінімумом опцій, який буде легкий для освоєння новачками, то більш

10

досвідчені користувачі не зможуть працювати з програмою досить ефективно, щоб задовольняти свої потреби.

Для вирішення цієї проблеми вдаються до простого прийому: функції,

які прискорюють роботу, оформлені так, що вони не видно початківцям, але легко доступні просунутим користувачам. Найпростіший приклад - це "гарячі клавіші", за допомогою яких можна швидко викликати часто виконуються функції програми, зокрема відкриття і збереження файлів. Позначення

"гарячих клавіш" пишуться поруч з відповідними пунктами меню, тому вони,

з одного боку, не заважають новачкам (вони можуть скористатися мишею для вибору пункту меню або натиснути кнопку на панелі інструментів), а, з

іншого боку, легко доступні досвідченим користувачам .

Розробники системи програмування Microsoft Quick Basic, яка була дуже популярна ще у вісімдесятих і на початку дев'яностих років, пішли ще далі:

вони передбачили два варіанти головного меню програми: повний і скорочений, між якими можна перемикатися одним клацанням.

Інший приклад реалізації універсального "інтерфейсу для кожного" -

можливість виконати складні функції програми як з допомогою Майстра,

який, немов за руку, проведе починаючого користувача по всіх етапах процесу, так і в ручну, за допомогою настройки опцій у відповідному діалоговому вікні.

Ще одна складова частина правила "Гнучкість і ефективність використання" - необхідність надавати користувачеві можливість швидкого виконання частих дій. Варіанти реалізації цього дуже різноманітні: це і вже згадувані "гарячі клавіші", і команди для виклику останніх відкритих файлів,

і меню, у яких спочатку показуються найбільш часто виконуються команди, і

макроси, і навіть цілі мови програмування, що вбудовуються в додатки,

зразок Visual Basic for Applications в продуктах сімейства Мicrosoft Office.

Естетичний і мінімалістичний дизайн. Якщо висловитися простіше,

то це правило означає: "Нічого зайвого". Не потрібно захаращувати інтерфейс програми елементами, які в даному випадку є недоречними і