Comments 29
Чем дизайнер может помочь фронтенд-разработчику
он должен знать верстку
pixel perfect
Есть такая особенность — реальный контент. Макет или верстанный макет и то что в итоге вы используете определенное время — не обязано быть прибитым к макету. Это живая штука. Например, расстояние между элементами может быть другим, потому что при скроле и использовании сайтом удобство доминирует перед более гармоничными отступами в статике на демо контенте.
Когда дизайнер умеет верстать, он может поправить стили самостоятельно, а потом пойти к верстале и попросить внести поправки на основе его изменений. Это сильно сокращает бюрократию.
Ну вот по другому шрифты смотрятся в фигме, хотя это же тоже браузер. Другая у них толщина, я не знаю почему. И этот фактор тоже может влиять на те изменения, которые не предусмотрены в макете. И пиксель перфект тут не поможет.
я постарался вынести самое основное в блок «Что следует знать дизайнерам о фронтенде»
на счет pixel perfect, я не писал, что нужно верстать всё один-в-один, но явные отличия знать стоит, я воспринимаю pixel perfect как инструмент, а не как парадигму
основы работы figma точно знать стоит
У дизайнера лучше наработано ощущение гармонии между пустым и занятым пространством и его задача правильно использовать приемы по расстановке визуальных приоритетов контента. Это база, а потом уже навыки и мастерство, кто как обтравливать умеет, кто как рефлексы наводить, кто сможет вложить в проект то, что у человека что-то щёлкнет, «ухты, прикольно» вообще молодец.
Задача наработки гармонии — вполне выполнима. Просто это как воздух, о нем нужно рассказать и поделать упражнения ртом и руками, чтобы его замечать.
Ну вот по другому шрифты смотрятся в фигме, хотя это же тоже браузер.
Они ж в канвасе все отрисовывают, в этом походу и причина.
Так же нужно учитывать что газету верстают под четко заданный размер листа а с сайтом так не получается, его будут открывать на всех возможных разрешениях, с разной плотностью пикселей.
Как правило, дизайнеры очень дорожат вертикальными отступами, потому что у всех страниц есть ритм который нарушать нельзя. В любой дизайн системе вертикальные отступы обычно кратны определённой величине.
Хотел бы еще добавить, сейчас на проекте пользуемся не фигмой, а XD + Zeplin, для общения между дизайнером и фронтом. Фигма в определенный момент стала слишком слабой чтобы тянуть все скрины проекта. Зеплин чем хорош, там как раз и реализован функционал учета версий. В бесплатном пакете 2 версии, в платных до 7 и более. Пока двух хватает, иногда пользовались. Там тоже можно оставить комментарии. Еще есть специальное место под компоненты, так что не обязательно держать стайлгайд страницу, если у меня в ХД мои адаптивные компоненты, и они же загружены в Зеплин, откуда можно смотреть размеры. Минус наверное в том что туда скрины заливаются вручную, поэтому глобальное обновление компонента хедера (например) требует перезаписать абсолютно все скрины проекта.
Советую рассмотреть такой сервис.
Как правило, вёрстка бывает адаптивная и резиновая. Адаптивная подстраивается под конкретные заданные разрешения экрана, а резиновая плавно изменяется, подстраиваясь под любую ширину экрана.Не совсем так.
Про адаптивную верно. Но то что вы называете резиновой, на самом деле отзывчивая (в оригинале responsive).
А резиновая (в англоязычном мире fluid) — это когда блоки просто механически тянутся вширь, не меняя своего лейаута. В свое время резиновая верстка пришла на смену фиксированной.
Эволюция: фиксированная, резиновая, адаптивная, отзывчивая.
Это если строго по терминологии.
Но в повседневной практике, понятия адаптивной и отзывчивой верстки де-факто давно смешались. Обычно все используют отзывчивую верстку, но называют её чаще адаптивной :) Адаптив в исходном значении слова уже неактуален, но выговаривать «отзывчивость» сложнее, да и не все изначально понимали эту разницу. Такие дела.
Хотя отдельные авторы писали, что есть отличия в нюансах — но их никто не понимал даже тогда, а уж сейчас тем более забыто.
предвзятое отношение и недоверие фронтендщиков к UI/UX-дизайнерам
Заметил, что такой паттерн просматривается во всей цепочке:
Бекенд: чё там ту формочку «сверстать», я сам за пять минут сделаю на джиквери… => фронты: та чё там ту формочку «нарисовать», и без дизайна всё понятно, всего-то несколько полей… => дизайнеры…
Вобщем каждая сторона


с приходом фигмы это легче познается, конечно. Другое дело был фотошоп))
Второй вариант —отвязать свой разум от бутстраповских брейкпоинтов и рассматреть каждый блок как независимый.
…
как показывает практика, этих состояний вряд ли будет больше шести, и все они будут инкапсулированы внутри своих блоков и ни на что не повлияют
В моей личной практике ничего хорошего из этого не вышло (может, просто не умели говить). Основная проблема — при таком подходе концептуально верным было бы адаптировать лэйаут блока в зависимости от размеров самого блока. К сожалению, соответствующее предложение в стандарт находится на стадии черновика и непонятно, будет ли когда-то реализовано (поправьте меня, если ошибаюсь).
В итоге, блок адаптируется под размеры экрана (вью порт) — но сам-то блок тоже не один на странице. Какой-то блок вообще может быть скрыт на меньше разрешении — оставляя больше места для другого блока. И вот различные сочетания брейкпойнтов у разных блоков привдят к тому, что, скажем, в одном конкретном диапазоне ширины экрана раскладка ломается.
Дописав все это, понял, что мало конкретики. Сорри. Конкретные баги, которые вылезали из-за этого, уже не помню. Было не так чтоб все плохо, но с глобальными брейкпойнтами стало надежней как-то.
вообще мой основной посыл был в том, что можно жить без жёстко заданных брейкпоинтов, а вообще лучше исходить из здравого смысла, бутстрап не серебряная пуля
Сейчас, кстати, Figma как раз активно идет в сторону БЭМ. Если есть время на правильное оформление дизайн-системы сайта, то у верстальщиков вопросов почти не возникает.

Боль фронтов, или что нам нужно от дизайнеров