Навигация и ориентация¶

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

Названия разделов говорят языком задачи¶

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

Текущее положение всегда видно¶

Активный пункт навигации выделяется не только цветом: WCAG 2.2 в критерии 1.4.1 Use of Color (уровень A) запрещает передавать информацию исключительно цветом, поэтому выделение дублируют начертанием, маркером или фоном, а для вспомогательных технологий - атрибутом aria-current="page". Заголовок страницы совпадает с пунктом, по которому пользователь пришёл, иначе он не уверен, что попал куда хотел. Навигационная цепочка полезна там, где иерархия глубже двух уровней и пользователь попадает на страницы извне, например по ссылке из письма; в плоской структуре она лишь занимает место.

Состояние сохраняется в адресе¶

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

Возврат к работе без потерь¶

Если пользователь покинул экран во время выполнения задачи, он должен вернуться к тому же месту: к той же позиции в списке и к тому же введённому тексту в форме. Если сохранение состояния невозможно, интерфейс должен предупредить о возможной потере данных до того, как пользователь уйдёт, а не после. Например, это предупреждение можно увидеть в диалоге «Несохранённые изменения», который описан в разделе Типовые диалоги. Важно показывать это предупреждение только тогда, когда есть реальный риск потери данных. Если выводить его на неизменной форме, это может привести к тому, что пользователи привыкнут закрывать его, не читая.

Поиск как вторая навигация¶

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

Адаптивная и отзывчивая вёрстка¶

Отзывчивая (responsive) вёрстка непрерывно перестраивает одну и ту же разметку под ширину окна; адаптивная (adaptive) отдаёт заранее подготовленные варианты для определённых классов устройств. Для навигации различие существенно: при отзывчивом подходе меню сворачивается в кнопку на узком экране, но набор пунктов сохраняется, а при адаптивном мобильная версия может сознательно предлагать другой набор, ориентированный на мобильные задачи. Второй путь оправдан, когда задачи на телефоне действительно другие (просмотр и согласование вместо настройки), но требует поддержки двух моделей навигации и создаёт риск, что пользователь не найдёт на телефоне привычную функцию. Критерий 1.4.10 Reflow (AA) требует, чтобы содержимое было доступно без горизонтальной прокрутки при ширине 320 CSS px, что фактически делает отзывчивую основу обязательной в любом случае.