обратной связи во время набора интерфейс может временно отображать пару налагаемых друг на друга символов в виде смежных символов. Смысл этого заключается в том, что интерфейс не может отличить одновременное нажатие клавиш при быстром наборе от одновременного нажатия с целью наложения символов друг на друга до тех пор, пока клавиши. не отпущены, после чего слияние накладываемых символов происходит автоматически. Также хочу добавить, что требуется радикальная реформа клавиатуры, связанная с удалением клавиши «CapsLock». Эта клавиша порождает режим.
6.5. Письмо от одного пользователя
Когда я работал над проектом для большой компании, один опытный пользователь программного обеспечения, производимого этой компанией, написал письмо, которое иллюстрирует некоторые идеи этой книги. Приводимые ниже высказывания в кавычках взяты из этого письма.
• «Этот программный пакет показался мне более развитым продуктом». В разговоре с программистами выяснилось, что приоритет был отдан больше плану выполнения работ, чем качеству. Поэтому покупателям была предложена скорее мечта руководителей изначального проекта. Скорее всего, в условиях жесткого плана работы был создан «минимальный полезный краткий вариант». Многие важные детали были пропущены, т. к. инструменты для разработки интерфейса были выбраны заранее и поэтому не дали возможности реализовать задуманные формы взаимодействия с пользователем.
• «Пользователь должен нажимать клавишу «Enter» или щелкать кнопкой мыши намного чаще, чем это требуется для ввода полезной информации». При вводе данных в поле
Использование клавиши «Tab» вместо клавиш со стрелками для перемещения по полям также создавало проблемы. Два поля на экране допускали свободное форматирование текста. В этих полях пользователь мог применять клавишу «Tab» для создания отступов или списков, и поэтому клавиша «Tab» не давала возможности перейти на следующее поле. Тяжело было смотреть на пользователя, который много раз и безуспешно нажимал на клавишу «Tab», чтобы попытаться перейти на следующее поле.[51]
Эти примеры иллюстрируют две распространенные проблемы в интерфейсах. Первая связана с использованием клавиши «Return» для разделения полей. Эта привычка уходит далеко в то время, когда несколько десятков лет назад в прикладных системах, работающих в режиме разделения времени, а также в приложениях для микрокомпьютеров использовались ограничения, принятые для телетайпных машин. Вторая проблема связана с функциональной перегрузкой клавиш «Return» и «Tab», в результате которой в полях, допускающих свободный ввод текста, они означают одно, а в более коротких полях – другое.
• «Когда выбирается опция поиска, курсор должен появляться в соответствующем текстовом окне так, чтобы пользователь мог начать вводить информацию без необходимости щелкать мышью внутри поля или нажимать на кнопку Tab». Это частный случай следующего общего принципа:
• «Ненужные диалоговые окна, наверное, являются главной причиной бесполезной траты времени и вызывают раздражение у пользователя». Речь идет о тех диалоговых окнах, которые предназначены для сообщения пользователю о том, что произошло, и для своего закрытия требующие нажатия кнопки мыши или клавиши «Enter». Другого выбора не остается – продолжить можно, только лишь кликнув по окну. Это другой частный случай приведенного выше принципа (если пользователь далее может выполнить только одно-единственное действие, пусть его выполнит компьютер). Как пишет автор в другом месте своего письма: «Важно, чтобы всякий раз, когда пользователь должен взаимодействовать с каким-то диалоговым окном, это взаимодействие давало полезный результат». Это можно обобщить до следующего утверждения:
Далее автор письма продолжает сетовать, что одно из диалоговых окон просто «сообщает пользователю, что элемент уже введен в список» в том случае, когда название или номер существующего предмета вводится в окно для новых элементов. Чтобы продолжить, вам требуется убрать это диалоговое окно. Вместо этого автор предложил, чтобы появлялись три кнопки: оставить элемент, удалить элемент из списка или перейти к его редактированию. Хотя вариант автора является лучшим, чем изначальный, мы все же можем предложить еще более лучшую схему. Описанная проблема отчасти связана с идеей, что ввод нового элемента отличается от редактирования или удаления элементов. Предложим более простой метод: пользователь вызывает форму и вводит дескриптор элемента. Если он является новым, элемент вводится, и пользователь продолжает работу, как предполагалось. Если элемент уже имеется в списке, данные о нем сразу же вызываются, чтобы пользователь мог увидеть, что элемент уже существует. После этого пользователь может редактировать их. Естественно, удаление – это один из способов редактирования.
• Автор отмечает, что экран очень быстро заполняется одинаковыми пиктограммами, которые можно различить только по именам, указанным внизу каждой из них. Он предложил, чтобы пиктограммы различались между собой в большей степени, поскольку «среда, по сути, является
• «Если вы открыли окно с формой для заказа на покупку и хотите внести в него какой-то элемент, перед вами открывается диалоговое окно со следующим содержанием: «Данное приложение не может работать одновременно с окном «Создать/обновить бланк заказа». Естественной реакцией пользователя может быть вопрос: «Почему не может?» Здесь разработчики просто не имели полного представления о том, как в действительности может проходить работа пользователя.
Общий принцип состоит в том, что почти любой чрезмерно структурированный подход к процессу взаимодействия с пользователем рискует стать препятствием при выполнении им той или иной задачи, которая требует совсем другого подхода. В данном случае интерфейс превращается из помощника для пользователя в диктатора.
• «В электронной промышленности существует тенденция к согласованию, независимо от того, насколько это может быть продуктивным… Согласование и использование стандартов очень важно, т. к. позволяет пользователю быстрее работать. Но если согласование и стандартизация создают бесполезные вещи, то такой проект можно считать неудачным». Именно это несколько лет назад и было сказано в известной статье Грудина (Grudin) «Дело против согласования пользовательских интерфейсов» («The Case Against User Interface Consistency», Grudin, 1989). Очевидно, что анализ, проведенный Грудиным, не был воспринят электронной индустрией.
• «При разработке этого программного обеспечения использовался стандартный метод построения меню, принятый в операционной системе Windows». Автор приводит пример: «Все меню изначально содержат в себе какую-то долю бесполезности. В одном из меню содержится команда Выход, которая вставлена в меню Файл». Другими словами, автор говорит, что команда Выход была