Проектирование отдельных блоков

Предсказание скорости. Часто приходится выбирать между разными вариантами реализации интерфейса, причем отбрасывать варианты жалко, потому что они хорошие. Можно, конечно, сделать несколько прототипов и протестировать их на пользователях, но это довольно длительный и трудоемкий процесс. К счастью, есть метод оценки интерфейса, позволяющий быстро выбрать лучший вариант.

В 1983 году Кард, Моран и Ньювел создали метод оценки скорости работы с системой, названный аббревиатурой GOMS (Goals, Operators, Methods, and Selection Rules – цели, операторы, методы и правила их выбора).

Идея метода очень проста: все действия пользователя можно разложить на составляющие (например, взять мышь или передвинуть курсор). Ограничив номенклатуру этих составляющих, можно замерить время их выполнения на массе пользователей, после чего получить статистически верные значения длительности этих составляющих. После чего предсказание скорости выполнения какой-либо задачи, или, вернее, выбор наиболее эффективного решения, становится довольно простым делом – нужно только разложить эту задачу на составляющие, после чего, зная продолжительность каждой составляющей, всё сложить и узнать длительность всего процесса. Обычно тот интерфейс лучше, при котором время выполнения задачи меньше.

Таким образом,

- Нажатие на клавишу клавиатуры, включая Alt, Ctrl, Shift (К): 0,28 сек

- Нажатие на кнопку мыши (М): 0,1 сек

- Перемещение курсора мыши (П): 1,1 сек

- Время реакции системы (Р): от 0,1 сек до бесконечности

- Взятие или бросание мыши (В): 0,4 сек

- Продолжительность выбора действия (Д): 1,2 сек

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

Адаптивная функциональность – этоготовность системы (а точнее, её разработчиков) усложнить свою логику, чтобы упростить логику пользователя. Результат: систему легче использовать. Наличие адаптивной функциональности служит отличным индикатором качества дизайна системы. Систему, которая не подстраивается под пользователей, невозможно назвать зрелой. Чтобы определить, какие фрагменты и функции системы должны быть адаптивными, необходим детальный анализ взаимодействия пользователей с системой. Помочь здесь может только тестирование интерфейса на пользователях.

6. Создание глоссария

Еще в процессе проектирования полезно зафиксировать все используемые в системе понятия. Для этого нужно просмотреть все созданные экраны и выписать из них все уникальные понятия (например, текст с кнопок, названия элементов меню и окон, названия режимов и т.д.). После этого к получившемуся списку нужно добавить определения всех концепций системы.

Теперь этот список нужно улучшить. Для этого:

Уменьшить длину всех получившихся элементов.

Показать этот список любому потенциальному пользователю системы и спросить его, как он понимает каждый элемент. Если текст какого-то элемента воспринимается неправильно, его нужно заменить.

Уменьшить длину всех получившихся элементов.

Проверить, что одно и то же понятие не называется в разных местах по-разному.

Уменьшить длину всех получившихся элементов.

Проверить текст на совпадение стиля с официальным для выбранной платформы (если вы делаете программу, эталоном является текст из MS Windows).

Уменьшить длину всех получившихся элементов.

Убедиться, что на всех командных кнопках стоят глаголы-инфинитивы.

После чего список нужно повесить на стену и стараться не менять его в будущем.

Дата добавления: 2014-01-06