Дизайнь як верстальник



Ваш дизайнер – справжній геній і його продукт ідеальний. Він доблестен в нерівній боротьбі з ТЗ і завжди виходить переможцем. Але вже п'ятий за рахунком верстальник, матюкаючись, робить з його макетів якусь гидоту? Не поспішайте шукати шостого. Найчастіше причина легко долається – досить лише сказати вашій генію про кількох приземлених правилах і попросити його їм слідувати.
У цій статті я спробував зібрати деякі рекомендації для дизайнерів, які роблять світ трохи світліше. Запитайте у верстальника про його проблеми, відправте цю статтю дизайнеру. Бо досконалості немає межі.

Проблема існувала завжди, скільки я себе пам'ятаю айтішником. Коли проектування інтерфейсів було лише красивим словосполученням, сенс якого розуміли тільки справжні профі, дизайн відповідав мінімум за дві третини враження від сайту. Зараз трохи простіше, UI-проектування все частіше відокремлене від дизайну, хоча і робить його деколи один і той же чоловік. У будь-якому разі, саме веб-дизайнер перетворює смутні образи або сухі прототипи в те, з чим потім взаємодіяти користувачеві. І дуже важливо, щоб верстальник переніс цей дизайн веб максимально точно. Бажано взагалі без змін. Попіксельно. Запитайте у будь-якого дизайнера, наскільки часто фінальна верстка повністю влаштовує? Упевнений, відповідь буде сумним, якщо не різким.

Про причини цього можна говорити довго, але найчастіше звинувачують верстальника. Воно й зрозуміло: дизайн є, дизайн хороший, будь як дизайн. Але, крім простого копіювання, верстальника лягає ще цілу купу обов'язків. Він повинен зробити сайт адаптивним, швидким, легким. Його верстка повинна бути семантичной, зображення – пожатыми або векторними, а форми – заточеними під бекенд. Так frontend-розробник взагалі багато чого і кому повинен, якщо він хороший (як дизайн). Ось і бере наш герой якоїсь фреймворк для прискорення та оптимізації роботи – причому не важливо, комбайн-бутстрадейшн або власний велосипед, з гридами на флексбоксах. Відкриває макети і починає ліпити. І то тут, то там, йому доводиться трохи відступати від дизайну. Або роздувати таблиці стилів, роблячи їх сложночитаемыми і невиправдано великими. Результат завжди не дуже: дизайнер незадоволений, фронтендер незадоволений, у світі стало трохи темніше.

Але це тільки в тому випадку, якщо наш дизайнер, створюючи макети і передаючи їх далі по ланцюжку, не врахував кілька важливих моментів, про які я і збираюся розповісти. Звичайно, навряд чи я зможу тут описати все, що заважає правильному взаємодії дизайнера з верстальником. Так і проблеми, що виникають у цій зв'язці, буває, взагалі ніяк не відносяться до професійних якостей сторін. Але дотримання викладених нижче рекомендаціям точно не зашкодить ні проекту, ні його розробникам.
Текст нижче — для дизайнера і, трохи, для фронтендщика. Отже, погнали.

зробіть однаковим елементи


Уявімо, що на сайті півсотні різних кнопок. Від банальної «читати далі» «провести розрахунок вартості лікування за перше півріччя». А є ще круглі кнопки з іконками і кнопки,-списки. І на кожній сторінці вони трохи відрізняються: де-то кнопка на 5 пікселів ширше за інших, де-то іконка перемістилася в праву частину, де-радіус кутів трохи різний… Виглядає, звичайно, дуже круто. І розрізнення на дизайн-макетів навіть не кидаються в очі. Але на ділі таке ставлення до елементів обертається кількома проблемами:
— верстати складніше, довше і дорожче;
— зростає ймовірність, що верстальник буде використовувати на всьому сайті тільки один з візуально майже однакових елементів;
— користувачеві доводиться кожен раз звикати» до нового виду елемента (хоча він і сам може цього не усвідомлювати);
— при розвитку проекту, швидше за все, вийде чехарда з різномастих кнопок, инпутов і тд.

Рішення просте. Дорогі дизайнери, створити єдиний документ, який помістіть всі-всі типові елементи. Заголовки, списки, параграфи, посилання, кнопки, поля форм, контроли, мініатюри зображень та інше. Таку доку називають «UI Style Guide» або «Frontend Style Guide» — хто як звик. Зазвичай це просто пошарове вихідний зразок цієї. І скрізь у проекті використовуйте тільки ці елементи і тільки в тій формі, в якій вони тут зображені. З'явився новий мультиселект? Додайте його в «стайлгайд».
Причому не варто обмежуватися тільки елементами. Створіть набір головних кольорів інтерфейсу — це теж корисно. У ряді випадків ми робимо список основних відступів, використовуваних у макетах.

Якщо верстальник досвідчений, він відразу зробить собі такий же «стайлгайд» в інтернеті, звідки просто буде копіювати елементи. Та й взагалі, переваг у «стайлгайдов» тьма: від зручності у розвитку проекту до прискорення роботи всіх, причетних до фронтенду.

Вивчіть основи верстки


Одна з найбільш суперечливих рекомендацій, мабуть. Багато хто мені заперечить, і це нормально. Але веб-дизайнер, розуміє хоча б самі базові принципи HTML і CSS, по моєму досвіду, коштує дорожче і працювати з ним приємніше. Такий дизайнер розуміє, що є шість типів заголовків, що параграф зазвичай має відступ знизу, що списки можуть бути вкладеними та інше. І тут йдеться не просто про типографіці — тут важливо, щоб макет був не тільки красивим, але і реалізованим, легким (про швидкості ми ще поговоримо нижче).

Це не складно, повірте. За пару тижнів щоденних годинних занять можна придбати базове розуміння основних HTML-тегів і можливостей CSS. Ніхто не просить вас, дорогі творці, ставати технарями і заглиблюватися в нетрі псевдоелемент. Але слід розуміти, які з ваших рішень можуть бути реалізовані в інтернеті, а для яких буде потрібно укладати союз з нечистою силою.

Навчитеся працювати з гридам


Гріди, сітка, колонки — суть одна. Якщо спростити, то модульна сітка для дизайнера представляє з себе умовний поділ макета на вертикальні колонки однакової ширини, з певними відступами між ними. Варто один раз розподілити елементи макета всередині цих колонок, і зворотного шляху вже не буде ви зрозумієте, наскільки це зручно.

Звичка працювати по сітці — одна з найбільш корисних (після ранкових пробіжок, роздільного харчування і використання хоткея). Вона дозволяє впорядковувати візуальну структуру документа, з легкістю переиспользовать блоки, прискорюючи розробку як дизайну, так і верстки. Крім того, саме на гридах будуються популярні front-end фреймворки разом з адаптивністю, а це важливо — і я до цього ще повернуся.

Для дизайнера ж гріди гарні ще й тим, що при перенесенні його макета у верстку шанс точного «збіги» зростає в багато разів. Для верстальника в цілому все спрощується. Досвідчений фронтендщик просто створить у себе в проекті точно такі ж колонки, і не буде витрачати час на попіксельне порівняння окремих блоків, не кажучи вже про адаптивності.

Тим, хто працює в photoshop'е, можу запропонувати навіть невелику добірку шаблонів. Для віддають перевагу Sketch такої штуки в мене, на жаль, немає, але вона є в гуглі.

Пам'ятайте про адаптивність


У попередньому пункті вона згадується аж два рази не просто так. Ігнорувати мобільний трафік зараз — справжній злочин, за який потрібно ввести шмагання різками. Ось вже два роки, як мені перестали потрапляти проекти, в яких не потрібно було б реалізовувати коректне відображення сайту на екранах мобільних пристроїв. Разом з тим багато дизайнери продовжують створювати тільки один варіант дизайну — основний, найбільш широкий.

Що відбувається після цього? У верстальника, який отримав такий макет, є кілька варіантів дій:
— запросити відсутні компонування сторінок, під інші дозволу;
— зробити тільки те, що йому прислали — тобто неадаптивную верстку;
— спробувати самостійно адаптувати існуючий дизайн.
Перший варіант частенько нереальний, тому як дизайнер вже отримав свої гроші, а замовник — жлоб (наприклад). Другий варіант відпадає, бо тоді фронтендщик стає співучасником і ризикує опинитися покараним. Найчастіше в такому випадку відпрацьовується третій варіант. І виходить так собі, тому що верстальник, навіть дуже хороший — це не дизайнер. Виключення украй рідкісні.

Так от, дизайнери. Дуже прошу, робіть кілька варіантів макетів, під різні дозволи. Цим ви заощадите час на розробку і підвищите шанси покласти проект в портфоліо, тому що за його реалізацію не буде соромно. Ну і в черговий раз доведете власний професіоналізм.

І до речі про гридах. Використання модульної сітки в дизайні дуже спрощує проектування адаптивності. Мені, наприклад, вже звичні наступні кроки (ширина макетів): 1440px, 1200 px, 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...», проставити галочку поруч із «Кирилиця»).

Бо немає більш надійного способу підкорити серце верстальника, ніж вручити йому готовий набір шрифтів для інтеграції у веб.

Епілог
Звичайно, безліч моментів залишено тут без уваги: ієрархія та накладання шарів в исходниках, типографіка, набори іконок і багато, багато іншого. Проте стаття і так вийшла об'ємною, а більшість того, про що я не написав, чудово знаходиться в інтернеті за запитом «поради дизайнеру». Ось, наприклад, ще рекомендації від Spaceoddity: habrahabr.ru/post/173271

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

Спасибы
Дякую нашого беззмінного дизайнера Andrianka за поради і підбір зображень для цього посту, а також фронтендера від Бога HtmlMak за грамотне резюмування і підказки.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.