Відмінності між версіями «Інтерфейси для майстрів»
Nopasha (обговорення • внесок) |
Nopasha (обговорення • внесок) |
||
(не показані 4 проміжні версії цього учасника) | |||
Рядок 1: | Рядок 1: | ||
==Нестабільність комп'ютерних інтерфейсів== | ==Нестабільність комп'ютерних інтерфейсів== | ||
− | + | Як можна підвищити придатність до майстерності у комп'ютерних призначених для користувача інтерфейсів? | |
− | Нагадаю, що в цілому цьому сприяють | + | Нагадаю, що в цілому цьому сприяють: |
− | + | *практика | |
− | + | *невимогливість до здібностей користувача | |
− | + | *автоматизація | |
− | + | *допомога майстра, що відбувся | |
− | + | *стабільність. | |
Практику і автоматизацію нам розглядати немає чого. Невимогливість до здібностей користувача, навпаки, вимагає деякого розбору. З одного боку, комп'ютерні інтерфейси мають тут великий плюс - вони абсолютно невимогливі до мускульної сили користувача. З іншої - вимагають хорошого зору і розвиненої тонкої моторики. В цілому, проте, це питання повинне нас хвилювати, тільки якщо проектований інтерфейс створюється для людей, близьких до літнього віку, - у них і зір і моторика, як правило, помітно погіршені. Осібно коштують вимоги до пильності - здатність до неї у різних людей сильно варіюється і якщо інтерфейс вимагає високої пильності, ви зобов'язані або передбачити максимум можливих перевірок на помилки, або, якщо це бізнес-система, прописати кваліфікаційні вимоги до користувачів. | Практику і автоматизацію нам розглядати немає чого. Невимогливість до здібностей користувача, навпаки, вимагає деякого розбору. З одного боку, комп'ютерні інтерфейси мають тут великий плюс - вони абсолютно невимогливі до мускульної сили користувача. З іншої - вимагають хорошого зору і розвиненої тонкої моторики. В цілому, проте, це питання повинне нас хвилювати, тільки якщо проектований інтерфейс створюється для людей, близьких до літнього віку, - у них і зір і моторика, як правило, помітно погіршені. Осібно коштують вимоги до пильності - здатність до неї у різних людей сильно варіюється і якщо інтерфейс вимагає високої пильності, ви зобов'язані або передбачити максимум можливих перевірок на помилки, або, якщо це бізнес-система, прописати кваліфікаційні вимоги до користувачів. | ||
Рядок 17: | Рядок 17: | ||
==Чи стабільні сучасні інтерфейси?== | ==Чи стабільні сучасні інтерфейси?== | ||
− | + | <p style="text-align:right;">Розбираються тільки Windows- інтерфейси</p> | |
Коротка відповідь - ні. Щоб отримати повний, необхідно розібрати головні причини їх нестабільності*, а саме фокус, що змінюється, маловдалий відробіток виняткових ситуацій, ігнорування клавіатури, велику кількість мікроскопічних елементів управління і зловживання вікнами. | Коротка відповідь - ні. Щоб отримати повний, необхідно розібрати головні причини їх нестабільності*, а саме фокус, що змінюється, маловдалий відробіток виняткових ситуацій, ігнорування клавіатури, велику кількість мікроскопічних елементів управління і зловживання вікнами. |
Поточна версія на 15:30, 13 грудня 2011
Зміст
Нестабільність комп'ютерних інтерфейсів
Як можна підвищити придатність до майстерності у комп'ютерних призначених для користувача інтерфейсів?
Нагадаю, що в цілому цьому сприяють:
- практика
- невимогливість до здібностей користувача
- автоматизація
- допомога майстра, що відбувся
- стабільність.
Практику і автоматизацію нам розглядати немає чого. Невимогливість до здібностей користувача, навпаки, вимагає деякого розбору. З одного боку, комп'ютерні інтерфейси мають тут великий плюс - вони абсолютно невимогливі до мускульної сили користувача. З іншої - вимагають хорошого зору і розвиненої тонкої моторики. В цілому, проте, це питання повинне нас хвилювати, тільки якщо проектований інтерфейс створюється для людей, близьких до літнього віку, - у них і зір і моторика, як правило, помітно погіршені. Осібно коштують вимоги до пильності - здатність до неї у різних людей сильно варіюється і якщо інтерфейс вимагає високої пильності, ви зобов'язані або передбачити максимум можливих перевірок на помилки, або, якщо це бізнес-система, прописати кваліфікаційні вимоги до користувачів.
Допомога майстра, що відбувся, навпаки, значно ширше, але тут говорити про неї не місце. Досить сказати, що найрозумніше, на мій погляд - узяти на себе обов'язки майстра і помістити повчальні матеріали безпосередньо в інтерфейсі.
А тепер найцікавіше - стабільність.
Чи стабільні сучасні інтерфейси?
Розбираються тільки Windows- інтерфейси
Коротка відповідь - ні. Щоб отримати повний, необхідно розібрати головні причини їх нестабільності*, а саме фокус, що змінюється, маловдалий відробіток виняткових ситуацій, ігнорування клавіатури, велику кількість мікроскопічних елементів управління і зловживання вікнами.
Фокус
У графічних віконних інтерфейсах є декілька т.з. фокусів, зокрема фокус клавіатурного введення і фокус оперування.
Фокус клавіатурного введення визначає, який елемент управління зараз активний і яке саме введення від користувача зараз прийнятне. Якщо кликнути на полі введення, можна натиснути на клавішу ж на клавіатурі і в полі з'явиться символ Ж. Якщо зробити те ж саме, приміром, чекбоксе, клавішу ж можна жати до посиніння, але нічого не станеться.
Фокус оперування визначає, яке саме застосування зараз доступно для введення; якщо додаток багатовіконний, фокус оперування визначає також яке саме вікно активно зараз.
Проблема з цими двома фокусами полягає в тому, що вони частенько змінюються системою, а не користувачем(відразу треба відмітити, що це швидше провина ОС, ніж провина конкретних застосувань).
Розберемо це на прикладі. Я пишу цю статтю в текстовому редакторові. Несподівано працююча у фоновому режимі програма-органайзер вирішує, що прийшло час нагадати мені про те, що я повинен їхати на чергову зустріч. Бум! Вискочило діалогове вікно з нагадуванням, фокус оперування змістився на нього, я, дарма що дивився в цей час на екран, так і продовжив друкувати слово " адіабатичний" - суто за інерцією. У редактор в результаті потрапив тільки недогризок слова.
Що я повинен зробити в такій ситуації? Багато що:
- Зрозуміти, що сталося.
- Оцінити, що я повинен зробити найближчим часом. Як правило, це.
- Перемкнутися назад в текстовий редактор.
- Згадати, що я збирався написати саме слово " адіабатичний".
- Якщо я ще пам'ятаю пропозицію, яку я збирався написати, написати його. Якщо не пам'ятаю, вирішити, чи встигну я ще придумати пропозицію наново або вже пора бігти.
Якби нове вікно відкрилося без крадіжки фокусу :
- Я принаймні зміг би дописати пропозицію до кінця, після чого.
- Перемістив би погляд на вікно нагадування, прочитав його вміст і вирішив, що мені робити далі. Як правило, це.
- Дописати абзац і поїхати на зустріч.
Контраст, на мій погляд, разючий.
Відробіток виняткових ситуацій
Зараз є нормою, коли при будь-якій винятковій ситуації(читай - людській помилці) система переводить користувача в режим корекції його дій.
Розглянемо черговий приклад. Користувач заповнює форму і в полі вік вводить слово " Вася". Можливі декілька реакцій системи(залежно від кваліфікації її розробників; перераховані в порядку убування вірогідності) :
- Варіант 1. Як тільки користувач натискає на кнопку Зберегти, відкривається вікно із словами "В одне або декілька полів введена некоректна інформація(код помилки #F4567) ". Вікно краде фокус з форми.
- Варіант 2. Як тільки користувач, ввівши " Вася" переходить до наступного елементу форми, вискакує те ж саме вікно і так само краде фокус.
...
- Варіант 9. Як тільки користувач натискає на кнопку Зберегти, форма перезавантажується; у новій формі згори написано, що "В одне або декілька полів введена некоректна інформація(код помилки #F4567) " і поле віку підсвічується червоним.
- Варіант 10. Як тільки користувач вводить символ " В", система показує йому поряд з полем пухир із словами "Сюди можна вводити тільки число(від 1 до 130) ". Фокус при цьому не воруется.
- Варіант 11. Спробувавши ввести символ" ", користувач виявляє, що ввести його неможливо. Після декількох спроб користувач вводить шуканий вік.
Окрім різниці в трудовитратах користувача, ці варіанти інтерфейсу розрізняються мірою перемикання дій користувача(а фактично - перемиканнями стану його діяльності). Спочатку користувач знаходиться в стані заповнення форми, все ж інтерфейси, окрім останніх двох, переводять його в стан пошук і виправлення помилки.
Чим частіше користувач змінює мету своїх дій, тим менш стабільний інтерфейс.
Ігнорування клавіатури
Розглянемо гіпотетичний інтерфейс, що складається з єдиної екранної кнопки Виконати(В). Користувач може запустити асоційовану з кнопкою операцію одним з двох способів : кликнувши по ній або натиснувши клавішу В на клавіатурі. Чим розрізняються ці два варіанти?
Як би добре користувач не володів мишею, будь-яка мишача операція по числу дій довше клавіатурної операції :
- Знайти поглядом, де розташований курсор зараз.
- Знайти поглядом, куди його треба перемістити.
- Перемістити курсор.
- Натиснути на клавішу миші.
Зрозуміло, у досвідчених користувачів ці операції згортаються, так, пункт 2 взагалі практично зникає. Але все одно миша не може перевершити клавіатуру, в якій від(досвідченого) користувача потрібно тільки :
- Не відриваючи погляду від потрібної кнопки на екрані, протягнути руку і натиснути на потрібну клавішу.
Уся різниця в тому, що курсор завжди знаходиться в різних точках екрану, а клавіатура залишається нерухома. Відповідно, клавіатура стабільна, а миша немає.
Мікроскопічні елементи управління
Як би не було хороше клавіатурне введення, ігнорувати мишаче введення не вийде, та це і не треба. Проблема в тому, що в сучасних інтерфейсах з ним пов'язана ще одна причина нестабільності - невиправдано дрібні елементи управління.
Згідно зі всесильним законом Фиттса, клик по маленькій кнопці займає більший час, ніж по кнопці великій. Але звідки береться це збільшення тривалості? Відповідь - час витрачається на прицілювання перед і під час руху миші, тобто на отримання зворотного зв'язку. Так що дрібні елементи управління містять додаткову нестабільність.
На мій погляд, мода робити все дрібним, що народилася в тисячоліття маленьких екранів, просто застаріла. Коли середньостатистичний монітор мав дозвіл 800*600, в ній був безперечний практичний сенс, але зараз, коли дозвіл 1024*768 є робочим мінімумом, малюсінькі елементи управління втратили усю свою чарівність.
Я переконаний, що форма має бути маленькою по площі тільки в одному випадку - якщо при її заповненні користувач повинен бачити дані з іншої форми. Якщо це не потрібно, формі краще бути більше, полегшуючи її читання(нічого так не прискорює сканування форми поглядом, як велика кількість з розумом застосованого порожнього простору) і, головне, наведення курсора.
Зловживання вікнами
Припустимо, користувач заповнює платіжне доручення і доходить до місця, в якому йому треба вибрати контрагента зі списку, а контрагента в списку-то і немає, тобто його потрібно додати. Типове рішення - поряд зі списком ставиться кнопка Новий контрагент., натиснення на яку викликає діалогове вікно з формою введення контрагента.
У цього рішення є, безумовно, деякі достоїнства, але також і недоліки :
- Модальні вікна переводять користувача в новий режим. Немодальні - збільшують кількість варіантів взаємодії, що не завжди добре(навіщо, питається, користувачеві змінювати розміри вікна, якщо його цей розмір вже влаштовує?).
- Недобре, якщо породжене вікно більше за розміром вікна, що породило його. Тобто виникнуть неминучі проблеми із забезпеченням компактності елементів управління(см вищий).
- Це рішення не універсальне, оскільки вікно може бути тільки одне: з вікна, що відкрилося, не можна викликати інше вікно(більше одного породженого вікна це mauvais ton).
- Нарешті, найголовніше: вікно розриває діяльність користувача. Спочатку користувач заповнював платежку, вікно ж тимчасово перекладе його на діяльність "створення контрагента". Цей розрив поганий сам по собі(діяльність потрібно берегти), але для стабільності він просто катастрофічний.
Я глибоко переконаний, що вікна - тільки один з можливих способів організації інтерфейсу. Є ситуації, коли вони працюють якнайкраще, але є ситуації, в яких будь-який інший спосіб працює краще.
Наприклад:
- Користувачеві пред'являється єдина форма з полями як платежки, так і контрагента. Якщо користувач вибрав контрагента зі списку, поля контрагента, що стали непотрібними, забираються.
- Користувачеві пред'являється форма платежки. Якщо в списку немає потрібного контрагента, користувач вводить його назву і тільки. Після того, як користувач завершує введення даних у форму, система повідомляє його, що бракує даних і пред'являє форму введення відомостей про контрагента із вже введеною назвою.
У обох випадках вікна не потрібні.