Відмінності між версіями «Інтерфейси для майстрів»

Версія за 15:10, 13 грудня 2011

Нестабільність комп'ютерних інтерфейсів

А тепер найцікавіше. Як можна підвищити придатність до майстерності у комп'ютерних призначених для користувача інтерфейсів?

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

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

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

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

А тепер найцікавіше - стабільність.

Чи стабільні сучасні інтерфейси?

• Розбираються тільки Windows- інтерфейси

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

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

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

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

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

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

Що я повинен зробити в такій ситуації? Багато що:

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

Якби нове вікно відкрилося без крадіжки фокусу :

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

Контраст, на мій погляд, разючий.

Відробіток виняткових ситуацій

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

Розглянемо черговий приклад. Користувач заповнює форму і в полі вік вводить слово " Вася". Можливі декілька реакцій системи(залежно від кваліфікації її розробників; перераховані в порядку убування вірогідності) :

   Варіант 1. Як тільки користувач натискає на кнопку Зберегти, відкривається вікно із словами "В одне або декілька полів введена некоректна інформація(код помилки #F4567) ". Вікно краде фокус з форми.

   Варіант 2. Як тільки користувач, ввівши " Вася" переходить до наступного елементу форми, вискакує те ж саме вікно і так само краде фокус.
   .

   Варіант 9. Як тільки користувач натискає на кнопку Зберегти, форма перезавантажується; у новій формі згори написано, що "В одне або декілька полів введена некоректна інформація(код помилки #F4567) " і поле віку підсвічується червоним.

   Варіант 10. Як тільки користувач вводить символ " В", система показує йому поряд з полем пухир із словами "Сюди можна вводити тільки число(від 1 до 130) ". Фокус при цьому не воруется.

   Варіант 11. Спробувавши ввести символ" ", користувач виявляє, що ввести його неможливо. Після декількох спроб користувач вводить шуканий вік.

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

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

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

Як би добре користувач не володів мишею, будь-яка мишача операція по числу дій довше клавіатурної операції :

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

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

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

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

Мікроскопічні елементи управління

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

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

На мій погляд, мода робити все дрібним, що народилася в тисячоліття маленьких екранів, просто застаріла. Коли середньостатистичний монітор мав дозвіл 800*600, в ній був безперечний практичний сенс, але зараз, коли дозвіл 1024*768 є робочим мінімумом, малюсінькі елементи управління втратили усю свою чарівність.

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

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

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

   Модальні вікна переводять користувача в новий режим. Немодальні - збільшують кількість варіантів взаємодії, що не завжди добре(навіщо, питається, користувачеві змінювати розміри вікна, якщо його цей розмір вже влаштовує?).
   Недобре, якщо породжене вікно більше за розміром вікна, що породило його. Тобто виникнуть неминучі проблеми із забезпеченням компактності елементів управління(см вищий).
   Це рішення не універсальне, оскільки вікно може бути тільки одне: з вікна, що відкрилося, не можна викликати інше вікно(більше одного породженого вікна це mauvais ton).
   Нарешті, найголовніше: вікно розриває діяльність користувача. Спочатку користувач заповнював платежку, вікно ж тимчасово перекладе його на діяльність "створення контрагента". Цей розрив поганий сам по собі(діяльність потрібно берегти), але для стабільності він просто катастрофічний.

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

Наприклад:

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

У обох випадках вікна не потрібні.