1. Використовуйте обмежену кількість кольорів. Для вікон не слід використовувати більше чотирьох або п'яти різних кольорів, в інтерфейсі системи не повинно бути більше семи кольорів.

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

3. Для допомоги користувачеві використовуйте колірне кодування. Якщо користувачам необхідно виділяти аномальні елементи, виділите їх кольором; якщо потрібно знайти подібні елементи, виділите їх однаковим кольором.

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

5. Обережно використовуйте доповнюючі кольори. Фізіологічні особливості людського ока не дозволяють одночасно сфокусуватися на червоному і синьому кольорах. Тому послідовність червоних і синіх зображень викликає зорова напруга. Деякі комбінації кольорів також можуть візуально порушувати або утрудняти читання.

Найчастіше розробники інтерфейсів допускають дві помилки: прив'язка значення до певного кольору і використання великої кількості кольорів на екрані. Використовувати кольори для представлення значення не слід по двох причинах. Близько 10% людей мають нечітке уявлення про кольори і тому можуть неправильно інтерпретувати значення. У різних груп людей різне сприйняття кольорів; крім того, в різних професіях існують свої угоди про значення окремих кольорів. Користувачі на підставі отриманих знань можуть неадекватно інтерпретувати один і той же колір. Наприклад, водієм червоний колір сприймається як небезпека. А у хіміка червоний колір означає гарячий.

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

5. Засоби підтримки користувача

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

* повідомлення, що генеруються системою у відповідь на дії користувача;

* діалогова довідкова система;

* документація, що поставляється з системою.

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

Таблиця 5. Чинники проектування текстових повідомлень

5.1. Повідомлення про помилки

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

Новачки і досвідчені користувачі повинні передбачати ситуації, при яких можуть виникнути повідомлення про помилки. Наприклад, хай користувачем системи є медсестра госпіталю, що працює у відділенні інтенсивної терапії. Обстеження пацієнтів виконується на відповідному устаткуванні, пов'язаному з обчислювальною системою. Щоб проглянути поточний стан пацієнта, користувач системи вибирає пункт меню Показати і набирає ім'я пацієнта в полі введення (мал. 15.9).

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

На мал. 15.10 показані приклади двох повідомлень про помилку. Повідомлення, розташоване зліва, спроектоване погано. Воно негативне (звинувачує користувача в здійсненні помилки), не адаптоване до рівня знань і досвідченості користувача, не враховує змісту помилки. У цьому повідомленні не пропонуються способи виправлення ситуації, що склалася. Крім того, в повідомленні використані специфічні терміни (номер помилки), не зрозумілі користувачеві. Повідомлення справа набагато краще. Воно позитивне, в нім використовуються медичні терміни і пропонується простій спосіб виправлення помилки за допомогою клацання на одній з кнопок. У разі потреби користувач може викликати довідку.

5.2. Проектування довідкової системи

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

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

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

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

Мал. 15.11. Точки входу в довідкову систему

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

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

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

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

Довідкову систему можна реалізувати у вигляді групи зв'язаних Web-страниц або за допомогою узагальненої гіпертекстової системи, інтегрованої з додатком. Ієрархічна структура легко реалізується у вигляді гіпертекстових посилань. Web-системы мають переваги: вони прості в реалізації і не вимагають спеціального програмного забезпечення. Проте при створенні контекстно-залежної довідки можуть виникнути труднощі при пов'язанні її з додатком.

5.3. Документація користувача

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

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

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

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

3. Ввідне керівництво, що представляє неформальне введення в систему, що описує її "повсякденне" використання. У цьому документі повинна міститися інформація про те, як почати роботу з системою, як використовувати загальні можливості системи. Всі описи повинні бути забезпечені прикладами і містити відомості про те, як відновити систему після помилки і як почати наново роботу. У книзі [68] запропонований ефективний спосіб складання ввідного керівництва, при якому основна увага приділена відновленню системи після помилок, а решта всієї інформації, необхідної користувачам, зводиться до мінімуму.

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

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

Мал. 13. Типи призначеної для користувача документації

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

5.4. Оцінювання інтерфейсу

Це процес, в якому оцінюється зручність використання інтерфейсу і ступінь його відповідності вимогам користувача. Таким чином, оцінювання інтерфейсу є частиною загального процесу тестування і атестації систем ПІВ

У ідеалі оцінювання повинне проводитися відповідно до показників зручності використання інтерфейсу, перерахованих в табл. 15.5. Кожен з цих показників можна оцінити чисельно. Наприклад, вивченість можна оцінити таким чином: досвідчений оператор після тригодинного навчання повинен уміти використовувати 80% функціональних можливостей системи. Проте частіше зручність використання інтерфейсу оцінюється якісно, а не через числові показники.

Таблиця 5. Показники зручності використання інтерфейсу

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

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

1. Анкети, в яких користувач дає оцінку інтерфейсу.

2. Спостереження за роботою користувачів з подальшим обговоренням їх способів використання системи при вирішенні конкретних завдань.

3. Відеоспостереження типового використання системи.

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

Анкетування користувачів - відносно дешевий спосіб оцінки інтерфейсу. Питання повинні бути точними, а не загальними. Не слід використовувати питання типу "Будь ласка, прокоментуйте практичність системи", оскільки відповіді, ймовірно, істотно розрізнятимуться. Краще ставити конкретні питання, наприклад: "Оціните зрозумілість повідомлень про помилки за шкалою від 1 до 5. Оцінка 1 означає повністю зрозуміле повідомлення, 5 - малозрозуміле". На такі питання легко відповісти і ймовірніше отримати в результаті корисну для поліпшення інтерфейсу інформацію.

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

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

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

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

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

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

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

КЛЮЧОВІ ПОНЯТТЯ

* Процес проектування інтерфейсу повинен орієнтуватися на користувача. Інтерфейс повинен взаємодіяти з користувачем на його «мові», бути логічним і послідовним. У інтерфейсі повинні бути довідкові засоби, що допомагають користувачам при роботі з системою, і засоби відновлення після помилок.

* Існує декілька стилів взаємодії з програмними системами: безпосереднє маніпулювання, системне меню, заповнення форми, командні мови і природна мова.

* Для відображення тенденцій числових даних і їх приблизних значень слід використовувати графічні уявлення. Числове уявлення повинне застосовуватися тільки тоді, коли потрібно відобразити точні значення даних.

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

* Повідомлення про помилки не повинні містити звинувачень в адресу користувача. Вони повинні пропонувати варіанти виправлення помилки і забезпечувати зв'язок з довідковою системою.

* У документації користувача повинне бути керівництво для початкуючих і досвідчених користувачів. Для системного адміністратора повинні бути окремі документи.

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

Страницы: 1, 2, 3