CSS для дизайнерів і не тільки. Основи, які має знати кожен. Частина 2

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Усім привіт! Як і обіцяв, публікую другу частину тексту CSS для дизайнерів. Першу частину можна прочитати за посиланням.

Як правило, чим складніший інтерфейс і його елементи, тим більший розрив між дизайном і версткою. Верстальнику складно реалізовувати амбіційні ідеї дизайну, а дизайнеру бракує знань цієї реалізації. Найкраще обговорити все на старті, але деякі речі все-таки можна винести як аксіоми. Про це ми поговоримо в другій частині статті про базову CSS для дизайнера.

Адаптивність

Адаптивність — одна з найскладніших частин як для дизайну, так і для верстки. Один мій знайомий дизайнер сказав: «Щоб зрозуміти, як це працює, треба зверстати це самому». А інший порадив прочитати книгу Фроста «Атомарний дизайн». Звісно, це чтиво для «ідеального розуміння». І все-таки певні вузькі місця в ній можна виокремити.

1. Mobile first

Підхід, на який переходять дедалі більше фахівців. На ділі все просто. Легше працювати з появою нового простору, ніж з його дефіцитом. Будь-який дизайнер прагне зробити свій макет унікальним і функціональним, тому, починаючи desktop-версію, застосовує всі свої свіжі сили, яких не залишається для стиснення всієї цієї краси та функціональності в мобільній версії. Рекомендую розібратися із цим підходом і випробувати його найближчим часом.

2. Точки роздільних здатностей

Уже давно прийнятий підхід створення дизайну під три роздільні здатності: 320, 768, 1024 (якщо інше не обговорено щодо проєкту). І це зручно. Гумовий дизайн (особисто на мою думку) не має сенсу. Малювати й верстати під усі роздільні здатності від 320 до 1500 економічно недоцільно, зважаючи на витрачені ресурси та кількість пристроїв «між».

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

3. Безшовні структури

Це про відчуття геометрії. Якщо в desktop намальований header, у якого градієнтний фон, то дуже дивно, якщо на планшеті він розділиться на два блоки з блоком між ними. Проте такі рішення зустрічаються. Вирішити це можна тільки через використання дублікатів контенту, а це зло, біль і милиця. Зважайте на те, що блоки мають переміщуватися між роздільними здатностями в адекватних рамках: наприклад, при зменшенні колонок, але елемент не може просто переміститися з одного безшовного блоку в інший.

4. Дизайн живий

Чи чули ви колись розмову поза контекстом? Інколи фраза, вирвана з контексту, може бути кумедною. Навіть до сліз. З дизайном так само. Тільки такий дизайн викликає сльози та страждання.

Завжди пам’ятайте, що створюєте інтерфейс, а не статичне зображення. Користувач взаємодіє з ним, а отже, інтерфейс може мати певні стани: з наведенням, активний, відкритий, закритий, увімкнений, вимкнений та інші, відкриватися на різних пристроях з різними роздільними здатностями та способами читання (йдеться про пристрої відтворення контенту й доступності інтерфейсів), підлаштовуватися під орієнтацію пристрою та багато іншого залежно від того, що це за елемент. Навіть якщо робите «легкий» редизайн елементу, продумуйте зміни його станів і версій під різноманітні пристрої. Пропуск таких важливих речей викликає дуже багато блокерів, затримок і непорозумінь.

Кольори

Кольори — головне джерело мемчиків. Знаєте, з категорії про «червоний колір червоніший» і «синє коло червоним кольором». Однак насправді тут усе просто.

1. Кольорів не може бути забагато

Споріднені або суміжні відтінки мають бути одним кольором. Ця проблема виникає, коли немає стайлгайду або він ігнорується.

2. Прозорість тексту

Колір тексту в CSS визначається властивістю color.
Для прозорості кольорів використовуються формати HEXA (#RRGGBBAA), якщо не підтримується IE11 або RGBA (rgba(255, 255, 255, 0)). Колір шрифту має бути зазначений у властивостях, і для його визначення достатньо однієї властивості. Мають бути виключені такі ситуації:

  • Колір тексту визначається змішуванням прозорості цього тексту й фону (за винятком випадків, коли змішування зроблено спеціально). Тобто якщо колір шрифту має бути червоного кольору, він не повинен «отримувати» цей колір від червоного фону за допомогою своєї прозорості. Є випадки, коли це задумано та необхідно, щоб колір тексту змінювався залежно від фону. Тоді можна просто зазначити прозорість у колір шрифту, а відтінок він візьме з фону, але це рідкість.
  • Колір тексту змінений через opacity батьківського елементу.
  • На текст накладені ефекти/шари, що спотворюють його колір.

Розміри та відступи

Розміри та відступи не цікаві. Краще одразу домовитися, за якими правилами й константами визначатимуться розміри блоку, і дотримуватися їх. Усього пара пунктів у цьому розділі.

1. Модульні сітки

Про важливість сіток я не писатиму. Якщо ви дизайнер, то, скоріш за все, знаєте всю теорію про сітки. Я напишу про важливість дотримання ширини колонок і відступів між ними. Першим кроком до верстки сайту по макету із сіткою є розмітка та стилізація «наскрізної» сітки для всіх сторінок. І якщо пізніше надходить макет без дотримання зазначених правил, то весь написаний раніше код стає непридатним для цієї сторінки. Така ситуація допустима, якщо створюється одиничний, унікальний дизайн промо-сторінки, що виходить за межі основного зовнішнього вигляду сайту. Однак вона абсолютно недопустима для створення типових сторінок. У першому випадку варто узгодити відхід від прийнятої моделі й додаткові витрати часу Front-end-розробника. До того ж слід врахувати, що правила СSS можуть описувати не тільки найвищу сітку, але й колонки всередині колонок, якщо є потреба. Тобто ми можемо мати елемент шириною в 6 колонок з 12 наявних (у разі 12-колонкового макета) і два елементи по 6 колонок всередині, оскільки відлік розпочатий у новому блоці.

Варто описати сітки для всіх трьох роздільних здатностей і дотримуватися їх.

2. Смерть Pixel Perfect

Якщо ви дизайнер і перевіряєте верстку своїх макетів на PP, припиніть просто зараз. Якщо ви верстальник, то донесіть, що робити це надмірно. Якщо ви QA і використовуєте PP, то зупиніться й подумайте: а навіщо?

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

Чи варто витрачати пів дня роботи на ті зміни, які жоден користувач візуально не побачить? Будь-який замовник скаже вам, що ні. Пам’ятайте, що ви створюєте продукт, а не виставковий експонат. Будь-які розбіжності з макетом, що не можна побачити неозброєним оком, можна ігнорувати, окрім константних (ширина макета, колонки модульної сітки, висота рядка тексту).

Моя рекомендація: допустиме відхилення — у 5 пікселів за вертикаллю та в 3 за горизонталлю.

Анімація

Як зверстати макет — зрозуміло. Але як зверстати анімацію? Як можна покращити верстку анімації по відео, де брати значення та чи вистачить чистої CSS? Дизайнер, який розуміється на CSS-анімації, відповість на ці запитання без проблем. Варто вивчити анімацію на базовому рівні. Це дасть пристойний буст у розробці анімацій для Web і не тільки.

1. Плавність

У CSS є плавність і анімації. Це два окремі набори властивостей. Однак найбільше ефектів анімування, як його бачать користувачі, досягаються якраз за допомогою використання плавності. Плавність — це просто. Це перехід однієї властивості з одного значення в інше, але не моментально, а за певний час. Але з іншого боку, це дуже гнучкий інструмент, щоб «оживити» макет. Погляньмо, що ми тут маємо:

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

На цьому сайті можна налаштувати виконання плавності залежно від часу. Використати одне з константних значень: easy, linear (стандартно), ease-in, easy-out, easy-in-out або просто зробити свою унікальну функцію та скопіювати, а потім передати значення верстальнику.

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

Детальна стаття про плавність.

Приклад кнопок чистою СSS з плавністю.

2. Справжня анімація

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

Трохи CSS

Як бачите, можливостей більше. Усі ці властивості описують кроки зі зміною однієї або безлічі властивостей, описаних раніше. Одразу приклад.

Кроки анімації з прикладу

Властивості анімації

У прикладі для кожного кружечка застосовується одна й та сама анімація, але з різною затримкою.

Можливо, вам стане цікаво вивчити можливості CSS для анімацій, але як мінімум із цими знаннями ви можете проводити аналогії з тими властивостями, які використовуєте для створення анімацій і передачі їх верстальнику.

Важливість стайлгайдів

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

Уся якісна верстка побудована на модульності. Будь-який дублікат коду — це зло. Тому якщо є два блоки, які візуально однакові, то їх варто уніфікувати й винести в окремий модуль (кнопки, типові картки, посилання), а його — у стайлгайд. З таким підходом у верстальника є універсальні модулі й дизайнеру легше розширювати макети. Не думаю, що для когось це новина, але не сказати про це не можна.

Другий важливий складник стайлгайду — це модульні сітки. Набори станів, кольорів, кнопок, елементів — це лад у роботі та відносинах.

Комунікація

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

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

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

Замість висновку

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі