Книга: Интерфейс: новые направления в проектировании компьютерных систем

3.2. Режимы

Режимы (modes) являются важным источником ошибок, путаницы, ненужных ограничений и сложности в интерфейсе. Многие проблемы, создаваемые режимами, хорошо известны. Тем не менее, практика создания систем без режимов почему-то не находит широкого применения в разработке интерфейсов. Прежде чем приступить к обсуждению методов устранения режимов, следует рассмотреть их подробно, тем более что даже среди специалистов по интерфейсам нет общего мнения относительно того, что представляет собой режим (Johnson and Engle-beck, 1989).

Чтобы понимать режимы, нам следует сначала определить понятие жеста. Жест (gesture) – это последовательность действий человека, которая выполняется автоматически (после старта). Например, для опытного пользователя набор такого простого слова, как это, представляет всего один жест, в то время как для начинающего пользователя, который еще не вполне овладел клавиатурой, набор этого слова по буквам будет состоять из отдельных жестов. Объединение последовательности действий в жест, связанный с определенным психологическим процессом, определяется как формирование модуля (chunking), т. е. соединение отдельных элементов когнитивного процесса в единый ментальный модуль, что позволяет воспринимать множество элементов как целое (Buxton,1986, с. 475–480; Miller, 1956).

В большинстве интерфейсов допускается несколько интерпретаций конкретного жеста. Например, в одном случае с помощью клавиши «Return» можно вставить в текст символ возврата каретки, тогда как в другом случае нажатие этой клавиши приводит к исполнению предшествующей строки в качестве команды.

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

Фонарик, управляемый с помощью кнопочного выключателя, может быть либо включен, либо выключен при условии, что он находится в хорошем рабочем состоянии. При нажатии кнопки свет зажигается, если фонарик находился перед этим в выключенном состоянии, и наоборот, если текущее состояние «включено», то после нажатия кнопки фонарик выключается. Два состояния фонарика соответствуют двум режимам интерфейса. В одном режиме нажатие кнопки включает свет. В другом режиме нажатие кнопки выключает свет. Если вы не знаете текущее состояние фонарика, вы не можете предсказать, к чему приведет нажатие кнопки. Если ваш фонарик лежит глубоко в сумке, и вы его не видите, то не можете узнать, включен свет или нет, при условии, что это нельзя почувствовать по температуре. Чтобы убедиться, что фонарик выключен, вам требуется вынуть его из сумки. Невозможность определить текущее состояние фонарика – это пример классической проблемы, возникающей в интерфейсе, в котором есть режимы. По состоянию управляющего механизма невозможно сказать, какое действие следует выполнить, чтобы достичь поставленной цели. Оперируя с управляющим механизмом без одновременной проверки состояния системы, вы не сможете предсказать, какой результат будет иметь данная операция.

К переключателям трудно подобрать надписи. Например, однажды мне показали интерфейс, в котором кнопка на экране была подписана Lock (Блокировать). Когда пользователи в первый раз видели эту кнопку, они считали, что должны нажать на нее для блокировки данных в этом окне. Когда они делали так, подпись кнопки изменялась на Unlock (Разблокировать), показывая, что при нажатии на эту кнопку данные разблокировались бы. После этого многие пользователи удивлялись, что данные оказывались разблокированными, поскольку кнопка показывала Unlock, что они считали индикатором текущего состояния, как это часто бывает при использовании переключателей на кнопках и в меню. Естественно, это приводило к путанице: на самом деле кнопка показывала Lock, когда данные были разблокированы, и Unlock – когда они были заблокированы. Очевидно, что проблему нельзя решить, просто поменяв надписи таким образом, чтобы разблокированные данные обозначались как Unlock, а заблокированные как Lock.

В данном случае следует, во-первых, использовать флажок, а не кнопку, а во-вторых, применить более точные формулировки – Locked (Заблокировано) вместо Lock (Блокировка), что будет восприниматься более правильно: если флажок установлен, значит, данные заблокированы, если же флажок сброшен – данные не заблокированы. Изменения подписей в этом случае не требуется. Можно использовать более развернутую формулировку, например: «Щелкните по этой кнопке, чтобы разблокировать данные» или даже: «Данные в настоящее время заблокированы. Щелкните по этой кнопке, чтобы разблокировать их». Однако на кнопке или около флажка, или в меню трудно разместить полное объяснение, если интерфейс не снабжен функцией увеличения изображения (см. раздел 6.2).

Флажки, тем не менее, оставляют неясным, какие еще есть альтернативы. Например, если флажок отмечен «Сохранить в архиве при закрытии», то при закрытии активного окна данные будут сохранены в архиве. Однако из подписи не понятно, что произойдет, если этот флажок сброшен. Данные будут сохранены где-то в другом месте? Или не сохранены вообще? Или при закрытии окна появится еще какая-то опция? Самым лучшим решением в этой ситуации зачастую оказывается использование набора переключателей (рис. 3.1). Такие переключатели не являются модальными, и пользователь может сразу определить не только текущее состояние, но и альтернативы. Независимо от того, применяются ли флажки или переключатели, важно, чтобы в названиях употреблялись прилагательные, описывающие состояние объекта, а не глаголы, описывающие действие с этим объектом, потому что иначе пользователю не ясно, действие уже произошло или только должно произойти.

Рис. 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, является указатель, который может следовать по внутренней или наружной стороне геометрической фигуры, выделяя (трассируя) описываемую границу. Чтобы перейти в режим трассировки, необходимо щелкнуть по соответствующей кнопке палитры инструментов, при этом стандартный курсор

преобразуется в курсор особой, «указательной» формы.

По завершении выделения легко забыть переключиться назад, к стандартному курсору. Выделение с помощью мыши является настолько частым действием, что для меня оно уже давно стало автоматичным, и поэтому когда в этой программе я щелкаю, чтобы выделить какой-то объект после операции трассировки, то вместо успешного выделения я с удивлением обнаруживаю, что обведенный указателем контур исчезает. Я совершаю эту ошибку уже не первый год, так же как и другие пользователи, с которыми мне приходилось говорить об этом. Хотя иногда я и ловлю себя на мысли, что делаю неправильно, но все же я никогда не смогу научиться всегда замечать, что нахожусь в режиме трассировки, так как выделение с помощью мыши, для меня во всяком случае, является автоматичным действием. В локусе моего внимания находится объект выделения, но не форма курсора. Изменяющийся курсор, используемый в Vellum, – это один из множества примеров, подтверждающих, что средства обратной связи и индикаторы текущего положения недостаточны, чтобы обеспечить устранение ошибок, вызываемых режимами, даже в том случае, когда индикатор расположен в непосредственной близости от локуса вашего внимания. Он может попадать в область высокой зрительной способности, например, когда индикатором служит курсор, и тем не менее, вы не сможете заметить сообщение, передаваемое этим индикатором, поскольку он не находится в локусе вашего внимания. Необходимой темой для будущих исследований должно стать определение частоты ошибок, связанных с режимами, и выяснение условий, влияющих на частоту их возникновения.

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

Приведем другой пример. В некоторых популярных моделях компьютеров для создания нового документа применяется следующее сочетание клавиш:

Command? n?? ?

Здесь n обозначает новый (new). Но если взять пакет электронной почты America Online, то в нем для получения нового бланка сообщения требуется использовать другую комбинацию клавиш:

Command? m?? ?

Я предполагаю, что m здесь обозначает почта (mail). Ошибка, которую совершают пользователи при создании нового сообщения, заключается в нажатии неверной комбинации клавиш:

Command? n?? ?

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

Норман (1983) указывает три метода предотвращения модальных (т. е. связанных с режимами) ошибок:

1. Не использовать режимы.

2. Обеспечить четкое различие между режимами.

3. Не использовать одинаковые команды в разных режимах, чтобы команда, примененная не в том режиме, не могла привести к неприятностям.

Из приведенных трех методов только первый позволяет полностью избежать модальных ошибок. Что касается второго метода, то, как мы могли уже убедиться, он не всегда работает. Третий метод не сокращает количество ошибок, но позволяет уменьшить их негативные последствия.

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

Оглавление книги