Лишние окна
Программирование – очень сильно ориентированный на функции процесс, поэтому пользовательский интерфейс часто создается по принципу: одно окно на одну функцию. Этот принцип упрощает реализацию и определяет модель представления, но имеет далеко идущие последствия для пользователя.
В реальной жизни при работе мы не приобретаем новый инструмент, если только он не будет служить специальной цели, которой нельзя достичь при помощи существующих инструментов.
Точно так же и в программе мы не должны добавлять окно в программу до тех пор, пока оно не будет служить какой-то цели, которой невозможно достичь в уже существующих окнах. Новое окно должно ассоциироваться именно с целью, а не с какой-то задачей или функцией.
Например, в большинстве программ для рисования, для установки глубины тени объекта обычно используется текстовое поле или ползунок в отдельном диалоговом окне. После изменения значения глубины тени программа возвращается к главному окну для продолжения работы. К таким решениям мы уже привыкли и перестали их замечать, но на самом деле это пример плохого дизайна. Адекватно отражая инфраструктуру инженерной деятельности, такой подход слабо помогает создавать целостные механизмы для достижения пользователями своих целей.
В программе для рисования основной задачей является работа над изображением, а так как объект находится в главном окне, то все инструменты для работы c ним тоже должны находиться в главном окне. Не так уж часто используемую операцию, но все же тесно связанную с процессом лучше производить не в отдельном окне, а воспользоваться (как новым инструментом) кнопкой на панели инструментов.
Еще лучше, если удастся реализовать прямое манипулирование, как например, при установке глубины тени объекта по тени можно щелкнуть мышкой и поменять размер тени, перетащив ее на новое место. Этот интерфейс следует ментальной модели художника, которому требуется получить определенный конечный вид изображения, а не набор абстрактных чисел.
Вынесение функций в диалоговое окно подчеркивает их обособленность от главной задачи.
С точки зрения программиста, изменение глубины тени - отдельная функция, поэтому кажется естественным так и относиться к ней. Однако, с точки зрения пользователя эта функция – часть процесса рисования и поэтому должна быть интегрирована в главное окно.
ПРИНЦИП проектирования: Пользовательский интерфейс должен следовать пользовательской ментальной модели, а не модели реализации.
Необходимые окна
Когда пользователь хочет выполнить функцию, выпадающую из нормальной последовательности событий, программа должна предоставить ему для этого специальное место. Если отдельное окно действительно необходимо, его надо предоставить.
Например, очистка всей базы данных – не обычное действие. Другие части программы могут служить для повседневных задач, таких как ввод и проверка записей, но задача стирания всех записей не встречается каждый раз. Удаление должно происходить в отдельном окне. В этом случае создание специального окна для этой функции совершенно уместно.
Для достижения хорошего эффекта нужно анализировать функции с точки зрения целей пользователя по частоте использования и удобства доступа к инструментам. Если это программа для рисования, то цель пользователя - создать рисунок.
Все инструменты, напрямую связанные с целью пользователя, должны быть интегрированы в рабочую область программы.. Эти инструменты должны быть готовы для немедленного использования, чтобы за ними не приходилось далеко тянуться, не говоря уже о том, чтобы вести утомительный диалог.
Инструменты в программе должны быть расположены так, чтобы их можно было вызвать одним щелчком мыши. Для таких задач пользователь не должен обращаться к меню или диалоговым окнам.
Если же пользователь решает выполнить дополнительную работу, все еще достаточно связанную с его главной целью, то для этого необходимо вызывать другие окна, не относящиеся непосредственно к процессу действия. При этом требуется, чтобы дополнительные средства были логически отделены, но легко доступны.
Например, в программе функция вставки изображения должна быть легко доступной, но, если для нее нужен целый набор инструментов, которые в обычной работе не требуются, то ее следует разместить в отдельном окне. Аналогично художник держит каталог с образцами не прямо на столе, а где-то рядом, например, на полке над столом, до которой можно дотянуться не вставая.
Когда пользователь закончил главную работу с объектом, он достиг своей начальной цели. В этом месте его цели меняются. В рамках работы у него появляется новая цель. Нужды в старых инструментах больше нет.
В программном эквиваленте этого процесса, пользователь временно оставляет программу вместе со всеми инструментами, и переключается на новую задачу с новым окном в контексте с главной задачей (например, сохранение файла и отсылка его по электронной почте).
Защитить пользователей от моделей реализации помогает осознанное проектирование взаимодействия и понимание того, что подход, хороший для разработки программ, не годится для создания ментальной модели пользователя.
Программисты имеют логичное математическое мышление и искренне считают, что логическое мышление надо положить в основу интерфейса. Однако, то, что естественно для инженера, совершенно противоестественно для пользователя.
Например, если фирма имеет филиалы в нескольких городах, то для получения списка сотрудников в Москве и Твери пользователь сформулирует запрос: «Найти всех сотрудников, работающих в Москве и в Твери». Но, с точки зрения математика запрос некорректен: сотрудники не могут числиться в Москве и в Твери одновременно, они могут быть либо в Москве, либо в Твери. Поэтому правильный запрос должен быть: «Найти всех сотрудников, работающих в Москве ИЛИ в Твери».
Попытка дисциплинировать пользователя, заставляя перейти от общепринятых и понятных человеку формулировок к математическим, создает для него серьезные проблемы и вызывает путаницу в понятиях.
Загрязнение окнами
Как уже говорилось, программу, которая отражает собственную модель реализации, спроектировать очень легко. Но если каждую функцию помещать в отдельное диалоговое окно, то заканчивается это тем, что называют загрязнением окнами.
Для достижения множества целей пользователю необходима целая серия функций. Если в программе используется одно окно для одной функции, экран быстро становится визуально загроможденным.
Становится очень трудно показать связи между множеством окон, поэтому просто не стоит создавать большое их количество. Есть, правда, модальные диалоги, которые всегда возвращают вас в точку отправления, поэтому они не работают против вас. От того, что легко сделать окна в большом количестве, интерфейс не становится хорошим.
Каждое новое окно увеличивает необходимость лишних манипуляций с ним. Когда программа используется ежедневно, это может перерасти в серьезную проблему.
Если программа, обладающая большим количеством окон, приближает пользователя к нескольким различным целям, то лучше разбить ее на несколько маленьких программ, и пусть каждая служит для достижения своей цели. У программы не может быть больше двух-трех целей, а значит, у неё не должно быть больше двух или трех окон.
С помощью выяснения целей пользователя мы естественным образом подходим к наиболее подходящей форме программы.
Вместо того, чтобы просто помещать каждую новую функцию в новое окно, видно, что некоторые функции не нужно помещать в диалоговые окна, другие должны быть вынесены в отдельное окно, интегрированное в общий интерфейс, а некоторые функции вообще нужно убрать из программы.
Ни одну программу с большим количеством форм нельзя использовать эффективно! Каждая форма может быть превосходной сама по себе, но все вместе это просто слишком много и громоздко.
Структура окна
Структура и само устройство окна или экрана является самым существенным фактором, влияющим на качество интерфейса в этом окне.
Производительность пользователей и степень удовлетворенности системой можно повысить просто изменив расположение элементов окна, не меняя сами элементы.
Каким же требованиям должно удовлетворять окно?
Во-первых, окно должно хорошо сканироваться взглядом, то есть его основные части должны быть сразу видны и заметны. В окнах, дающих доступ к большому числу функций, возникает необходимость организовывать интерфейсные элементы окна в блоки так, чтобы элементы группировки и разделители не дали эффекта визуального шума.
Во-вторых, окно должно читаться как текст. Окно, все элементы которого можно без туда связно прочесть, будет лучше запомнено и быстрее понято пользователем. При этом один элемент окна должен однозначно преобразовываться в единый фрагмент предложения, а единая группа элементов – в целое предложение.
В-третьих, окно должно удовлетворять закону: релевантное – вперед (англ relevant – относящийся к делу). Чаще используемые элементы должны располагаться в левой верхней части экрана, реже используемые – в правой нижней части. Просмотр экрана происходит так же, как и процесс чтения – слева направо и сверху вниз. При этом вертикальный элемент управления, разрывающий воображаемые строки на части, будет замедлять сканирование и создавать дискомфорт.
В-четвертых, один экран должен содержать только те элементы, которые в нем нужны и которые пользователь может в этом экране ожидать. При этом заголовки экранов должны быть созданы и сформулированы еще до начала проектирования экранов и содержимое экранов не должно выходить за рамки смысла заголовков.
В-пятых, терминационные кнопки, то есть кнопки, управляющие окном, например, Ок или Закрыть должны быть расположены либо снизу окна, либо в правой его части. Дело в том, что в интерфейсе должно быть реализовано правило: сначала выбор параметров, объекта с которым работать, а потом действие с этими объектами. Например, при редактировании мы сначала выделяем фрагмент текста, а потом уже указываем что с ним сделать.
Аналогичная последовательность действий при копировании файлов: сначала выбрать файл(ы), указать куда копировать, а потом уже дать команду копировать (как в Norton Commander). Менее предпочтительнее сначала выбрать файл, потом действие, а затем указать куда скопировать. В этом случае увеличивается число ошибок и ослабляется пользовательское ощущение контроля, что грозит снижением удовлетворения от общения с системой.