Таблицы в Figma. Дизайн Data Grid одной ячейкой
Строительство таблицы из компонентов — задача, которая рано или поздно возникает перед каждым разработчиком дизайн-систем в Figma.
Существует три подхода к дизайну таблиц, чтобы создать data grid с гибкой архитектурой. В каждом из случаев используется либо row-компонент, либо column-компонент, либо cell-компонент. Каждый из случаев подробно рассмотрим ниже.
Зачем всё это?
Зачем вообще всё запихивать в одну ячейку? Действительно ли среднему по размеру проекту требуется такая гибкость? Нужна ли компонентная архитектура для обычной таблицы?
Внутри большого командного проекта это единственный верный путь создавать новые data grid — через компонент. Это помогает генерировать больше вариантов и быстрее валидировать новые идеи.
Мои наблюдения показывают, что не все Figma-дизайнеры приучают себя работать с компонентами с самых ранних стадий нового проекта. Согласно недавнему опросу в Figma-чате чуть менее половины дизайнеров используют компоненты. Большая часть используют просто фреймы и copy-paste.
Но те, кому удалось переключить свой workflow на компонентный, скорее всего уже никогда не сделают шаг назад, потому что этот подход даёт больше гибкости и востребован среди организаций с собственным штатом дизайнеров. Хотите сохранить интерес к своей вакансии, если метите в крутую организацию, где уже работают в Figma — работайте с компонентами.
Тем не менее дизайнерам-фрилансерам я бы тоже рекомендовал использовать собственную библиотеку. Можно делать дубликат под нового клиента и через мастер-компоненты быстро стилизовать под конкретные задачи.
Стили таблицы
Когда я создавал свои уже не первые дизайн-системы в Figma, я пересмотрел сотни таблиц и мне удалось категоризировать наиболее часто используемые стили.
Классика
Контрастный заголовок
Материальная таблица
Черезполосица
Минимализм
Использование компонентов для создания таблицы
Все пять стилей, которые я показал выше, собраны из одной ячейки-компонента, разница лишь в содержимом и все они будут ссылаться на один единственный главный компонент. Этот способ я считаю наиболее гибким и о нем подробно скоро расскажу, но сперва перечислю два других подхода.
Row-компонент
Использование строки с ячейками заранее заданного количества. Таким образом таблица быстро собирается простым клонированием сверху вниз. Далее регулируется ширина каждого ряда.
Cons: низкая степень гибкости, ячейки масштабируются всегда пропорционально. Придётся держать в системе много компонентов с различным набором ячеек, а потом для каждого набора дополнительно создавать новые состояния, что может усложнить организацию.
Pros: высоту Row удобно регулировать. Идеально подходит для dashboard-проектов, в которых часто меняются горизонтальные состояния в проекте: onHover, onSelected, onFocus и так далее и специфика разработки требует частого переключения между ними:
Column-компонент
Впервые эта идея пришла мне в голову чуть более года назад и я реализовал её в поздних версиях Material Design System. Таблицу удобно было бы собирать из компонентов-колонок, внутри которой заранее предопределено и размножено N-количество рядов, а все лишние срезались бы за границей фрейма через опцию Clip Content. Тогда было бы достаточно потянуть фрейм вниз за нижнюю границу, чтобы показать больше дополнительных ячеек в колонке:
Cons: внутри компонента не удастся регулировать высоту каждой ячейки (горизонтальный шаг), так как иначе не получится реализовать «срезание лишнего».
Pros: достаточная гибкость, чтобы строить таблицы в дизайн-системе с различной шириной колонок, например, чтобы умещался разный тип данных.
Совет: можно держать три таких компонента с разным шагом: S-32px / M-48px / XL-64px , например, и в какой-то степени решить проблему плотности ячеек. Особенно полезно в случае создания и мобильных и десктопных темплейтов внутри одного проекта / team library.
Cell-компонент
Использование ячейки-компонента даёт максимальную гибкость в стилизации таблицы. Редко какой проект требует использования и Material-стиля, и классического для data grid. Но если вы фрилансер, который регулярно создает новые дашборды своим клиентам из собственной или коммерческой базы компонентов, то вам лучше начинать с ячейки, из которой вы вы будете кирпичик-за-кирпичиком создавать таблицы. Потом будет достаточно вложить четыре линии, прижать их по бокам ячейки, расставить constraints и генерировать новые стили.
Cons: практически нет, разве что этот подход требует больше времени и навыков
Pros: максимальная гибкость, возможность управлять сеткой с помощью одного компонента, регулировать разделители, background, вложенные иконки и многое другое.
Подробный состав такой супер-ячейки я рассмотрю в следующем выпуске. Подписывайтесь на мой канал, там будут все анонсы!
Исходник с компонентами доступен тут.
В этой статье описан подход, который используется для секции таблиц в двух дизайн-системах: для iOS12 и для веба. За последние полтора года я сделал несколько качественных UI библиотек для Фигмы, которые значительно ускоряют дизайн-рутину.
Люблю статьи про Figma, побольше бы таких! Спасибо за материал
Люблю такие статьи. Высосать из пальца базовые вещи и такие «офигеть мы крутые». Жду статьи как держать отвертку в руках
Привет скетчистам! Но холиваров не будет...
Я тоже на фигме. Но я тоже считаю, что эта статья — как держать отвёртку. Однако, это не умаляет её ценности для новичков, которые не знают, как работают компоненты.
Здорово ещё саму таблицу делать компонентой с колонками (сеткой) к которым можно привязывать объекты.
Ещё неплохо делать cell, из них собирать row, потом уже объединять в table, если нужно много более-менее типовых решений, у которых меняется только количество колонн, строк и их размеры и при этом чтобы можно было просто поменять стиль всех ячеек.
Эх, жаль, только я на фигме больше года :)
А что, перевести нормально религия не позволяет?
Перевести кому и сколько?
Андрею переведи. Сколько? Нормально!
Текст читается как сухой перевод. Вот я и подумал, что перевести можно было и получше.
А оказалось это слог такой у вас. Был не прав.
за фигму автолайк
А вот где в Фигме такая штука типа Anima, чтобы при изменении высоты компоненты или группы сами разъезжались?
PS лайк статье - без вопросов :)
Ага. Или paddle. Всем хороши компоненты, но гибкости не хватает категорически.
Всё только начинается. Допилят и никуда не денутся.
ага, не волнуйтесь. Успеете еще такие фичи увидеть до пенсии
Дел