Один компонент Figma – 3360 вариантов
Если вы еще не знаете о Figma Variants, мы постараемся прояснить ситуацию на примере input, radio button и checkbox. Обсудить Перевод публикуется с сокращениями, автор оригинальной статьи – Luke Cardoni. В статье будут часто встречаться ссылки на Variants (заглавная буква V), как на функцию Figma. Не следует путать с variants (строчная буква v) – актуальными вариациями элемента пользовательского интерфейса. До появления вариантов было трудно ориентироваться в библиотеке Figma для компонентов с несколькими состояниями или характеристиками. Еще более болезненной была задача создания соглашений об именах. Функция Variants полностью устраняет эту сложность, позволяя объединить несколько компонентов в один. Вы также можете управлять этими состояниями и характеристиками, настраивая «свойства» и «значения». Это значительно упрощает использование и обслуживание компонента. рис. 1. 18 компонентов для чекбокса в библиотеке Cedar. Checkbox имеет три вложенные папки, каждая для разного размера элемента (small, medium и large). В этих папках по шесть отдельных компонентов, представляющих три состояния чекбокса (unchecked, checked и indeterminate) в двух состояниях взаимодействия (rest и disabled). В общей сложности имеем 18 отдельных компонентов только для одного элемента формы (рис. 1). Существуют еще и дополнительные характеристики, которые еще не были учтены. Они включают состояния взаимодействия для hover, focus и pressed, интервал для макетов групп форм и цвет фона, в котором установлен флажок (аналогично light/dark mode). Это увеличило результат с 18 до 192 вариаций для нашего чекбокса. Добавление их в Cedar привнесло новую сложность и еще больше свойств для отслеживания, однако было важно включить их, чтобы любой, кто использует систему проектирования, мог создавать доступные элементы формы. Благодаря функции Variants, все 192 вариации можно легко представить в одном компоненте (рис. 2) без этой чепухи: Checkbox, Checkbox_Compact и т. д. рис. 2. Один компонент содержит 192 варианта. Можно применить тот же подход и к Radio Button, создав один компонент со 120 вариантами (рис.3). Следующим в списке рассмотрим Text Input, с которым все немного сложнее. рис. 3. Один вариант и 120 Variants. В то время, как Checkbox и Radio Button уже содержали почти 200 Variants, Text Input имеет множество состояний, вариантов использования и характеристик, которые необходимо учитывать. Строка ввода – один из самых распространенных элементов UI, используемых для ввода регистрационных данных, номеров кредитных карт, адресов и прочей информации, а также направления пользователя через поток форм. Кроме того input имеет следующие характеристики, которые сочетаются различными способами в зависимости от контекста использования (рис. 4): Рис. 4. На этом этапе необходимо было ввести некоторые изменения для ограничения нежелательных комбинаций: запретить использование helper-ссылки и иконки (рис. 5), helper-текста «над-под» (рис. 6) или установку 3 иконок одновременно (рис. 7). Рис. 5 – 7 слева направо В то время, как основной компонент служил общей отправной точкой для каждого множества вариантов, матрица свойств помогала настроить среду для отслеживания и валидации каждой возможной перестановки компонента. Мастер-компонент обеспечивает схему сложного элемента UI и помогает управлять сложностью с помощью вложенности. Как это работает? Допустим, есть 5 различных свойств, которые мы отслеживаем в данном компоненте, и каждое из этих свойств может быть или «off» или «on». Главный компонент отображает все возможные свойства в состоянии «on». Другими словами, это представление компонента в его наиболее сложной форме. Для Text Input главный компонент состоит из трех вложенных, к которым применяется вертикальная автокомпоновка (рис. 8). Здесь главный компонент (в крайнем правом углу на рис. 8) отображает все заполненные ячейки иконок, обязательную и необязательную подпись, текст хелпера, ссылку, иконку и сообщение об ошибке. Все вложенные компоненты, включая главный, начинаются символом .base/. Использование символов . или _ перед именем компонента предотвращает их публикацию и распространение как части библиотеки. рис. 8. Структурная разбивка основного компонента для инпута. Вложенные компоненты строятся слева направо и приводят к главному компоненту в крайнем правом углу. Обратите внимание на рис. 8, что средний компонент представляет собой Variant сам по себе. Вложенность варианта добавляет масштабируемости этому компоненту. Если в будущем изменятся цвета проекта или общие стили, их нужно будет корректировать только в этом месте внутри Variant основного компонента. Nesting Variants могут быть использованы для расширения отдельных частей основного компонента, если они занимают аналогичные ячейки и работают в окончательном представлении. рис. 9. Преобразование компонента сообщения об ошибке в Variant, включающее warning и success, а также стили формы обратной связи. Теперь, когда у нас есть мастер-компонент для работы, пришло время вернуться к 7 свойствам и связанным с ними значениям для инпута (рис. 10). С их помощью создадим рабочее пространство, чтобы начать строить множество перестановок, которые может принять этот компонент. рис. 10. Свойства и значения Variant-а для инпута. Матрица свойств представляет собой сеточную систему, представляющую все возможные комбинации свойств и значений. Для начала создадим таблицу, в которой каждая ячейка представляет значения одного свойства. Затем продублируем ее для каждого значения следующего свойства на противоположной оси. Процесс дублирования и чередования осей продолжается до тех пор, пока все свойства не будут представлены в таблице. Это гарантирует, что для каждой возможной комбинации значений всех свойств будет определено пространство. Теперь отсортируем наши свойства (рис. 11), чтобы можно было работать с большими партиями – начиная со свойства с наибольшими значениями до наименьших значений. рис. 11. Демонстрация создания матрицы свойств с использованием свойств и значений Text Input. Для Text Input начнем с однострочной таблицы с 5 столбцами, по одному для каждого значения в свойстве «Icon». Затем продублируем эту строку для каждого из 3 значений в свойстве «Text» и «Required», а затем для «Helpers», «Size» и т. д. рис. 12. Пустая сетка свойств – массив. Начиная с верхнего левого угла в горизонтальном направлении поместим экземпляр главного компонента и настроим видимость слоев и стилей в соответствии со значениями, определенными матрицей. Далее дублируем, переименовываем и корректируем настройки соответствующего значения свойства для всей строки. рис. 13. Уменьшение масштаба, чтобы увидеть все 3 360 вариантов Text Input. В конце концов мы заполнили все пространства уникальным представлением каждой комбинации значений (рис. 13). Мы выбрали все экземпляры, преобразовали их в компоненты и объединили в Variants. Мы сделали это! Создали единый, адаптируемый к контенту, полностью настраиваемый и легко обслуживаемый компонент с 3 360 вариантами, который будет обрабатывать каждую возможную комбинацию допустимых настроек для Text Input. Дополнительные материалы:
Рассмотрим пример с чекбоксом на базе Cedar
Деконструкция Text Input
Настройка сложных вариантов
Построение мастер-компонента
Это Nested Variant?
Настройка матрицы свойств
Заключение
- 12 views
- 0 Comment