Пролистываемые списки

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

Размер. По-вертикали в список должно помещаться как минимум четыре строки, а лучше восемь. Список, содержащий пустое место в конце, смотрится неряшливо. Не следует забывать выводить полоски прокрутки в больших списках.

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

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

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

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

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

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

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

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

Размеры. Основная часть требований к полям ввода касается размера. Размер по вертикали должен быть производным от размера вводимого текста. Ширина поля по горизонтали должна соответствовать объему вводимого текста, поскольку гораздо удобнее вводить текст, который видишь. Ширина поля ввода не должна быть больше объема вводимого в поле текста, поскольку частично заполненное поле выглядит как минимум неряшливо. Ширина поля ввода не должна быть больше максимальной длины строки. Вопрос с ограничение объема вводимого текста нужно решать применительно к конкретной ситуации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окна Современная наука знает несколько типов окон, а именно: главные окна программы, окна документа, режимные диалоговые окна, безрежимные диалоговые окна, палитры, окна браузера.

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

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

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

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

Так родились панели инструментов, которые на самом деле могут содержать (и содержат) не только пиктограммы инструментов, но довольно сложные элементы управления.

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

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

Дело в том, что текст и, в меньшей степени, пиктограмма заголовка играют важную роль в ПО (они заведуют переключением задач) и очень важную в Интернете (заведуют навигацией).

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

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

Поскольку связки «программа-документ» в Интернете нет, эффективнее всего показывать адрес текущей страницы в навигационной системе сайта (если сайт иерархический). В данном случае релевантность требует, чтобы сначала шло название текущего документа, затем раздела, в котором он находится, затем раздела более высокого уровня и так далее. Не надо также забывать, что размер строки ограничен, так что более 70-80 символов в ней быть не может.

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

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

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

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

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

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

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

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

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

Фактически, чуть ли не единственным применением этих полосок является перемещение «примерно к нужному фрагменту» при работе с большими документами.

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

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

Если всё-таки приходится оставлять полосы прокрутки, крайне желательно добиться нескольких свойств полосок:

- Размер ползунка должен показывать общий объем пролистываемого документа.

- Стрелки на полосах должны быть спаренными, т.е. обе стрелки должны находиться рядом, а не на разных сторонах полоски.

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

- Обратите внимание, что местоположение подсказки при перемещении курсора должно оставаться неизменным.

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

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

Структура окна Структура и само устройство окна или экрана является самым существенным фактором, влияющим на качество интерфейса в этом окне.

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

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

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

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

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

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

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

Число вкладок. Теоретически число вкладок может быть сколь угодно большим. На практике оно ограничивается двумя факторами: во-первых, объемом КВП, а во-вторых, размером области, в которые ярлыки вкладок могут помещаться. Дело в том, что если ширина всех ярлыков будет больше ширины окна, придется либо делать несколько строк ярлыков, либо скрывать часть из них, пока пользователь не нажмет специальную кнопку. И то и другое плохо.

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

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

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

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

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

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

Не старайтесь рассортировать элементы так, чтобы в каждой вкладке их был одинаковое количество.

Терминационные кнопки. В диалоговом окне с вкладками терминационные кнопки обязательно должны располагаться вне области вкладок.

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

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

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

Последовательные окна. Особым вариантом окон являются действия, выполняющиеся в последовательности сменяющих друг друга окон (мастера).

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

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

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

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

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

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

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

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

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

Помимо элементов управления, меню и окон, интерфейс состоит из многих других «кирпичей», основными из которых являются пиктограммы, курсоры, цветовое кодирование и звуки.

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

Дело в том, что понимание того, что именно на пиктограмме изображено, не приводит автоматически к пониманию того, что эта пиктограмма означает. Недаром все пиктографические системы записи были вытеснены буквенными алфавитами.

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

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

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

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

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

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

В традиционном ПО пиктограмм используется довольно много: пиктограмма системы, пиктограммы отдельных файлов системы, которые пользователи могут как-либо изменять, пиктограммы документов, которые создаются и редактируются системой, пиктограммы инструментов системы, пиктограммы панели инструментов и меню, пиктограммы объектов, использующихся для реализации непосредственного манипулирования.

Количество типов пиктограмм в Интернете фактически исчерпывается одной позицией – пиктограммы меню.

Универсальные требования к пиктограммам

Разборчивость. Намеренное усиление контраста в изображении. Предназначено оно для того, чтобы максимально усилить уникальность формы пиктограммы и тем самым увеличить степень её запоминаемости. Также, в понятие разборчивости входит требование непохожести пиктограмм друг на друга.

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

Минимально возможная детализация сюжета. Перенос мелких деталей в сюжет пиктограммы неоправдан – на пиктограмме они отвлекают внимание и тем самым замедляют распознавание. Направление теней во всех пиктограммах должно быть одинаковым: снизу справа

Стандартность стилистики. Все пиктограммы в системе должны обладать единой стилистикой: последовательное выдерживание единого ракурса и иных изобразительных приемов.

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

Эстетическая привлекательность. По большей части субъективна.

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

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

Пиктограмма системы и пиктограммы файлов. Пиктограмма документа образуется от суммирования пиктограммы неопределенного документа из ОС и мотивов, почерпнутых из основной пиктограммы системы

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

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

Теперь о наборе пиктограмм. Поскольку пиктограммы этих типов показываются не только в самой системе, но и в ОС, делать их необходимо в трех вариантах (подразумевается, что они делаются для Windows): стандартного размера (32х32), уменьшенного (16х16) и, поскольку в последнее время мониторы выиграли в разрешении, увеличенного (48х48).

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

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

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

Но что вообще входит в понятие «красивого курсора»? Это, по преимуществу, все внешние курсоры, неважно, откуда они приходят, из ОС для ПО или CSS для сайта (набор курсоров в обоих источниках практически совпадают). Можно, конечно, нарисовать и собственные курсоры, но, поскольку все хорошие курсоры уже были кем-то нарисованы, вы можете легко нарушить чьи-то авторские права.

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

Во-первых, следует сразу сказать, что цветами невозможно передавать пользователям сколько-нибудь сложную информацию. Как правило, схемы типа «этот объект тёмный, значит…» не работают, поскольку требуют от пользователей длительной тренировки. С другой, стороны, люди хорошо способны замечать и анализировать взаимосвязи цветов, так, строки в таблице, окрашенные в разные цвета, подсознательно будут группироваться пользователями по цветовому признаку. Обратите внимание, что работать это будет только при очень ограниченном числе используемых цветов.

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

Не используйте кодирование цветом без крайней необходимости, когда же вы всё-таки его используете, добавляйте дополнительные способы индикации.

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

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

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

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

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

Документация есть часть интерфейса, причем в сложных системах – большая часть

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

Дата добавления: 2014-01-06