Комментарии 10
А если бы перед началом разработки изучили бы опыт Material Design - не пришлось бы сейчас мучаться подбирать и изобретать! :)
MD3 - просто песня с его инструментом по генерации и подбору цветов для светлой и темной теме по картинке, по брендовым и кастомным цветам
Добрый день. В статье описан опыт решения наших задач и более общий подход по подбору цветов для переменных, зашитых в дизайн-систему. В DataLens совсем недавно вышел инструмент для стилизации UI в платном тарифе, можно им воспользоваться для примерки цветов с его помощью.
Вопрос не в конкретном инструменте, а в основных принципах дизайна ну отсюда вытекает естественный процесс генерации цветов.
Material Design - это не про конкретную библиотеку компонентов - это про дизайн и проектирование на его основе любых дизайн-систем и библиотек компонентов (там собраны лучшие идеи и практики дизайна интерфейсов)
Благодаря системному подходу в дизайне можно генерировать тысячи цветовых схем , которые будут консистентны и будут содержать контрастные цвета
Посмотрите на Хром - там есть галочка динамически менять цветовые темы - он по несколько раз за день меняет цветовые схемы - они генерируются динамически!
А так можно героически напрягаться и в конце месяца сгенерировать таки одну тему для продукта, руками подбирая цвета и даже потом какой-то инструмент изобрести, но это процесс от обратного
После такой работы если вы прочтете Material Desing вы будете удивлены : блин а почему мы раньше это не прочли? мы бы не мучались и сделали все гораздо проще!
В статье также учитываются практики, рассказывается с чем можно столкнуться, что есть от части внутри и как можно делать быстро и безопасно. Когда с этим работаешь, все происходит иначе – тут в этом речь. Вы говорите про волшебную кнопку, а мы про то, что под капотом.
Вы говорите как вы героически сражались с тем что сотворили не используя знания и системный подход к проектированию UI - да вы молодцы поборолись со своими же проблемами и смогли таки создать тему
А я , пройдя такие же этапы разработки и лишь затем обнаруживший Material Design, рекомендую вам после всего этого процесса который вы прошли и которым идет большинство (не изучая теорию и лучшие практики бросаются что-то строить) изучить его - я думаю вы на многое взглянете другими глазами и узнаете что любую новую тему при системном подходе к проектированию UI не нужно героически создавать - она автоматически получается за пару секунд :) Думаю что после изучения Material Design у вас возникнет сильное желание переписать все сделанное ранее )
Приветствую! Они основаны на двухслойной цветовой модели. Можно раскрыть это момент ?
Хороший вопрос, попробую рассказать, как я это понял на примере, который иллюстрируется на картинке:
Цветовая модель включает в себя два уровня:
Абсолютные значения цвета — на этом уровне задаются конкретные цветовые коды. Например,
#000обозначен какBlack1000равно абсолютный черный цвет.Семантический слой — здесь задаются переменные, которые относятся к определенным элементам дизайна или контента. Например, переменная
Line-genericдля линий иText-genericдля основного текста. При этом они оба могут ссылаться наBlack1000.
В такой модели проще управлять цветовой схемой всего проекта. Если мы вдруг решим изменить тон всех черных элементов, достаточно будет обновить значения на уровне абсолютных цветов. Изменения автоматически применятся ко всем элементам, привязанным к соответствующим семантическим переменным.
Например, если мы изменим Black1000 с #000 на #111, все элементы, связанные с этим цветом через переменные Line-generic и Text-generic, автоматически обновятся. Аналогичные корректировки потребуется сделать для всего ряда черных цветов, например, Black500, Black100 и т. д., чтобы все остальные элементы тоже изменили оттенок черного.
Такой подход упрощает процесс управления цветами в больших проектах и помогает сохранить единообразие.
Здравствуйте, спасибо за статью!
Можете рассказать как вы добились экспорта переменных из фигмы в код? Какие технологии использовали (самописный парсер или что сторонке)? Насколько была большая команда и сколько времени на это ушло? Может ли это реализовать команда небольшого стартапа (1 фронт, 1 бэк, 1 диз) или для этого нужны мощности яндекса?
У нас продукт, к которому мы продаём уникальные темы клиентами как доп услугу. В фигме сделал конструктор с переменными и режимами (радиусы, шрифты, компактность, цвета) с ним работают дизайнеры. Но вот дальше это всё верстается руками, а не экспортом в код с помощью одного клика. Я пытаюсь понять в какой момент становится целесообразной разработка экспорта в переменных в код и насколько это ресурсозатратная разработка?
Почти все плагины фигмы работают с Plugin API, при помощи него можно доставать значения цветов из сущностей фигмы. Пока наш внутренний плагин работает с приватными цветами (Variables) внутри коллекции (Collection или VariableCollection в терминах API).
На вход плагин принимает базовые цвета (можно импортировать из артборда или указать в полях в плагине), а на выходе генерирует палитру приватных цветов (alpha и solid) по заранее определенным формулам для всех тем. Тем самым он может обновить все зависимые Variables в Collection (в Local variables), а фигма сама обновит Local styles, которые зависят от Local variables.
При экспорте в код, плагин собирает обновленные приватные цвета, и выдаёт CSS‑файлик с обновленными цветами.
В нашей команде этим занимаются не более 10 человек и в облаке много сервисов, которые нуждаются в подобном подходе.
Наверное, об автоматизации стоит задуматься, когда техническая часть (перенос Variables) начнет преобладать по трудозатратам над смысловой (создание / применение темы).
Изменить цвета и кнопки сервиса — и не сломать дизайн-систему