Содержание · 8
Именование определяет живучесть системы. Разбираем схемы наименования, уровни абстракции и типичные ошибки, из-за которых токены становятся бесполезными.
Имя должно пережить значение
Главное правило именования: токен называется по роли, а не по внешнему виду. «color-blue» перестанет быть верным, как только акцент станет зелёным; «color-accent» переживёт любой ребрендинг.
То же с размерами: «space-16» лучше, чем «space-medium», потому что «средний» — понятие относительное, а 16 — точное.
Три уровня
Практика сошлась на трёхуровневой схеме. Каждый следующий уровень ссылается на предыдущий, а не задаёт значение напрямую.
Шкала отступов
Отступы должны браться из ограниченного набора, иначе в макетах появятся значения 13, 17 и 23 пикселя. Базовая единица 4 или 8 пикселей, шкала строится умножением.
Практичный набор: 4, 8, 12, 16, 24, 32, 48, 64, 96, 128. Десяти значений хватает почти на любой интерфейс.
- Одна базовая единица на всю систему.
- Не больше 10–12 значений в шкале.
- Именование по числу, а не по «small/medium/large».
- Отдельная шкала для внутренних отступов компонентов.
Цвет и темы
Поддержка тёмной темы решается на семантическом уровне: базовая палитра остаётся общей, а семантические токены получают разные значения в разных темах.
Именно поэтому важно не использовать базовые токены напрямую в компонентах: иначе тема не переключится.
Имя токена переживёт значение. «Цвет-опасности» живёт годами, «красный-500» умирает при первой смене палитры.
Синхронизация с кодом
Токены имеют смысл только тогда, когда одинаково называются в макетах и в коде. Расхождение в именах убивает систему быстрее всего: дизайнер говорит «акцент», разработчик ищет «primary».
Решается общим источником: файл токенов, из которого генерируются и переменные для кода, и библиотека для редактора макетов.
Что происходит при расхождении с кодом
Токены существуют в двух местах — в библиотеке макетов и в коде — и расходятся почти всегда. Дизайнер добавляет оттенок в макете, разработчик заводит переменную с другим именем, через полгода в системе два «акцента» с близкими значениями и никто не знает, какой из них верный.
Единственное надёжное решение — общий источник значений: файл токенов, из которого генерируются и переменные кода, и библиотека для редактора. Всё остальное держится на дисциплине и разваливается при первой же спешке.
Как назвать так, чтобы имя пережило значение
Общий принцип: имя описывает назначение, а значение остаётся сменным. Если при смене темы или палитры приходится переименовывать токены, система названа неверно.
- Плохо: «синий-600» — при смене фирменного цвета имя станет ложью.
- Хорошо: «поверхность-акцент» — описывает роль, а не цвет.
- Плохо: «отступ-16» — при смене шкалы придётся переименовывать всё.
- Хорошо: «отступ-м» — ступень шкалы, а не абсолютная величина.
- Плохо: «текст-серый» — не переживёт тёмную тему.
- Хорошо: «текст-второстепенный» — в тёмной теме меняется значение, не имя.
Что в итоге
Токены живут долго, если названы по роли, организованы в три уровня и одинаково называются в макетах и коде.
Ограничьте шкалу отступов десятью значениями и никогда не используйте базовые токены напрямую в компонентах.
Коротко
- Зачем нужны токены, если есть переменные?
- Токен — это переменная с назначением, а не со значением: не «серый 700», а «цвет второстепенного текста». Благодаря этому тему можно сменить целиком, не переписывая макеты и код.
- Сколько уровней токенов достаточно?
- Двух: базовый набор значений и смысловой слой поверх него. Третий уровень для отдельных компонентов заводят только тогда, когда без него действительно не обойтись, — иначе система становится непроходимой.
Состояния компонентов
Загрузка, ошибка, пустота, отключено, фокус с клавиатуры. Разбираем полный набор состояний и то, почему интерфейс разваливается именно на них.ДальшеЧитайте также
Посмотреть примеры
Нашли ошибку или неточность в атрибуции? Напишите нам
Обсуждение
Загружаем…