Директивно-диалоговая форма взаимодействия с программной системой Интерфейс командной строки (Command Line Interface - CLI)

и расширенный  комбобокс (справа).  

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

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

Крутилки 

Крутилка (spinner, little arrow) есть поле ввода, не такое  универсальное, как обычное, поскольку не позволяет вводить текстовые данные, но зато обладающее двумя полезными возможностями.   

Рис. 6. Крутилка   

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

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

Ползунки

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

■ значений в ряду много (см. рис. 7)

■ нужно  передать пользователям ранжируемость  значений.

Рис. 7. Примеры  ползунков. Видно, что количество параметров в ползунке может быть весьма значительным.

■ необходимо дать возможность пользователям  быстро выбрать значение из большого их количества (в таких случаях  ползунок оказывается самым эффективным  элементом, хотя и опасен возможными человеческими ошибками).

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

Меню

При упоминании применительно к интерфейсу термина  меню, большинство людей немедленно представляют стандартные раскрывающиеся меню.

В действительности, понятие меню гораздо шире. Меню – это метод взаимодействия пользователя с системой, при котором пользователь выбирает из предложенных вариантов, а не предоставляет системе свою команду.   

Рис. 8. Стандартное  раскрывающееся меню.  

Соответственно, диалоговое окно с несколькими кнопками (и без единого поля ввода) также является меню.  

Рис. 9. Это  тоже меню.

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

Типы  меню

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

■ Статические  меню, т. е. меню, постоянно присутствующие на экране. Характерным примером такого типа меню является панель инструментов.

■ Динамические меню, в которых пользователь должен вызвать меню, чтобы выбрать какой-либо элемент. Примером является обычное  контекстное меню.

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

Вторая  таксономия также делит меню на два  типа:

■ Меню, разворачивающиеся в пространстве (например, обычное раскрывающееся меню). Всякий раз, когда пользователь выбирает элемент нижнего уровня, верхние элементы остаются видимыми.

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

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

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

Устройство  меню

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

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

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

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

глядя на соответствующий элемент меню.

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

Пиктограммы в меню

Пиктограммы в меню, если они повторяют пиктограммы  в панели инструментов, обладают замечательной  способностью обучать пользователей  возможностям панели. Помимо этого они здорово ускоряют поиск известного элемента и точность его выбора, равно как и общую разборчивость меню. Таким образом, пиктограммы в меню объективно хороши (только стоят дорого, к сожалению). Это очевидный факт. Теперь менее очевидный: пиктограммы лучше работают, когда ими снабжены не все элементы. Когда все элементы имеют пиктограммы, разборчивость каждого отдельного элемента падает: в конце концов, пиктограммы всех ненужных в данное время элементов являются визуальным шумом. Когда же пиктограммами снабжены только самые важные элементы, их разборчивость повышается (а разборчивость остальных не понижается), при этом пользователям удается легче запоминать координаты элементов («элемент сразу под второй пиктограммой»). Не снабжайте пиктограммами все элементы меню, снабжайте только самые важные.  

Переключаемые элементы

Особого внимания заслуживают случаи, когда  меню переключает какие-либо взаимоисключающие  параметры, например, показывать или  не показывать палитру. Тут есть несколько возможных способов. Можно поместить перед переключателем галочку, показывая, что он включен (если же элемент снабжен пиктограммой, можно её утапливать). Заранее скажу, что это лучший метод. Можно не помещать галочку, зато инвертировать текст элемента: например, элемент Показывать сетку превращается в Не показывать сетку. Это плохо по многим причинам. Во-первых, в интерфейсе желательно не употреблять ничего негативного: в меньшей степени потому, что негативность слегка снижает субъективное удовлетворение; в большей степени потому, что она снижает скорость распознавания текста (главное слово не первое, нужно совершить работу, чтобы из отрицания вычислить утверждение). Во-вторых, если изъять «не» и переформулировать одно из состояний элемента, пользователям будет труднее осознать, что два разных элемента на самом деле есть один элемент. Таким образом, галочка предпочтительнее. Всегда формулируйте текст в интерфейсе без использования отрицаний.  

Предсказуемость действия

Пользователей нужно снабжать чувством контроля над системой. Применительно к меню это значит, что по виду элемента пользователи должны догадываться, что произойдет после выбора. Сделать это неимоверно трудно, поскольку на экране нет места под такие подсказки. Можно сделать только одно, но сделать это нужно обязательно: нужно показать пользователям, какой элемент запускает действие или меняет параметр, а какой открывает окно c продолжением диалога. Почти во всех ОС стандартным индикатором продолжения диалога является многоточие после текста элемента, так что пользоваться этим признаком стоит везде, включая Интернет. Также необходимо показывать, какой элемент срабатывает сразу, а какой открывает элементы меню нижнего уровня (в любой ОС это делается автоматически, в Интернете нужно не забывать делать это вручную).

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