Ваш дизайнер – настоящий гений и его продукт идеален. Он доблестен в неравной борьбе с ТЗ и всегда выходит победителем. Но уже пятый по счету верстальщик, матерясь, делает из его макетов какую-то гадость? Не торопитесь искать шестого. Чаще всего причина легко устранима – достаточно лишь поведать вашему гению о нескольких приземленных правилах и попросить его им следовать.
В этой статье я попробовал собрать некоторые рекомендации для дизайнеров, делающих мир чуть светлее. Спросите у верстальщика о его проблемах, отправьте эту статью дизайнеру. Ибо совершенству нет предела.
Проблема существовала всегда, сколько я себя помню айтишником. Когда проектирование интерфейсов было лишь красивым словосочетанием, смысл которого понимали только настоящие профи, дизайн отвечал минимум за две трети впечатления пользователя от сайта. Сейчас немного проще, UI-проектирование все чаще отделено от дизайна, хотя и делает его порой один и тот же человек. В любом случае, именно веб-дизайнер преобразует смутные образы или сухие прототипы в то, с чем потом взаимодействовать пользователю. И очень важно, чтобы верстальщик перенес этот дизайн в веб максимально точно. Желательно – вообще без изменений. Попиксельно. Спросите у любого дизайнера, насколько часто финальная верстка полностью его устраивает? Уверен, ответ будет печальным, если не резким.
О причинах этого говорить можно долго, но чаще всего винят верстальщика. Оно и понятно: дизайн есть, дизайн хороший, будь как дизайн. Но помимо простого копирования, на верстальщика ложится еще целый ворох обязанностей. Он должен сделать сайт адаптивным, быстрым, легким. Его верстка должна быть семантичной, изображения – пожатыми или векторными, а формы – заточенными под бэкенд. Да frontend-разработчик вообще много чего и кому должен, если он хороший (как дизайн). Вот и берет наш герой какой-нибудь фреймворк для ускорения и оптимизации работы – причем не важно, комбайн-бутстрадейшн или собственный велосипед, с гридами на флексбоксах. Открывает макеты и начинает ваять. И то тут, то там, ему приходится немного отступать от дизайна. Или раздувать таблицы стилей, делая их сложночитаемыми и неоправданно большими. Результат всегда не очень: дизайнер недоволен, фронтендер недоволен, в мире стало чуток темнее.
Но это только в том случае, если наш дизайнер, создавая макеты и передавая их дальше по цепочке, не учел несколько важных моментов, о которых я и собираюсь рассказать. Конечно, вряд ли я смогу здесь описать все, что мешает правильному взаимодействию дизайнера с верстальщиком. Да и проблемы, возникающие в этой связке, бывает, вообще никак не относятся к профессиональным качествам сторон. Но следование изложенным ниже рекомендациям точно не повредит ни проекту, ни его разработчикам.
Текст ниже — для дизайнера и, чуть-чуть, для фронтендщика. Итак, погнали.
Унифицируйте элементы
Представим, что на сайте полсотни различных кнопок. От банальной «читать далее» до «произвести расчет стоимости лечения за первое полугодие». А есть еще круглые кнопки с иконками и кнопки-списки. И на каждой странице они немного отличаются: где-то кнопка на 5 пикселей шире остальных, где-то иконка переместилась в правую часть, где-то радиус углов немного разный… Выглядит, конечно, очень круто. И различия на дизайн-макетах даже не бросаются в глаза. Но на деле такое отношение к элементам оборачивается несколькими проблемами:
— верстать сложнее, дольше и дороже;
— возрастает вероятность, что верстальщик будет использовать на всем сайте только один из визуально почти одинаковых элементов;
— пользователю приходится каждый раз «привыкать» к новому виду элемента (хотя он и сам может этого не осознавать);
— при развитии проекта, скорее всего, получится чехарда из разномастных кнопок, инпутов и тд.
Решение простое. Дорогие дизайнеры, создайте единый документ, в который поместите все-все типовые элементы. Заголовки, списки, параграфы, ссылки, кнопки, поля форм, контролы, миниатюры изображений и прочее. Такую доку называют «UI Style Guide» или «Frontend Style Guide» — кто как привык. Обычно это просто послойный исходник вроде этого. И везде в проекте используйте только эти элементы и только в той форме, в которой они здесь запечатлены. Появился новый мультиселект? Добавляйте его в «стайлгайд».
Причем не стоит ограничиваться только элементами. Создайте набор главных цветов интерфейса — это тоже полезно. В ряде случаев мы даже делаем список основных отступов, используемых в макетах.
Если верстальщик опытный, он сразу сделает себе такой же «стайлгайд» в вебе, откуда просто будет копировать элементы. Да и вообще, преимуществ у «стайлгайдов» тьма: от удобства в развитии проекта до ускорения работы всех, причастных к фронтенду.
Изучите основы верстки
Одна из самых спорных рекомендаций, пожалуй. Многие мне возразят, и это нормально. Но веб-дизайнер, понимающий хотя бы самые базовые принципы HTML и CSS, по моему опыту, стоит дороже и работать с ним приятнее. Такой дизайнер понимает, что есть шесть типов заголовков, что параграф обычно имеет отступ снизу, что списки могут быть вложенными и прочее. И здесь речь не просто о типографике — тут важно, чтобы макет был не только красивым, но и реализуемым, легким (о скорости мы еще поговорим ниже).
Это не сложно, поверьте. За пару недель ежедневных часовых занятий можно приобрести базовое понимание основных HTML-тегов и возможностей CSS. Никто не просит вас, дорогие творцы, становиться технарями и вникать в дебри псевдоэлементов. Но следует понимать, какие из ваших решений могут быть реализованы в вебе, а для каких потребуется заключать союз с нечистой силой.
Научитесь работать по гридам
Гриды, сетка, колонки — суть одна. Если упростить, то модульная сетка для дизайнера представляет из себя условное разделение макета на вертикальные колонки одинаковой ширины, с определенными отступами между ними. Стоит один раз распределить элементы макета внутри этих колонок, и
Привычка работать по сетке — одна из самых полезных (после утренних пробежек, раздельного питания и использования хоткеев). Она позволяет упорядочивать визуальную структуру документа, с легкостью переиспользовать блоки, ускоряя разработку как дизайна, так и верстки. Кроме того, именно на гридах строятся популярные front-end фреймворки вместе с адаптивностью, а это важно — и я к этому еще вернусь.
Для дизайнера же гриды хороши еще и тем, что при переносе его макета в верстку шанс точного «совпадения» возрастает во много раз. Для верстальщика в целом упрощается все. Опытный фронтендщик просто создаст у себя в проекте точно такие же колонки, и не будет тратить время на попиксельное сравнение отдельных блоков, не говоря уже об адаптивности.
Тем, кто работает в Photoshop'е, могу предложить даже небольшую подборку шаблонов. Для предпочитающих Sketch такой штуки у меня, увы, нет — но она есть в гугле.
Помните про адаптивность
В предыдущем пункте она упоминается аж два раза не просто так. Игнорировать мобильный трафик сейчас — настоящее преступление, за которое нужно ввести порку розгами. Вот уже два года, как мне перестали попадаться проекты, в которых не нужно было бы реализовывать корректное отображение сайта на экранах мобильных устройств. Вместе с тем многие дизайнеры продолжают создавать только один вариант дизайна — основной, самый широкий.
Что происходит после этого? У верстальщика, получившего такой макет, есть несколько вариантов действий:
— запросить недостающие компоновки страниц, под остальные разрешения;
— сделать только то, что ему прислали — то есть неадаптивную верстку;
— попытаться самостоятельно адаптировать имеющийся дизайн.
Первый вариант частенько нереален, потому как дизайнер уже получил свои деньги, а заказчик — жлоб (например). Второй вариант отпадает, потому что тогда фронтендщик становится соучастником и рискует оказаться наказанным. Чаще всего в таком случае отрабатывается третий вариант. И получается так себе, потому что верстальщик, даже очень хороший — это не дизайнер. Исключения крайне редки.
Так вот, дизайнеры. Очень прошу, делайте несколько вариантов макетов, под разные разрешения. Этим вы сэкономите время на разработку и повысите шансы положить проект в портфолио, потому что за его реализацию не будет стыдно. Ну и в очередной раз докажете собственный профессионализм.
И к слову о гридах. Использование модульной сетки в дизайне очень упрощает проектирование адаптивности. Мне, например, уже как-то привычны следующие шаги (ширина макетов): 1440px, 1200px, 960px, 768px, 600px и 320px. Иногда заменяю 600 на 480, но это уже индивидуальности проекта. При переходе на каждый шаг уменьшается ширина колонки, но расстояние между ними остается прежним. Найти уже готовые шаблоны можно по ссылке в пункте выше.
Будьте в курсе трендов
В общем-то, банальный совет. Но буквально на днях я обнаружил дизайнера, не знакомого с принципами material design. Ну то есть общее понимание концепции у него было, а вот о «гайдлайнах» material он слыхом не слыхивал. Конечно, у матерого дизайнера изучение практически любого направления не займет много времени, но иногда незнание основ может помешать получить вкусный и интересный заказ.
Однако, помимо направлений в дизайне как таковых, существуют еще и популярные фронтенд-фреймворки. Их задача — упростить и ускорить разработку внешней части сайта, включая верстку, js и прочее. Если вы, дизайнер, работаете в команде, которая предпочитает использовать определенный фреймворк, изучение его базовых особенностей сохранит время и нервы всей команды. И речь тут не только о цветовой схеме или компоновке блоков, не стоит загонять себя в чересчур жесткие рамки, вы же творец. Речь, скорее, о базовых элементах или особенностях анимации. Например, в некоторых фреймворках боковое меню, появляющееся на небольших экранах, накладывается поверх контента, а не сдвигает его. И изменить такое поведение порой стоит немалых жертв. Поэтому не стесняйтесь общаться с frontend-разработчиками на самых первых этапах, узнавайте о фреймворках и их особенностях.
Из популярных могу назвать:
— Bootstrap. Не нуждается в особом представлении. Почти все, что нужно на старте — есть из коробки. Самый популярный в мире.
— Foundation. Гибкий, современный, настоящий комбайн. Достойная альтернатива бутстрапу.
— Materialize. Заточен под material design, что видно из названия. Включает в себя также анимации в стиле материал.
— Material Design Lite. По сути, брат предыдущего. Имеет в себе все необходимые для быстрого создания проекта в стиле material.
— Ionic. Фреймворк для создания мобильных приложений на базе cordova. По сути, реализуется той же HTML-версткой, а потом компилится под разные платформы.
— Mobile Angular UI. То же самое, что и предыдущий, но использует верстку bootstrap.
Frontend-фреймворков тьма, все перечислять не стану. В случае необходимости сами загуглите.
Учитывайте скорость загрузки сайта
Да, скорость загрузки и работы сайта во многом закладывается на этапе дизайна. Знаю, для кого-то это будет новостью. Но стоит вдуматься — и это становится очевидно. От чего зависит скорость загрузки сайта? Исключим сервер и кривые руки фронтедеров. Статика. Изображения, скрипты, стили.
С картинками, вроде, все понятно — чем их и они меньше, тем быстрее пользователь увидит сайт в том виде, на который вы рассчитываете. Но это ведь не повод отказываться от фоновых изображений, верно? Современные технологии разработки позволяют верстальщикам подставлять разные изображения на разных разрешениях. Так зачем на экраны мобильных устройств тянуть те же мегабитные фоны, что и на десктопах? Подготовьте несколько вариантов фона для разных разрешений — хотя бы просто в макетах, верстальщик сам их вынет оттуда. Ну или предоставьте верстальщику готовую папку с фонами, если Вы совсем уж святой.
По возможности, используйте векторную графику для иконок или простых изображений — она и весит меньше, и выглядит лучше.
Скрипты не во власти дизайна, это очевидно. Но если во время дизайна понавтыкать в каждый квадратный сантиметр сайта параллаксы, анимированное появления блоков и прочие свистелки, у кого-то сайт не загрузится никогда. Очень прошу, дорогие дизайнеры, не увлекайтесь анимацией, если того не требует ТЗ.
О стилях же я уже писал в самом начале. Если в макете отсутствует унификация элементов, а верстальщик попался добросовестный и усердный, размер таблицы стилей будет сопоставим с размером изображений на сайте. И все это придется тащить браузеру, покуда он не закэширует все это безобразие. Мне в одном проекте встретился файл стилей размером с небольшого котенка — 17 мегабайт. И это в минифицированном виде. До сих пор кошмары снятся.
Изучите, наконец, векторную графику
Мой самый любимый и одновременно ненавистный пункт. Именно он пришел мне на ум первым, когда я собрался писать эту статью. Прошу дизайнеров отнестись к нему со всей серьезностью.
Речь, конечно, об SVG. Это такой формат векторных изображений, о котором в последнее время говорят все чаще. И я не стану плодить сущности, рассказывая о его преимуществах. Я расскажу о проблеме, которая с ним связана.
Про себя я ее обзываю «псевдо-SVG». Это когда дизайнер дает верстальщику SVG-файл, но тот не может его нигде использовать. Весьма распространенное явление. Причина простая — дизайнер, работая в фотошопе, просто экспортирует иконку как SVG (по ctrl+shift+alt+w), хотя она является растровой. Внутри таких бесполезных эсвэгэшек обычно лежит текст с:
<image xlink:href="data:img/png;base64...Такое изображение не получится масштабировать, да и разницы между ним и растром, по сути, никакой.
Происходит это от того, что дизайнер не очень понимает, что такое SVG, и не умеет правильно его использовать. Для таких я бы рекомендовал, все-таки, изучить формат. Если же вы работаете в фотошопе, то стараться такие изображения создавать «перьями». Или использовать готовые наборы иконок. Пользователям Sketch тут проще — у них вектор получается по умолчанию. В любом случае, если вы хотите быть «дизайнером будущего», знать SVG необходимо. Вот несколько полезных ресурсов на русском языке: раз, два, три.
Для уменьшения количества запросов к серверу (привет, HTTP/2), да и просто для удобства использования все SVG-иконки на сайте очень часто объединяют в спрайты — этакие комбинированные файлы. Создать SVG-спрайт можно тремя способами:
— вручную, копируя содержимое каждого SVG в один общий файл;
— программно, при помощи различных библиотек;
— посредством специальных онлайн-сервисов.
—
Первый способ оставим людям, у которых много свободного времени. Со вторым все понятно — он используется верстальщиком и требует определенных навыков. А вот третий способ может подойти и дизайнеру. К примеру, если он ведет развивающийся проект и регулярно добавляет в него новые иконки. Тогда дизайнер может самостоятельно изменять SVG-спрайт, например, через этот вот сервис и отправлять готовый файл на фронтенд. Мелочь, а приятно.
Прикладывайте шрифты
Любой дизайнер, думаю, знаком со списком «безопасных» веб-шрифтов. Однако их чаще всего не достаточно. Когда я занимался версткой, мне регулярно попадались макеты с проприетарными или просто редкими шрифтами, при виде которых фотошоп разрывался от ярости предупреждающими окнами. Конечно, многие дизайнеры, отправляя финальный макет, прикладывают к нему и архив со шрифтами (а многие не прикладывают). Но даже имея «на руках» необходимый шрифт в формате .ttf или .otf, не всегда получается правильно внедрить его в верстку.
Хочу открыть небольшую тайну дизайнерам. По крайней мере тем из них, кто с ней еще не знаком. Каждый шрифт, который вы хотите использовать в макете (если он не входит в список «безопасных»), должен быть представлен как минимум в четырех форматах: ttf, eot, woff (или woff2, а лучше оба) и svg. А если вы используете проприетарный шрифт, то его использование в вебе может быть несколько осложнено. Да и не совсем законно.
Я всегда советую подбирать шрифт из Google Fonts, предварительно посмотрев, есть ли у него поддержка кириллицы. Если же этот вариант не подходит, то стоит проверить проприетарность шрифта или сразу подготовить архив со всеми необходимыми форматами. Сконвертировать их можно при любезной помощи этого сервиса (не забудьте переключиться в режим «EXPERT...» и в секции «Subsetting», отметив «Custom Subsetting...», проставить галочку рядом с «Cyrillic»).
Ибо нет более надежного способа покорить сердце верстальщика, чем вручить ему готовый набор шрифтов для интеграции в веб.
Эпилог
Конечно, множество моментов оставлено здесь без внимания: иерархия и наложение слоев в исходниках, типографика, наборы иконок и многое, многое другое. Однако статья и так получилась объемной, а большинство того, о чем я не написал, прекрасно находится в интернете по запросу «советы дизайнеру». Вот, например, еще рекомендации от Spaceoddity: habrahabr.ru/post/173271
И да, о смысле. Если этот пост помирит хотя бы одну пару дизайнера с верстальщиком, или сэкономит десяток-другой человекочасов — значит, время на его написание было потрачено не зря.
Спасибы
Благодарю нашего бессменного дизайнера Andrianka за советы и подбор изображений для этого поста, а также фронтендера от Бога HtmlMak за грамотное резюмирование и подсказки.
Комментарии (66)
A-Stahl
09.10.2016 18:42+4>Изучите основы верстки
Так дизайнер (если мы говорим про сайты или другие вещи где применима вёрстка ) и так должен быть в курсе азов вёрстки. Иначе он художник, а не дизайнер.
А всё остальное в статье отталкивается от того, что дизайнер ничего про вёрстку не знает.Delphinum
09.10.2016 18:44+1Должен, только чаще дизайнеры больше походят на «девочек дизайнеров, оформителей интерьеров», умеют в 3DMax кубики собирать, но когда им говоришь, что сюда раковину не поставить ибо трубы в такую тонкую стену не залезут — округляют глазки и долго вдупляют, что же этот подлый дядька-строитель от них хочет…
Shkip
10.10.2016 14:41В мебельном дизайне тоже самое — то что дизайнер творить не всегда можно реализовать(
Skreep
09.10.2016 18:46+3C первой частью согласен. Вот только на лицо совсем иная ситуация. Очень много дизайнеров, называющих себя профессионалами, с версткой не знакомы абсолютно.
А касаемо «всего остального» — согласиться не могу. Лично знаю пару дизайнеров, которые не знают верстки, но умеют работать с SVG и всегда прикладывают шрифты.
Firefoxic
09.10.2016 19:24+1Побольше бы таких статей.
Спасибо!isersh
09.10.2016 19:57-1Их и так уже вагон и маленькая тележка… :)
Firefoxic
11.10.2016 08:55Видимо мало этих вагона с тележкой, раз до сих пор приходится об этом всём писать.
isersh
11.10.2016 09:06-1Зачем же писать всё то же самое и переливать из пустого в порожнее...?
Достаточно дать ссылки на уже написанный качественный материал. :)Skreep
11.10.2016 23:00Цитируя Хабраэтикет:
Если схожие темы неоднократно поднимаются под разными предлогами, это не значит, что надо ставить минус. Это лишь значит, что проблема до сих пор не решена.
isersh
12.10.2016 11:21Проблема во многом надуманная.
А окончательно она будет решена, когда появятся совсем уж гибкие для верстальщика инструменты и возможности. А нужен ли будет тогда верстальщик...? :)
Хотя и сейчас уже столько всего напридумано, что сверстать можно любой макет, было бы желание и достаточная квалификация у верстальщика.
Да и вообще, для меня понятия «веб-дизайнер», «вебмастер» — человек, который способен красиво нарисовать и качественно сверстать задуманное.Skreep
12.10.2016 11:33Какая проблема — надуманная? Недостаточная квалификация некоторых дизайнеров? Или проблема взаимодействия обеих сторон? Простите, не могу согласиться ни с тем, ни с другим.
Как и с тем, что проблема решится только с появлением какого-либо гибкого инструмента. У меня в команде, например, очень профессиональный дизайнер и такой проблемы попросту нет уже несколько лет. И я лично знаю еще несколько веб-дизайнеров, которые знают свою работу и делают ее хорошо — так, что с их макетов верстать легко и быстро. Но вместе с тем есть масса и обратных примеров.
А насчет «сверстать можно любой макет» — конечно. Внимательно перечитайте статью. Там в самом начале указаны последствия верстки непрофессионально созданных макетов.
Если честно, у меня создается ощущение, что мы с Вами о разных проблемах говорим))
isersh
12.10.2016 12:17Помните, как в Матрице — «ложки не существует» :)
Так же и здесь — проблемы, обозначенной в статье, не существует.
Проблема только в кадрах.
Если мы говорим о профессионалах, то как для дизайнера, так и для верстальщика, а также и для дизайнера-верстальщика сделать конфетку проблем не составит.
Если речь идёт о «любителях-нелюбителях», то Крылов об этом уже всё сказал: "… А вы, друзья, как ни садитесь, Все в музыканты не годитесь"…Skreep
12.10.2016 12:27Проблема только в кадрах.
Это настолько же верно, насколько и банально. Кроме кадров, в нашей сфере и нет ничего. Ни станков, ни заводов, ни логистики даже толком. Офисы и ПО — да и без первого обходятся все чаще. Указывая, что проблема только в кадрах, Вы лишь подтверждаете ее наличие.
Люди становятся профессионалами не сразу. Многим подобные статьи как раз и помогают в таковых превращаться.isersh
12.10.2016 13:35Да я ведь не против статьи как таковой. Я просто подчеркнул, что таких статей множество, а «воз и ныне там»… Т.к. во многом в этих статьях делают акцент на разделении дизайна и вёрстки в отдельные узкие специализации, а это, imho, не верно.
Это должен быть _профессионал_ в одном лице.
NeoCode
09.10.2016 20:19+1Мне вообще кажется все это странным. Зачем такое жесткое разделение обязанностей? Зачем рисовать сайт в фотошопе попиксельно? Дизайн это так, приблизительный внешний вид. Приблизительный.
Должно быть так — идеологи придумывают функционал сайта, определяют что где будет находиться, меню там всякие и формы ввода, совместно с дизайнером придумывают приблизительные эскизы страниц. Пусть в фотошопе, но эскизно. Далее разработчики делают сайт, пытаясь при этом минимизировать его размер, количество всяких картинок, скриптов и прочего шлака, что мы закачиваем мегабайтами каждый раз при заходе на страницу. Максимизируют скорость загрузки (для этого в конторе должна быть специальная машина, желательно старая и дохлая, с зарезанной до предела скоростью интернета и древней операционной системой, по возможности с вирусами). И самое главное — разработчики повышают удобство работы, логичность всего на сайте.
А дизайнер смотрит на все это, на промежуточные этапы, на конечный результат, на юзабилити сайта и говорит — вот здесь шрифт нечитаемый, здесь сочетание цветов неадекватное, здесь слишком мелко, здесь неровно и т.д. То есть советует, корректирует работу в процессе и оценивает результат. А не рисует никому не нужные макеты в фотошопе и не заставляет нас, пользователей, закачивать тонны никому не нужных шрифтов, картинок и css-ок.sashabeep
09.10.2016 20:33+1В какой момент дизайнер получит свои деньги при таком подходе?
А верстальщик?NeoCode
09.10.2016 20:35-3Ну если все упирается в деньги то да, будем иметь такой интернет как имеем.
sashabeep
10.10.2016 11:10+2Суть в том, что при таком подходе разработка проекта, разбитая на этапы не может закончиться в-принципе. Ответственность участников за каждый из этапов необоснованно усиливается и размазывается по количеству подходов и итераций
Skreep
09.10.2016 21:21+1И снова все неоднозначно.
Например, моя команда работает как раз примерно так, как Вы и описали (с тем лишь различием, что макеты, все же, готовим полностью, а не эскизно). Но мы за пять лет сработались и знаем, что друг от друга ждать.
Если же брать наиболее частый случай, когда команда собирается только на один-два проекта… Я очень сильно сомневаюсь, что описанный Вами подход сработает. Фронтендщики, а уж тем более — программисты, не очень шарят в дизайне, уж простите. И доверять им формирование внешнего вида сайта, пусть даже в деталях, я бы, как руководитель, не стал. Мне жалко дизайнера.
И не совсем понял, при чем здесь «никому не нужные макеты» по отношению к тоннам статики. Это уже частности, я о них как раз в статье и написал))
Slydex
09.10.2016 23:23+2После придумывания приблизительных эскизов страниц будет сделан приблизительный дизайн, позже отдан, приблизительно, верстальщику для приблизительной верстки, после чего приблизительная верстка будет натянута на приблизительный бэкенд. Отдел тестирования приблизительно протестирует и опишет приблизительные баги. Команда сдаст такой проект в приблизительный дедлайн и получит приблизительный к описанному в контракте оклад.
Finesse
12.10.2016 05:59+1Это не работает в случае разработки сайтов под ключ. В них дизайн является самой важной составляющей сайта. В таком случае выгоднее сделать дизайн, согласовать его с заказчиком, внести пожелания и уже только после этого начать верстать, чем верстать страницы до согласования с заказчиком. В первом случае несколько раз работает дизайнер и 1 раз верстальщик, а во втором оба работают по несколько раз.
alltiptop
09.10.2016 21:24-1А как можно всего этого не знать?
Skreep
09.10.2016 21:26+1Можно. В смысле, нельзя, но встречается. И чаще, чем хотелось бы.
Я очень люблю дизайнеров, их работа действительно важна. И от того еще сильнее расстраивают, когда сталкиваюсь с подобными вещами.
zahmTOD
11.10.2016 18:47Да легко. Уже больше 10 лет есть высшее образование на графдизов этого врофиля, но спрос настолько велик, что их катастрофически не хватает. По моим прикидкам в России только 1% веб-дизайнеров имеет профильное образование.
search
09.10.2016 23:10С аналогичной проблемой я столкнулся на своей текущей работе римерно 2 года назад.
Внедрение и использование стайлгайда частично решило проблему. Теперь у дизайнера перед глазами все функциональные элементы и, перед тем как ваять что-то новое, дизайнер пробегает глазами по тому, что уже есть.
Полностью, от дизайнерских полётов фантазии, стайлгайд не спасает. Но всегда есть возможность прислать дизайнеру ссылку на аналогичный элемент и поинтересоваться, почему именно на этой странице должно быть что-то другое.
Пользуясь случаем, хочу пропиарить свою библиотеку для быстрого создания стайлгайдов: https://github.com/sneas/component-library. Использую её на своём текущем проекте. В папке /demo есть пример того как встроить стайлгайд в процесс сборки на галпе. В /demo/gulpfile.js можно увидеть пример подключения.
radist2s
09.10.2016 23:13+4Каждый шрифт, который вы хотите использовать в макете (если он не входит в список «безопасных»), должен быть представлен как минимум в четырех форматах: ttf, eot, woff (или woff2, а лучше оба) и svg.
Если я и получу от дизайнера шрифты сразу во всех веб-форматах, то толку от них будет мало, скорее всего. Из шрифта нужно вырезать неиспользуемые символы, сделать хинтинг, прописать нормальную высоту строки, чтобы на всех ОС вертикальное выравнивание было одинаковым.
И, кстати, забудьте вы уже про шрифты в svg, идея изначально была бредовая.Skreep
09.10.2016 23:22+2Благородно и похвально, честно. Как-нибудь надо провести опрос, сколько фронтенд- разработчиков так же серьезно относятся к шрифтам. Боюсь, не очень много. Но фронтенд — это тема отдельной статьи.
radist2s
10.10.2016 01:26+1Раз уже зашел разговор про оптимизацию шрифтов, до я тихонько пропиарю свой модуль для ноды, где все вышеперечисленное выполняется автоматически.
Ashot
10.10.2016 01:26+1сделать хинтинг, прописать нормальную высоту строки, чтобы на всех ОС вертикальное выравнивание было одинаковым.
А вот про это можно поподробнее? Сам фронтэндщик, но как правильно поступать с этими параметрами не знаю до сих пор, к сожалению
radist2s
10.10.2016 01:34+2По-русски про это написано мало, но недавно прочитал от гугла неплохую вводную статью, по поводу вертикального выравнивания большинство ссылок уже устарело, но можно почитать тут, а как делать это на практике тут. Вообще, FontForge — это инструмент №1 для работы со шрифтами(по крайней мере для меня). Сообщением выше я уже написал про свой модуль для ноды, который делает все сам.
noodles
10.10.2016 01:10+1В чьей зоне ответственности оптимизация svg ( т.е. уменьшение узловых точек, выравнивание по пиксельной сетке, по возможности максимальное использование простых примитивов круг, квадрат, полигон и последующее их объединение при необходимости вместо фигачинья кистью 100500 точек) — дизайнера или верстальщика?
Если верстальщик явно видит что некое растровое изображение в макете простое и явно будет меньше весить в svg — можно ли требовать от дизайнера перерисовать в кривых?Skreep
10.10.2016 01:18+1Скользкий вопрос.
Я всегда возлагал оптимизацию SVG на дизайнера. Это графика. Верстальщик может пропустить и не заметить какой-то элемент. Точку там или даже глаз — такое бывало.
Последние года полтора-два мы вообще используем только векторные иконки. И если приходится работать со сторонним дизайнером, то я всегда прошу предоставить набор SVG. Очень часто это приводит к увеличению сроков, так как дизайнер присылает те самые «псевдо-SVG». Но такова жизнь.
Но если верстальщик сам немного дизайнит, или, например, в команде так заведено — ради Бога.radist2s
10.10.2016 01:24Да ладно, чаще всего дизайнер даже не понимает чем отличаются разные варианты экспорта svg. Не понимает разницу между встроенными и инлайн-стилями, или атрибутами. Если на странице используется инлайновый svg, то криво-экспортированный svg может доставить кучу проблем с отображением, начиная от непонятных масок, заканчивая слетевшими цветами.
Skreep
10.10.2016 01:34+1Да. Именно поэтому я и вынес эту историю в отдельный пункт про SVG. Веб-дизайнер должен уметь работать с SVG более глубоко, чем «экспортнуть из фотошопа». Надеюсь, в ближайшем будущем ситуация поменяется и дизайнеры поймут, насколько важен для веба вектор.
Если есть проблемы с вектором, который дал дизайнер, мы отправляем его обратно на доработку (хотя в ряде случаев быстрее и проще самим поправить). Здесь многое зависит от того, будет ли сотрудничество долговременным.
Дизайнеры далеко не так глупы, как их часторисуют. У меня за всю SVG-историю с ними только раз был инцидент с «нехочунебуду». Почти всегда дизайнер, даже если не понимал, о чем мы его просим, довольно быстро разбирался в теме.radist2s
10.10.2016 01:39Если честно, то я не совсем могу понять эту проблемы про с svg. 99% из 100 иконки и так уже векторные, если говорить про PSD. Даже представить сложно кто сейчас рисует только с учетом 96 dpi. Хотя, быть может я просто с откровенно плохими дизайнерами не работал.
Skreep
10.10.2016 01:44+1Некоторые веб-дизайнеры не берут готовые иконки, а рисуют их сами. Растром. Или находят в вебе, и копируют в макет. Тоже растром. И когда потом просишь их предоставить вектор, возникают проблемы. Это в случае с фотошопом.
С дизайнерами, работающими в Sketch, немного проще. Но тут все равно остается актуальным вопрос с «data:img/png;base64» и оптимизацией. Если это иконки знака вопроса, а весит она как чугунный мост, стоит задуматься.
anton_reut
10.10.2016 14:49Если рисовать в Fireworks в формате PNG то там по сути объекты векторные при редактировании, прижелании можно сохранить в SVG и закинуть или в Иллюстратор или в Корел — будет вектор.
Skreep
10.10.2016 15:03Наверное. Вот только большинство макетов для веба создаются в фотошопе и скетче)
andrhohlov
10.10.2016 05:17А я требую от дизайнера собюдать вот это: https://github.com/andrey-hohlov/psd-templates-requirements и буду рад пулл-реквестам
Glomberg
10.10.2016 09:42+1Спасибо за статью, прочел с интересом. Сам я frontend-ер и работал с несколькими дизайнерами. Некоторым из них я бы с удовольствием скинул эту статью :-)
Единственное, хотел бы возразить пункту «Помните про адаптивность». Адаптивность — это да. Но не такими жертвами — делать несколько макетов под каждое разрешение. Это очень дорого. Я работал с дизайнером, у которого в отдельном txt было описано поведение каждой страницы при каждом пороге разрешений (для Bootstrap). Примерно так:
Категории товаров
до 970px уменьшается ширина элементов
при меньших экранах блоки размещаются друг под другом.
Блоки с преимуществами
Сначала уменьшается ширина блоков в соответствие со столбцами.
При экранах от 750 и меньше
блоки скидки и торговая марка размещаются под блоком доставка
При экране 320px блоки занимают всю ширину экрана и размещаются друг под другом.
Хиты продаж
Уменьшается количество выводимых товаров.
Для 1170 - 6 товаров, 1 товар занимает 2 колонки
для 970 - 4 товара, 1 товар - 3 колонки
для 750 - 3 товара, 1 товар - 4 колонки
для 480 - 2 товара 1 товар - 3 колонки (всего 6 колонок)
для 320 - 2 товара, 1 товар - 3 колонки (всего 6 колонок)
И еще — добавьте в статью информацию о фавиконе) Это обязанность дизайнера, а фавиконов в макете почти всегда нет :(Skreep
10.10.2016 10:06Адаптивность адаптивности рознь. Не сказать, что я не совсем не доверяю верстальщикам, сам из них, но не всегда перестраивание элементов — такая простая задача. Всегда есть отступы, позиции кнопок, иконки — тьма не самых очевидных для фронтендера нюансов. И потом смотришь на сайт — все, вроде, на месте, а глаз режет. Даже при наличии инструкций. Хотя здесь кое-что зависит от масштаба проекта и «дизайнутости» верстальщика.
Насчет favicon — это тема отдельной статьи, и недавно на хабре она уже
публиковалась. Фавиконок нужно довольно много, не говоря уже о манифесте и прочем. Не думаю, что стоит повторяться с такой малой периодичностью.
В ряде простых случаев достаточно воспользоваться вот этим ресурсом, если нет возможности запросить у дизайнера favicon.
noodles
10.10.2016 12:27Почему всё-время пиарят эти сетки? Оне вроде бы же ограничивают как-то дизайнера, разве нет?:
«сначала нужно сделать хорошо, а потом уже заниматься сеткой” https://youtu.be/trf-C-MI5x8?t=18m10s (скорость лучше х1,5)
http://artgorbunov.ru/bb/soviet/20131104/
я, например, эту вырвеглазную сетку вообще отключаю, только мешает продумать/увидеть общую архитектуру компонентов. По-моему с помощью flexbox-ов, свойства calc и единиц измерений vw, vh можно построить любую сетку (могу ошибаться), а всякие бутстрапы это избыточно, максимум оттуда взять отдельные элементы можно (попап-окна, чекбоксы)
По поводу адаптивности — тоже как-то напряжно когда дизайнер даёт 25 макетов под все возможные разрешения. Мы договорились что он рисует под максимальное и минимальное разрешения (может ещё быть промежуточный вариант под какой-то конкретный айпад если сильно нужно), а разработчик уже делает компоненты резиново-адаптивными в этих пределах на своё усмотрение, когда компонент начинает „ломаться“ при уменьшении ширины и нужно принять компромиссное решение, зову дизайнера и спрашиваю „что делаем? перескакиваем на следующий ряд или прячем элемент? картинку кропаем или просто уменьшаем?“ (так вроде легче и быстрее всем). Да и пиксель-перфект это как-то уже старомодно и не рационально, выше правильно написали — что надо корректировать уже походу дела с дизайнером ок/не ок. Это как-бы и есть командная работа всё-таки.Skreep
10.10.2016 19:02Насчет сетки не согласен, но каждый работает так, как ему удобно. По моему мнению, визуальная структуризация адаптивности невозможна без гридов или их аналогов.Сверстать-то можно все, с этим никто не спорит. Однако тогда легко скатиться в бездну «если не видно разницы, зачем платить больше».
О том, почему не всегда стоит перекладывать адаптивность на верстальщика, я выше уже писал. Описанная Вами схема работает отнюдь не всегда. Велика вероятность того, что итог работы будет не самым лучшим, потому что где-то надо грамотно расставить пропорции блоков, где-то заменить иконку на текст, где-то просто убрать элементы. И далеко не всегда верстальщик способен (да и должен) правильно это сделать. Просто потому что он не дизайнер и не проектировщик.
Пиксель-перфект же нерационален только в случае, если предварительное взаимодействие с дизайнером не прошло на должном уровне. Если дизайнер в своей работе не учел реалий — например, фреймворка. Мы же хотим жить в идеальном мире, правда? Так давайте попробуем сами сделать его немного лучше хотя бы в той сфере, в котором работаем))noodles
10.10.2016 21:12О том, почему не всегда стоит перекладывать адаптивность на верстальщика, я выше уже писал. Описанная Вами схема работает отнюдь не всегда. Велика вероятность того, что итог работы будет не самым лучшим, потому что где-то надо грамотно расставить пропорции блоков, где-то заменить иконку на текст, где-то просто убрать элементы. И далеко не всегда верстальщик способен (да и должен) правильно это сделать.
Согласен, именно поэтому я и написал, что в такие моменты зовём дизайнера и ОБЩАЕМСЯ. Если нужен какой-то конкретный промежуточный вариант с идеальной композицией (например заказчик просматривает результат на своём айпаде) — пусть отдельно отрисовывает под это разрешение, не проблема.
anton_reut
10.10.2016 14:41-1«Научитесь работать по гридам» — а не проще написать Научитесь работать по модульным сеткам?
inoyakaigor
10.10.2016 14:58SVG это боль, да. Недавно прислали макет в котором SVG нарисованы с помощью clip mask или чего-то такого (извините, я не силён в терминологии SVG) и когда я их совал в icomoon, то сайт либо ругался на меня, что нужно stroke (могу ошибаться в термине) конвертировать в path, либо рисовал чёрный квадрат на месте катушки Кинопоиска.
illo
10.10.2016 15:17Мастерство заголовка. «Дизайнь» — это что за слово?
Skreep
10.10.2016 18:34А какой глагол может быть производным от существительного «дизайн»?
illo
10.10.2016 19:08-1А зачем создавать производные? Существует множество слов которые не склоняют.
Cлово дизайн (design) может использоваться как глагол.
У вас в тексте есть отличный пример:
Некоторые рекомендации для дизайнеров, делающих мир чуть светлее.
Skreep
10.10.2016 19:11Ну как бы русский язык потому и могуч, что славится заимствованиями и производными)) Впрочем, не думаю, что это принципиально. Я учту Ваш комментарий, когда буду придумывать название для следующей статьи, спасибо.
Finesse
12.10.2016 06:06+2Это слово воспринимается как существительное дизайн, написанное с ошибкой. Нужно приложить усилия, чтобы увидеть в нём глагол.
Realetive
11.10.2016 03:53+1Купив фотоаппарат, я стану фотографом, борную машинку — стоматологом, Фотошоп — дизайнером. А после прочтения этой статьи, меня полюбят все верстальщики…
Нет, не бывает дизайнеров, не знакомых с правилами типографики, не отличающих гротеск от антиквы, не слышавших о понятии вертикального ритма, «выключки» или висячей пунктуации.
Не существует ни одного дизайнера интерфейсов, не читавшего труды Чихольда, Альцшуллера или Нильсена. И каждый из них знает про законы Фиттса и Хика, его интерфейсы проходят на тестирование «переполнения контентом», а анимация описывается бо?льшим смыслом чем «красивая» или «плавная».
Потому что именно эти знания позволяют понять, почему после абзаца следует отступ, что динамика требует связности, а переопределение — доступности. Только знание правил позволяет их же и нарушать, а не «вот этот блок сюда, ему нужно больше „воздуха“». Иначе я возьму в руки скальпель и начну лечить этих «дизайнеров», потому что «мне идёт этот халат».Skreep
11.10.2016 03:54+1Не после прочтения. После кропотливой и довольно серьезной работы, на которую может сподвигнуть прочтение этой статьи.
heathen
11.10.2016 07:30Нет, не бывает дизайнеров, не знакомых с правилами типографики, не отличающих гротеск от антиквы, не слышавших о понятии вертикального ритма, «выключки» или висячей пунктуации.
«Вы не поверите»…
Увы, действительность такова, что часто приходится выбирать из того, что есть. В любой области, и дизайн — не исключение. Относительно недавний яркий пример: человек «рисует» очень неплохо, заказчикам нравится, но вот он имел весьма смутные понятия о том, как всё нарисованное реализуется в конечном продукте, и потому зачастую появлялись проблемы. При этом категорически ленился заняться самообучением, хотя мог бы зарабатывать больше в этом случае.
DenVdmj
11.10.2016 07:37Я не дизайнер, и не верстальщик, и скажу спасибо если мне кто-нибудь объяснит, почему веб-дизайнер и веб-верстальщик настолько разные и гордые профессии, что не просто не пересекаются, но и, по всей видимости, считают это ниже собственного достоинства.
heathen
11.10.2016 09:43В том числе и потом, что квалификация требуется разная, и стоимость дизайнера (нормального, а не доширакера) существенно выше стоимости верстальщика. Плюс есть технические нюансы, в которых нужно разбираться верстальщику — не то, чтобы сложные, но достаточно нудные.
Delphinum
Мне кажется всю эту статью можно ужать в старый добрый «Keep It Simple, Stupid». Это крайне часто относится к дизайнерам и их мании величия («если не я, то от продукта клиент будет плеваться!»), но как правило чем проще, тем лучше и клиенту, и дизайнеру, и верстальщику, и, соответственно, кошелькам.