Создание ультимативного инпута в Figma
Привет! Сегодня хотел бы затронуть тему корректного создания компонентов с учетом AL 4.0.
Разговор сегодня пойдет про элемент input, так как этот элемент используется практически в любом дизайне, начиная от лендинга и заканчивая сложными веб-сервисами.
С введение новой верссии AutoLayout, Figma нам очень сильно упростили жизнь. Теперь не нужно создавать элементы с иконкой справа, слева, с лейблом, без и т. д.
Далее скажу, что мы с вами постараемся создать максимально ультимативный инпут, который будет отвечать большинству требований.
Поделим все создание на несколько частей:
P. S. Статья рассчитана на людей, которые уже имеют какой-то опыт работы в фигма и знают, как минимум, что такое «компоненты», «варианты» и т. д.
Подготовка вспомогательных элементов
В инпуте нам будут нужны иконки, которые мы будем менять в зависимости от ситуации. Давайте сделаем компоненты из нескольких иконок, чтобы протестировать финальный результат. Я за основу беру пак Unicons с сервиса icones. js. org. (Отличный сервис, за использование которого разработчки скажут вам спасибо). Иконки с этого ресурса распространяются по “free for commercial use” лицензии.
Берем иконки, делаем компонентами, потом пакуем в варианты.
Построение компонента инпута
Здесь нам нужно понять самое главное правило для создания любого компонента при помощи Auto Layout v. 4. Пихаем в компонент максимальное количество того, что можем напихать. (дальше скроем).
Создаем само поле ввода
- Пишем текст (text color: AAB7C6)
- Shift + A
- Добавить Fill (ffffff)
- Добавить Border (AAB7C6)
- Отступы (По бокам — 16, сверху и снизу — 12)
- Скругления/толщина обводки (border radius: 12, fill width: 1)
- Выбираем у Placeholder значение Fill Container
Добавляем в поле иконки слева и справа
Не забываем, что иконки мы добавляем исключительно из тех вариантов, которые мы сделали на шаге 1.
- Копируем иконку
- Вставляем в наше поле
- Отступы иконки от текста справа и слева по 8px
- Иконка должна быть по высоте равно высоте текста в этом инпуте
Добавляем Label
- Пишем текст (text color: 18212D)
- Выбираем Label и поле
- Shift + A
- Выбираем у Label значение Fill Container
- Отступы от текста до поля — 4px
Добавляем Hint + Иконка
- Пишем текст (text color: 18212D)
- Добавляем иконку (color: 18212D)
- Выбираем два объекта -> Shift + A
- Расстояние между иконкой и текстом — 4px
- Засовываем в общий элемент
- Отступы от подсказки до поля — 4px
- Выбираем у всего автолейаута значение Fill Container
- Выбираем у текста значение Fill Container
Создание instances & properties внутри компонента
Здесь и начинается самое интересное. Тут нам нужно всем изменяемым/скрываемым элементам задать необходимые параметры.
Поделим логически наш компонент на 3 части: лейбл, поле ввода, подсказка. Пойдем сверху вниз.
Лейбл
- Создаем компонент из нашего элемента (cmd+opt/ctrl + K)
- Выделяем Label
- В разделе Layer нажимаем на соответсвующую иконку и задаем наименование нашему контролу. (Show Label)
- В разделе Content нажимаем на соответсвующую иконку и задаем наименование нашему контролу. (Change Label Text)
- Проверяем
Поле ввода
- Выделяем иконку
- В разделе Layer нажимаем на соответствующую иконку и задаем наименование нашему контролу. (Show Right Icon)
- Проверяем
- Выделяем иконку
- В разделе компонента нажимаем на соответствующую иконку и задаем наименование нашему контролу. (Change Right Icon)
Проделываем все тоже самое с другой иконкой.
- В разделе Content нажимаем на соответствующую иконку и задаем наименование нашему контролу. (Change Placeholder Text)
- Проверяем
Подсказка
Выделяем ВСЮ подсказку.
- В разделе Layer задаем наименование (Show Hint)
- Выделяем иконку
- В разделе Layer задаем наименование (Show Hint Icon)
- В разделе компонента задаем наименование (Change Hint Icon)
- Выделяем ТЕКСТ подсказки
- В разделе Layer задаем наименование (Show Hint Text)
- В разделе Content задаем наименование. (Change Hint Text)
- Проверяем
Проверяем элемент на респонсив
На этом этапе нам нужно протыкать еще раз все инстансы и составные элементы и проверить, что везде, где нужно стоит Fill и проверить компонент окончательно.
Создаем варианты
Перед тем как начать создавать варианты нужно переименовать все слои внутри элемента. Так вам будет проще им управлять и править в будущем. А также поменять расположение инстансов и свойств в панели вариантов.
Теперь, когда мы полностью проверили элемент, мы можем создать его комбинации. Мы покажем состояния: hovered, focused, filled, disabled, error. И сделаем инпут поменьше размером.
Шаг 1
- Дублируем мастер-компонент
- Разбираем его (opt + cmd + B)
- Создаем новый мастер компонент (cmd + K)
- Выделяем оба элемента и создаем варианты
- Переименовываем варианты
Шаг 2
- Дублируем исходный элемент
- Меняем цвет обводки на 7D8C9E
- Переименовываем компонент на Hovered
- Дублируем исходный элемент
- Меняем цвет обводки на 3B90F2
- Переименовываем компонент на Focused
- Дублируем исходный элемент
- Меняем цвет обводки на 182737
- Меняем цвет текста на 182737
- и т. д.
Шаг 3
- Дублируем ВСЕ исходные элементы
- Меняем отступы внутри поля ввода на 12 справа и слева и 8 сверху и снизу
- Переименовываем
Шаг 4
- Кликаем на иконку слева, затем на появившийся “прицел”.
- Фигма выделяем все эти иконки. Скрываем их
- Тоже самое проделываем с подсказкой
Вывод
На выходе мы получаем максимально ультимативный компонент, который мы можем использовать в огромном количестве случаев. Можем собрать инпут для дропдауна, можем сделать поле без лейбла, можем дописывать ошибки. В дальнейшем можно пойти еще дальше и создать внутри этого компонента выпадающие списки и тем самым объединить инпут + дропдаун. Но это уже совсем другая история.
Автор молодец, но
Инпут не ультимативный как минимум из-за того, что нет мастера и придётся редактировать все варианты.
Если у вас есть разные инпуты: поиск, текст, почта с маской, числовой и тд — вы запаритесь редактировать все.
Да и настраивать каждый раз с дефолтного на, например, поиск, надоест) имхо
1. Ресайз не должен переносить текст на новую строку. Так никто не делает
2. Иконки все в одном компоненте. Зачем свойство Boolean тогда?
3. В инпутах бывает сброс (крестик). Как сделаете? Иконкой? Иконка - не интерактивный элемент
4. Лейбл и хелпер - такие же компоненты
я уж не говорю про то, что не хватает состояний и интерактивности
Сори, не ультимативно, но основы сборки поданы хорошо. Лайк
Раньше я всегда собирал отдельно .base компонент для редактирования, но по опыту буквально 1-2 раза за все время мне пришлось его отредактировать. Поэтому я и отказался от этого.
1) Ресайз, да, должен скрывать текст. Не отписал тут этот момент.
2) Да, иконки нельзя никогда хранить в вариантах. Я просто обернул их, чтобы показать, что они компоненты, а не просто валяются. Но это ввело в заблуждение, учту:)
Состояния в макете есть:) Интерактивность просто решил не описывать тут.
Спасибо за отклик:)
Дополню -
1 - самый первый компонент должен быть наиболее часто используемый. То есть ваши дизайнеры не должны тратить время на то чтобы добавить компонент из библиотеки и тратить время на отключение иконок, подсказок и тому подобного.
2 - Никогда. слышите? НИКОГДА - не объединяйте ассет иконок в один компонент как варианты. Во-первых он никак не сортируется внутри и все иконки будут будут предлагаться в хаотичном списке. Второе - в списке вариантов иконок нет превью это так же усложняет поиск компонента. И в-третьих это противоречит принципам Figma Properties - когда вы создаете instance swap properties это подразумевает что вы будете выбирать иконку не из вариантов этого компонента а среди отдельных компонентов (для удобства иконки компонентов организуют просто в отдельном артборде)
3 - Большие матрицы компонентов нагружают файлы - старайтесь делать более компактные компоненты. Например вам в компоненте не нужны состояния ховера, фокуса или например ассинхроной отправки данных - их можно отрисовать для документации а в компоненте оставить только те что вы реально используете постоянно.
4 - добавляйте обязательно Resizing Truncate Text для всех текста внутри поля чтобы он сокращался внутри инпута. (Не очень "ультимативно" если ваш компонент не предусматривает это поведение )
1) Самый первый компонент и есть самый используемый
2) Да, иконки никогда нельзя хранить в вариантах. Я просто собирал что бы было видно, что они являются компонентами.
3) Благодаря последнему автолейауту совсем больших матриц и не будет. Хранить отдельные компоненты в другом месте ерунда, так как за этим невозможно будет следить
4) Да, этот момент я просто забыл тут описать. Спасибо.
Вы просто не строили библиотек, которые славливали алерт по большой нагрузке на память. Как раз из-за большого количества состояний компонентов, попыток запихнуть в один компонент все на свете )
И я не верю что самый используемый компонент это у вас поле с двумя иконками по обоим краям и подсказкой) Я обычно рисую вот так -
компонент в дефолтном состоянии и рядом min max где всё включено... при этом даже скрытые иконки у меня по дефолту самые популярные в использовании
Так я же вроде написал, что в конце я убираю ненужные иконки и подсказки, получая тем самым инпут с лейблом и иконкой.
Я согласен насчет используемых иконок. Статья в принципе подразумевала просто рассказ об основных принципах построения.
А в чем у вас отличие на скрине в плане количества слоев? В левом артборде нет скрытых элементов?
Интересный подход, полезная статья!
Топовое оформление статиьб
Эх, получаецо пролистываем🥲
Подскажите, а вертикально у компонентов стоит fixed или hug? То есть при скрытии элементов фрейм поджимается или всегда по самой большой заполненности стоит?
Фрейм поджимается, при выключении слоя