Comments 8
Старайтесь описывать состояния где-то отдельно с помощью стилей. Ну зачем вам вид нажатой кнопки на каждом макете?
Так на каждом макете и не надо, надо только в библиотеке. Что мешает в третьем варианте добавить столбец с этими же элементами при ховере?
А для сложных компонентов еще надо рисовать адаптивную версию. В общем, состояния нужны в библиотеке.
Аналогично делал универсальный компонент одно время, только иконки две: слева и справа — так более гибко. Позволяет реализовывать выпадающие списки с иконическими элементами, аккордеоны, инпуты с иконками поля и иконкой состояния («глаз» для паролей) и т.п.
Вот тут везде по сути один такой компонент в основе) Он реально удобный.
Но со временем наоборот стал сознательно избегать излишней унификации.
Дело в том, что при всей внешней схожести компонентов, у них разная семантика. Поэтому они по-разному ведут себя внутри других компонентов, реагируют на ввод и т.п. Например, у инпута добавляются результаты валидации, подсказки по ошибкам и т.п. А у выпадающего списка — нет. При наведении на простую кнопку меняется цвет, а при наведении на кнопку-иконку внутри крошек к ней просто добавляется бордюр. И так далее.
Когда элементов и проектов накапливается много, «универсальный» компонент превращается в обузу, потому что от него наследуется целое дерево модификаций и при малейшем обновлении «корня» часть веток запросто может посыпаться. Так что в итоге теряется сам смысл универсальности. В итоге я решил особо не умничать и делать компоненты полностью независимыми друг от друга :) Тут примерно та же попа, как при высокой связности кода в программировании. Тем более, что во некоторых проектах компоненты имеют другую структуру, состав или кол-во состояний.
Состояния (вообще все модификаторы) храню отдельными компонентами. Все локальные мастер-компоненты, задействованные в проекте, выношу на отдельную «техническую» страницу, предназначенную для верстака. Именно там показываю все состояния, не тягая их в остальные макеты вообще. Там же комментирую, если нужно. Именую всё в духе БЭМ, отделяя модификаторы слэшами, чтобы фигма группировала состояния в списки.
Если не используются глобальные компоненты, всё вообще становится просто. На странице компонентов они группируются по фреймам. Тогда локальная библиотека становится компактной и ворочается быстро. То есть вместо того, чтобы скроллить сто иконок, я бросаю из библиотеки на макет экземпляр дефолтной иконки (первый в списке) или копирую любую иконку из макета. А потом через меню instanсe (см. выше) быстро выбираю нужные модификаторы во вложенных списках. Если в проекте много всего, то компоненты можно ещё и по страницам разложить, тогда вообще удобно:
P.S. Важное замечание: эта система хороша для случая когда дизайнеров мало (один-два), а проектов много и они разноплановые, автономные. В больших командах с сингл-проджектом и глобальной библиотекой всё может быть иначе.
Вот тут везде по сути один такой компонент в основе) Он реально удобный.
Но со временем наоборот стал сознательно избегать излишней унификации.
Дело в том, что при всей внешней схожести компонентов, у них разная семантика. Поэтому они по-разному ведут себя внутри других компонентов, реагируют на ввод и т.п. Например, у инпута добавляются результаты валидации, подсказки по ошибкам и т.п. А у выпадающего списка — нет. При наведении на простую кнопку меняется цвет, а при наведении на кнопку-иконку внутри крошек к ней просто добавляется бордюр. И так далее.
Когда элементов и проектов накапливается много, «универсальный» компонент превращается в обузу, потому что от него наследуется целое дерево модификаций и при малейшем обновлении «корня» часть веток запросто может посыпаться. Так что в итоге теряется сам смысл универсальности. В итоге я решил особо не умничать и делать компоненты полностью независимыми друг от друга :) Тут примерно та же попа, как при высокой связности кода в программировании. Тем более, что во некоторых проектах компоненты имеют другую структуру, состав или кол-во состояний.
Состояния (вообще все модификаторы) храню отдельными компонентами. Все локальные мастер-компоненты, задействованные в проекте, выношу на отдельную «техническую» страницу, предназначенную для верстака. Именно там показываю все состояния, не тягая их в остальные макеты вообще. Там же комментирую, если нужно. Именую всё в духе БЭМ, отделяя модификаторы слэшами, чтобы фигма группировала состояния в списки.
Если не используются глобальные компоненты, всё вообще становится просто. На странице компонентов они группируются по фреймам. Тогда локальная библиотека становится компактной и ворочается быстро. То есть вместо того, чтобы скроллить сто иконок, я бросаю из библиотеки на макет экземпляр дефолтной иконки (первый в списке) или копирую любую иконку из макета. А потом через меню instanсe (см. выше) быстро выбираю нужные модификаторы во вложенных списках. Если в проекте много всего, то компоненты можно ещё и по страницам разложить, тогда вообще удобно:
P.S. Важное замечание: эта система хороша для случая когда дизайнеров мало (один-два), а проектов много и они разноплановые, автономные. В больших командах с сингл-проджектом и глобальной библиотекой всё может быть иначе.
Спасибо за такой обширный комментарий)
Да, я не призываю все состояния всех элементов делать внутри одного компонента. Это неправильно. Я это использую для структурного построения элементов. Все цвета, бордеры, толщины и прочее, конечно, советую описывать отдельно.
Аналогично делал универсальный компонент одно время, только иконки двеЯ нарисовал эти картинки специально для статьи как простые примеры. В рабочих макетах у меня тоже иконки с обоих сторон есть.
Да, я не призываю все состояния всех элементов делать внутри одного компонента. Это неправильно. Я это использую для структурного построения элементов. Все цвета, бордеры, толщины и прочее, конечно, советую описывать отдельно.
Выше уже написали громадный толковый коммент. Поэтому напишу мелкий беспечный коммент.
Чем дольше юзаю фигму, тем меньше унифицирую компоненты. На то есть две важные причины:
1) Продумывание унификации трудоёмко и в целом утяжеляет процесс дизайна в дальнейшем.
2) Унификация очень часто сковывает дизайн в будущем, а в чём именно — почти нельзя предугадать. Поэтому рано или поздно начинают появляться отдельные компоненты, независимые от других.
Поэтому процесс дизайна таки скатывается к старому доброму воркфлоу: накидай по-быстрику — а потом рефакторь, ЕСЛИ это станет целесообразным вообще.
Да, компонентов становится больше, но в целом ими становится легче управлять. Экономятся силы и время. Для облегчения вникания в большую библиотеку удобно компоненты расставлять над теми фреймами, где они впервые возникают. Таким образом вся масса компонентов дробится между макетами и не вызывает ужаса из-за количества разных сущностей. И их назначение становится проще понять — ведь демонстрирующий макет прямо рядом.
Чем дольше юзаю фигму, тем меньше унифицирую компоненты. На то есть две важные причины:
1) Продумывание унификации трудоёмко и в целом утяжеляет процесс дизайна в дальнейшем.
2) Унификация очень часто сковывает дизайн в будущем, а в чём именно — почти нельзя предугадать. Поэтому рано или поздно начинают появляться отдельные компоненты, независимые от других.
Поэтому процесс дизайна таки скатывается к старому доброму воркфлоу: накидай по-быстрику — а потом рефакторь, ЕСЛИ это станет целесообразным вообще.
Да, компонентов становится больше, но в целом ими становится легче управлять. Экономятся силы и время. Для облегчения вникания в большую библиотеку удобно компоненты расставлять над теми фреймами, где они впервые возникают. Таким образом вся масса компонентов дробится между макетами и не вызывает ужаса из-за количества разных сущностей. И их назначение становится проще понять — ведь демонстрирующий макет прямо рядом.
Продумывание унификации трудоёмко и в целом утяжеляет процесс дизайна в дальнейшемА вы что хотели? Наебашить быстренько и пойти дальше? Работа дизайнера принципе не самая легкая, если углубляться в детали. Нужно думать наперед. Особенно когда работаешь над одним продуктом, а не в студии над небольшими проектами.
Унификация очень часто сковывает дизайн в будущемНе согласен. Практика (не только моя) показывает, что ограничения рождают гениальные решения. А когда дизайнеру дается полная свобода, получается фигня. Вы только посмотрите на Бутстрап. Там стандартный набор элементов, а какое огромное количество совершенно разных сайтов на нем сделано. Это чистой воды фантазия разработчиков. Не иначе.
Поэтому рано или поздно начинают появляться отдельные компоненты, независимые от других.
Для облегчения вникания в большую библиотеку удобно компоненты расставлять над теми фреймами, где они впервые возникают.Это и есть отсутствие системы дизайна.
Да, компонентов становится больше, но в целом ими становится легче управлять. Экономятся силы и время.Это вам становится легче. Но только разработчикам от этого тяжелее. Лишняя верстка и программирование. И как результат — долгое обновление продукта и медленное движение вперед.
Таким образом вся масса компонентов дробится между макетами и не вызывает ужаса из-за количества разных сущностей. И их назначение становится проще понять — ведь демонстрирующий макет прямо рядом.Такой стиль работы допустим при разработке лендингов и небольших сайтов до 50 страниц. Но работая над большим проектом, в котором огромное количество страниц и состояний это недопустимо. В систему дизайна придется вникнуть, чтобы получить хороший результат.
Хорошая статья, спасибо. Вопрос насущный, как хранить состояния компонентов системы. Вложенные состояние обеспечивают компактность библиотеки, но выбор через инстансы чуть быстрее в работе. Сейчас храним состояния в компоненте и показывая их открытие вариации на страницах библиотеке. Для полей, кнопок, чекбоксов, форм держим отдельные мастер-формы, что дает больше гибкости для нескольких проектов. (К примеру в одном проекте все скругления равны 4, а в другом квадратные поля и скругленные кнопки)
Sign up to leave a comment.
Мой способ создания мастер-компонентов в Фигме