Жанр: Учеба
Дизайн пользовательского интерфейса
...характерными для них признаками, например, ссылку на почтовый адрес
пиктограммой письма1.
Группировка
элементов
Второй составляющей качества меню является группировка его элементов.
В большинстве меню группировка оказывает не меньшее значение при
поиске нужного элемента, нежели само название элемента, просто потому,
что даже идеальное название не сработает, если элемент просто нельзя
найти.
Чтобы уметь эффективно группировать элементы в меню, нужно знать
ответы на три вопроса: зачем элементы в меню нужно группировать, как
группировать элементы и как разделять группы между собой.
Зачем элементы в меню нужно группировать.
Меню, группы элемен
тов в котором разделены, сканируется значительно быстрее обычного,
поскольку в таком меню больше "точек привязки" (так же, как и в меню с
пиктограммами). К тому же наличие явных разделителей многократно
облегчает построение ментальной модели, поскольку не приходится гадать,
как связаны между собой элементы. Наконец, в объемных меню группиров
ка элементов облегчает создание кластеров в кратковременной памяти,
благодаря чему всё меню удается пометить в КВП.
. По этой же причине не рекомендуется что либо делать со строкой статуса (см.
стр. ): в интернете это практически единственный способ узнать, куда приведет
ссылка, не идя по ней.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Как группировать элементы.
Каждый знает, или, во всяком случае,
догадывается, что элементы в меню нужно группировать максимально
логично. Поспорить с этим утверждением нельзя, но от этого его
проблематичность не уменьшается.
Взаимоисключающие элементы желательно помещать в отдельный
уровень иерархии
Дело в том, что существует множество типов логики. Есть логика разра
ботчика, который знает все функции системы. Есть логика пользователя,
который знает только меньшую часть. При этом практика показывает, что
эти типы логики в значительной мере не совпадают. Поскольку пользо
ватели важнее, нужно сгруппировать меню в соответствии с их логикой.
Для этого используется очень простой и надежный метод, называемый
карточной сортировкой (см. стр. 118).
Как разделять группы между собой.
Существует два основных способа
разделять группы: между группами можно помещать пустой элемент (разде
литель) или же размещать отдельные группы в разных уровнях иерархии.
Второй способ создает более четкое разделение: в меню Файл, например все
элементы более близки друг другу (несмотря на разделители), чем элемен
ты других меню. В то же время выбор конкретного способа диктуется ре
зультатами карточной сортировки, так что интерес представляет только
вопрос "как должны выглядеть и действовать разделители".
Для разграничения групп традиционно используют полоски. Это надеж
ное, простое решение, другой разговор, что с дизайнерской точки зрения
полоски плохи, поскольку представляют собой визуальный шум. Гораздо
правильнее, но и труднее, использовать только визуальные паузы между
группами, как это сделано, например, в MacOS X.
Глубина меню. Наличие многих уровней вложенности в меню приводит
к там называемым "каскадным ошибкам": выбор неправильного элемента
верхнего уровня неизбежно приводит к тому, что все следующие элементы
также выбираются неправильно. При этом широкие меню больше нравятся
пользователям. Поэтому большинство разработчиков интерфейсов ста
раются создавать широкие, а не глубокие меню1.
К сожалению, у широких меню есть недостаток: они занимают много
места. Это значит, что, начиная с определенного количества элементов,
меню физически не сможет оставаться широким, оно начнет расти в глу
бину. Возникает проблема, которую надо решать. Итак, проблема заключа
ется в том, что велика вероятность каскадных ошибок. Чтобы снизить их
число, нужно повысить вероятность того, что пользователи будут правиль
но выбирать элементы верхних уровней. Чтобы повысить эту вероятность,
нужно заранее снабдить пользователей контекстом.
При перемещении по меню пользователь действует по определенному
алгоритму:
1 Выбирая элемент первого уровня, он выбирает элемент, "нужность"
которого кажется ему максимальной.
2 После выбора он видит список элементов второго уровня, при этом он
оценивает вероятность соответствия всех элементов второго уровня
его задаче и выбирает наиболее вероятный элемент. При этом в уме он
держит контекст, т. е. название элемента первого уровня.
3 Если ни один из элементов не кажется пользователю достаточно веро
ятным, пользователь возвращается на первый уровень.
4 Если какой то элемент удовлетворяет пользователя, он выбирает его и
получает список элементов третьего уровня. Действия из второго и
третьего шагов повторяются с новыми элементами меню.
. Напротив, с научной точки зрения оценить преимущество ширины перед
глубиной (и обратно) достаточно сложно. На эту тему было написано множество
работ, было проведено множество исследований, но четкого и однозначного
вывода сделать из них нельзя.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Видно, что действия пользователя при поиске нужного элемента
отчетливо цикличны, при этом на каждом шаге есть вероятность ошибок.
С каждым новым уровнем меню объем контекста, который приходится
держать в голове, непрерывно возрастает. При этом, если пользователь всё
таки не находит нужного элемента, весь этот контекст оказывается
ненужным. Хранение же контекста, даже не засчитывая усилия,
затрачиваемые на выбор элемента, есть довольно существенная работа. Её
объем лучше уменьшить.
Теперь рассмотрим другой вариант: пользователь по самому элементу
может предугадать его содержимое, т. е. при поиске элемента в меню не
столько оценивает контекст, сколько просто ищет нужный элемент. Эта
возможность есть в любом случае, поскольку элемент имеет хоть сколько
нибудь значимый идентификатор (т. е. его название). Но она, как правило,
довольно слаба и почти всегда допускает неоднозначность. Усилить её
можно наличием аннотации к каждому элементу, но эту аннотацию никто
не будет читать.
Есть другой метод, и этот метод есть, пожалуй, лучшее, что дал интернет
науке о проектировании интерфейсов: в качестве аннотации к элементу
можно показывать наиболее популярные элементы следующего уровня.
Рис. 45. Насколько я знаю, такой элемент управления для меню впервые появился в
каталоге Yahoo. Несмотря на то, что с тех пор этот элемент сейчас присутствует на мно
жестве сайтов, я, стремясь подчеркнуть заслугу Yahoo, выбрал оригинал. Yahoo! Inc
В этом случае пользователь может сформировать контекст элемента, не
перемещаясь внутрь этого элемента, при этом вероятность ошибочного
перехода значительно снижается. Помимо уменьшения числа ошибок,
такая система позволяет ускорить доступ к наиболее популярным
элементам второго и последующих уровней.
В целом, ширина и глубина меню являются, пожалуй, наименее значи
мыми факторами. Гораздо важнее хорошая группировка, при этом как
группировку, так и структуру дерева меню, всё равно лучше определять
карточной сортировкой (см. стр. 118).
Применительно же к раскрывающимся меню действует ещё один ограни
читель глубины. Раскрывающиеся меню довольно тяжелы в использовании,
поскольку требуют от пользователей достаточно тонкой моторики. Поэто
му главное меню с более чем тремя уровнями вложенности просто
невозможно.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: МЕНЮ
Контекстные меню
Преимущество контекстных (всплывающих) меню заключается в том, что
они полностью встраиваются в контекст действий пользователей: не нужно
переводить взгляд и курсор в другую область экрана, практически не нужно
прерывать текущее действие для выбора команды. При этом они не зани
мают места на экране, что всегда ценно. С другой стороны, из за того, что
они не находятся всё время на экране, они практически неспособны чему
либо научить пользователя.
Не делайте контекстные меню единственным способом вызова какой либо
функции
Поскольку основной причиной появления контекстных меню является
стремление максимально повысить скорость работы пользователей, на их
размер и степень иерархичности накладываются определенные ограниче
ния. Если меню будет длинным, пользователям придется сравнительно
долго возвращать курсор на прежнее место, так что привлекательность
нижних элементов окажется под вопросом. Поэтому лучше сокращать раз
мер контекстных меню до разумного минимума (порядка семи элементов).
К тому же не надо забывать, что главное меню не всегда перекрывает
выделенный (т. е. актуальный объект), а контекстное меню - почти всегда
(как никак оно вызывается на самом объекте). В большинстве же случаев
перекрытие актуального объекта нежелательно (сбивается контекст). Мы
не можем сделать в этой ситуации ничего, кроме как уменьшить размер
меню, в расчете, что маленькое меню будет перекрывать малое количество
информации. Разумеется, если точно известно, что оперируемый объект
совсем уж мал, сокращать объем меню бесполезно.
Другая особенность контекстных меню - иерархия. В обычном меню
иерархия имеет хотя бы одно достоинство: при обучении она позволяет
упорядочивать элементы меню и тем самым делать его понятнее. В кон
текстных же меню обучающая функция не играет никакой роли, поскольку
такими меню пользуются только опытные пользователи. Иерархия элемен
тов теряет свое единственное достоинство, не теряя ни одного недостатка.
Поэтому делать иерархические контекстные меню можно, ничего плохого
в этом нет, но необходимо сознавать, что вложенными элементами почти
никто не будет пользоваться (тем более что вложенность сбивает контекст
действий).
Система сначала должна показывать максимально релевантную
информацию, затем всё остальное
Последнее отличие контекстных меню от обычных заключается в том,
что в них очень важен порядок следования элементов. В главном меню не
обязательно стремиться к тому, чтобы наиболее часто используемые эле
менты были самим первыми - все равно курсор придется возвращать к
рабочему объекту, так что разницы в дистанции перемещения курсора
практически нет. В контекстном же меню ситуация обратная - чем дальше
нужный элемент от верха меню, тем больше придется двигать курсор.
Поэтому правило релевантности в таких меню действует в полной мере.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Окна
Поскольку разработка интерфейса заключается в основном в том, чтобы
правильно помещать правильные элементы управления в правильные окна
или экраны, окна требуют не меньше заботы, чем элементы управления.
Типы окон
Буржуазная псевдонаука знает несколько типов окон, а именно:
главные окна программы
окна документа
режимные диалоговые окна (о разнице между режимными и
безрежимными окнами см. стр. 85)
безрежимные диалоговые окна
палитры
окна браузера (поскольку используемая в интернете технология
существенно отличается от технологии ПО, этот тип окон стоит
несколько особняком).
При этом доля отдельных типов в общем пироге со временем изменя
ется: окна документов, как будет показано ниже, отмирают, заменяясь
окнами программ, режимные диалоговые окна сменяются безрежимными,
а безрежимные, в свою очередь, палитрами. Интересно, что идея палитр
тоже клонится к закату (палитры сменяются панелями инструментов,
причины этого опять таки рассмотрены ниже), так что в будущем, скорее
всего, в ПО останутся только окна программ, панели инструментов и
режимные диалоговые окна (которые разработчики поленятся
переделывать). Но об этом отдельно.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Недолгая история
окон на экране
Сейчас многим в это трудно поверить, но сравнительно недавно никаких
окон не было, даже диалоговых окон, которые уже стали восприниматься
как данность. Вместо них какая то часть экрана выделялась под меню1,
которое в те времена было функционально более богатым, чем меню
теперешнее (так, нормой были поля ввода в меню).
Рис. 46. Типы окон на примере MS Word 97. Самое большое окно есть окно программы.
Внутри него два окна документов, в более свежих версиях Word их уже нет. Слева
сверху располагается режимное диалоговое окно (Абзац), под ним справа - безре
жимное (Найти и заменить). Слева внизу располагается палитра (Форматирование, я
получил её, оторвав соответствующую панель инструментов от края окна). Сверху и
справа две панели инструментов (бывшие палитры).
Потом, с появлением графического режима, стало возможным реали
зовать в интерфейсе метафору рабочего стола (если бумажные документы
могут лежать на столе друг на друге, то почему этого не могут делать
электронные документы?). Появились окна программ, окна документов и
диалоговые окна, первоначально сплошь режимные.
Понятие "режимное диалоговое окно" кажется довольно загадочным
(еще более загадочным кажется его англизированный вариант "модальное
диалоговое окно", из за чего я этот вариант не употребляю). На самом деле
всё просто. Если открывшееся окно блокирует доступ к остальной части
системы, происходит, фактически, запуск нового режима работы (поскольку
. Формально, называть словом "меню" то, что было, не совсем правильно (соб
ственно говоря, меню в нашем понимании там отсутствовало как класс). Но
поскольку располагалось это "нечто" на месте современных меню, я и выбрал
такое название.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
функциональность отдельного диалогового окна никогда не совпадает
с функциональностью системы в целом). После того, как окно закрыто,
происходит возвращение предыдущего (основного) режима. В этом и есть
всё значение термина "режимный".
Прошло несколько лет, и наличие режима в диалоговых окнах стало
немодным. Во первых, всех раздражает, что, вызвав диалоговое окно и
обнаружив, что вызвано оно преждевременно, приходится закрывать окно
и открывать его в следующий раз заново. Во вторых, что важнее, в систе
мах, ориентированных на документы, режим сбивает внимание пользо
вателя и вообще лишает его ощущения управляемости (в отличии систем,
ориентированных на формы ввода, в которых режим работает лучше, чем
его отсутствие). В третьих, сама по себе идея сближения интерфейса
с реальным миром (в частности, метафора рабочего стола) протестовала
против идеи режимов в любом их проявлении, поскольку в реальном мире
вообще не бывает режимов, аналогичным интерфейсным. А поскольку
"дизайн пользователей" был ориентирован на функционирование в
реальном мире, решили не переделывать пользователей, а переделать
интерфейс.
Избегайте режимов работы
Так появились безрежимные диалоговые окна, т. е. окна, которые можно
было неограниченное время держать на экране, переключаясь по мере
надобности между ними и собственно документом. К сожалению, и здесь не
без проблем. Дело в том, что такие диалоговые окна нельзя делать тонущи
ми, т. е. позволять пользователю перекрывать их окнами документа или
программы. Причина проста - пользователи забывают, что они когда то
открывали соответствующее окно и пытаются открыть его заново. Зачем,
спрашивается, такие окна? Поэтому решили сделать такие окна плаваю
щими, т. е. перекрываемые только другими плавающими окнами этой же
программы или другими программами. Разумеется, некоторые диалоговые
окна невозможно сделать безрежимными: например, что делать с сообще
ниями об ошибках? Но, в целом, с переводом окна в безрежимное
состояние нет особой проблемы.
Но и тут обнаружилась гадость. Дело в том, что просто диалоговое окно,
даже будучи безрежимным, малополезно, поскольку перекрывает слишком
много важного и нужного. Решение этой проблемы было эволюционным,
а не революционным, и поэтому относительно простым - были придуманы
палитры, т. е. окна, из которых выжали всё пустое место. Сразу оказалось,
что палитры, помимо малых размеров, имеют одно большое достоинство:
пользователи очень любят их расставлять на экране индивидуальным
порядком. Пользы это особой не приносит, зато существенно повышает
субъективное ощущение контроля над системой. К сожалению, визуальный
дизайн палитр, как правило, довольно сложен и длителен, так что сугубо
экономические причины мешают переделать в палитры все диалоговые
окна.
Рис. 47. Пример палитры из программы Adobe PageMaker. К сожалению, из за малых
размеров палитр в них никогда не помещаются полноценные подписи к элементам, что
существенно замедляет скорость обучения. Например, несмотря на то, что я пользуюсь
PageMaker уже много лет, я до сих пор не знаю, что делает большая квадратная кнопка
слева. Adobe
Как легко догадаться, гадость была найдена и в палитрах. Существует
неформальный, но на удивление верный закон1, гласящий, что субъектив
ная важность информации, перекрываемой диалоговым окном (палитрой в
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
частности), не зависит ни от размеров, ни от положения окна, а зависит
только от периметра. В результате постоянно оказывается, что пользо
ватели, стараясь открыть нужную информацию, перекладывают окна с
места на место, что снижает производительность (несущественно) и
субъективное удовлетворение (существенно). При этом, если сделать
палитру маленькой, снизится вероятность её вынужденного перетаскива
ния, но зато вырастет субъективное неудовольствие от её перетаскивания
("такая маленькая, а так раздражает"). Более того. Гораздо чаще оказы
вается так, что палитра перекрывает не всю нужную информацию, но её
часть; при этом всё равно палитру приходится перемещать. Единственным
способом избавиться от этого эффекта является уменьшение периметра
палитры, а добиться этого можно, только прикрепив палитры к краю
экрана.
Так родились панели инструментов, которые на самом деле могут
содержать (и содержат) не только пиктограммы инструментов, но довольно
сложные элементы управления. В некотором смысле, это возвращение к
началу, к временам, когда один из краев экрана был занят громадным и
очень функциональным меню. С другой стороны, оказалось, что это
наиболее эффективно.
Параллельно с рождением сложных панелей инструментов происходит
ещё одна драма борьбы за выживание. Окна документов вымирают1. Выми
рают они по двум простым причинам. Во первых, они плохо согласуются с
ментальной моделью большинства пользователей. Во вторых, невозможно
придумать сколько нибудь эффективного способа переключаться между
ними. Самый эффективный (с точки зрения разработчиков операционной
системы, разумеется) способ обычно отдается переключению между
программами, соответственно, переключению документов достается
заведомо худший способ. В Windows, из за разнобоя в способах переклю
чения между документами (поскольку все разработчики самостоятельно
старались найти какой либо приемлемый или неприемлемый способ),
возникают трогательные казусы: в MS Word, например, официальным
способом для клавиатурного переключения между документами является
комбинация клавиш Ctrl+F6. Попробуйте использовать эту комбинацию
клавиш одной рукой, и вы поймете, что это невозможно. Главное же в
другом: с самого начала окна документов были не столько желаемым
свойством системы, сколько хаком. Для того чтобы запустить две
одинаковые программы, каждая с одним документом внутри, не хватало
ресурсов компьютера, вот и приходилось запускать одну программу с двумя
документами. Сейчас, напротив, памяти достаточно, к тому же появились
технологии программирования, позволяющие ни о чем таком даже не
думать. Так что окна документов умирают. Не будем им мешать.
. Его открыл я.
. Во всех операционных системах, кроме Mac OS, устройство которого таково, что
разницы между окном программы и окном документа не было никогда.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Элементы окна
Окна, помимо областей с элементами управления, имеют некоторые общие
элементы, главными из которых являются строки заголовка окна, строки
статуса, панели инструментов и полосы прокрутки.
Строка
заголовка окна
У каждого окна есть строка заголовка. Человеку не свойственно обращать
внимание на обыденность, особенно если эта обыденность не находится в
фокусе его внимания (а строка заголовка как раз в нем не находится).
Поэтому пользователи строкой заголовка интересуются весьма мало.
В результате, пользователи обращают внимание на строку заголовка,
только обучаясь пользоваться компьютером или в ситуациях, когда они
совсем ничего не понимают в системе. Из этого, однако, не следует, что
строкой состояния можно пренебрегать. Точнее, самой строкой как раз
пренебречь можно, но её содержимым - нельзя.
Дело в том, что текст и, в меньшей степени, пиктограмма заголовка
играют важную роль в ПО (они заведуют переключением задач) и очень
важную в интернете (заведуют навигацией).
Рис. 48. Влияние строки заголовка окна на переключение между задачами. Панель
задач в Windows создает по кнопке для каждой запущенной программы. Поскольку
ширина экрана ограничена, при увеличении количества запущенных программ
размеры кнопок сокращаются, соответственно в эти кнопки помещается меньше
текста. В результате пользователь сохраняет способность опознать программу по её
пиктограмме и обрывку текста, но теряет возможность опознавать документы
(обратите внимание, что даже в верхнем примере полное название документа
определить невозможно). Проблемы можно было бы избежать, если бы название
программы на кнопке (и в строке заголовка окна) было бы короче и/или название
документа выводилось бы до названия программы. Заодно пользователям не
пришлось бы сотни и тысячи раз читать название программы (последствия
неумеренного продвижения торговой марки).
С переключением задач всё просто и сложно одновременно. Просто,
поскольку правило тут простое "Релевантное выводится в первую очередь".
Поскольку пользователю нужен именно конкретный документ конкретной
программы, а вовсе не программа просто (мы уже определили, что окна
документов, не попадающие в переключатель задач, нехороши), названия
документов, как более релевантные, нужно выводить в первую очередь.
Наоборот, сложность состоит в том, что из за жесткости интерфейса
Windows много не сделаешь. Тем не менее, сокращать название программы
нужно безусловно.
Иная ситуация в интернете. Поскольку пиктограмма в строке заголовка
приходит от браузера, нет особой возможности оптимизировать переклю
чение задач. С другой стороны, качество этого заголовка оказывает сущест
венное влияние на навигацию, поскольку при показе результатов поиска в
поисковых системах заголовком элемента становится содержимое тега Title.
Каковое содержимое и попадает в обычном режиме на верх экрана. При
этом в интернете нет проблемы с текстом заголовка - что хотим, то и
пишем (стараясь не обращать внимания на то, что к этому прибавится
название браузера).
Нажатие на пиктограмму в строке заголовка вызывает раскрывающееся
меню, являющееся замечательным местом для вызова функций, которые
нужны только наиболее опытной аудитории
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Правило релевантности действует и здесь - в начале строки должна быть
более релевантная информация, нежели в её конце. Поскольку связки
"программа документ" в интернете нет, эффективнее всего показывать
адрес текущей страницы в навигационной системе сайта (если сайт иерар
хический). В данном случае релевантность требует, чтобы сначала шло
название текущего документа, затем раздела, в котором он находится, затем
раздела более высокого уровня и так далее. Не надо также забывать, что раз
мер строки ограничен, так что более 70 80 символов в ней быть не может.
Также важно понимать, что тот факт, что пользователи редко читают
заголовки окна, вовсе не означает, что заголовки пользователям не нужны.
Напротив, хороший заголовок может здорово облегчить понимание
работы диалога. Поэтому наличие на экране заметного и адекватного
заголовка окна часто оказывается очень полезным. Жалко только, что в
обычном Windows интерфейсе места под него нет.
Строка статуса
Строка статуса является, пожалуй, самым недооцененным элементом
интерфейса (во всяком случае, способы её использования в интернете
существенно портят статистику). В то же время она заслуживает лучшей
участи.
Почему то распространено мнение, будто строка статуса предназначена
для того, чтобы информировать пользователей о значении тех или иных
элементов интерфейса. Подразумевается, что если пользователь подводит
курсор к какому либо элементу, в строке статуса появляется краткое его
описание. На самом деле строка не может этого делать вообще: дело в том,
что курсор находится в одном месте, а подсказка появляется совсем в
другом, пользователю при этом приходится читать подсказку либо
переводя взгляд, либо периферийным зрением. Разумеется, никто в таких
условиях читать подсказку не будет, причем те, кто уверен, что строка
статуса есть место для подсказки, чувствуют это прекрасно. Неудивительно,
что разработчики строку статуса игнорируют.
В действительности строка статуса предназначена для двух вещей: она
может быть либо собственно строкой статуса, т. е. отображать текущее
состояние системы, либо быть панелью инструментов для опытных
пользователей (или же делать и то, и другое). Разберем это подробнее.
Отображение текущего состояния системы
. Практически каждая
система имеет свойства, либо зависящие от документа, либо изменяющиеся
со временем. Например, в иллюстративных программах объекты имеют
какие либо свойства, причем не все эти свойства показываются. Другой
пример: когда система долгое время занята, она должна показывать пользо
вателю индикатор степени выполнения. И, наконец, самый простой
пример: пользователь текстового процессора имеет право знать, на какой
странице документа он сейчас находится. Эффективнее всего выводить всё
это в строке с
...Поділитися у соцмережах
