Удобство использования на практике

Стратегии создания навигации приложений

Др. Чарльз Крейтцберг и Эмброз Литтл (Dr. Charles Kreitzberg, Ambrose Little)

Содержание

ПОЗНАВАТЕЛЬНОЕ ПРЕДСТАВЛЕНИЕ
Навигация – это метафора
Почему пользователи вводятся в заблуждение
Группирование нескольких страниц в логические разделы
Создание рамки
Использование средств навигации
Дополнительные расширения
МОДЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Копирование известных аналогов
Сортировка карт
Шаблоны проектирования UX
Ясные точки входа
Реализация
Элементы управления
Тестирование, отслеживание и настройка
Заключение

ПОЗНАВАТЕЛЬНОЕ ПРЕДСТАВЛЕНИЕ

Др. Чарльз Б. Крейтцберг

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

Навигация – это метафора

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

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

Рис. 1. Разбираем Word — все на одном экране

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

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

Рис. 2. В программе Excel также используется один экран

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

Почему пользователи вводятся в заблуждение

Если вдуматься, нет ничего удивительного в том, что перемещение между экранами вводит в заблуждение. Дезориентация означает, что пользователь теряет направление. Посмотрите на двух пользователей на рис. 3. Боб работает с программой на основе одного экрана. Салли работает с программой с несколькими экранами.

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

Рис. 3. Ввод пользователя в заблуждение

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

Всегда используйте навигацию с одной страницей, если это возможно.

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

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

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

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

Я придерживаюсь идеи проектирования, которая заключается в том, что следует избегать перемещения между экранами, если это возможно. Я объясню это на простом примере. На рис. 4 показана типичная навигация в Интернете.

Рис. 4. Типичная навигация в Интернете

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

Теперь взглянем на версию навигации с одним экраном (см. рис. 5). В этой версии три продукта представлены на наборе вкладок. При щелчке вкладки появляется описание продукта. При щелчке пользователем ссылки «Warranty Information» (Сведения о гарантии) появляется модальное всплывающее окно с информацией. При закрытии пользователем всплывающего окна он возвращается на исходную страницу.

Рис. 5. Модель навигации с одним экраном

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

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

Группирование нескольких страниц в логические разделы

Мой навигационный кошмар – простая ссылка HTML. (В действительности этот кошмар создали мы с моим коллегой Беном Шнейдерманом (Ben Shneiderman) с помощью HyperTies, гипертекстового обозревателя, существовавшего до Интернета, но мы сейчас не об этом.) При каждом щелчке пользователем сноски выполняется переход на новую страницу. Без тщательного проектирования в навигации можно легко заблудиться.

При создании продукта со множеством страниц тщательно продумайте объединение этих страниц в разделы. На рис. 6 показан типичный макет навигации с группировкой страниц на подразделы.

Рис. 6. Типичный макет навигации

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

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

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

Модель навигации, показанная на рис. 6, имеет явную иерархию. Это ясно видно при составлении путей.

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

Рис. 7. Навигация между разделами

1. Куда вы переходите при перемещении между разделами? Это зависит от процесса, которого вы пытаетесь достичь. В большинстве случаев наименее запутанным вариантом будет перемещение пользователя на первую страницу раздела (например, путь A на схеме) при первом посещении сеанса. Эту страницу можно сделать входом в раздел (это «домашняя» страница раздела). Затем я бы сохранил состояние меню боковой панели, чтобы при входе пользователя из раздела и последующем возврате он бы оказался на этой же странице.
2. Что если необходимо перейти (например) на страницу B или G?

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

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

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

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

Создание рамки

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

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

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

Использование средств навигации

Два распространенных средства навигации, которые стоит включить, – это деревья и карта узла. Но не надейтесь на них, чтобы решить проблемы дизайна. Многие пользователи не видят или не понимают деревья. Но для других пользователей это очень полезное средство. На веб-узле гуру по удобству использования Якоба Нильсена (Jakob Nielsen), useit.com, он отмечает, что все больше пользователей используют деревья. Он также особо подчеркивает (с чем я полностью согласен), что деревья должны отражать иерархию навигации, а не историю посещения страниц.

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

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

Помня об этом, ниже приведены некоторые предлагаемые рекомендации.

1. Минимизируйте усилия, необходимые для понимания и принятия решений о навигации. Чем проще использование пользовательского интерфейса, тем выше удобство использования.
2. По возможности используйте один экран. Используйте богатые возможностями многопанельные элементы управления, всплывающие окна и мастера, чтобы пользователи могли выполнять как можно большую часть задач, не прибегая к побочной навигации.
3. При создании нескольких страниц объединяйте их в разделы. Упростите перемещение между разделами с помощью основного элемента управления навигации и дополнительного элемента управления для перемещения между разделами. Избегайте углубления, если его можно избежать. Чем проще навигация, тем быстрее пользователи достигают эффективности.
4. Убедитесь, что ключевые элементы, такие как меню, заголовки и другая информация, отображающаяся на всех страницах, присутствует единообразно с визуальной точки зрения. Пользователь должен понимать, что некоторые элементы экрана стабильны и доступны для использования для обеспечения ориентирования.
5. Следует быть очень осторожным в отношении навигационных элементов управления для перемещения пользователей между внутренних страниц различных разделов. Это возможно, но это может просто дезориентировать пользователя.
6. Используйте дополнительные средства навигации, такие как деревья и карты узлов, но не полагайтесь на них.
7. 7.Всегда думайте о будущем расширении. Если в будущем ожидается включение в продукт новых функций, в начале необходимо решить, как будет расширяться навигация для эффективного включения новых экранов.

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

МОДЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Эмброз Литтл

Навигация – это одна из вещей, которую большинство специалистов по программному обеспечению принимают как должное, и, как и с большинством вопросов проектирования, обычно мы просто смотрим, что делают другие, и следуем их примеру. Мы получаем указания от менеджеров — «это должно выглядеть как Office» или «это должно выглядеть как Amazon.com» — но я считаю, что, если разработчики занимаются обеспечением работы программ, мы тратим немного времени на дизайн.

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

Копирование известных аналогов

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

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

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

Рис. 8. Лента Microsoft Word (часть пользовательского интерфейса Office Fluent)

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

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

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

Так что перед копированием других приложений необходимо определить, если ли смысл их дизайна в вашей ситуации. Имеется такой же масштаб? (Amazon.com и Netflix используют рекомендации на основе множества данных пользователей, для понимания чего требуется большой масштаб.) Office имеет массу команд, использующих преимущества многоуровневой организации ленты, но при наличии небольшого количества команд лучше использовать обычное меню.

Имеется такое же содержимое? То, что работает для веб-узла электронной коммерции, такого как Amazon, может не подходить для информационного узла в среде. То, что работает для информационного узла, может не подходить для приложения. Как упомянул Чарли, когда пользователи пытаются выполнить задачу, распространенная в Интернете неформальная модель навигации, скорее всего, не подойдет — вам необходимо помочь людям в достижении их целей, а не сбивать с толку или дезориентировать их.

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

Сортировка карт

Сортировка карт – это способ привлечения людей, желательно из целевой аудитории, к участию в организации содержимого (на рис. 9 показан пример). Она сходна с другими методами с участием заинтересованных лиц, такими как карты class-responsibility-collaboration (CRC) (метод объектно-ориентированной схемы, или OOD), заметки пользователей и другими подобными, в том, что основываются на активном участии заинтересованных лиц в проектировании решения (и использовании карт). Обычно она используется для организации информации на веб-узлах, но методы могут использоваться для организации команд в приложении.

Рис. 9. Пример сортировки карт с Usability.gov/ design/cardsort.html

Она использует ориентированный на пользователя, а не на решение (или домен) подход и поэтому помогает найти дизайн, имеющий смысл для тех, кто будет действительно взаимодействовать с решением. Я не буду углубляться в сам метод. Достаточно сказать, что она и пользователи систематизируют материал для вас. В Интернете доступно множество ресурсов (например, usability.gov/design/cardsort.html) и, кроме того, доступен ряд пакетов программного обеспечения, которые могут помочь, например OptimalSort. Но перед использованием программного обеспечения необходимо выбрать подход карты индекса. Эксперты соглашаются с тем, что сбор пользователей вместе и использование действительных карт обычно приводят к хорошим результатам.

Шаблоны проектирования UX

Вероятно, одним из лучших ресурсов в проектировании UX являются шаблоны. Неудивительно, что существует множество шаблонов проектирования для навигации, от Breadcrumb, который помогает пользователям ориентироваться, до Faceted Navigation, в котором используются элементы (метаданные) результатов поиска для их активной фильтрации, и до Modal Panel, в котором представлено знакомое модальное окно, и еще много шаблонов по середине. В качестве примера на рис. 10 показан пример шаблона Clear Entry Points.

Clear Entry Points

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

Рис. 10. Основной пример Clear Entry Points

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

Рис. 11. Облако тегов с веб-узла Flickr

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

Тестирование, отслеживание и настройка

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

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

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

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

Навигация очень важна; он стоит потраченных на нее времени и ресурсов. Это можно сделать постепенно с помощью шаблонов или использовать отличные простые для чтения руководства, например, Don't Make Me Think Стива Круга (Steve Krug) и Ambient Findability Питера Морвиля (Peter Morville). Людям, которым придется пользоваться вашим программным обеспечением, понравится это.

Др. Чарльз Крейтцберг (Dr. Charles Kreitzberg) – генеральный директор компании Cognetics Corporation (www.cognetics.com), представляющей консультации по удобству использования и проектированию взаимодействия с пользователями. Его страстью является создание интуитивно понятных интерфейсов, завлекающих и радующих пользователей и в то же время поддерживающих деловые задачи продукта. Чарльз живет в центральном Нью-Джерси, где подрабатывает музыкантом-исполнителем.

Эмброз Литтл (Ambrose Little) живет со своей женой и четырьмя детьми в центральном Нью-Джерси. Он занимается проектированием и разработкой программного обеспечения в течение более чем 10 лет и удостоился чести стать спикером INETA, а также обладателем звания наиболее ценного специалиста (MVP) Майкрософт. В последнее время он перешел с технической разработки к разработке для публики и является сейчас проектировщиком взаимодействия с пользователем для Infragistics.