Требования к PSD макету от верстальщика

или как оценить макет и остаться в живых

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

Минимальный список требований для макетов любого сайта, даже лендинга и даже на один экран:

1. Сетка в макете

Зачем это нужно? Макет с сеткой своим эстетическим видом уже вызывает еле слышное удовлетворённое мурлыканье верстальщика. Также сетка даёт возможность без особых усилий и временных затрат собирать каркас страницы и располагать (позиционировать) элементы на той же странице максимально приближённо к тому, что изображено на макете. От направляющих не составит труда точно измерить расстояние и записать его в пиксельном эквиваленте в таблицу стилей.

2. Градиент к слою

Для сайта градиент в некоторых случаях выглядит эффектно, применять его крайне рекомендуется в обычном режиме наложения ( blend mode: normal). Использоваться должны его реальные цвета, никаких симпатичных полупрозрачностей и сложных режимов наложения, таких как multiply, screen, overlay и тому подобное.

Также режим blend mode: normal относится к любым свойствам слоя, таких как inner shadow, drop shadow…

3. “Слой на слое”

Верстальщик не поприветствует градиенты и другие различные эффекты, созданные путём “слоя на слое”. Слой должен быть один, как ты в 3 часа ночи на кухне у холодильника.

4. No to gradient borders!

Или никаких рамок и stroke с использованием градиента.

5. Шрифты в макете

При использовании нестандартных шрифтов настоятельно рекомендуется их наличие у верстальщика в формате .ttf или .otf. Далее они будут конвертироваться в определённые форматы для веб-страницы. Желательно использовать не более 2-х нестандартных шрифтов, так как их количество влияет на рендеринг страницы в браузере: чем их больше, тем дольше будет отрисовываться контент.

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

6. Стандартные элементы типографики

Наличие одного макета со стандартными элементами веб-страницы возносит крутость дизайнера до небес. На таком макете должны быть представлены заголовки, параграфы, таблицы, списки, блоки с цитатами и другие стандартные моменты.

7. Состояние наведения

Иными словами — :hover. Любой сайт будет содержать ссылки, кнопки или другие элементы, которые будут иметь состояние наведения или нажатия. Набор потенциально “наводимых” элементов:

  1. Ссылка.
  2. Кнопка (иногда может иметь состояние неактивности — disabled).
  3. Стрелка слайдера.
  4. Поле формы.
  5. Иконка социальной сети.

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

  1. На элементе будет присутствовать курсор в виде руки (figure 1)и будет показан наводимый эффект.
  2. Макет может содержать скрытый слой с элементами в состоянии наведения, нажатия.
  3. Отдельный макет с набором элементов, которые будут иметь эффекты наведения, нажатия. Могут входить в макет со стандартными элементами типографики.
figure 1

8. Каждому блоку — по папке

А также и по человекочитаемому названию. Конечно, если верстать будет робот, к названию из символов и цифр вопросов нет, но для лучшего понимания верстальщиком его местонахождения на макете логичное название блока, например, “Шапка” даст 100%-ную информацию о локации.

Дизайнеры-сверхлюди умудряются располагать папки с блоками согласно их порядку на макете — шапка, сайдбар, контент, подвал.

9. Скрытые слои

Если в макете предусмотрены скрытые слои/папки с жизненно важным содержимым, таким как модальные окна, выпадающие панели, выпадающие n-уровневые меню, то их стоит выделять цветом и давать схожее по функциональности блоков название.

10. Название макетов

Ну и наконец — здравое название макетов. Открывая папку или архив хочется видеть осмысленные названия макетов, такие как “Главная”, “Контакты”, “О нас” и тому подобную красоту.

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

Также все вышеупомянутые манипуляции помогут избежать следующих недугов:

  1. Несоответствие макета и готовой вёрстки.
  2. Проблем с утверждением вёрстки заказчиком.
  3. Проблем с кроссбраузерностью и работой вёрстки в целом.

Разделяй и властвуй (макетом)

С логикой макета и его запчастями разобрались. Но что делать верстальщику дальше? В стандартном рабочем процессе после получения макета верстальщик оценивает стоимость работы и сроки её выполнения. Вот тут и встаёт вопрос о том, за сколько дней, ночей или наносекунд вёрстка будет выполнена без ущерба здоровью исполнителя. Чтобы не сорвать сроки и не включать по ночам космическую скорость вёрстки, следует серьёзней отнестись к оценке рабочего времени. Как адекватно всё осуществить:

  1. Разбить (визуально) макет на основные составляющие блоки. Это может быть шапка, сайдбар, контентная область, подвал, модальные окна.
  2. В каждом полученном блоке проанализировать его компоненты. Стандартный частый набор для шапки — логотип, меню, форма поиска, область регистрации и тому подобное. Отметить для себя, насколько сложным является их осуществление. Например, адаптация многоуровневого меню для планшетов и мобильных, эффект появления вложенных пунктов меню, анимация при наведении на ссылки, кнопки, анимация появления блоков при клике на кнопку регистрации.
  3. Наличие слайдера, галереи, табов, меню-аккордеона и других элементов, которым потребуется JavaScript “вмешательство”. Как долго будет писаться отдельный модуль?
  4. Сложность сетки контентной области. Примеров может быть множество, так как единого стандарта вывода контента нет, но часто встречающиеся это — блок с картинкой и текстом, masonry-сетка, картинка с появляющимся текстом при наведении… Здесь стоит оценить сложность структуры сетки, её гибкость при добавлении большого количества текста, поведение при изменении размера окна браузера.
  5. Содержимое сайдбара. Там может быть меню категорий, баннер с картинкой, виджет социальной сети, фильтр с чекбоксами и прочим. При таком раскладе следует уделить внимание сложности реализации фильтра — чекбоксы, радио кнопки, меню выбора (select), бегунок (range) могут быть кастомными (нестандартными по внешнему виду), структуру меню категорий и его внешний вид на планшетах и мобильных, сложность реализации виджета.
  6. Наличие подвала и его контент. В подвале отлично может продублироваться меню, разместиться копирайт и иконки социальных сетей. Оцениваем сложность структуры и наличие анимационных эффектов.
  7. Фоновое изображение, градиент и другие эффекты, применимые к графике. Стоит подумать, каким образом будут реализовываться градиенты, затемнения, тени, позиция фоновых изображений — при помощи CSS или используя картинки с макета. Что будет менее трудозатратно и более кроссбраузерно?
  8. Анимация — эффекты появления блоков, плавность прокрутки, кнопка “Наверх”, плавность при наведении на ссылки или кнопки, эффект появления блоков при наведении, нажатии. Желательно определить, каким образом будут написаны данные эффекты и сколько времени займёт их написание.
  9. Наличие модальных окон, pop-up’ов, лайтбоксов и прочих скрытых блоков. Будут они написаны вручную или лучше использовать универсальный плагин?
  10. Проверка контента. Зачастую контентом в макете является “рыба”, она же “lorem ipsum”. Дизайнер помещает контент в блок с фиксированной высотой. Но что будет с данным блоком, если текста будет намного больше или всего пару слов? Этот момент стоит обсудить с заказчиком, если в макете не предоставлены блоки с разным количеством контента.

Вышеописанные пункты помогут оптимизировать время и наладить рабочий процесс. Оценив несколько разных по структуре макетов можно научиться более точно определять сроки для вёрстки и не уходить в овертаймы.

А как же мобильные?

Быстрое развитие веба и наличие разных устройств, на которых можно открыть сайт, побуждает к созданию адаптивных сайтов. Это значит, что мобильная или планшетная версия сайта может отличаться по внешнему виду, редко — по содержанию, от десктопной версии. Что мы получаем в папке с макетами? Еще пару папок с дизайном, заточенным под определённые разрешения. Например, для планшетов это может быть 780px по ширине, а для мобильных — 320px (цифры взяты неспроста — http://mydevice.io/devices/). Но стоит учесть следующее:

  1. Ширина окна браузера на планшетах может находиться в пределах от 600px до 1024px.
  2. У мобильных — от 320px до 504px.

О чём это говорит? Правильно, как верстать сайт, если ширина макета отличается от медиа-запроса под планшеты или мобильные телефоны. Ответ прост — если сайт предусмотрен с fluid (резиновой) вёрсткой, то проблем быть не должно; если используются фиксированные по ширине блоки под определённые устройства и их переходное состояние от дексктопа к планшетной версии не учтено и не согласовано с заказчиком в техническом задании, то этим стоит заняться до начала вёрстки, иначе проблем не избежать.

Как может выглядеть боль и отчаяние на примере (figure 2)

figure 2

Если заказчика устраивает тот факт, что блоки перестроятся на указанных break-points согласно дизайну, но в промежуточных вариантах что-то будет выглядеть не так, как на макете, то приступаем к работе. Если же он не согласен, можно предложить верстать на своё усмотрение или сразу определить внешний вид явных несоответствий.

Всё уяснили, а теперь…

Помним, что перед началом работы стоит уделить достаточно времени на обсуждение всех деталей, которые упростят и оптимизируют вашу работу. Процесс согласования покажется длительным, но важно чётко определить сроки выполнения проекта. Нет ничего плохого в том, чтобы их завысить, закладывая в оценку риски — незапланированный отпуск, болезнь, сложности при вёрстке, время на дополнительные обсуждения макета.

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