Інтерфейси для майстрів

Матеріал з Вікі ЦДУ
Версія від 15:30, 13 грудня 2011; Nopasha (обговореннявнесок)

(різн.) ← Попередня версія • Поточна версія (різн.) • Новіша версія → (різн.)
Перейти до: навігація, пошук

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

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

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

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

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

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

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

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

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

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

Фокус

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Варіант 1. Як тільки користувач натискає на кнопку Зберегти, відкривається вікно із словами "В одне або декілька полів введена некоректна інформація(код помилки #F4567) ". Вікно краде фокус з форми.
  • Варіант 2. Як тільки користувач, ввівши " Вася" переходить до наступного елементу форми, вискакує те ж саме вікно і так само краде фокус.
...
  • Варіант 9. Як тільки користувач натискає на кнопку Зберегти, форма перезавантажується; у новій формі згори написано, що "В одне або декілька полів введена некоректна інформація(код помилки #F4567) " і поле віку підсвічується червоним.
  • Варіант 10. Як тільки користувач вводить символ " В", система показує йому поряд з полем пухир із словами "Сюди можна вводити тільки число(від 1 до 130) ". Фокус при цьому не воруется.
  • Варіант 11. Спробувавши ввести символ" ", користувач виявляє, що ввести його неможливо. Після декількох спроб користувач вводить шуканий вік.

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

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

Ігнорування клавіатури

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

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

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

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

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

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

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

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

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

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

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

Зловживання вікнами

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

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

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

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

Наприклад:

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

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