А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
Тогда мы добавляем новый цвет, например, red, а blue мы ни в коем случае не трогаем!
Затем идем на семантический слой и меняем там все токены blue на red
По итогу имена примитивов остались честными, а имя семантического токена не изменилось. Все компоненты во всех продуктах перекрасились за несколько минут
Примитивы описывают физику (что это за цвет), а семантика — логику (где он сидит). Если физика поменялась, мы добавляем новый примитив, а не врем в старом.
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить.
Продуктовый интерфейс и маркетинговый — это разные вещи. Лендинги или промо-материалы живут своей жизнью. Никто не мешает экспериментировать, на дизайн-систему это не повлияет. В дизайн-систему мы вносим те токены и компоненты, которые прошли отбор и используются в нескольких местах
- А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде.
Есть компонентный уровень, в который и можно добавить такие исключения. Например, создать что-то вроде:
color-button-bg-celebrate-hover — у этого токена будет свой уникальный цвет, со всем остальным аналогично. Создаем отдельную коллекцию для нового года и помещаем эти токены туда.
Есть еще такое понятие как снежинка — это компонент или токен на один спринт, это мусор, который мы не тянем в ДС. Я могу спокойно накостылить что угодно руками, а потом перенести это в корзину или архив, когда оно больше не понадобится. Дизайн-система тут не нужна, она будет мешать.
А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить.
То же самое — компонентные токены, либо семантику новую создаем, если на постоянке будет использоваться.
А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
Для такого мы можем создать несколько тем, например, brand-dark / brand light / brand-weak-dark / brand-weak-dark, и переключать эти моды при необходимости у конкретных организмов или блоков
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
С типографикой мы также можем создавать разные коллекции и кастомить компоненты как душе угодно, а скругления и отступы, в основном, стандартные и привязаны к 4px сетке. Но если значения, например, задаются от ширины экрана, то мы для этого создаем вариант с парметрами scale внутри и fixed aspect ratio, и он будет скейлиться спокойно без привязки к конкретным значениям.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Дизайн-система в первую очередь нужна, чтобы облегчить жизнь дизайнерам и связать их с фронтами. Мы берем самые частые случаи и выносим их в токены и компоненты, вследствие чего их можно переиспользовать как в дизайне, так и в коде — мы ставим рамки и уменьшаем неопределенность. Плюс это уменьшает в десятки раз время на перепроверку компонентов, потому что больше не будет такого, что в одной карточке 31px скругление, а в другой 32, в третьей 33 — мы сводим человеческий фактор на нет.
Дизайн-система, это не тюрьма, а помощь команде. Не везде она нужна. Если продукт небольшой, можно и нужно обходиться без нее, потому что она будет его тормозить. Уже дальше можно подключать, так как возникает много рутины и экспериментов, и нужно высвобождать время дизайнеров на эксперименты и тесты.
Это как генерить в Stable Diffusion либо на GTX 1050, либо на RTX 5090 — разница будет колоссальная, и экспериментов можно сделать в разы больше на мощной видюхе. Но вопрос целесообразности — а зачем генерить? Чтобы поржать над котиками или создавать изображения для отдела маркетинга и приносить прибыль? С дизайн-системами также, нужна цель и метрики успешности.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
Кажется, вы немного перепутали работу принципов связности и зацепления. Хардкодинг стилей внутри компонентов — это как раз путь к Tight Coupling (высокому зацеплению). Компонент становится намертво привязан к конкретному визуальному бренду.
Дизайн-токены — это реализация паттерна Inversion of Control (Инверсия контроля) и Low Coupling. Наш компонент Button имеет High Cohesion (он отвечает только за структуру и состояния) и Low Coupling (он ничего не знает про HEX-коды или бренды). Он использует абстрактный контракт (семантический токен color-bg-primary). Благодаря этому мы можем переключить всю компанию на фиолетовый бренд или темную тему, вообще не касаясь кода компонентов. Абстракция не "течет", она выполняет роль идеального API между дизайном и разработкой
Хм, так компании потихоньку растут, а методы найма меняются, персонал вычищается. И нужна новая кровь, которую заливают уже не через грязный шприц, а профессиональную капельницу) Ахах, сори за такой пример)
В общем, невозможно же бесконечно обманывать систему? Она ведь тоже подстраивается. Если постоянно нанимать балбесов с ИИ, то компания будет стремительно терять деньги. А есть толковые ребята, которые взращивают себя сами и готовы работать, учиться и адаптироваться, решать проблемы, расти.
За такими охотятся, их выискивают, достают из-под земли. Их, конечно, не так много, но, как мне кажется, стоит тратить силы на охоту за ними, чем на масштабный найм. Не знаю, может, я не прав, но считаю, что к этому все идет. Как думаете?)
Мне кажется, что ИИ дает понимание, что за реальные знания стоит платить. Это как сходить либо к дешевому врачу, который создаст еще больше проблем, либо к профессионалу, который проблему решит и еще даст совет, как поддерживать здоровье. Я так атлант вправил за немалые деньги и не дня не жалею) А до этого ходил к неврологам бесконечно и мануальным терапевтам.
Плюс, если сразу нормального специалиста нанять, то он уже сможет организовать проект, и на него нанять тех самых джунов с ИИ, а тех, кто не адаптируется и не покажет результат в течение проекта — уволить
Еще одна аналогия — вирусы на ПК. Ставишь антивирус, и 99% из них тебя не побеспокоят. Да, будет 1% проворных, но экономически выгоднее уже их впустить и по гайду потом удалить) Также и с самозванцами, разе нет? От всего не защитишься ведь
Хм, а некоторые цвета же грязнить начинают с черным поверх, например, желтый. Там надо играться с тоном и яркостью, а не просто черный поверх накладывать. Но главный косяк такого подхода — сложно Accessibility/a11y проверять, так как плагины тупят на двойных заливках полупрозрачных. Хотя, надо проверять, вдруг поумнели)) Может, вы тестили?
По идее, чтобы желтый выглядел хорошо, нужно просто создать токен именно для желтого цвета, например, не black 5%, а dark-orange 5% — сейчас проверил, реально работает) Если просто черный накладывать, то уходит в оливковый
Ммм, какой классный вопрос. Вообще на фронте, например, в Material используют 5% черного или белого поверх — это экономит токены. Но как поступить дизайнеру дизайн-системы, чтобы продуктовым дизам было удобно? Можно сделать в ховер состоянии кнопки поверх основного фона фрейм, в котором будет 5% черного — но если вариантов много, фигма будет тормозить.
В идеале нужно сделать больше шагов в палитре изначально, чтобы не возникало таких ситуаций в принципе — можно посмотреть на Radix UI — у них 12 шагов контрастности, чего хватит с головой для любых сценариев. Если не подходит прозрачная палитра в каком-то кейсе, то пробуем использовать solid-цвета, и создаем компонентный токен под конкретную ситуацию.
Также, насколько мне известно, в Tokens studio есть модификаторы, которые прям в плагине могут сделать цвет кнопки на 5% темнее, а затем экспортировать полученный цвет в Figma variables как сплошной цвет или прозрачный.
Если бы возникла ситуация, когда не хватает шагов контрастности, то я бы переделывал палитру и токены в рабочее и внерабочее время — сам виноват, что сделал недостаточно))
Спасибо! Добавил информацию про версионирование и deprecated-токены. На эту тему просто можно еще одну статью написать, поэтому не знаю, стоит ли раздувать эту)
На сайте BFL развернута полноценная модель без сжатий, поэтому результат получается лучше. В идеале пользоваться этим всем на сервере, чтобы не мучить себя :)
Есть еще куда развиваться, согласен. Спасибо за коммент, буду дальше матан подтягивать и копаться в этом всем. Очень хотелось бы, чтобы реальный ML-щик дополнил статью или дал фидбек, просто сам не нашел ничего толкового, поэтому и написал на том уровне, которым владею сейчас
Самое понятное не может быть без научной базы, ибо для ученого простой пример понятен не будет)))
А для всех я привел аналогию с лизуном, к примеру, она вполне, как мне кажется, отражает суть понятия)
Да, возможно не затронул полностью все области, всех деталей, но считаю, что написал достаточно. Математику стоит изучить уже в статьях, там высшая алгебра и матан, я только часть формул понял и одну из них вынес в виде скрина
Тогда мы добавляем новый цвет, например, red, а blue мы ни в коем случае не трогаем!
Затем идем на семантический слой и меняем там все токены blue на red
По итогу имена примитивов остались честными, а имя семантического токена не изменилось. Все компоненты во всех продуктах перекрасились за несколько минут
Примитивы описывают физику (что это за цвет), а семантика — логику (где он сидит). Если физика поменялась, мы добавляем новый примитив, а не врем в старом.
Продуктовый интерфейс и маркетинговый — это разные вещи. Лендинги или промо-материалы живут своей жизнью. Никто не мешает экспериментировать, на дизайн-систему это не повлияет. В дизайн-систему мы вносим те токены и компоненты, которые прошли отбор и используются в нескольких местах
Есть компонентный уровень, в который и можно добавить такие исключения. Например, создать что-то вроде:
color-button-bg-celebrate-hover— у этого токена будет свой уникальный цвет, со всем остальным аналогично. Создаем отдельную коллекцию для нового года и помещаем эти токены туда.Есть еще такое понятие как снежинка — это компонент или токен на один спринт, это мусор, который мы не тянем в ДС. Я могу спокойно накостылить что угодно руками, а потом перенести это в корзину или архив, когда оно больше не понадобится. Дизайн-система тут не нужна, она будет мешать.
То же самое — компонентные токены, либо семантику новую создаем, если на постоянке будет использоваться.
Для такого мы можем создать несколько тем, например, brand-dark / brand light / brand-weak-dark / brand-weak-dark, и переключать эти моды при необходимости у конкретных организмов или блоков
С типографикой мы также можем создавать разные коллекции и кастомить компоненты как душе угодно, а скругления и отступы, в основном, стандартные и привязаны к 4px сетке. Но если значения, например, задаются от ширины экрана, то мы для этого создаем вариант с парметрами scale внутри и fixed aspect ratio, и он будет скейлиться спокойно без привязки к конкретным значениям.
Дизайн-система в первую очередь нужна, чтобы облегчить жизнь дизайнерам и связать их с фронтами. Мы берем самые частые случаи и выносим их в токены и компоненты, вследствие чего их можно переиспользовать как в дизайне, так и в коде — мы ставим рамки и уменьшаем неопределенность. Плюс это уменьшает в десятки раз время на перепроверку компонентов, потому что больше не будет такого, что в одной карточке 31px скругление, а в другой 32, в третьей 33 — мы сводим человеческий фактор на нет.
Дизайн-система, это не тюрьма, а помощь команде. Не везде она нужна. Если продукт небольшой, можно и нужно обходиться без нее, потому что она будет его тормозить. Уже дальше можно подключать, так как возникает много рутины и экспериментов, и нужно высвобождать время дизайнеров на эксперименты и тесты.
Это как генерить в Stable Diffusion либо на GTX 1050, либо на RTX 5090 — разница будет колоссальная, и экспериментов можно сделать в разы больше на мощной видюхе. Но вопрос целесообразности — а зачем генерить? Чтобы поржать над котиками или создавать изображения для отдела маркетинга и приносить прибыль? С дизайн-системами также, нужна цель и метрики успешности.
Кажется, вы немного перепутали работу принципов связности и зацепления. Хардкодинг стилей внутри компонентов — это как раз путь к Tight Coupling (высокому зацеплению). Компонент становится намертво привязан к конкретному визуальному бренду.
Дизайн-токены — это реализация паттерна Inversion of Control (Инверсия контроля) и Low Coupling. Наш компонент Button имеет High Cohesion (он отвечает только за структуру и состояния) и Low Coupling (он ничего не знает про HEX-коды или бренды). Он использует абстрактный контракт (семантический токен
color-bg-primary). Благодаря этому мы можем переключить всю компанию на фиолетовый бренд или темную тему, вообще не касаясь кода компонентов. Абстракция не "течет", она выполняет роль идеального API между дизайном и разработкойХм, так компании потихоньку растут, а методы найма меняются, персонал вычищается. И нужна новая кровь, которую заливают уже не через грязный шприц, а профессиональную капельницу) Ахах, сори за такой пример)
В общем, невозможно же бесконечно обманывать систему? Она ведь тоже подстраивается. Если постоянно нанимать балбесов с ИИ, то компания будет стремительно терять деньги. А есть толковые ребята, которые взращивают себя сами и готовы работать, учиться и адаптироваться, решать проблемы, расти.
За такими охотятся, их выискивают, достают из-под земли. Их, конечно, не так много, но, как мне кажется, стоит тратить силы на охоту за ними, чем на масштабный найм. Не знаю, может, я не прав, но считаю, что к этому все идет. Как думаете?)
Мне кажется, что ИИ дает понимание, что за реальные знания стоит платить. Это как сходить либо к дешевому врачу, который создаст еще больше проблем, либо к профессионалу, который проблему решит и еще даст совет, как поддерживать здоровье. Я так атлант вправил за немалые деньги и не дня не жалею) А до этого ходил к неврологам бесконечно и мануальным терапевтам.
Плюс, если сразу нормального специалиста нанять, то он уже сможет организовать проект, и на него нанять тех самых джунов с ИИ, а тех, кто не адаптируется и не покажет результат в течение проекта — уволить
Еще одна аналогия — вирусы на ПК. Ставишь антивирус, и 99% из них тебя не побеспокоят. Да, будет 1% проворных, но экономически выгоднее уже их впустить и по гайду потом удалить) Также и с самозванцами, разе нет? От всего не защитишься ведь
А еще есть мультибрендовые палитры, и их тоже нужно в семантике учитывать 🙈
Нам нужно больше статей по токенам!
Хм, а некоторые цвета же грязнить начинают с черным поверх, например, желтый. Там надо играться с тоном и яркостью, а не просто черный поверх накладывать. Но главный косяк такого подхода — сложно Accessibility/a11y проверять, так как плагины тупят на двойных заливках полупрозрачных. Хотя, надо проверять, вдруг поумнели)) Может, вы тестили?
По идее, чтобы желтый выглядел хорошо, нужно просто создать токен именно для желтого цвета, например, не black 5%, а dark-orange 5% — сейчас проверил, реально работает) Если просто черный накладывать, то уходит в оливковый
Ммм, какой классный вопрос. Вообще на фронте, например, в Material используют 5% черного или белого поверх — это экономит токены. Но как поступить дизайнеру дизайн-системы, чтобы продуктовым дизам было удобно? Можно сделать в ховер состоянии кнопки поверх основного фона фрейм, в котором будет 5% черного — но если вариантов много, фигма будет тормозить.
В идеале нужно сделать больше шагов в палитре изначально, чтобы не возникало таких ситуаций в принципе — можно посмотреть на Radix UI — у них 12 шагов контрастности, чего хватит с головой для любых сценариев. Если не подходит прозрачная палитра в каком-то кейсе, то пробуем использовать solid-цвета, и создаем компонентный токен под конкретную ситуацию.
Также, насколько мне известно, в Tokens studio есть модификаторы, которые прям в плагине могут сделать цвет кнопки на 5% темнее, а затем экспортировать полученный цвет в Figma variables как сплошной цвет или прозрачный.
Если бы возникла ситуация, когда не хватает шагов контрастности, то я бы переделывал палитру и токены в рабочее и внерабочее время — сам виноват, что сделал недостаточно))
Спасибо! Добавил информацию про версионирование и deprecated-токены. На эту тему просто можно еще одну статью написать, поэтому не знаю, стоит ли раздувать эту)
Нужно ноду на загрузку GGUF модели поставить вместо стандартной 😉
😁😁
Да, все правильно. Под другие системы есть сборки, но они могут работать нестабильно — возни намного больше, особенно если с нуля изучать эту тему.
На сайте BFL развернута полноценная модель без сжатий, поэтому результат получается лучше. В идеале пользоваться этим всем на сервере, чтобы не мучить себя :)
У FLUX dev в ComfyUI у меня также работал Euler Normal и DPM++, но с последним параметры точно не помню, один раз его использовал
Euler normal чуть быстрее преобразовывает
Есть еще куда развиваться, согласен. Спасибо за коммент, буду дальше матан подтягивать и копаться в этом всем. Очень хотелось бы, чтобы реальный ML-щик дополнил статью или дал фидбек, просто сам не нашел ничего толкового, поэтому и написал на том уровне, которым владею сейчас
Самое понятное не может быть без научной базы, ибо для ученого простой пример понятен не будет)))
А для всех я привел аналогию с лизуном, к примеру, она вполне, как мне кажется, отражает суть понятия)
Да, возможно не затронул полностью все области, всех деталей, но считаю, что написал достаточно. Математику стоит изучить уже в статьях, там высшая алгебра и матан, я только часть формул понял и одну из них вынес в виде скрина