Ответственные дизайнеры любят организовывать свои макеты по какой‑то системе, принятой в компании или основанной на своих соображениях. Любят группировать слои, давать специальные названия группам, кодировать их цветами, использовать Layer Comps.

На практике я столкнулся с тем, что довольно часто для технолога всё это не имеет никакого смысла и не помогает в вёрстке.

Дело вот в чём — вся работа технолога с макетами сводится к двум задачам:

  1. Понять, какие у макета есть состояния и ограничения.

  2. Визуально точно воспроизвести макет.

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

Если в одном макете сразу несколько состояний, то сгруппировать их не помешает:

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

Если в одном макете сразу несколько состояний, то сгруппировать их не помешает:

Состояния кнопок, комбобоксов и других элементов удобно показывать на отдельном листе в виде матрицы:

Кстати, это поможет не упустить пробелы в различных состояниях.

Решение второй задачи сводится к измерениям размеров и расстояний. Для этого не надо знать, в какой группе лежит та или иная кнопка. Технолог просто берёт Move tool и выбирает нужный элемент. Потом дошлифовывает, накладывая картинку макета на живую вёрстку.

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

Полная бессистемность в именовании слоёв косвенно подтверждает, что никакая система не нужна

На мой взгляд:

Бесполезно

Осмысленно называть каждый слой

Группировать каждый, даже самый маленький блок в соответствии с логической иерархией

Использовать Layer comps для сложных интерфейсов с большим количеством состояний

Будет полезно технологу

Давать названия крупным блокам и разным состояниям интерфейса

Группировать крупные блоки и разные состояния интерфейса

Использовать артборды

Показывать разные состояния на разных артбордах

А какой подход используете вы?

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.
Веб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы