HIF / Документация / Представление

Визуальный язык HIF

1. Роль визуального языка

Визуальный язык выражает семантическую модель. Он не создаёт её.

Последовательность проектирования:

смысл
→ структура
→ состояния
→ взаимодействие
→ визуальная и звуковая форма

Изменение темы MAY менять форму, но MUST сохранять значение.

2. Information architecture

До стилизации должны быть определены:

объекты и их отношения;
первичные пользовательские задачи;
иерархия содержания;
постоянная и контекстная навигация;
critical paths;
состояния empty, loading, error и success.

Layout не должен маскировать отсутствие информационной архитектуры.

3. Иерархия

Иерархия строится сочетанием:

порядка;
положения;
размера;
пространства;
контраста;
веса;
группировки;
движения.

Не следует одновременно усиливать элемент всеми средствами без необходимости. Визуальная громкость должна соответствовать значимости и частоте.

Primary action определяется задачей, а не желанием максимизировать conversion.

4. Layout

4.1. Опорная структура

Каждый интерфейс определяет:

content regions;
navigation regions;
work area;
system/status area;
transient layers;
safe areas;
reflow rules.

4.2. Grid

Grid является инструментом согласования, а не обязательной эстетикой. Он MAY быть:

колонным;
модульным;
spatial;
базовый;
управляемый средой.

4.3. Пространство

Spacing выражает отношения. Близкие элементы воспринимаются как связанные. Одинаковый spacing SHOULD означать одинаковый уровень связи.

Tokens SHOULD строиться из ограниченной шкалы, но шкала MAY различаться между density profiles.

4.4. Reflow

При изменении размера приоритеты определяются заранее:

сохранение функции;
сохранение содержания;
сохранение контекста;
изменение композиции;
сокращение второстепенного представления.

Масштабирование всего desktop как картинки обычно не является адаптацией.

5. Typography

5.1. Роли

Минимальная типографическая система:

display;
page title;
section heading;
body;
interface label;
supporting text;
data;
code/monospace.

Роль определяется не только размером, но и line-height, weight, width и контекстом.

5.2. Читаемость

Система MUST поддерживать:

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

Font weight SHOULD использовать существующее начертание, а не искусственный синтез, когда это влияет на качество.

5.3. Выбор гарнитуры

HIF не устанавливает одну обязательную гарнитуру для всех продуктов. Product profile определяет:

UI family;
reading family;
monospace family;
стек резервных шрифтов;
supported scripts;
лицензирование и распространение;
performance budget.

5.4. Технические данные

Monospace используется для данных, где выравнивание и различение символов важнее текстовой пластики: code, hashes, IDs, paths, terminal. Он не должен автоматически применяться ко всему «техническому» интерфейсу.

6. Color

6.1. Семантические роли

Color tokens описывают функцию:

canvas;
surface;
text;
muted text;
border;
accent;
focus;
success;
warning;
danger;
information;
selection.

Названия вроде blue500 MAY существовать в palette, но component contract должен зависеть от semantic token.

6.2. Контраст

Контраст проверяется для текста, controls, focus, графики и всех состояний. Соответствие одной пары цветов не гарантирует доступность темы целиком.

6.3. Цвет и состояние

Существенное различие дублируется формой, текстом, icon, pattern или положением. Красный не является самостоятельным сообщением об ошибке.

6.4. Темы

Theme contract определяет полную систему пар foreground/background и состояний. Dark theme не получается механическим инвертированием.

Forced colors и пользовательский contrast имеют приоритет над brand fidelity.

7. Components

Компонент включает:

семантическую роль;
accessible name strategy;
состояния;
команды;
keyboard model;
pointer/touch behavior;
размеры и constraints;
content rules;
error/empty/loading behavior;
tokens;
тесты.

Скриншот normal state не является спецификацией компонента.

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

8. Controls и hit areas

Видимая форма и интерактивная область MAY различаться, но hit area не должна создавать неожиданные перекрытия.

Размер определяется:

способом ввода;
плотностью;
частотой;
риском ошибки;
расстоянием между целями;
доступностью альтернативы.

Compact mode не освобождает от минимальной управляемости.

9. Iconography

Icon должен:

иметь определённое значение;
соответствовать стилю набора;
сохранять читаемость в целевых размерах;
иметь text alternative для assistive technologies;
сопровождаться label, когда значение не является устойчиво общеизвестным.

Одна иконка не должна обозначать разные опасные действия в соседних контекстах.

Emoji не являются надёжной заменой системному icon set из-за платформенной вариативности.

Third-party icon set проходит лицензионную проверку до включения.

10. Images, wallpaper и illustration

Изображение используется, если передаёт содержание, идентичность или ориентацию. Оно не должно:

снижать контраст controls;
имитировать interactive element;
создавать ложное системное состояние;
быть единственным носителем инструкции.

Background и wallpaper должны выдерживать непредсказуемый foreground либо система обязана обеспечивать backplate/scrim.

11. Elevation и layers

Тень, border, blur и z-position выражают layer и отношение к контексту.

Одинаковый elevation SHOULD означать сходную модель:

embedded;
raised;
floating;
overlay;
modal;
critical.

Blur и transparency не должны быть необходимы для различения boundaries.

12. Движение

Motion используется для:

continuity;
происхождения и назначения;
изменения состояния;
spatial orientation;
подтверждения.

Motion profile определяет:

duration ranges;
easing roles;
interruptibility;
reduced-motion alternative;
поведение при низкой производительности.

Анимация не должна задерживать доступ к результату после фактической готовности. Decorative loop SHOULD быть редким и останавливаемым.

13. Sound и haptics

Sound и haptics MAY дополнять:

подтверждение;
предупреждение;
spatial cue;
critical event.

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

Системные настройки mute, volume и reduced feedback имеют приоритет.

14. Density

Density — профиль геометрии, а не масштабирование CSS.

Типовые профили:

comfortable;
compact;
touch;
large/accessible;
kiosk/distance.

Density MAY изменять spacing и видимый объём данных, но MUST сохранять:

семантику;
порядок;
hit-area requirements;
focus;
читаемость;
доступность команд.

15. Design tokens

Рекомендуемые слои:

primitive tokens
→ semantic tokens
→ component tokens
→ environment/brand overrides

Переопределение нижнего слоя не должно обходить ограничение доступности.

Token SHOULD иметь:

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

16. Originality и reference

Референс используется для понимания:

архитектуры;
поведения;
культурного соглашения;
уровня качества.

Reference не даёт права копировать код, assets, trade dress или branding. Производный интерфейс должен иметь собственную идентичность и проверенное происхождение материалов.