Договорились! Архитектура дизайн-системы
Vložit
- čas přidán 19. 08. 2023
- Это видео для продуктовых ребят, которые решали свои продуктовые задачи, но в какой-то момент задались вопросом систематизации сделанного.
Какие бывают «уровни абстракции», откуда они появляются и как элементы дизайн-системы могут трансформироваться. Это верхнеуровневый обзор, по конкретным вопросам не стесняйтесь - пишите в телегу @malamuth
Апрув ❤
присоединяюсь
Вау супер .......
Достаточно информативно, Спасибо!
Услышал тезис "Нет принципа - не фиксируем" - сразу по больному резануло. Все время попытки оверфинка по всем компонентам и классическое "Как это все не систематизировать и не стандартизировать?!"
Потрясное видео, супер информативное, структурированное и без воды. Спасибо большое! Очень интересно узнать про каждый уровень отдельно: посмотреть пример создания токенов с нуля для большого продукта; как задается семантика. Миллион спасибов ❤️
Спасибо
но очень интересно, как говорится
Про то как продуктовые дизайнеры не могут договориться.
Невероятно крутая инфа, нигде не видел, чтобы так подробно и четко рассказали про все эти штуки. Подскажите, а есть ссылка на презентацию которую вы показываете в видео?
Спасибо ❤️ Презы нет, но планирую скоро выложить её вместе с новым материалом :)
@@malamuth Жду 🤝
Спасибо за крутую инфу! Смотрю второй раз и открываю для себя что-то новое🔥
Вопрос про организмы есть: как в Фигме ограничиваются варианты nested instances атомов на уровне организма, на примере того же аватара? Создаётся новый вариант организма с другим размером аватара или другим контеном? Если так делать, то можем получить большое количество вариантов и быстро раздуть библиотеку!?
Всё ещё не знаю правильный ответ на этот вопрос :) Есть несколько подходов, которые я лично миксую, даже в рамках одной системы: иногда просто помечаю проперти внутреннего компонента, которые можно менять снаружи, эмоджей. Это работает, если почти всегда снаружи можно манипулировать одним и тем же (например, в аватаре такой штукой может быть контент: иконка, надпись - это почти всегда можно менять снаружи). Иногда детачу внутренний компонент - это усложняет поддержку кита, но упрощает использование. То есть, такой подход справедлив, когда степеней свободы у компонента реально много, что-то прям надо забетонировать в конкретном организме, при этом хочется прокинуть настройку пропертей на верхний уровень, потому что в продукте их очень часто надо перенастраивать. Отчасти проблемы поддержки решает наследование вариаблов - поменяли цвет/размерность в оригинальном компоненте, дубль унаследовал изменения, потому что смотрит в те же вариаблы. Но с дублями точно надо осторожнее работать, потому что да, кит раздувает. Ну и третий способ - пресеты. То есть, верхнеуровневый компонент строится на нераздетаченных низкоуровневых, но чтобы не потрогать что-то лишнее, делаем в верхнеуровневом пресеты и договариваемся вниз не лезть - настраивать только то, что в наружных настройках торчит. И да, это тоже может раздуть кит. Пока смотрю по ситуации и имею готовность в случае чего задеприкетйтить одну реализацию компонента и выпустить новую, в которой перехожу на другую модель работы с нестед штуками. В моменте решение принимаю, опираясь на то, как это будет использоваться в продукте. Продукты же тоже разные - в каких-то раздутый кит не является проблемой (например, нет потребности держать большие продуктовые файлы или детализированные прототипы), в каких-то является. От этого зависит и способ организации нестед штук. Где-то вполне допускаю, что организмы вообще не должны существовать в виде компонентов в фигме - только на уровне гайдов
@@malamuth Понял, спасибо! Появилась идея одна, пока сам не пробовал её реализовать, не знаю на сколько она может сработать на большим масштабе. Делить атом по размеру (обычно от него зависит набор возможного контента) на отдельные компоненты, получается будет не один атом с возможностью переключать размер через проперти, а несколько компонентов. А сверху над ними уже делать обертку с проперти размера, которая будет по сути тем самым начальным атомом с возможностью выбора размера. Чтобы отдельные компоненты атома не светили наружу, можно унести их в отдельную библиотеку и не подключать её всем. В итоге мы получим атом обертку доступный всем и компоненты атомы разных размеров, которые легко использовать для ограниченного набора уникальных аддонов в различных организмах. Хотя, возможно, такая связь может быть излишней, но с другой стороны может решить доступности всех нестед проперти.
Подскажите, почему токену текста заголовка не следует давать симантическое название? Ведь это бы помогло и разработчику и дизу верно считывать где этот стиль используется. Ну и потом конкретно для заголовков делать еще микс из токенов, то что вы называете компонентом для заголовка. Ведь если понадобится править текстовую гарнитуру, то править ее будут не из компонента. И при этом ее нужно будет опознать.
Я считаю, что это не очень честно, потому что в многих продуктах токен «заголовка» используется не только для заголовка - например, большая цена или какая-то другая крупная выделяющаяся текстовая штука для привлечения внимания. Заголовок это всё же нечто более комплексное, чем только типографика
Чтобы не мучаться, где что - да, как вы и пишете, в компоненте заголовка зашиваем несемантический токен. И в компоненте цены. И ещё где-то. И с голыми токенами вообще не работаем из фичи
Спасибо за рассказ! Не очень понял, а как вы эти принципы описываете. Просто как текстовую документацию к компоненту? А если они абстрактные, как, например, сепараторы у ячеек?
Принципы становятся формальным ТЗ для разработки компонентов :) Компонент сопровождается текстовой докой, в случае с сепараторами будет описан компонент списка, в котором будет описана эта механика. Для дизайнеров пока всё по-старому - просто примеры в фигме. Но в разработке будет работать чётко, даже если диз забыл убрать сепаратор где-то
Я правильно понимаю, что в таком подходе дизайнеры видят следующие библиотеки:
- Atoms
- Molecules
- Organisms
- Wrapper / Extents ?
- Modules
И у них не возникает проблем где искать кнопки, где инпуты, а где аватары (интересно где они, кстати)?
Вообще не факт. Основная идея, которую я пыталась донести, что это деление очень условное и что компоненты могут кочевать из одной условной категории в другую. Разделять библиотеки нужно чётко осознавая потребность. Моё глубокое убеждение, что начинать вообще нужно всегда с одного файла и разносить на несколько библиотек только когда возник понятный запрос, почему это необходимо. Ну и из запроса будет ясно, как именно следует разносить эти файлы. Разносить во имя категоризации - что тут у нас атомы, а тут организмы, вижу необходимость только в случае, если есть атомы, которые юзают все, и организмы, которые нужны не всем (одним нужны одни, другим другие). Разносить по техническому признаку (это атомы, это врапперы) не вижу необходимости - не важно, что чем является, важно, что к чему ближе по использованию. Например, может быть библиотека компонентов, связанных с формами (поля ввода, саджестеры...), и отдельная, связанная с представлением данных (карточки, тексты...). Такое разделение позволит в одном месте манипулировать родственными штуками - шатнули базовый инпут и в том же файле шатнулись все родственные поля ввода, например. И обновление тогда получат пользователи, которым это релевантно. Например, те, у кого фичи с формами. А у кого нет форм - вообще не получат обновлений)
В общем, надо смотреть на структуру продукта, команд и от этого отталкиваться. И не расщеплять, пока нет явной необходимости
@@malamuth соглашусь, что названия библиотек помогают находить компоненты, когда они имеют связь с местом применения или типом самих компонентов.
42:00 тут на уровне молекул стек из двух кнопок, а также попап на уровне молекул, содержащий тот стек. Разве этот попап не должен быть уже на другом уровне?
Формально да, неформально считаю, что такое более глубокое разделение не несёт практической пользы, а только усложняет систему. Поэтому в моём мире условные «молекулы» могут включать в себя, как условные «атомы», так и такие же условные «молекулы»
Спасибо ❤@@malamuth
Если коротка то суть:
Делаем форк либы компонентов из фигмы и адаптируем под свои нужды.
Не благодарите