зажигается, если фонарик находился перед этим в выключенном состоянии, и наоборот, если текущее состояние «включено», то после нажатия кнопки фонарик выключается. Два состояния фонарика соответствуют двум режимам интерфейса. В одном режиме нажатие кнопки включает свет. В другом режиме нажатие кнопки выключает свет. Если вы не знаете текущее состояние фонарика, вы не можете предсказать, к чему приведет нажатие кнопки. Если ваш фонарик лежит глубоко в сумке, и вы его не видите, то не можете узнать, включен свет или нет, при условии, что это нельзя почувствовать по температуре. Чтобы убедиться, что фонарик выключен, вам требуется вынуть его из сумки. Невозможность определить текущее состояние фонарика – это пример классической проблемы, возникающей в интерфейсе, в котором есть режимы. По состоянию управляющего механизма невозможно сказать, какое действие следует выполнить, чтобы достичь поставленной цели. Оперируя с управляющим механизмом без одновременной проверки состояния системы, вы не сможете предсказать, какой результат будет иметь данная операция.
К переключателям трудно подобрать надписи. Например, однажды мне показали интерфейс, в котором кнопка на экране была подписана Lock (Блокировать). Когда пользователи в первый раз видели эту кнопку, они считали, что должны нажать на нее для блокировки данных в этом окне. Когда они делали так, подпись кнопки изменялась на Unlock (Разблокировать), показывая, что при нажатии на эту кнопку данные разблокировались бы. После этого многие пользователи удивлялись, что данные оказывались разблокированными, поскольку кнопка показывала Unlock, что они считали индикатором текущего состояния, как это часто бывает при использовании переключателей на кнопках и в меню. Естественно, это приводило к путанице: на самом деле кнопка показывала Lock, когда данные были разблокированы, и Unlock – когда они были заблокированы. Очевидно, что проблему нельзя решить, просто поменяв надписи таким образом, чтобы разблокированные данные обозначались как Unlock, а заблокированные как Lock.
В данном случае следует, во-первых, использовать флажок, а не кнопку, а во-вторых, применить более точные формулировки – Locked (Заблокировано) вместо Lock (Блокировка), что будет восприниматься более правильно: если флажок установлен, значит, данные заблокированы, если же флажок сброшен – данные не заблокированы. Изменения подписей в этом случае не требуется. Можно использовать более развернутую формулировку, например: «Щелкните по этой кнопке, чтобы разблокировать данные» или даже: «Данные в настоящее время заблокированы. Щелкните по этой кнопке, чтобы разблокировать их». Однако на кнопке или около флажка, или в меню трудно разместить полное объяснение, если интерфейс не снабжен функцией увеличения изображения (см. раздел 6.2).
Флажки, тем не менее, оставляют неясным, какие еще есть альтернативы. Например, если флажок отмечен «Сохранить в архиве при закрытии», то при закрытии активного окна данные будут сохранены в архиве. Однако из подписи не понятно, что произойдет, если этот флажок сброшен. Данные будут сохранены где-то в другом месте? Или не сохранены вообще? Или при закрытии окна появится еще какая-то опция? Самым лучшим решением в этой ситуации зачастую оказывается использование набора переключателей (рис. 3.1). Такие переключатели не являются модальными, и пользователь может сразу определить не только текущее состояние, но и альтернативы. Независимо от того, применяются ли флажки или переключатели, важно, чтобы в названиях употреблялись прилагательные, описывающие состояние объекта, а не глаголы, описывающие действие с этим объектом, потому что иначе пользователю не ясно, действие уже произошло или только должно произойти.
Переключатели стали стандартным средством для выбора одной из нескольких возможностей, и вряд ли следует их заменять какими-то другими механизмами.
За исключением случаев, когда текущее состояние находится в локусе внимания, – а обычно это не так, – выключатели могут приводить к ошибкам. Такие ошибки обычно имеют кратковременный характер и легко исправляются. Тем не менее, их нельзя не учитывать при разработке интерфейсов. Заниматься разработкой интерфейсов и при этом не обращать внимания на такие детали – все равно, что пытаться исполнить скрипичный концерт, иногда забывая диезы и бемоли, обозначенные в нотной записи. Такие ошибки раздражают слушателя тем, что отвлекают его внимание от музыки. Точно так же мелкие ошибки в интерфейсе затрудняют ход работы пользователя.
Другую связанную с режимами трудность, которая особенно изматывает пользователей компьютеров, можно проиллюстрировать на примере того, как работает клавиша «Caps Lock», присутствующая на большинстве типов клавиатур. Часто первым признаком случайного нажатия этой клавиши оказывается то, что вы замечаете, что набранное вами предложение напечатано заглавными буквами, и только после этого вы замечаете также, что включен индикатор «Caps Lock» (если он есть на клавиатуре). «Не случайно ругательства обозначаются в виде цепочки символов, наподобие #&%!# $&. Именно такая картина возникает, когда кто-то набирает цифры при ошибочно нажатой клавише «Caps Lock», – утверждает мой коллега доктор Джеймс Уинтер (личное сообщение, 1998).
Несколько десятилетий назад Ларри Кларк заметил, что режимы создают проблемы по той причине, что привычные действия приводят к неожиданным результатам (dark, 1979). [10] Наиболее часто предлагаемое средство против ошибок, порождаемых режимами, состоит в том, чтобы ясным образом показывать пользователю текущее состояние системы. Доктор Дональд Норман охарактеризовал ошибки, связанные с режимами, как результаты недостаточной обратной связи, осуществляемой индикатором состояния системы (Norman, 1983). Однако, на мой взгляд, истинной причиной является не недостаточная обратная связь, а то, что этот индикатор не находится в локусе внимания пользователя.
Особенно показательный пример неудачного применения индикатора, отражающего текущее состояние системы, можно встретить в интерфейсе системы автоматизированного проектирования (САПР) (computer-aided design, CAD) Vellum (Ashlar, 1995), во всех остальных отношениях превосходном. Всем, кто занимается разработкой графических пакетов, я настоятельно рекомендую изучить программу Drafting Assistant, разработанную Ashlar. Эта программа оснащена чрезвычайно удобным интерфейсом, намного более эффективным и приятным в использовании, чем тот, который применяется в более известном пакете AutoCAD.[11] Одной из функций, предусмотренных для экономии времени в пакете Vellum, является указатель, который может следовать по внутренней или наружной стороне геометрической фигуры, выделяя (трассируя) описываемую границу. Чтобы перейти в режим трассировки, необходимо щелкнуть по соответствующей кнопке палитры инструментов, при этом стандартный курсор
преобразуется в курсор особой, «указательной» формы.
По завершении выделения легко забыть переключиться назад, к стандартному курсору. Выделение с помощью мыши является настолько частым действием, что для меня оно уже давно стало автоматичным, и поэтому когда в этой программе я щелкаю, чтобы выделить какой-то объект после операции трассировки, то вместо успешного выделения я с удивлением обнаруживаю, что обведенный указателем контур исчезает. Я совершаю эту ошибку уже не первый год, так же как и другие пользователи, с которыми мне приходилось говорить об этом. Хотя иногда я и ловлю себя на мысли, что делаю неправильно, но все же я никогда
