HIF / Документация / Паттерны

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

Версия: 0.2

1. Что такое паттерн

Паттерн — повторяемый ответ на повторяющуюся проблему в указанном контексте. Это не screenshot, название компонента или визуальное предписание.

Паттерн для промышленного применения MUST определять проблему, контекст и намерение; объекты, команды и состояния; предусловия и последствия; семантику доступности и эквивалентность ввода; содержание; адаптивность и локализацию; ошибки и восстановление; доказательства, ограничения, misuse и acceptance tests.

Используйте platform-native convention, когда оно несёт установленный смысл и не нарушает более сильное требование. Новая форма MAY отличать бренд; новая семантика требует доказательств.

2. Действия

Primary и secondary

Иерархия действий SHOULD следовать последствиям и порядку задачи. Визуальная выраженность MUST NOT искажать важность, безопасность или коммерческий интерес.

Destructive action

Назовите объект и последствие, отделите действие от повседневных команд, предотвратите случайный запуск, подтвердите пропорционально риску и дайте undo/recovery, где возможно.

Command menu

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

Batch action

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

3. Ввод

Text input

Используйте постоянный видимый label, сообщайте ограничения до ввода, принимайте безопасные варианты, сохраняйте значение и связывайте error с полем и summary.

Choice

Radio — один вариант из небольшого видимого набора; checkbox — независимые варианты; select — длинный знакомый список или реальное ограничение места. Switch означает немедленно применяемое бинарное setting, а не отправку решения.

Date, time и quantity

Принимайте форматы locale и задачи. Объясняйте границы и timezone, если они существенны. Не навязывайте calendar для даты, которую проще ввести.

File upload

До передачи сообщите types, limits, security processing и progress. Retry не должен удалять корректную окружающую работу.

Search и autocomplete

Сохраняйте введённый текст, различайте suggestions и results, обеспечьте keyboard. Suggestion MUST NOT подменять намерение без согласия.

4. Навигация

Link ведёт к ресурсу или месту; button выполняет команду. Внешний вид MAY меняться, но semantic role и ожидаемое browser behaviour MUST быть правдивыми.

Tabs

Tabs переключают равноправные представления одного контекста. Они SHOULD NOT обозначать длинный процесс, навигацию всего сайта или зависимые шаги.

Breadcrumbs отражают стабильную иерархию, не заменяют back и не показывают произвольную историю.

Pagination и progressive loading

Pagination нужна для стабильной позиции, sharing и осознанного обхода. Progressive loading MAY помогать исследованию, но MUST сохранять focus, history, reachability и путь дальше текущей порции.

Step flow

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

5. Disclosure и layers

Accordion/details — для необязательного подчинённого содержания, не для сокрытия информации решения. Tooltip MAY кратко пояснять, но MUST NOT быть единственным местом команды или важной информации и MUST работать без hover.

Modal dialog допустим для ограниченного решения, которое должно прервать контекст. Ему нужны name, contained focus, logical initial focus, escape и focus restoration. Popover/menu требуют правил dismissal, focus и collision.

6. Обратная связь

Inline validation должна появляться, когда помогает действию, а не на каждом нажатии. Determinate progress используется при известной доле, indeterminate — при неизвестной. Fake progress не является доказательством завершения.

Notification выбирает persistence и interruption по срочности и последствиям. Transient message MUST NOT быть единственной записью значимого результата.

Empty state различает first use, no results, cleared data, unavailable data и permission limit.

7. Представление данных

Table нужна для сравнения по общим измерениям и требует настоящих headers, relationships, responsive access и невизуального понимания sort/state. List выражает повторяющихся peers. Card группирует данные и действия одного объекта.

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

8. Account, permission и trust

Authentication поддерживает password managers, paste и accessible authentication. Permission спрашивается в момент потребности, объясняет capability/consequence, даёт отказ и способ изменить выбор.

Consent MUST быть specific, informed и freely chosen. Necessary processing и optional preference различаются; refusal MUST NOT требовать большей скрытой трудности.

9. Допуск паттерна

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

One-off composition SHOULD оставаться локальной до появления повторения и доказательств.

Источники