С началом рабочей недели! Мем о наболевшем.
Вот шутки шутками, а сейчас заметил, что работа в фигме или с фигмой сократилась до 20-25% времени. Большая часть это таблички и созвоны. Много созвонов!
Сейчас работаю над матрицей навыков, и открыл для себя интересный инструмент — матрица RACI (Ответственности). Как закончу, поделюсь, что получилось.
- - - - -
Канал: Мыслью по древу
Вот шутки шутками, а сейчас заметил, что работа в фигме или с фигмой сократилась до 20-25% времени. Большая часть это таблички и созвоны. Много созвонов!
Сейчас работаю над матрицей навыков, и открыл для себя интересный инструмент — матрица RACI (Ответственности). Как закончу, поделюсь, что получилось.
- - - - -
Канал: Мыслью по древу
🔥7
#SDUI #технологии
Уже мелькало на канале такое сочетание букв, как SDUI.
Но что же это реально такое?
SDUI - Server Driven User Interface. На самом деле сама концепция не столько про дизайн, сколько про данные и обработку действий. В классическом приложении все действия обрабатывает клиент, на нём же и значительная часть бизнес-логики.
В SDUI приложении же клиент "тупой" на столько, что виджеты умеют только отправлять события на сервер вроде "Ой, на меня нажали". И ждать от сервера инструкции, как должен поменяться интерфейс после нажатия. Вся бизнес-логика уходит на бэкенд приложения.
А клиент умеет только обрабатывать контракт. Контракт это чаще всего JSON с деревом объектов и их параметрами. Такой принцип открывает возможность делать изменения на клиенте без релиза в магазин приложений. И чем вариативнее отрисовщик, чем более управляемый интерфейс, тем больше типов изменений можно делать без релиза.
- - - - -
Канал: Мыслью по древу
Уже мелькало на канале такое сочетание букв, как SDUI.
Но что же это реально такое?
SDUI - Server Driven User Interface. На самом деле сама концепция не столько про дизайн, сколько про данные и обработку действий. В классическом приложении все действия обрабатывает клиент, на нём же и значительная часть бизнес-логики.
В SDUI приложении же клиент "тупой" на столько, что виджеты умеют только отправлять события на сервер вроде "Ой, на меня нажали". И ждать от сервера инструкции, как должен поменяться интерфейс после нажатия. Вся бизнес-логика уходит на бэкенд приложения.
А клиент умеет только обрабатывать контракт. Контракт это чаще всего JSON с деревом объектов и их параметрами. Такой принцип открывает возможность делать изменения на клиенте без релиза в магазин приложений. И чем вариативнее отрисовщик, чем более управляемый интерфейс, тем больше типов изменений можно делать без релиза.
- - - - -
Канал: Мыслью по древу
🔥11💯1
#технологии #SDUI #платформаманго #цвет
Референсная палитра
Организация цветов в дизайн-системах интересная тема. И разговоры в комьюнити не утихают, как лучше, как правильно...
Хочу поделиться, что я для себя считаю оптимальным и какой путь выбрал для текущего проекта. И начать с того, что я считаю оптимальной многослойную палитру. Ну то есть когда есть палетка со всеми уникальными цветами а на неё уже ссылаются светлая и темная темы, и прочие семантические штуки.
Вот эта палетка и есть — референсная палитра.
- - - - -
Канал: Мыслью по древу
Референсная палитра
Организация цветов в дизайн-системах интересная тема. И разговоры в комьюнити не утихают, как лучше, как правильно...
Хочу поделиться, что я для себя считаю оптимальным и какой путь выбрал для текущего проекта. И начать с того, что я считаю оптимальной многослойную палитру. Ну то есть когда есть палетка со всеми уникальными цветами а на неё уже ссылаются светлая и темная темы, и прочие семантические штуки.
Вот эта палетка и есть — референсная палитра.
- - - - -
Канал: Мыслью по древу
🔥7
#технологии #SDUI #платформаманго #цвет
Инструменты генерации палитры
Сейчас есть многообразие решений: leonardo, huetone и другие. Их любят за работу с OKLCH цветовым пространством. Мой любимчик — это Colorbox. Причем по ссылке откроется сразу одна из моих палитр, можно посмотреть мой вариант настроек. За что мне нравится именно этот инструмент: понятный параметрический интерфейс настройки прогрессии, есть плагин для экспорта в фигму. С sRGB я пока для себя не увидел плюсов переходить на что-то модное для P3 экранов, платформа и так не плохо справляется с адаптацией не P3 контента под новые дисплеи. Но это лично моё решение.
На выходе получается палетка как на превью предыдущего поста. Отталкивался я в первую очередь от контрастов, во вторую от светимости, добиваясь коридорных значений по горизонталям в матрице. Ну то есть если взять brand1.L300 и brand2.L300, то контрастность по отношению к белому и темному у них будет примерно одинаковая, то же касается и светимости.
Далее из этих цветов формируется уже семантический слой, например темная и светлая темы. Но об этом постараюсь рассказать в следующих постах.
P.S. Сейчас думаем о том, чтобы воспроизвести что-то типа Колорбокса у себя в инструментах платформы, чтобы сразу получать на выходе токены в нашем формате. Это вообще продвинет работу с палитрой на новый уровень.
- - - - -
Канал: Мыслью по древу
Инструменты генерации палитры
Сейчас есть многообразие решений: leonardo, huetone и другие. Их любят за работу с OKLCH цветовым пространством. Мой любимчик — это Colorbox. Причем по ссылке откроется сразу одна из моих палитр, можно посмотреть мой вариант настроек. За что мне нравится именно этот инструмент: понятный параметрический интерфейс настройки прогрессии, есть плагин для экспорта в фигму. С sRGB я пока для себя не увидел плюсов переходить на что-то модное для P3 экранов, платформа и так не плохо справляется с адаптацией не P3 контента под новые дисплеи. Но это лично моё решение.
На выходе получается палетка как на превью предыдущего поста. Отталкивался я в первую очередь от контрастов, во вторую от светимости, добиваясь коридорных значений по горизонталям в матрице. Ну то есть если взять brand1.L300 и brand2.L300, то контрастность по отношению к белому и темному у них будет примерно одинаковая, то же касается и светимости.
Далее из этих цветов формируется уже семантический слой, например темная и светлая темы. Но об этом постараюсь рассказать в следующих постах.
P.S. Сейчас думаем о том, чтобы воспроизвести что-то типа Колорбокса у себя в инструментах платформы, чтобы сразу получать на выходе токены в нашем формате. Это вообще продвинет работу с палитрой на новый уровень.
- - - - -
Канал: Мыслью по древу
🔥10🤔1
#платформаманго
На фото: фигма, android, iOS.
Первые реальные экраны с бизнес-логикой на новой платформе. Кстати всё выгружено из фигмы без верстальщика.
Внимательные заметят небольшие отличия на андроид, но осталось отловить совсем не много багов отрисовщика, и настанет полный кроссплатформенный пиксельперфект. Что в фигме в макете, то и на проде.
P.S. Приложение полностью нативное.
- - - - -
Канал: Мыслью по древу
На фото: фигма, android, iOS.
Первые реальные экраны с бизнес-логикой на новой платформе. Кстати всё выгружено из фигмы без верстальщика.
Внимательные заметят небольшие отличия на андроид, но осталось отловить совсем не много багов отрисовщика, и настанет полный кроссплатформенный пиксельперфект. Что в фигме в макете, то и на проде.
P.S. Приложение полностью нативное.
- - - - -
Канал: Мыслью по древу
🔥16
Про менторство
«Не умеешь сам, научи другого», —
так я себе вижу большинство курсов и менторов.
«Сделай лучше, раз такой умный», – кто-то скажет. А вот тут есть нюанс.
Запросы на менторство приходят ко мне не прям уж пачками, но довольно регулярно, и есть тенденция на возрастание. Однако, всем я мягко отказываю. Почему?
Смотрите, какая штука, чаще всего с запросом приходят достаточно молодые дизайнеры. Есть у меня ощущение (не подтверждено данными), что условные джуны считают, что сеньоры от всех скрывают какой-то секрет. Вот узнай они этот секрет, так точно сразу в сеньоры.
Если я начну считать, сколько бы взял, например, за часовую беседу во внеурочное время... Сумма получается такая, что точно должен быть какой-то секрет, а его, спойлер, нет.
Если бы подобный сеанс обучения произошел, он был бы очень «капитанский»:
— Ну, значит работай, набирайся опыта и через несколько лет станешь мидлом. Бери больше ответственности, через еще несколько лет станешь сеньором.
Получается денег взял, ценности (т.е. секрет) не дал. Всё! Репутационные потери, тонны недовольства. И оно мне надо?!
А где взять ценность? Сесть разработать комплексный курс «От джуна до сеньора и обратно» с фундаментальной теорией, с практикой, домашкой, списками литературы... При переводе времени на деньги — о-о-о-очень дорого. Желание — хотя бы отбить затраты, не говоря уже о выйти в плюс. А как? Значит: реклама, раскрутка, набор в группы, потоки, основание своей школы... И вот уже нифига не занимаюсь дизайном, только админю всё это дело и веду лекции. Что происходит с моими навыками? Они, конечно, начинают устаревать без практики. Ценность курсов падает...
Я лучше пока поработаю 😁
Могу, конечно, где-то ошибаться, но вот таким я себе это всё вижу, потому не берусь за коммерческое менторство. Лучший способ поучиться именно у меня — поработать в моей команде. Вакансии, благо, периодически появляются.
А теперь на других коучей, лекторов, менторов тоже попробуйте через такой взгляд посмотреть 😉
- - - - -
Канал: Мыслью по древу
«Не умеешь сам, научи другого», —
так я себе вижу большинство курсов и менторов.
«Сделай лучше, раз такой умный», – кто-то скажет. А вот тут есть нюанс.
Запросы на менторство приходят ко мне не прям уж пачками, но довольно регулярно, и есть тенденция на возрастание. Однако, всем я мягко отказываю. Почему?
Смотрите, какая штука, чаще всего с запросом приходят достаточно молодые дизайнеры. Есть у меня ощущение (не подтверждено данными), что условные джуны считают, что сеньоры от всех скрывают какой-то секрет. Вот узнай они этот секрет, так точно сразу в сеньоры.
Если я начну считать, сколько бы взял, например, за часовую беседу во внеурочное время... Сумма получается такая, что точно должен быть какой-то секрет, а его, спойлер, нет.
Если бы подобный сеанс обучения произошел, он был бы очень «капитанский»:
— Ну, значит работай, набирайся опыта и через несколько лет станешь мидлом. Бери больше ответственности, через еще несколько лет станешь сеньором.
Получается денег взял, ценности (т.е. секрет) не дал. Всё! Репутационные потери, тонны недовольства. И оно мне надо?!
А где взять ценность? Сесть разработать комплексный курс «От джуна до сеньора и обратно» с фундаментальной теорией, с практикой, домашкой, списками литературы... При переводе времени на деньги — о-о-о-очень дорого. Желание — хотя бы отбить затраты, не говоря уже о выйти в плюс. А как? Значит: реклама, раскрутка, набор в группы, потоки, основание своей школы... И вот уже нифига не занимаюсь дизайном, только админю всё это дело и веду лекции. Что происходит с моими навыками? Они, конечно, начинают устаревать без практики. Ценность курсов падает...
Я лучше пока поработаю 😁
Могу, конечно, где-то ошибаться, но вот таким я себе это всё вижу, потому не берусь за коммерческое менторство. Лучший способ поучиться именно у меня — поработать в моей команде. Вакансии, благо, периодически появляются.
А теперь на других коучей, лекторов, менторов тоже попробуйте через такой взгляд посмотреть 😉
- - - - -
Канал: Мыслью по древу
🔥9🤔2
UX FLOW • Сергей Мухин
#технологии #SDUI #платформаманго #цвет Референсная палитра Организация цветов в дизайн-системах интересная тема. И разговоры в комьюнити не утихают, как лучше, как правильно... Хочу поделиться, что я для себя считаю оптимальным и какой путь выбрал для…
#технологии
Палитра. Семантический уровень.
В продолжение темы о цветах, хотелось бы рассказать о том, как я создаю следующий слой - семантический. Эта палитра служит для того, чтобы придать смысл цветам из референсной палитры.
Существует несколько подходов к созданию семантики:
1. Элементный
Этот подход заключается в том, что имя токена получает вид
Пример ДС: Carbon от IBM.
2. Функциональный
В этом подходе семантика указывает на более общие понятия: тип поверхности, иерархия акцентов, цвета группируются в пары и наборы:
Пример ДС: Material от Google
Кроме того существует ещё третий уровень палитры — компонентный. И вот тут единства у дизайнеров нет, что порождает третий подход.
3. Сочетание семантического и компонентного уровней.
Это сочетание одного из вышеупомянутых подходов с примесью компонентного уровня. В этом случае частотные сущности рассматриваются как элементы. Например, когда это выглядит как путь к элементу, но вместо элемента у нас, скажем, кнопка. Получаем:
Мой подход
Я совершенно не понимаю компонентный уровень токенов. Это очень серьезное усложнение, которое приводит к сотням токенов при масштабировании. В интернете есть видео от Atlassian, где они демонстрировали свою систему токенов. Кто-то из сообщества сказал: “Они сфотографировали хаос”.
Подход от состояния и элемента на масштабе также порождает длинные и нечитаемые конструкции, такие как
Мне нравится подход Google, если его правильно адаптировать и докрутить, получаются очень лаконичные и читаемые схемы, понятные всем дизайнерам в команде.
Кроме того, если поработать над состояниями с точки зрения «вынесения за скобки», то получится еще компактнее.
Проектируя компоненты в фигме, вы, наверное, замечали, что рисуете очень много похожих вещей у разных компонентов. Тот же принцип построения нажатий и наведений, disabled, focus. Все это можно вынести в модель. Не описать у каждого отдельного компонента, каким должен быть новый цвет при нажатии, а один раз сформулировать алгоритм или формулу получения нового цвета. Есть много вариантов, самые популярные: HSL или LHC смещение, наложение другого цвета. И часто в макете вы используете наведение, бездействие, фокус? Что проще: прорабатывать все состояния в вариантах компонента, обслуживать огромную матрицу вариантов… или один раз описать принцип в документации и, при необходимости, раз в месяц создавать по нему, например, disable-состояние в макете?
Для текущего приложения ВкусВилл я выбрал именно такой подход. В платформе Манго мы пошли ещё дальше, и расширили семантику микро-темами (контекстами). Но об этом в другой раз.
- - - - -
Канал: Мыслью по древу
Палитра. Семантический уровень.
В продолжение темы о цветах, хотелось бы рассказать о том, как я создаю следующий слой - семантический. Эта палитра служит для того, чтобы придать смысл цветам из референсной палитры.
Существует несколько подходов к созданию семантики:
1. Элементный
Этот подход заключается в том, что имя токена получает вид
border-subtle-selected или text-on-color-disabled, то есть в его основе лежит целевой элемент и его состояние. Пример ДС: Carbon от IBM.
2. Функциональный
В этом подходе семантика указывает на более общие понятия: тип поверхности, иерархия акцентов, цвета группируются в пары и наборы:
brand-primary, on-brand-primary.Пример ДС: Material от Google
Кроме того существует ещё третий уровень палитры — компонентный. И вот тут единства у дизайнеров нет, что порождает третий подход.
3. Сочетание семантического и компонентного уровней.
Это сочетание одного из вышеупомянутых подходов с примесью компонентного уровня. В этом случае частотные сущности рассматриваются как элементы. Например, когда это выглядит как путь к элементу, но вместо элемента у нас, скажем, кнопка. Получаем:
button.primary.accent.bg-colorМой подход
Я совершенно не понимаю компонентный уровень токенов. Это очень серьезное усложнение, которое приводит к сотням токенов при масштабировании. В интернете есть видео от Atlassian, где они демонстрировали свою систему токенов. Кто-то из сообщества сказал: “Они сфотографировали хаос”.
Подход от состояния и элемента на масштабе также порождает длинные и нечитаемые конструкции, такие как
text.primary.neutral.disabled.on-dark.Мне нравится подход Google, если его правильно адаптировать и докрутить, получаются очень лаконичные и читаемые схемы, понятные всем дизайнерам в команде.
Кроме того, если поработать над состояниями с точки зрения «вынесения за скобки», то получится еще компактнее.
Проектируя компоненты в фигме, вы, наверное, замечали, что рисуете очень много похожих вещей у разных компонентов. Тот же принцип построения нажатий и наведений, disabled, focus. Все это можно вынести в модель. Не описать у каждого отдельного компонента, каким должен быть новый цвет при нажатии, а один раз сформулировать алгоритм или формулу получения нового цвета. Есть много вариантов, самые популярные: HSL или LHC смещение, наложение другого цвета. И часто в макете вы используете наведение, бездействие, фокус? Что проще: прорабатывать все состояния в вариантах компонента, обслуживать огромную матрицу вариантов… или один раз описать принцип в документации и, при необходимости, раз в месяц создавать по нему, например, disable-состояние в макете?
Для текущего приложения ВкусВилл я выбрал именно такой подход. В платформе Манго мы пошли ещё дальше, и расширили семантику микро-темами (контекстами). Но об этом в другой раз.
- - - - -
Канал: Мыслью по древу
🔥8
Вот так это выглядит в текущей версии приложения ВкусВилл. Кстати, у surface есть особенность: третий уровень используется только для небольших элементов item группы, таких как кнопка, инпут, поиск. Необходимость в большем количестве уровней surface в нашей команде считается ошибкой проектирования и ведет прямо к рефакторингу.
- - - - -
Канал: Мыслью по древу
- - - - -
Канал: Мыслью по древу
🔥4
UX FLOW • Сергей Мухин
В интернете есть видео от Atlassian, где они демонстрировали свою систему токенов. Кто-то из сообщества сказал: “Они сфотографировали хаос”.
А вот и скрин с того самого (кажется) выступления.
Как вам паутина связей?
- - - - -
Канал: Мыслью по древу
Как вам паутина связей?
- - - - -
Канал: Мыслью по древу
Доброе утро! Начнем этот день с мудрости:
«Джун ступает осторожно, ища границы возможного, Мидл осмеливается войти внутрь, а Сеньор парит за пределами»
- - - - -
Канал: Мыслью по древу
«Джун ступает осторожно, ища границы возможного, Мидл осмеливается войти внутрь, а Сеньор парит за пределами»
- - - - -
Канал: Мыслью по древу
😁9
#статья #платформаманго #SDUI
Решил написать статью о том, как работает одна из ключевых функций нашей платформы. В планах раскрыть все основные механизмы в серии публикаций, а затем собрать их в большой лонгрид.
Ссылки на первую часть: vc.ru, дзен, медиум, телетайп
- - - - -
Канал: Мыслью по древу
Решил написать статью о том, как работает одна из ключевых функций нашей платформы. В планах раскрыть все основные механизмы в серии публикаций, а затем собрать их в большой лонгрид.
Ссылки на первую часть: vc.ru, дзен, медиум, телетайп
- - - - -
Канал: Мыслью по древу
🔥12
UX FLOW • Сергей Мухин
#статья #платформаманго #SDUI Решил написать статью о том, как работает одна из ключевых функций нашей платформы. В планах раскрыть все основные механизмы в серии публикаций, а затем собрать их в большой лонгрид. Ссылки на первую часть: vc.ru, дзен, медиум…
Лучше один раз потыкать
Нашел в одной из первых презентаций вот такой прототип в фигме, показывающий работу контекстов.
- - - - -
Канал: Мыслью по древу
Нашел в одной из первых презентаций вот такой прототип в фигме, показывающий работу контекстов.
- - - - -
Канал: Мыслью по древу
Figma
Контексты
Created with Figma
🔥9
#технологии #дизайнсистемы
Бывают ли неатомарные дизайн-системы?
Сегодня в мире дизайна господствует атомарная концепция построения дизайн-систем по Фросту: токены → атомы → молекулы → организмы... планеты, галактики😁
Я наткнулся на видео Брэда Фроста, где он ставит под вопрос актуальность концепции атомарного дизайна сегодня. Фрост размышляет о том, как со временем процесс создания продуктов и разработки интерфейсов стал значительно сложнее, и что, возможно, процесс перестал укладываться в рамки изначальной концепции. Но в итоге он приходит к выводу, что атомарный дизайн все еще применим к современным дизайн-системам. Далее он рассуждает и мечтает о глобальной дизайн-системе, но это тема для отдельного поста.
Возможно, мне стоит перечитать книгу Фроста, или здесь найдутся знатоки, которые скажут, в чем я не прав. Но я не считаю дизайн-систему, над которой работаю, атомарной в полной мере. Тогда какой? Термин не вполне устоявшийся, но я называю эту архитектуру “виджетной”.
А чем плох чисто атомарный подход? Зачем что-то придумывать новое? Вот здесь поправляйте, если что, но насколько я понимаю, суть атомарного дизайна заключается в том, что элементы того же уровня не должны содержать друг друга, тем более включать себя же. Например, если атом “кнопка” содержит атом “иконка”, то это уже будет не атом, а молекула "кнопка с иконкой". Да и сама кнопка не может содержать такую же кнопку внутри себя. Возможно странный пример, но попробуйте представить, что все элементы в вашем проекте организованы так же, как в Figma. Тогда что же представлял бы собой “frame” с точки зрения атомарности?
А как работает “виджетный” дизайн? Здесь каждый может подойти к его созданию по-своему. Как ни странно, все основано на виджетах! Далее термины, которые использую я сам при проектировании. Виджеты могут быть двух типов, назовём их открытые и закрытые. Закрытые виджеты принимают только параметры, а открытые могут принимать параметры и другие виджеты. Открытые виджеты, в свою очередь, могут работать как контейнеры или иметь специальные слоты. Окна, например, работают как контейнеры, которые способны вместить в себя любой набор виджетов. Списки могут принимать шаблоны типов элементов или даже другие списки (получая, таким образом, списки списков 🤯).
Еще есть один тип виджетов - виджеты свойств. Они могут добавить новые свойства любому виджету, в который они попадают. Например, они могут превратить статический объект в интерактивный, добавить возможность показывать различные анимационные эффекты, переходы и многое другое.
Такой подход, на мой взгляд, отлично сочетается с принципами SDUI, хотя где-то в проекте, возможно, и будет присутствовать атомарность "по Фросту". Если бы мне пришлось отвечать сейчас на вопрос “Is atomic design dead?”, я бы сказал, что в его нынешнем виде - да. Ведь в старых рамках многие уже начинают чувствовать себя тесно, искать альтернативы. Но полностью, вероятно, атомарность никуда не исчезнет. Однако, сегодня это уже не единственный путь, а лишь один из инструментов для решения конкретных задач.
- - - - -
Канал: Мыслью по древу
Бывают ли неатомарные дизайн-системы?
Сегодня в мире дизайна господствует атомарная концепция построения дизайн-систем по Фросту: токены → атомы → молекулы → организмы... планеты, галактики
Я наткнулся на видео Брэда Фроста, где он ставит под вопрос актуальность концепции атомарного дизайна сегодня. Фрост размышляет о том, как со временем процесс создания продуктов и разработки интерфейсов стал значительно сложнее, и что, возможно, процесс перестал укладываться в рамки изначальной концепции. Но в итоге он приходит к выводу, что атомарный дизайн все еще применим к современным дизайн-системам. Далее он рассуждает и мечтает о глобальной дизайн-системе, но это тема для отдельного поста.
Возможно, мне стоит перечитать книгу Фроста, или здесь найдутся знатоки, которые скажут, в чем я не прав. Но я не считаю дизайн-систему, над которой работаю, атомарной в полной мере. Тогда какой? Термин не вполне устоявшийся, но я называю эту архитектуру “виджетной”.
А чем плох чисто атомарный подход? Зачем что-то придумывать новое? Вот здесь поправляйте, если что, но насколько я понимаю, суть атомарного дизайна заключается в том, что элементы того же уровня не должны содержать друг друга, тем более включать себя же. Например, если атом “кнопка” содержит атом “иконка”, то это уже будет не атом, а молекула "кнопка с иконкой". Да и сама кнопка не может содержать такую же кнопку внутри себя. Возможно странный пример, но попробуйте представить, что все элементы в вашем проекте организованы так же, как в Figma. Тогда что же представлял бы собой “frame” с точки зрения атомарности?
А как работает “виджетный” дизайн? Здесь каждый может подойти к его созданию по-своему. Как ни странно, все основано на виджетах! Далее термины, которые использую я сам при проектировании. Виджеты могут быть двух типов, назовём их открытые и закрытые. Закрытые виджеты принимают только параметры, а открытые могут принимать параметры и другие виджеты. Открытые виджеты, в свою очередь, могут работать как контейнеры или иметь специальные слоты. Окна, например, работают как контейнеры, которые способны вместить в себя любой набор виджетов. Списки могут принимать шаблоны типов элементов или даже другие списки (получая, таким образом, списки списков 🤯).
Еще есть один тип виджетов - виджеты свойств. Они могут добавить новые свойства любому виджету, в который они попадают. Например, они могут превратить статический объект в интерактивный, добавить возможность показывать различные анимационные эффекты, переходы и многое другое.
Такой подход, на мой взгляд, отлично сочетается с принципами SDUI, хотя где-то в проекте, возможно, и будет присутствовать атомарность "по Фросту". Если бы мне пришлось отвечать сейчас на вопрос “Is atomic design dead?”, я бы сказал, что в его нынешнем виде - да. Ведь в старых рамках многие уже начинают чувствовать себя тесно, искать альтернативы. Но полностью, вероятно, атомарность никуда не исчезнет. Однако, сегодня это уже не единственный путь, а лишь один из инструментов для решения конкретных задач.
- - - - -
Канал: Мыслью по древу
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13
This media is not supported in your browser
VIEW IN TELEGRAM
Не получается у меня что-то писать короткие посты... Так что завтра в следующем тоже будет много букв.
Ну а с другой стороны, название канала оправдывать-то надо😁
- - - - -
Канал: Мыслью по древу
Ну а с другой стороны, название канала оправдывать-то надо
- - - - -
Канал: Мыслью по древу
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8😁2