От технологов и программистов — веб-дизайнерам. О чём нужно помнить, чтобы называть себя веб-дизайнером.
Сверстать можно всё, что можно придумать и воплотить на этапе дизайна. Вопрос, однако, во времени, деньгах и удобстве расширения полученного результата и адекватности перестроения блоков при адаптации страницы под разную ширину окна браузера.
Веб-дизайнер — это инженер. Веб-дизайнер придумывает «как сделать, чтобы проект лучше всего решал поставленные задачи» и вопрощает это это визуально. Если Вы совсем не умеете верстать (не представляете как работает страница, как ведут себя блоки), вероятно, Вы ещё не веб-дизайнер. Отрисовка макета без представления о том, как будет работать сайт, напоминает проектирование автомобиля без представления о его двигателе, системах управления, условиях эксплуатации, количестве и расположении конечностей водителя.
Технически недоработанный макет осложняет работу технолога. Для студий — это увеличение сроков разработки. Для фриланса — ухудшение кармы дизайнера в момент, когда технолог описывает клиенту список технических недоработок и/или неучтённых дизайнером ограничений.
Создавайте компоненты, а не страницы. Некоторые проекты будут нуждаться в расширении. Гораздо разумнее собирать новые страницы из компонентов (блоков, элементов), чем создавать дубликаты уже имеющихся (или похожих) элементов.
Работайте вместе с технологом. Договоритесь о терминологии и организации работы. Одной из лучших стратегий является БЭМ — концепция, при которой все участники оперируют понятиями Блока, Элемента и Модификатора. Не обязательно использовать полный стек БЭМ технологий, достаточно наличия стайлгайда, системы именования селекторов и библиотеки компонентов. Подробнее с точки зрения вёрстки
Макет нужно делать в sRGB. Обязательно и критично. Иначе цвета в вёрстке могут отличаться от макетных.
Макет должен иметь тот размер, в котором его нужно сверстать. Размеры (более важна ширина) выбираются, исходя из специфики проекта и целевой аудитории. Для большинства проектов разумно предоставить внешний вид страниц для «мобильных» размеров и для «настольных». На момент написания, для «мобильных» разумно ориентироваться на минимальный размер 360×640 пикселей, а для «настольных» делать макет, контентная ширина которого комфортно впишется в 1200 пикселей (высота, обычно, менее важна, т.к. гораздо более вариативна).
Актуальную информацию по растространенности расширений экранов можно посмотреть тут (делайте поправку на специфичность целевой аудитории) или на каком-либо другом сервисе, предоставляющим статистику.
В макетах допустим только режим наложения normal (если в инструменте есть режимы наложения слоёв). Критично, обязательно. И так будет, пока не появится кроссбраузерная поддержка режимов наложения. И даже когда появится, использование режимов наложения нужно будет применять осторожно, с оглядкой на особенности реализации в вебе. Это правило не касается состоящих из множества слоёв иллюстраций, которые планируется соединять в одно изображение.
Для PSD-макетов одна страница = один макет. Обычно, это довольно объёмные файлы, если хранить все на артбордах в едином файле, он может подтормаживать. Для простых AI-макетов может быть допустимо разместить все макеты на артбордах в одном файле.
Скрытые слои не будут свёрстаны, если в техническом задании не указано иное. Хотите показать, что в макете есть необходимые блоки, скрытые по умолчанию — донесите эту информацию до технолога любым доступным образом. От указания в ТЗ и?или личного общения до скриншотов, на которых эти слои видны. Обязательно складывайте нужные скрытые слои в отдельные папки/группы и скрывайте такие папки.
Для PSD-макетов оставляйте эффекты слоёв. Эффекты, преобразованные в слои, ощутимо дольше верстать.
Для PSD-макетов про корректирующие слои лучше забыть. Любые «пост-модификации» могут всерьёз осложнить работу технолога.
Делаете макет в Adobe Illustrator — прикладывайте все линкованные ресурсы (картинки, шрифты...) и скриншоты макета. Если в макете использована растровая картинка, не записанная в файл (линкованная), технолог её не увидит, если она не приложена к макету.
Должен быть стайлгайд, в котором видны все необходимые состояния меняющихся элементов (интерактивных и просто изменяющихся) и типографическое оформление.
Создали стайлгайд — используйте его. Нет ничего хуже, чем обнаружить «новую» кнопку, атипичную модульную сетку или «уникальный» размер шрифта. Хотите создать новый блок (который нельзя собрать из уже имеющихся) — начните со стайлгайда. Думайте «компонентами» (блоками), не плодите сущности (размеры шрифтов и отступов, цвета, типы обводки и пр.) без надобности.
Стайлгайд — это отдельный макет или отдельная страница в figma. Это не текстовая инструкция как включать/выключать видимость слоёв, варианты композиции слоёв. Это не артборд, включённый в какой-либо макет.
Для ссылок нужны, как минимум, состояния: «покой», «наведение», «клик» (последние два могут совпадать). Для навигационных ссылок нужно состояние «находимся на этой странице». Для контентных ссылок можно указать состояние «ссылка посещалась».
Для кнопок нужны состояния: «покой», «наведение», «клик», «блокирована». Иногда ещё нужно состояние «занята» (к примеру, так может быть показан процесс отправки какой-либо формы).
Для текстовых полей форм нужны состояния: «покой», «курсор в поле», «блокировано». Обычно, нет смысла прорисовывать состояния «клик» и «наведение». Иногда стоит показать состояние «ошибка заполнения» или даже «заполнено верно».
Для флажков (чекбоксов) и радиокнопок нужны состояния: «отмечено», «не отмечено», «блокировано». Нет смысла прорисовывать состояния «клик» и «наведение».
Для типографики нужно показать, как минимум, следующую последовательность: заголовок 1, параграф, заголовок 2, параграф, заголовок 3, параграф, заголовок 4, параграф, параграф, маркированный список, параграф, нумерованный список, блочная цитата, параграф, таблица, параграф. Верстальщику важно увидеть все вертикальные расстояния (для этого и нужно чередование параграфами и два параграфа подряд).
Хорошо, когда текстовые блоки имеют один интерлиньяж при разных размерах шрифта (на разных вьюпортах). Если размер шрифта на «мобильной» ширине уменьшается (в сравнении с «настольной» шириной), относительный интерлиньяж (140%, к примеру) лучше не менять.
В идеале, стайлгайд служит библиотекой блоков, из которых строится весь интерфейс. Один раз делается прототип элемента (кнопки, поля ввода, заголовка...), а везде, где он нужен, вставляется его клон. При изменении прототипа, элемент меняется во всех местах, где использован.
Думайте о клик-блоках. Любой реагирующий на действие пользователя (скажем, клик) элемент должен иметь некоторую минимальную площадь, реагирующую на действие. Для кнопок-иконок, к примеру, рекомендуемая площадь клик-блока — не менее 32×32 пикселей, независимо от размеров иконки (важно для устройств с touch-интерфейсом).
Используйте модульные сетки. Это сделает результат аккуратнее и, если не допускать глупых ошибок, ускорит реализацию макета в вёрстке. Самая глупая ошибка: создать модульную сетку, но не следовать ей.
Модульные сетки — резиновые. «Строку» с блоками модульной сетки можно вставить в блок любой ширины с сохранением параметров сетки. Пример.
Граница ячеек модульной сетки — это середина промежутка между ячейками. Блок не может выступать за середину этого промежутка — левая граница блока не может проходить по правой границе предыдущей ячейки модульной сетки.
Идеал модульной сетки — 12 колонок. Ибо 12 делится на 2, 3, 4 и 6. Чтобы придумывать свои (пяти- и восьми-колоночные) сетки нужно иметь действительно серьезные причины, ибо восьми-колоночная сетка не позволит выстроить блоки по 3 в ряд.
Между колонками может быть пустое место, пропорциональное ширине колонки. К примеру, блоки в 12-колоночном ряду могут распределяться так: 2-колоночный блок, 1 колонка «пустоты», 9-колоночный блок.
Отступы справа и слева от контентной области нужно делать не колонками сетки. Представьте, что есть 12-колоночная модульная сетка и она лежит внутри прямоугольника (контентная область). На достаточно большой ширине вьюпрта вы хотите ограничить максимальную ширину прямоугольника и выравнивать его в центр по горизонтали. В этом случае, обычно, нет смысла оставлять первую и последнюю колонки пустыми просто для отступа.
Используйте легальные шрифты. Есть множество хороших бесплатных. Например, на Google Fonts.
Используйте проверенные шрифты. Перед использованием редкого шрифта или особого начертания, обязательно проверяйте, как они отображаются во всех браузерах из технического задания на всех операционных системах. Это особенно важно в Windows и Linux. Самые проблемные браузеры — IE (встречается в ТЗ всё реже, к счастью) и Firefox. За этим можно обратиться к технологу.
Размеры шрифтов указывайте целыми числами в пикселях. Браузер всё равно приведёт их к пиксельным размерам, пересчёт в другие единицы удобнее всего из пикселей. Интерлиньяж лучше всего указывать в относительных единицах. Для PSD-макетов интерлиньяж лучше указать в пикселах.
Выберите несколько размеров шрифта и придерживайтесь их. Пример размеров: для заголовков 1, 2, 3 и 4 уровней, контентный, акцентированный (если не совпадает с каким-либо заголовочным), уменьшенный. Не плодите сущности без надобности. Идеальная ситуация — использование системных шрифтов посетителя (не нужно загружать файлы шрифтов, страница покажется быстрее).
Вертикальные границы текстового блока проходят по границам «высоты линии», а не по границам букв первой и последней строк. Нужно учитывать в PSD-макетах. Для Figma важно, чтобы слой с текстом был не блоком, а строкой (это не затруднит выяснение отступов).
Избегайте менять кернинг и трекинг. На подавляющем большинстве дисплеев очень мало «пикселей на дюйм», такое изменение нередко приводит к грустным эффектам: размытие символов, изменение их визуальной плотности.
Интерлиньяж не должен быть меньше размера шрифта. Всегда помните: если в текстовом блоке более одного слова, количество строк непредсказуемо. Не избегайте знакомства с «электрогардиографической одиннадцатиклассницей, псевдореволюцонизирующей циклопентанпергидрофенантрены».
В вебе нет кроссбраузерных переносов. Лучше не использовать переносы слов вообще. Расстановка символов мягкого переноса в тексте возможна (никто не будет делать это вручную, а автоматическое ещё нужно внедрить в проект), автоматический перенос в браузерах имеет хорошую поддержку, но легко может отличаться в разных браузерах.
Символ «рубль» есть во многих шрифтах. При желании использовать символ рубля в указании цен, не стоит использовать комбинацию «Р-», в которой дефис сильно сдвинут (отрицательным кёрнингом). Во многих шрифтах есть символ рубля, а если подходящий его вид найти не удалось, нарисуйте векторную картинку и отдайте ее технологу в формате svg.
Избегайте маркерного выделение текста, если предполагается перенос строк (это случится обязательно, если строка длиннее одного слова и проект подразумевает адаптивность). Правый и левый внутренние отступы возможны только в начале и в конце какого-либо элемента, при переносе они будут нулевыми.
Думайте о блоках и потоках блоков. Крайне важно понимать как ведут себя блоки на странице и как они могут взаимодействовать в потоке. Это помогает избежать наложения блоков друг на друга при адаптивности.
Всегда думайте о переполнении блока текстом или другими блоками. Всегда. Почти для всех блоков нужно предусматривать возможность переполнения. Это самое важное с точки зрения технической реализации макета в вёрстке.
У блоков есть внутренние и внешние отступы. Внешние отступы пересекаются, а не суммируются.
Однотипные блоки должны иметь однотипные свойства. То есть, одинаковую ширину, высоту, цвет бордюра и пр. Допустимы типовые (повторяющиеся) модификации.
Используйте векторную графику Везде, где это возможно. При соблюдении некоторых условий, векторная графика технологичнее растровой: меньше размер файлов, поддерживает «эффекты внутри картинки», не требует ретинизации или ускоряет её.
Создавайте векторную графику в векторных редакторах. Для любых форм (сложнее прямоугольника со сглаженными краями или простых библиотечных форм) используйте Adobe Illustrator, Inkscape или подобное ПО.
Не рисуйте векторную графику в Photoshop. Составные иконки (более одного слоя), нарисованные с помощью векторных форм в Photoshop, почти никогда не получается «достать» без серьезного искажения картинки.
Создавайте векторную графику в отдельных файлах. Любые иконки и иллюстрации создавайте в отдельных файлах (лучше всего — сразу в SVG-файлах, одна иконка = один файл). При работе не в Figma, если Вы предоставите такие небольшие файлы технологу, его работа будет существенно быстрее.
Рисуйте векторные формы вместо работы кистью. Заливки и формы, созданные кистью получаются «грязными» — имеют множество лишних ключевых точек, что крайне негативно сказывается на размере файла (иногда, оптимизировав количество точек, удавалось сжать SVG-изображение в 12 (!!!) раз — прим. Н.Г.).
Предоставляйте векторную графику в том её размере, в котором она использована в макете. Обязательно!
Если в проекте несколько размеров одного изображения, по возможности, не делайте несколько файлов картинок. К примеру, если используются иконки, напоминающие смайлы, и нужно 2-3 размера, то лучше всего ограничиться одной картинкой и менять ее размер, а не прорисовывать 2-3 почти идентичные иконки.
Не накладывайте на векторные изображения в PSD-макетах корректирующие слои, маски, эффекты. C высокой вероятностью это приведёт к невозможности использования такой векторной графики.
Попадайте в пикселы. Выравнивайте точки в кривых по пиксельной сетке если возможно. Тогда иконки не будут мыльными на экранах с низким разрешением, к тому же будут лучше сжиматься. Иконка, в которой прямые горизонтальные и вертикальные линии не попадают в границы пикселей, смотрится размытой.
Артборд должен быть подогнан по габаритам фигуры. Для разных иконок сходного размера допустимо, чтобы атрборды были одинаковых размеров (больше габарита фигур). К примеру, использованы иконки «домой» и «назад», использовать предполагается в навигации. Допустимо обе иконки разместить на квадратных плашках одинакового размера с выравниванием в середину.
Оконтурите все линии с указанной шириной перед экспортом. Если есть некая кривая линия с указанной шириной и стилями концов, лучше оконтурить её, чтобы получить фигуру с нулевой толщиной линии обводки и заливкой. В противном случае при сжатии размеров или сборке SVG-спрайта могут появиться проблемы (у незамкнутых линий возникает заливка).
Все слои иконки, которые могут быть слиты в единую форму, должны быть слиты. Это позволяет уменьшить размер файла (иногда, довольно существенно).
Удаляйте всё лишнее из векторных картинок. Если какие-либо формы не видны, их нужно удалить, иначе они будут бессмысленно увеличивать размер файла.
Избегайте наложения эффектов и трансформаций. Переводите всё в кривые, применяйте трансформации.
Избегайте градиентов и теней. В некоторых случаях это может наложить ограничения на использование векторной графики.
Для форм с заливкой не используйте обводку того же цвета, что и заливка. Толщина обводки должна быть нулевой.
Не комбинируйте в макете слои со вставленной векторной графикой и элементы, нарисованные в макете. Если Вы вставили в макет векторную картинку и потом «дополнили» её какими-то слоями макета, использовать такую картинку в векторном формате заметно сложнее (или невозможно).
Выберите 2-3 брейкпоинта (ширины, на которых происходит перестроение) и создавайте макеты для них. Обычно, брейкпоинты следующие: 360 (минимум), 768, 992, 1200, 1600 пикселей (иногда используют 576 пикселей). Прорисовывать все ширины не нужно. Часто, выгоднее показать «мобильный» (360), «планшетный» (768) и «настольный» (1200 или 1440) варианты. Традиционно, мы принимаем некую минимальную ширину (320 или 360), преобразования блоков происходят по достижении брейкпонта. Важно понимать: сделав макет в ширине 768, Вы показали то, как макет выглядит от 768 до следующего брекпоинта в большую сторону (скажем, 992).
Уточняйте в техническом задании как ведет себя дизайн на разных брейкпоинтах. По умолчанию, всё, что уже чем ≈1000 пикс. будет «резиновым».
Ретинизируемые растровые изображения в оригинале должны быть в 4 раза больше по площади, чем видно в макете. Для PSD-макетов лучше всего, чтобы они не лежали в режиме подрезающей маски, а были масштабированными смарт-объектами. Для макетов в Figma — добавляйте изображения, которые в 2 раза шире и в 2 раза выше (в 4 раза больше).
Мы можем показывать разные изображения (по пропорциям и по содержимому вообще) на разных размерах экранов штатными методами (picture с полифилом).
Хотите сами подготовить растровую графику — посоветуйтесь с верстальщиком. Общие правила: нужна прозрачность — PNG (8-24 бит), не нужна прозрачность — JPEG (прогрессивный, качество 60-80%).
Анимация может повредить проекту с точки зрения технологии реализации. Хотите добавить анимационные эффекты? Посоветуйтесь с технологом. Недостаточно просто найти пример реализации (или, что гораздо хуже, видео или GIF с нужной анимацией), так как реализация анимации может потребовать подключения к проекту тяжелой библиотеки, сравнимой по размеру файла с файлом всех используемых на проекте стилей.
Реализация нестандартных элементов форм увеличивает сроки проекта. Особенно это касается нестандартных выпадающих списков (если не планируется использовать какое-либо готовое решение).
Не рисуйте векторные иконки в Sketch. Такие иконки в 90% случаев технологически непригодны к использованию в векторном виде.
Не накладывайте полупрозрачные слои на автопроигрываемое видео. Блок с фоновым полупрозрачным цветом, будучи положен на блок с проигрываемым видеороликом, может ухудшить производительность.
Отсутствие структуры слоёв. Если слои не разложены по правильно именованным папкам, это незначительно замедляет работу.
Большие части PSD-макета в смарт-объектах. «Шапка» и «подвал» в смарт-объектах не имеют смысла для экономии места, но увеличивают время доступа к своим составляющим. Это не относится к связанным смарт-объектам, в случае, когда макетов много.
Изменение цвета объектов или текста при помощи прозрачности. Плохо, так как технологически мы стараемся избегать прозрачности — много полупрозрачных объектов могут вызвать проблемы быстродействия страницы.
Изменения вида векторных объектов эффектами Photoshop. Это может привести к невозможности использования векторной графики.
Набор текстовых блоков КАПСОМ вместо использования «All Caps». Приводит к необходимости нажимать несколько лишних кнопок при копировании текста слоя. Когда таких слоёв много — потеря времени.
Заголовок текстового блока и его контентный текст в одном текстовом слое. Несколько лишних кликов.
Блокированные папки и слои. Если действительно нужно что-то блокировать, блокируйте папку, не блокируйте отдельные слои — до них становится сложнее добраться.
- Николай Громов. Ведущий разработчик интерфейсов ООО Наука. Преподаватель EpicSkills.
- Андрей Алексеев. Технолог. Фрилансер.