Ответственные дизайнеры любят организовывать свои макеты по какой‑то системе, принятой в компании или основанной на своих соображениях. Любят группировать слои, давать специальные названия группам, кодировать их цветами, использовать Layer Comps.
На практике я столкнулся с тем, что довольно часто для технолога всё это не имеет никакого смысла и не помогает в вёрстке.
Дело вот в чём — вся работа технолога с макетами сводится к двум задачам:
Понять, какие у макета есть состояния и ограничения.
Визуально точно воспроизвести макет.
Для решения первой задачи в идеальном мире существуют строгие правила организации макетов, которых неукоснительно придерживаются и дизайнеры, и технологи. Но шансы сформулировать такие простые и однозначные правила довольно призрачны. Мне ни разу не удавалось. Каждый проект разный и всегда появляются исключения, не вписывающиеся в правила.
Если в одном макете сразу несколько состояний, то сгруппировать их не помешает:
Если дизайнер хочет показать некую взаимосвязь состояний интерфейса с помощью различных группировок слоёв или артбордов, то это может быть понятно ему, но не другому человеку. Поэтому все состояния нужно показывать отдельными картинками.
Если в одном макете сразу несколько состояний, то сгруппировать их не помешает:
Состояния кнопок, комбобоксов и других элементов удобно показывать на отдельном листе в виде матрицы:
Кстати, это поможет не упустить пробелы в различных состояниях.
Решение второй задачи сводится к измерениям размеров и расстояний. Для этого не надо знать, в какой группе лежит та или иная кнопка. Технолог просто берёт Move tool и выбирает нужный элемент. Потом дошлифовывает, накладывая картинку макета на живую вёрстку.
Я часто ловлю себя на мысли, что в слои я вообще не смотрю. Поэтому в маниакальном переименовывании каждого слоя нет смысла. Так тоже нормально:
На мой взгляд:
Бесполезно
Осмысленно называть каждый слой
Группировать каждый, даже самый маленький блок в соответствии с логической иерархией
Использовать Layer comps для сложных интерфейсов с большим количеством состояний
Будет полезно технологу
Давать названия крупным блокам и разным состояниям интерфейса
Группировать крупные блоки и разные состояния интерфейса
Использовать артборды
Показывать разные состояния на разных артбордах
А какой подход используете вы?
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.