uidesign1

Меню

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

Рис. 43. Стандартное выпадающее меню.

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

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

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

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

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

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

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

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

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

Например, в предыдущей иллюстрации диалоговое окно с меню перекрыло элемент управления, которым это меню было вызвано.

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

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

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

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

. Diana Parton, Keith Huffman, Patty Pridgen, Kent Norman, and Ben Shneiderman. Learning a Menu Selection Tree: Methods Compared. Behaviour and Information Technology, ( ) , pp. U .

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

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

Всегда формулируйте текст в интерфейсе без использования отрицаний

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

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

. По этой же причине не рекомендуется чтоUлибо делать со сторокой статуса (см. стр. ): в интернете это практически единственный способ узнать, куда приведет ссылка, не идя по ней.

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

Взаимоисключающие элементы желательно помещать в отдельный уровень иерархии

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

Как разделять группы между собой. Существует два основных способа разделять группы: между группами можно помещать пустой элемент (разде% литель) или же размещать отдельные группы в разных уровнях иерархии.

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

Для разграничения групп традиционно используют полоски. Это надеж% ное, простое решение, другой разговор, что с дизайнерской точки зрения полоски плохи, поскольку представляют собой визуальный шум. Гораздо правильнее, но и труднее, использовать только визуальные паузы между группами, как это сделано, например, в MacOS X.

Глубина меню. Наличие многих уровней вложенности в меню приводит к там называемым «каскадным ошибкам»: выбор неправильного элемента верхнего уровня неизбежно приводит к тому, что все следующие элементы также выбираются неправильно. При этом широкие меню больше нравятся пользователям. Поэтому большинство разработчиков интерфейсов ста% раются создавать широкие, а не глубокие меню1.

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

При перемещении по меню пользователь действует по определенному алгоритму:

1 Выбирая элемент первого уровня, он выбирает элемент, «нужность» которого кажется ему максимальной.

2После выбора он видит список элементов второго уровня, при этом он оценивает вероятность соответствия всех элементов второго уровня его задаче и одновременно выбирает наиболее вероятный элемент.

При этом в уме он держит контекст, т.е. название элемента первого уровня.

3 Если ни один из элементов не кажется пользователю достаточно веро% ятным, пользователь возвращается на первый уровень.

4Если какой%то элемент удовлетворяет пользователя, он выбирает его и получает список элементов третьего уровня. Действия из второго и

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

третьего шагов повторяются применительно к новым элементам меню.

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

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

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

Рис. 45. Насколько я знаю, такой элемент управления для меню впервые появился в каталоге Yahoo. Несмотря на то, что с тех пор этот элемент сейчас присутствует на мно+ жестве сайтов, я, стремясь подчеркнуть заслугу Yahoo, выбрал оригинал. © Yahoo! Inc

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

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

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

Не делайте контекстные меню единственным способом вызова какой*либо функции

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

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

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

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

Система сначала должна показывать максимально релевантную информацию, затем всё остальное

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

Окна

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

Рис. 46. Типы окон на примере MS Word 97. Самое большое окно есть окно программы. Внутри него два окна документов, в более свежих версиях Word их уже нет. Слева сверху располагается режимное диалоговое окно (Абзац), под ним справа – безре+ жимное (Найти и заменить). Слева внизу располагается палитра (Форматирование, я получил её, оторвав соответствующую панель инструментов от края окна). Сверху и справа две панели инструментов (бывшие палитры).

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

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

. Формально, называть словом «меню» то, что было, не совсем правильно (собU ственного говоря, меню в нашем понимании там отсутствовало как класс). Но поскольку располагалось это «нечто» на месте современных меню, я и выбрал такое название.

функциональность отдельного диалогового окна никогда не совпадает

сфункциональностью системы в целом). После того, как окно закрыто, происходит возвращение предыдущего (основного) режима. В этом и есть всё значение термина «режимный».

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

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

Избегайте режимов работы

Так появились безрежимные диалоговые окна, т.е. окна, которые можно было неограниченное время держать на экране, переключаясь по мере надобности между ними и собственно документом. К сожалению, и здесь не без проблем. Дело в том, что такие диалоговые окна нельзя делать тонущи% ми, т.е. позволять пользователю перекрывать их окнами документа или программы. Причина проста – пользователи забывают, что они когда%то открывали соответствующее окно и пытаются открыть его заново. Зачем, спрашивается, такие окна? Поэтому решили сделать такие окна плаваю% щими, т.е. перекрываемые только другими плавающими окнами этой же программы или другими программами. Разумеется, некоторые диалоговые окна невозможно сделать безрежимными: например, что делать с сообще% ниями об ошибках? Но, в целом, с переводом окна в безрежимное состояние нет особой проблемы.

Но и тут обнаружилась гадость. Дело в том, что просто диалоговое окно, даже будучи безрежимным, малополезно, поскольку перекрывает слишком много важного и нужного. Решение этой проблемы было эволюционным, а не революционным, и поэтому относительно простым – были придуманы палитры, т.е. окна, из которых выжали всё пустое место. Сразу оказалось, что палитры, помимо малых размеров, имеют одно большое достоинство: пользователи очень любят их расставлять на экране индивидуальным порядком. Пользы это особой не приносит, зато существенно повышает субъективное ощущение контроля над системой. К сожалению, визуальный дизайн палитр, как правило, довольно сложен и длителен, так что сугубо экономические причины мешают переделать в палитры все диалоговые окна.

Рис. 47. Пример палитры из программы Adobe PageMaker. К сожалению, из+за малых размеров палитр в них никогда не помещаются полноценные подписи к элементам, что существенно замедляет скорость обучения. Например, несмотря на то, что я пользуюсь PageMaker уже много лет, я до сих пор не знаю, что делает большая квадратная кнопка слева. © Adobe

Как легко догадаться, гадость была найдена и в палитрах. Существует неформальный, но на удивление верный закон1, гласящий, что субъектив% ная важность информации, перекрываемой диалоговым окном (палитрой в