поле ввода в фигме
🎨 Один компонент Figma – 3360 вариантов
Перевод публикуется с сокращениями, автор оригинальной статьи – Luke Cardoni.
До появления вариантов было трудно ориентироваться в библиотеке Figma для компонентов с несколькими состояниями или характеристиками. Еще более болезненной была задача создания соглашений об именах. Функция Variants полностью устраняет эту сложность, позволяя объединить несколько компонентов в один. Вы также можете управлять этими состояниями и характеристиками, настраивая «свойства» и «значения». Это значительно упрощает использование и обслуживание компонента.
Рассмотрим пример с чекбоксом на базе Cedar
Checkbox имеет три вложенные папки, каждая для разного размера элемента (small, medium и large). В этих папках по шесть отдельных компонентов, представляющих три состояния чекбокса (unchecked, checked и indeterminate) в двух состояниях взаимодействия (rest и disabled). В общей сложности имеем 18 отдельных компонентов только для одного элемента формы (рис. 1).
Добавление их в 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 имеет множество состояний, вариантов использования и характеристик, которые необходимо учитывать.
Деконструкция Text Input
Кроме того input имеет следующие характеристики, которые сочетаются различными способами в зависимости от контекста использования (рис. 4):
На этом этапе необходимо было ввести некоторые изменения для ограничения нежелательных комбинаций: запретить использование helper-ссылки и иконки (рис. 5), helper-текста «над-под» (рис. 6) или установку 3 иконок одновременно (рис. 7).
Рис. 5 – 7 слева направо
Настройка сложных вариантов
В то время, как основной компонент служил общей отправной точкой для каждого множества вариантов, матрица свойств помогала настроить среду для отслеживания и валидации каждой возможной перестановки компонента.
Построение мастер-компонента
Мастер-компонент обеспечивает схему сложного элемента UI и помогает управлять сложностью с помощью вложенности. Как это работает? Допустим, есть 5 различных свойств, которые мы отслеживаем в данном компоненте, и каждое из этих свойств может быть или «off» или «on». Главный компонент отображает все возможные свойства в состоянии «on». Другими словами, это представление компонента в его наиболее сложной форме.
Для Text Input главный компонент состоит из трех вложенных, к которым применяется вертикальная автокомпоновка (рис. 8).
Здесь главный компонент (в крайнем правом углу на рис. 8) отображает все заполненные ячейки иконок, обязательную и необязательную подпись, текст хелпера, ссылку, иконку и сообщение об ошибке.
рис. 8. Структурная разбивка основного компонента для инпута. Вложенные компоненты строятся слева направо и приводят к главному компоненту в крайнем правом углу.
Это Nested Variant?
Обратите внимание на рис. 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.
Библиотеки компонентов в Figma: что это, зачем нужно и как работает
Редактируете одну кнопку — меняются все. Разбираемся с главной фишкой Figma, за которую её любят веб-дизайнеры.
Если каждую кнопку на сайте рисовать по отдельности, жизнь веб-дизайнера превратится в ад. Чтобы этого не произошло, в Figma есть компоненты.
Что такое компонент Figma
Компонент — это элемент, копии которого меняются вместе с ним. Например, поле ввода, аватар со статусом или меню. Исходный компонент называется основным (main component), его копии — экземплярами (instances).
Допустим, мы создали основной компонент — чёрный квадрат. Затем добавили два его экземпляра.
Перекрасим первый в красный цвет. Все три тоже станут красными — экземпляры наследуют параметры основного компонента.
Наряду с наследованием, экземпляры можно изменять напрямую, не разрывая при этом связь с «родителем». Например, сделать второй квадрат сиреневым, а третьему добавить обводку и растянуть.
Свойства, полученные экземплярами непосредственно, всегда приоритетны по сравнению с унаследованными. Если уменьшить и перекрасить «родителя» в жёлтый цвет, один из его «потомков» всё равно останется фиолетовым, а другой — прямоугольником, потому что эти свойства были приобретены самостоятельно, а не от основного компонента.
Основной компонент — шаблон для будущих элементов дизайна. Например, для кнопки он состоит из прямоугольника, текста и иконки. А их размер и содержание зависят от экземпляра.
Автор статей о веб-дизайне и веб-разработке с неразделённой любовью к программированию.
Что такое библиотека компонентов
Библиотека — это файл, где хранятся основные компоненты для проекта. Он точно такой же, как файл с готовым дизайном, — отличается только назначением. Если нужно добавить в проект один из стандартных элементов, дизайнер не рисует его заново, а берёт из библиотеки.
Для библиотек нет строгих стандартов оформления. Обычно компоненты структурируют и снабжают заголовками. Их удобно группировать по фреймам — например, в зависимости от интерфейса (мобильный или десктопный) и типа (уведомления, контекстные меню и тому подобное).
Зачем нужны библиотеки компонентов
Профессионалы сходятся во мнении: библиотеки компонентов — одно из главных преимуществ Figma перед другими программами для дизайна. Они позволяют:
Как создать библиотеку компонентов
Сделайте пустой файл, который станет библиотекой, и наполняйте его компонентами. Вначале нарисуйте составные части компонента. Затем выделите их и щёлкните Create Component в верхней панели.
Чтобы новую библиотеку можно было использовать в проектах, её нужно опубликовать. Сделайте это на вкладке Assets, кликнув иконку-книгу и нажав Publish.
С библиотеками проще работать, если соблюдать несколько правил:
Фрейм называют как категорию элементов. Допустим, «Уведомления» — все уведомления помещают в него. Визуально так проще ориентироваться, но самое главное — в раскрывающемся списке компонентов появится одноимённый пункт.
Как правильно использовать библиотеки
Когда библиотека опубликована для команды, её компоненты появляются на вкладке Assets в левой панели. После этого участники могут их использовать.
Поместить экземпляр компонента в дизайн можно тремя способами:
Бывает, что изменённый экземпляр уже сильно отличается от «родителя». Если он ещё понадобится в таком виде, можно сделать две вещи:
Что в итоге
Библиотеки компонентов Figma — удобный способ хранить заготовки для интерфейсов, а также делиться ими с командой и всем миром. Сохраняйте в них всё, что будет использоваться многократно. Чтобы подредактировать экземпляр, вносите правки на месте. А если уйдёте далеко от оригинала, элемент можно сделать самостоятельным компонентом.
Как рисовать универсальные компоненты, которые адаптируются к размеру экрана, создавать команды, взаимодействовать с разработчиками и не только — вы узнаете на нашем курсе. Прокачайте знание Figma и станьте настоящим профессионалом веб-дизайна!
Один компонент Figma — 3,360 вариантов (Variants)
Один компонент, чтобы управлять ими всеми.
Я работаю на должности UX Lead в компании REI, и часто участвую в разработке нашей дизайн-системы Cedar. Совсем недавно я сосредоточился на улучшении доступности наших элементов формы. Оказалось, что эти компоненты интерфейса представляют прекрасную возможность изучить функцию Вариантов Figma, поскольку у каждого поля ввода, переключателя и флажка есть так много вариантов.
В дальнейшем я буду называть функцию Figma Вариантами (заглавная буква «В»). Не путайте с вариантами (строчная буква в), как фактическими вариациями одного элемента интерфейса.
До появления Вариантов было сложно перемещаться по библиотеке в Figma, если у вас был компонент с несколькими состояниями или характеристиками. Еще более болезненной была проблема создания кратких и содержательных имен. Функция Варианты (Variants) полностью устраняет эту сложность, позволяя объединить несколько компонентов в один. Вы также можете управлять этими состояниями и характеристиками, настраивая «свойства» и «значения». Это значительно упрощает использование и обслуживание данного компонента.
Давайте посмотрим на чекбоксы в дизайн-системе Cedar
Когда я приступил к работе, компонент Checkbox имел три вложенные папки в библиотеке, каждая для разного размера элемента (маленький, средний и большой). В этих папках было шесть отдельных компонентов, представляющих три состояния флажка (снятый, отмеченный и неопределенный) в двух состояниях взаимодействия (покой и отключен). Всего это 18 отдельных компонентов только для одного элемента формы (рис. 1).
Но подождите, это еще не все.
Когда я работал над улучшением дизайна и доступности флажка, я понял, что есть дополнительные характеристики, которые не были учтены в нашей библиотеке. К ним относятся состояния взаимодействия для наведения, фокуса и нажатия, интервала макетов групп форм и цвет фона того места, где находится флажок (аналогично светлой / темной темам). Это увеличило количество вариантов флажка с 18 до 192.
Добавление их в дизайн-систему внесло новую сложность и еще больше свойств, за которыми нужно следить. Однако было важно включить их, чтобы любой, кто пользуется дизайн-системой, мог создавать доступные элементы формы. А благодаря функции Варианты все 192 варианта могут быть легко представлены в одном компоненте, который просто называется «Checkbox» (рис. 2). Больше нет подобной ерунды Checkbox/ Checkbox_Compact/ 1 — Rest.
Рис. 2 – Один компонент Checkbox, содержащий 192 Варианта
Я смог применить тот же подход к радиокнопке, создав один компонент со 120 Вариантами (рис.3). Следующим в моем списке было поле ввода, которое, как оказалось, потребовало гораздо больших усилий.
Рис. 3 – Единый вариант для радиокнопки со 120 вариантами
В то время, как флажок и радиокнопка уже содержат почти 200 вариантов, поле ввода, с другой стороны, имеет множество состояний, случаев использования и характеристик, которые необходимо учитывать. Но сколько свойств у поля ввода? Со сколькими вариациями я могу иметь дело?
Спойлер: Очень много.
Разбор полей ввода
Текстовое поле ввода – один из самых распространенных элементов интерфейса. Все мы когда-то использовали его для входа в аккаунт, ввода номеров кредитных карт, адресов доставки и т. д. Они предназначены для беспрепятственного использования, сопровождая пользователя на протяжении всего юзерфлоу формы. Итак, откуда взялась вся сложность?
В Cedar поле ввода имеет следующие характеристики, которые комбинируются различными способами в зависимости от контекста использования (рис. 4):
На этом этапе необходимо было ввести ряд ограничений и инструкций, чтобы отсечь нежелательные комбинации. Например, запретить одновременно вспомогательную ссылку и иконку (рис. 5), вспомогательный текст сверху и снизу (рис. 6) или наличие всех 3 иконок одновременно в поле ввода (рис. 7).
Можно ли задокументировать все это в одном компоненте? По крайней мере, я собирался попробовать …
Так началось мое погружение в безумие.
Настройка сложных вариантов
На протяжении этого процесса меня удерживали две вещи: использование главного компонента и матрицы свойств. В то время, как главный компонент служил общей отправной точкой для каждого из множества Вариантов, матрица свойств помогла мне настроить среду для отслеживания и проверки всех возможных изменений компонента.
Создание главного компонента
Главный компонент (master component) представляет собой схему сложного элемента интерфейса и помогает управлять сложностью за счет вложенности. (Для получения дополнительной информации о вложенных компонентах я бы порекомендовал работу Anthony DiSpezio и Thomas Lowry). Как это работает? Предположим, есть 5 различных свойств, которые мы отслеживаем в данном компоненте, и каждое из этих свойств может быть «включено» или «выключено». Главный компонент отображает все возможные свойства в состоянии «включено». Другими словами, это представление компонента в его наиболее сложной форме, независимо от того, произойдет ли этот случай в реальности.
Главный компонент поля ввода состоит из трех вложенных компонентов, к которым применяется вертикальный auto layout (рис. 8).
Здесь главный компонент (виден справа на рис. 8) отображает все заполненные слоты иконок, как обязательные, так и необязательные обозначения, вспомогательный текст над и под полем, вспомогательную ссылку и иконку, а также сообщения об ошибках. Это наиболее сложное состояние, однако вы никогда не увидите его в реальности. Это просто план распределения пространства.
Рис. 8 – Структурная разбивка основного компонента для поля ввода. Вложенные компоненты строятся слева направо, приводя к главному компоненту справа
Подождите – это вложенный Вариант?!
Обратите внимание на рисунке 8 видно, что средний компонент сам по себе является Вариантом. Вложение варианта в этом случае повышает масштабируемость и надежность этого компонента. Если где-то в дальнейшем цвета бренда или решения, принятые в отношении стилей взаимодействия, должны будут измениться, их нужно будет скорректировать только в этой единственной точке в Варианте, в главном компоненте. Вложенные Варианты также можно использовать для расширения отдельных частей главного компонента, если они занимают аналогичные слоты и функционируют в окончательной презентации.
Рис. 9 – Преобразование компонента обмена сообщениями об ошибках в Вариант, чтобы включить стили предупреждения и успеха для обратной связи формы
Пока я работал над этим, в других частях системы все еще принимались решения в отношении стилей, цветов и иконок для положительного и предупреждающего фидбека. Как только эти решения будут окончательно приняты, используя подход вложенных Вариантов, я планирую преобразовать компонент ошибки в Вариант, чтобы включить положительный и предупреждающий фидбек (рис. 9). Затем эти стили станут доступны главному компоненту.
Теперь, когда у меня был главный компонент, с которым можно было работать, пришло время вернуться к 7 свойствам и связанным значениям для поля ввода (рис. 10). С ними я создал рабочее пространство, чтобы начать создавать множество модификаций, которые может принять этот компонент.
Рис. 10 – Планирование свойств и значений для варианта ввода текста
Настройка матрицы свойств
Матрица свойств требует немного математических расчетов, но, по сути, представляет собой сеточную систему, в которой представлены все возможные комбинации свойств и значений. Для начала создайте таблицу, в каждой ячейке которой представлены значения одного свойства. Затем продублируйте таблицу для каждого значения следующего свойства на противоположной оси. Этот процесс дублирования и чередования осей продолжается до тех пор, пока все свойства не будут представлены в таблице. Это обеспечит определение пространства для каждой возможной комбинации значений для всех свойств.
При подготовке к этому процессу я рекомендую стратегически отсортировать свойства (рис.11), чтобы вы могли работать с большими партиями по мере вашего продвижения – начиная со свойства с наибольшим значением до наименьших значений или упорядочивая по состоянию, теме и т. д. При объединении в качестве Вариантов эти свойства и значения могут быть переупорядочены на панели builder.
Рис. 11 – Демонстрация создания матрицы свойств с использованием свойств и значений поля ввода
Для поля ввода я начал с однострочной таблицы с 5 столбцами, по одному для каждого значения в свойстве «Icon». Затем я продублировал эту строку для каждого из 3 значений в свойстве «Text». Затем я продублировал этот набор для всех значений в свойстве «Required», а затем снова для «Helpers», «Size», «State» и, наконец, «Background Color».
Рис. 12 – Пустая сетка свойств, которая лежала передо мной
Я утверждал, что создание сетки упростит задачу, но вначале это может быть довольно сложно (рис. 12). Figma определенно столкнулась с проблемами производительности. Уменьшение масштаба для просмотра сетки целиком займет несколько секунд на обновление экрана. На тот момент у меня не было времени на подсчет количества Вариантов, которые необходимо было создать – честно говоря, я слегка боялся, что их число может меня обескуражить. Я увеличил масштаб и продолжил работу.
Начиная с левого верхнего угла и двигаясь по горизонтали, я разместил экземпляр главного компонента и скорректировал видимость слоев и стилей, чтобы они соответствовали подходящим значениям, определенным матрицей. Продолжая, я смог систематически дублировать, переименовывать и настраивать общий параметр для соответствующего значения свойства для всей строки.
Я решил остановить этого балрога, используя рабочий процесс, с которым был наиболее знаком в то время – создание отдельных компонентов и присвоение имени каждому слою для каждого из значений свойств, разделенных слешем (/). Думаю, что предпочитаю этот подход, так как проще выбрать несколько слоев и использовать функцию «переименовать» для сопоставления и замены части имени слоя.
Моя работа продолжалась несколько часов и дней. По мере завершения создания каждой крупной горизонтальной группы свойств я мог дублировать все более и более крупные пакеты, сосредоточившись на переименовании и настройке единственного параметра для соответствующего значения в группе свойств. Например, когда я завершил все варианты поля ввода в состоянии покоя, я смог продублировать все экземпляры и настроить их, чтобы они соответствовали активному состоянию, а затем снова для отключенного состояния и состояния ошибки.
Рис. 13 – Уменьшение масштаба, чтобы увидеть все 3 360 вариантов поля ввода
И я продолжал работать, ячейка за ячейкой, час за часом, слушая плейлисты Spotify. Когда я добрался до последней строки, волосы на затылке встали дыбом. Наконец, я заполнил таблицу уникальным представлением каждой комбинации значений (рис. 13). Я выбрал все экземпляры, преобразовал их в компоненты и, наконец, нажал кнопку «Combine as Variants».
Я сделал это. Я создал один, полностью адаптируемый к контенту, легко обслуживаемый компонент с 3 360 Вариантами, который будет обслуживать любую возможную комбинацию допустимых настроек для поля ввода. Компонент с несколькими Вариантами, который почти вдвое превышает количество миль, пройденных от Шира до Роковой горы (1779 миль, согласно Атласу Средиземья под редакцией Карен Винн Фонстад).
Семь вспомогательных композиций для компоновки,
Пять комбинаций отображения иконок,
Четыре состояния взаимодействия для перемен,
Текстовое поле представлено тремя способами.
Чтобы узнать, требуется ли информация,
На светлом или темном фоне –
Один Компонент, чтобы управлять всеми,
Один Компонент, чтобы выровнять их,
Один компонент, чтобы вмещать их все, и связать их с помощью Вариантов,
В землях Figma, где процветают дизайн-системы.