Комментарии 22
У вас заголовки в посте случайно цветом забрендировались.
Спасибо за статью. А расскажите про сетку поподробнее, очень интересно. На design.ivi.ru нет информации.
Про это можно рассказывать часами!) Что именно интересует?
НЛО прилетело и опубликовало эту надпись здесь
Для начала нужно забыть про повышенные плотности экранов (retina) и считать их в дипах (dp у Андроида) или поинтах (pt у Айос).
За отправную точку для сетки вы взяли количество постеров, которые хотим видеть на том или ином экране. На телефонах получилось от 2 до 4 колонок. На всём остальном от 3 (Андроид фаблеты шириной 600 dp) до 7 (1280). Ширину всех телеэкранов мы решили считать равной 960 dp (5 колонок), поэтому им подходят макеты среднего планшета. В зависимости от платформы (Android TV, tvOS, Smart TV) вёрстка просто умножается на коэффициент (скейлится) и всегда выглядит одинаково.
У сетки по сути есть один основной параметр — минимальная ширина одной колонки и один формальный — максимальная ширина всей сетки (мы решили, что не будем заполнять контентом экраны десктопов шире 1280 pt). Запускаясь на устройстве, приложение/сайт измеряет ширину экрана/окна и считает сколько колонок в неё помещается. При расположении элементов на экране, их привязка и ширина задаётся не в хардкодных пикселях, а в колонках, вот и всё. Например промо блок вверху главной страницы ivi.ru всегда занимает все колонки и сетка сама ему передаёт нужную ширину для того или иного окна. Галерея рисует столько постеров в подборке, сколько есть колонок. А размер каждого постера берётся из текущей ширины колонки.
Надеюсь объяснил хоть немного!)
За отправную точку для сетки вы взяли количество постеров, которые хотим видеть на том или ином экране. На телефонах получилось от 2 до 4 колонок. На всём остальном от 3 (Андроид фаблеты шириной 600 dp) до 7 (1280). Ширину всех телеэкранов мы решили считать равной 960 dp (5 колонок), поэтому им подходят макеты среднего планшета. В зависимости от платформы (Android TV, tvOS, Smart TV) вёрстка просто умножается на коэффициент (скейлится) и всегда выглядит одинаково.
У сетки по сути есть один основной параметр — минимальная ширина одной колонки и один формальный — максимальная ширина всей сетки (мы решили, что не будем заполнять контентом экраны десктопов шире 1280 pt). Запускаясь на устройстве, приложение/сайт измеряет ширину экрана/окна и считает сколько колонок в неё помещается. При расположении элементов на экране, их привязка и ширина задаётся не в хардкодных пикселях, а в колонках, вот и всё. Например промо блок вверху главной страницы ivi.ru всегда занимает все колонки и сетка сама ему передаёт нужную ширину для того или иного окна. Галерея рисует столько постеров в подборке, сколько есть колонок. А размер каждого постера берётся из текущей ширины колонки.
Надеюсь объяснил хоть немного!)
Это нормально?
Figma или Sketch?: )
Sketch. Да, не всё гладко с версионностью и нет командного доступа к одному проекту, но почти весь UI подключён библиотекой, а остальное обещают скоро докатить.
да, тоже есть надежды на новые фичи Скетча, как раз на распутье сейчас.
спасибо за статью и за сам труд по системе!
спасибо за статью и за сам труд по системе!
Да, примеряли Abstract и осознанно отказались. Это прилично усложняло наши процессы, а смысла поддерживать мастер-макет = продакшн мы не увидели. К тому же это ещё один сторонний инструмент, а значит зависимость от чужой технологии и её багов. Наш источник «правды» для UI — дизайн-система, для UX — продакшн. Минусы нашего подхода тоже есть. Со временем макетов становится много и найти актуальное состояние сложно. Сделают подобное в Скетче, может попробуем ещё раз.
Очень суперская статья, круто подошли к процессу.
По сетке я так понимаю продумали умножение на 2.
А будете что-то делать под широкие экраны? А то куча свободного места пропадает, да и карточки кажутся мелкими.
По сетке я так понимаю продумали умножение на 2.
А будете что-то делать под широкие экраны? А то куча свободного места пропадает, да и карточки кажутся мелкими.
Спасибо.
Да, для универсализации UI, вёрстка под телеэкраны умножается на различные коэффициенты, в зависимости от платформы. А на этапе дизайна мы считаем их все равными шириной в 960 pt.
Речь про широкие экраны веба, как я понимаю? Текущая сетка адаптируется до 1280 pt и мы пока думаем, что делать с бо́льшими размерами.
Да, для универсализации UI, вёрстка под телеэкраны умножается на различные коэффициенты, в зависимости от платформы. А на этапе дизайна мы считаем их все равными шириной в 960 pt.
Речь про широкие экраны веба, как я понимаю? Текущая сетка адаптируется до 1280 pt и мы пока думаем, что делать с бо́льшими размерами.
Хотелось бы узнать, каким набором инструментов пользуетесь для верстки, сборки всех веб-компонентов и элементов веб-дизайна. Интересно буквально все: сборщики, препроцессоры, постпроцессоры, шаблонизаторы итд. Желательно отдельный материал по теме.
Если коротко то:
Интеграция ДС на вебе: ts + nodejs.
сборщик стилей: grunt и gulp (да да, такая вот у нас связка, legacy код, из под grunt вызываем gulp)
препроцессор для стилей: less.
постпроцессор: postcss со стандартными модулями, autoprefixer, postcss-url, css-byebye, csso, postcss-prefixer
шаблонизатор вёрстки: twig, react
P.S. Готовим отдельный материал на эту тему
Интеграция ДС на вебе: ts + nodejs.
сборщик стилей: grunt и gulp (да да, такая вот у нас связка, legacy код, из под grunt вызываем gulp)
препроцессор для стилей: less.
постпроцессор: postcss со стандартными модулями, autoprefixer, postcss-url, css-byebye, csso, postcss-prefixer
шаблонизатор вёрстки: twig, react
P.S. Готовим отдельный материал на эту тему
Спасибо большое за статью! Есть несколько вопросов.
Таким образом, взаимодействие с дизайн-системой происходит не в реальном времени, а только в момент сборки новых релизов.
Вы действительно делаете это только при релизах или на каждую сборку, например для тестирования новой функциональности (возможно в рамках CI)?
Для генерации стилей в проекте Android мы используем Gradle, превращая данные дизайн-системы в стили формата XML.
Компонентные. Пишутся для каждого компонента, где описано какие свойства и как перевести в стили.
Вы на стороне Android генерируете только xml из стандартных виджетов фреймворка? Или у вас так же есть кастомные реализации для ваших компонент и подразумевается также java/kotlin кодогенерация?
Вы действительно делаете это только при релизах или на каждую сборку, например для тестирования новой функциональности (возможно в рамках CI)?
Когда нам нужно что-то новое из ДС, мы мигрируем на следующую версию Json с описанием ДС.
Время, когда новые компоненты появлялись постоянно, прошло и сейчас это требуется раз или два в неделю. На Android эта процедура занимает пару минут, поэтому CI для этого пока не используем.
Вы на стороне Android генерируете только xml из стандартных виджетов фреймворка? Или у вас так же есть кастомные реализации для ваших компонент и подразумевается также java/kotlin кодогенерация?
У нас есть кастомные реализации для своих компонентов, но логику их работы мы прописываем сами на Kotlin. А вот стили и значения для описания их внешнего вида, мы берём из xml, который генерируется автоматически. Таким образом, у нас есть возможность достаточно гибко настраивать компоненты сначала, а потом автоматически подтягивать изменения из ДС.
Илья, подскажите, пожалуйста, а как у вас устроен процесс создания дизайна и верстки писем? Вам удалось стандартизировать и автоматизировать этот процесс?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От UI-kit до дизайн-системы