3.2. Режими

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

Карла Дженнингз

Режими (modes) є важливим джерелом помилок, плутанини, непотрібних обмежень і складності в інтерфейсі. Багато роблем, створювані режимами, добре відомі. Проте , практика створення систем без режимів чомусь не знаходить широкого застосування в розробці інтерфейсів. Перш ніж приступити до обговорення методів усунення режимів, варто розглянути їхній докладно, тим більше що навіть серед фахівців з інтерфейсів немає загальної думки щодо того, що являє собою режим (Johnson and Engle-beck, 1989).

Щоб розуміти режими, нам варто спочатку визначити поняття жесту. Жест (gesture) - це послідовність дій людини, що виконується автоматично (після старту). Наприклад, для досвідченого користувача набір такого простого слова, як це, представляє всего один жест, у той час як для починаючого користувача, що ще не цілком опанував клавіатурою, набір цього слова по буквах буде складатися з окремих жестів. Об'єднання послідовності дій у жест, зв'язаний з визначеним психологічним процесом, визначається як формування модуля (chunkіng), тобто з'єднання окремих елементів когнітивного процесу в єдиний ментальний модуль, що дозволяє сприймати безліч елементів як ціле (Buxton ,1986, с. 475-480; Mіller, 1956).

У більшості інтерфейсів допускається кілька інтерпретацій конкретного жесту. Наприклад, в одному випадку за допомогою клавіші <Return> можна вставити в текст символ повернення каретки, тоді як в іншому випадку натискання цієї клавіші приводить до виконання попередньої рядка як команду.

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

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

До перемикачів важко підібрати напису. Наприклад, один раз мені показали інтерфейс, у якому кнопка на екрані була підписана Lock (Блокувати). Коли користувачі в перший раз бачили цю кнопку, вони вважали, що повинніо натиснути на неї для блокування даних у цьому вікні. Коли вони робили так, підпис кнопки змінювалася на Unlock (Розблокувати), показуючи, що при натисканні на цю кнопку дані розблокувалися б. Після цього багато користувачів дивувалися, що дані виявлялися разблокированными, оскільки кнопка показувала Unlock, що вони вважали індикатором поточного стану, як це часто буває при використанні перемикачів на кнопках і в меню. Природно, це приводило до плутанини: насправді кнопка показувала Lock, коли дані були разблокированы, і Unlock - коли вони були заблоковані. Очевидно, що проблему не можна вирішити, просто помінявши напис таким чином, щоб разблокированные дані позначалися як Unlock, а заблоковані як Lock.

У даному випадку випливає, по-перше, використовувати прапорець, а не кнопку, а по-друге, застосувати більш точні формулювання - Locked (Заблоковане) замість Lock (Блокування), що буде сприйматися більш правильно: якщо прапорець установлений, виходить, дані заблоковані, якщо ж прапорець скинутий - дані не заблоковані. Зміни підписів у цьому випадку не потрібно. Можна використовувати більш розгорнуте формулювання, наприклад: "Клацніть по цій кнопці, щоб розблокувати дані" чи навіть: "Дані в даний час заблоковані. Клацніть по цій кнопці, щоб розблокувати їх". Однак на чи кнопці біля прапорця, чи в меню важко розмістити повне пояснення, якщо інтерфейс не постачений функцією збільшення зображення (див. роздягнув 6.2).

Прапорці, проте , залишають неясним, які ще є альтернативи. Наприклад, якщо прапорець відзначений "Зберегти в архіві при закритті", те при закритті активного вікна дані будуть збережені в архіві. Однак з підпису не зрозуміло, що відбудеться, якщо цей прапорець скинутий. Дані будуть збережені десь в іншім місці? Чи не збережені взагалі? Чи при закритті вікна з'явиться ще якась опція? Найкращим рішенням у цій ситуації найчастіше виявляється використання набору перемикачів (мал. 3.1). Такі перемикачі не є модальними, і користувач може відразу визначити не тільки поточний стан, але й альтернативи. Незалежно від того, чи застосовуються чи прапорці перемикачі, важливо, щоб у назвах уживалися прикметники, що описують стан об'єкта, а не дієслова, що описують дію з цим об'єктом, тому що інакше користувачу не ясно, дія вже чи відбулася тільки повинне відбутися.

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

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

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

Іншу зв'язану з режимами труднощі, що особливо вимотують користувачів комп'ютерів, можна проілюструвати на прикладі того, як працює клавіша <Caps Lock>, що є присутнім на більшості типів клавіатур. Часто першою ознакою випадкового натискання цієї клавіші виявляється те, що ви зауважуєте, що набране вами пропозиція надрукована заголовними буквами, і тільки після цього ви зауважуєте також, що включено індикатор <Caps Lock> (якщо він є на клавіатурі). "Не випадково лайки позначаються у виді ланцюжка символів, на зразок #&%!#$&. Саме така картина виникає, коли хтось набирає цифри при помилково натиснутій клавіші <Caps Lock>", - затверджує мій колега доктор Джеймс Уинтер (особисте повідомлення, 1998).

Кілька десятиліть назад Ларри Кларк помітив, що режими створюють проблеми з тієї причини, що звичні дії приводять до несподіваних результатів (dark, 1979).10 Найбільше часто пропонований засіб проти помилок, породжуваних режимами, полягає в тому, щоб ясним образом показувати користувачу поточне стан системи. Доктор Дональд Норман охарактеризував помилки, зв'язані з режимами, як результати недостатнього зворотного зв'язку, здійснюваної індикатором стану системи (Norman, 1983). Однак, на мій погляд, щирою причиною є не недостатній зворотний зв'язок, а те, що цей індикатор не знаходиться в локусі уваги користувача.

Особливо показовий приклад невдалого застосування індикатора, що відбиває поточне стан системи, можна зустріти в інтерфейсі системи автоматизованого проектування (САПР) (computer-aіded desіgn, CAD) Vellum (Ashlar, 1995), у всіх інших відносинах чудовому. Усім, хто займається розробкою графічних пакетів, я настійно рекомендую вивчити програму Draftіng Assіstant, розроблену Ashlar. Ця програма оснащена надзвичайно зручним інтерфейсом, набагато більш ефективним і приємної у використанні, чим той, котрий застосовується в більш відомому пакеті AutoCAD.11 Однієї з функцій, передбачених для економії часу в пакеті Vellum, є покажчик, що може випливати по внутрішній чи зовнішній стороні геометричної фігури, виділяючи (трасуючи) описувану границю. Щоб перейти в режим трасування, необхідно клацнути по відповідній кнопці палітри інструментів, при цьому стандартний курсор перетвориться в курсор особою, "вказівної" форми . По завершенні виділення легко забути переключитися назад, до стандартного курсору. Виділення за допомогою миші є настільки частою дією, що для мене воно вже давно стало автоматичным, і тому коли в цій програмі я клацаю, щоб виділити якийсь об'єкт після операції трасування, то замість успішного виділення я з подивом виявляю, що обведений покажчиком контур зникає. Я роблю цю помилку вже не перший рік, так само як і інші користувачі, з якими мені приходилося говорити про це. Хоча іноді я і ловлю себе на думці, що роблю неправильно, але все-таки я ніколи не зможу навчитися завжди зауважувати, що знаходжуся в режимі трасування, тому що виділення за допомогою миші, для мене у всякому разі, є автоматичным дією. У локусі моєї уваги знаходиться об'єкт виділення, але не форма курсору. Курсор, що змінюється, використовуваний у Vellum, - це один з безлічі прикладів, що підтверджують, що засобу зворотного зв'язку й індикатори поточного положення недостатні, щоб забезпечити усунення помилок, викликуваних режимами, навіть у тому випадку, коли індикатор розташований у безпосередній близькості від локусу вашої уваги. Він може попадати в область високої зорової здатності, наприклад, коли індикатором служить курсор, і проте , ви не зможете помітити повідомлення, передане цим індикатором, оскільки він не знаходиться в локусі вашої уваги. Необхідною темою для майбутніх досліджень повинне стати визначення частоти помилок, зв'язаних з режимами, і з'ясування умов, що впливають на частоту їхнього виникнення.

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

Приведемо інший приклад. У деяких популярних моделях комп'ютерів для створення нового документа застосовується наступне сполучення клавіш:

Command? n?? ?

Тут n позначає новий (new). Але якщо взяти пакет електронної пошти Amerіca Onlіne, те в ньому для одержання нового бланка повідомлення потрібно використовувати іншу комбінацію клавіш:

Command? m?? ?

Я припускаю, що m тут позначає пошта (maіl). Помилка, що роблять користувачі при створенні нового повідомлення, полягає в натисканні невірної комбінації клавіш:

Command? n?? ?

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

Норман (1983) указує три методи запобігання модальних (тобто зв'язаних з режимами) помилок:

1. Не використовувати режими.

2. Забезпечити чітке розходження між режимами.

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

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

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