Да, согласен, от модели монетизации сильно зависит судьба проекта и восприятие в комьюнити. Изначально планировал предоставлять платный доступ к мультиплееру и синхронизации, чтобы можно было над одной базой знаний работать всей командой
Я пока не знаю, какой модели распространения буду придерживаться, потому что планировал изначально зарабатывать на этом проекте. Я уже давно занимаюсь созданием бесплатных продуктов, в основном, плагинов и граф. материалов в Figma, но хочется уже создать ценный продукт для пользователей, за который они будут готовы платить -- для этого я планирую развивать его дальше на основе фидбека и мультиплеера с бесшовной синхронизацией
Да, планирую, но в будущем, когда будет готов стайл гайд и апи -- сейчас в приоритете другие платформы, оформление сертификатов разработчика и т.п.
Похожее уже есть: запросы dataview строят таблицы и списки заметок по их свойствам из YAML. Отдельные файлы баз с редактированием ячеек, как в Obsidian Bases, пока не делал, но идею записал
Да, планирую это сделать -- сейчас ищу решение и провожу ресерч, после мультиплатформы начну реализацию
Синхронизация и мобилка -- следующий этап. При создании интерфейса я ориентируюсь на доступность компонента и его эфффектов / анимаций во всех браузерах, поэтому на всех устройствах приложение должно работать нормально)
Я все еще думаю про веб-версию, чтобы вообще на ПК ничего не нужно было ставить, но это пока не понятно как реализуемая идея)
Про мобилку тоже пока внятно не могу ответить: буду изучать)
На скрине дерево файлов раскрытое, поэтому там пустое место. А слева сайдбар дополнительный, который в будущем будет заполняться, и места уже не так много останется
Воздух все равно нужен в интерфейсах, иначе в глазах будет рябить)
Не умею с авторскими правами пока работать, да и не придумал, как лучше опубликовать исходный код - его нужно сначала причесать, а то костылей пока хватает. Тег open source из статьи убрал 🙏
А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
Тогда мы добавляем новый цвет, например, 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-токены. На эту тему просто можно еще одну статью написать, поэтому не знаю, стоит ли раздувать эту)
Спасибо за обалденне предложение! Этого мне не хватало, буду реализовывать! Пока не умеет)
Доброго дня! На линукс сборка есть в последних релизах https://github.com/Freaction/Aquilum/releases
Про emacs знаю, но сам его не трогал. А про howm и org не в курсе. Можете рассказать, пожалуйста, чем они хороши и на что стоит обратить внимание?
Выложил сборку для линукса, посмотрите в последнем релизае, пожалуйста
Также выложил билды для линукса, винды и мака, поэтому можете на любых платформах тестировать приложуньку, если будет такая потребность)
Выложил исходники, можете экспериментировать
Приветствую) Выложил исходники, можете экспериментировать)
Да, согласен, от модели монетизации сильно зависит судьба проекта и восприятие в комьюнити. Изначально планировал предоставлять платный доступ к мультиплееру и синхронизации, чтобы можно было над одной базой знаний работать всей командой
Лицензия AGPL 3.0
Выложил исходники, можете экспериментировать)
Доброго дня!
Я пока не знаю, какой модели распространения буду придерживаться, потому что планировал изначально зарабатывать на этом проекте. Я уже давно занимаюсь созданием бесплатных продуктов, в основном, плагинов и граф. материалов в Figma, но хочется уже создать ценный продукт для пользователей, за который они будут готовы платить -- для этого я планирую развивать его дальше на основе фидбека и мультиплеера с бесшовной синхронизацией
Да, планирую, но в будущем, когда будет готов стайл гайд и апи -- сейчас в приоритете другие платформы, оформление сертификатов разработчика и т.п.
Похожее уже есть: запросы dataview строят таблицы и списки заметок по их свойствам из YAML. Отдельные файлы баз с редактированием ячеек, как в Obsidian Bases, пока не делал, но идею записал
Да, планирую это сделать -- сейчас ищу решение и провожу ресерч, после мультиплатформы начну реализацию
Спасибо вам большое за референсы и механики 🙏🙏🙏
Видимо, нужно будет все-таки открыть исходники, потому что огромный пластом информации я просто не обладаю...
Спасибо вам за фидбек! 🙏
TiddlyWiki буду изучать, благодарю за реф! Есть в планах дать пользователю возможность создавать публичную базу знаний, это точно будет)
Кстати, агенты могут легко запрашивать связи с определенной заметкой в обе стороны -- т.е. граф для моделей имеется)
Синхронизация и мобилка -- следующий этап. При создании интерфейса я ориентируюсь на доступность компонента и его эфффектов / анимаций во всех браузерах, поэтому на всех устройствах приложение должно работать нормально)
Я все еще думаю про веб-версию, чтобы вообще на ПК ничего не нужно было ставить, но это пока не понятно как реализуемая идея)
Про мобилку тоже пока внятно не могу ответить: буду изучать)
На скрине дерево файлов раскрытое, поэтому там пустое место. А слева сайдбар дополнительный, который в будущем будет заполняться, и места уже не так много останется
Воздух все равно нужен в интерфейсах, иначе в глазах будет рябить)
Не умею с авторскими правами пока работать, да и не придумал, как лучше опубликовать исходный код - его нужно сначала причесать, а то костылей пока хватает. Тег open source из статьи убрал 🙏
Спасибо! Сделаю чуть позже, как только изучу доступные решения
Тогда мы добавляем новый цвет, например, 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-токены. На эту тему просто можно еще одну статью написать, поэтому не знаю, стоит ли раздувать эту)