Создание единой библиотеки компонентов14.11.2017 21:06

Дизайнер Сергей Никишкин написал на «Хабрахабре» колонку о дизайн-системе компании Acronis.

Меня зовут Сергей, я работаю старшим дизайнером в компании Acronis. В отделе дизайна продуктов для бизнеса я отвечаю за разработку и внедрение единой библиотеки компонентов.

Так как у нас много продуктов и сервисов, а дизайн в этих продуктах и сервисах сильно отличается, мы решили его унифицировать и привести к единому UI. Такой подход дает возможность оптимизировать работу отдела, сосредоточить дизайнеров на UX, ускорить процесс разработки и запуск новых продуктов, снизить нагрузку на отделы тестирования и значительно сократить количество багов на стороне фронтенд.

В этой статье я расскажу о нашем опыте, остановлюсь на инструментах и покажу, как устроена библиотека изнутри.

Здравствуйте, я ваш куратор в игре «Актуальный UI-кит»

Долгое время роль библиотеки играл собранный в Adobe Illustrator PDF-файл с палитрой цветов, скудным набором элементов и большими планами на будущее в виде 70 пустых страниц.

Для того, чтобы найти какой-нибудь уже существующий элемент, приходилось постоянно дергать других дизайнеров или лопатить чужие исходники, а потом сверять актуальность с реализованным элементом на одном из тестовых стендов. Пик отчаяния наступал в тот момент, когда на тестовом стенде искомый элемент выглядел несколько иначе и вел себя не совсем так, как было запланировано в макетах.

Получалась достаточно стандартная ситуация: дизайнеры тянули одеяло в свою сторону, мотивируя свои решения авторитетным «хочу, чтобы было так!», а разработчики пытались прикрываться мало значимым «но ведь технические ограничения». Такой подход, закономерно, приводил к не самым лучшим результатам по обе стороны баррикад и его нужно было менять.

Забегая вперед, скажу, что сейчас большинство сложных UI-решений мы принимаем коллегиально и стараемся искать компромисс между красотой и технологичностью.

Основные проблемы, которые требовали решения

• Централизованная библиотека UI-элементов.
• Версионность файлов и контроль за изменениями.
• Единый и понятный workflow.
• Базовый набор инструментов для работы.
• Взаимодействие с разработчиками.

Первое, что предстояло сделать, это найти инструменты, которые закроют большую часть потребностей отдела. После длительного изучения различных подходов к формированию библиотек и дизайн-систем, после вороха статей на блог-платформе Medium и тестирования огромного количества приложений и сервисов, мы выстроили следующую схему:

Система Abstract отвечает за контроль версий и историю изменений мастер-файла библиотеки. Набор плагинов Craft используется как библиотека для палитры цветов и замена нативному Color Inspector. Библиотека Lingo отвечает за хранение, подключение и обновление компонентов библиотеки в Sketch-файлах.

Такая схема уже сейчас позволяет легко поддерживать библиотеку в актуальном состоянии, контролировать изменения и, что наиболее важно, быстро доставлять обновления дизайнерам. При этом, доступ к мастер-файлу библиотеки имеет только владелец, а остальные участники процесса получают элементы в виде символов и составных компонентов из Lingo. Для доступа к компонентам Angular мы подняли на каждой машине песочницу, чтобы дизайнеры с помощью npm-start в консоли могли быстро запустить node-server и работать с кодом.

Еще раз забегая вперед, скажу, что одна из наших основных, долгосрочных и амбициозных задач — перенести большую часть работы над дизайном из графического редактора в браузер.

Abstract

Это десктопное приложение, которое позволяет контролировать историю изменений, откатываться к прошлым версиям и держать один актуальный мастер-файл, доступ к которому есть у каждого члена команды.

Для начала работы с Abstract достаточно добавить в приложение уже существующий проект или создать новый. Изменения идут в одной или нескольких параллельных ветках с последующим добавлением утвержденных кусков в мастер-файл.

Так как Abstract не дает создать новую ветку или слить ветку с мастер-файлом без комментария, история изменений появляется сама собой. Благодаря таким комментариям, значительно снижается вероятность случайных или неконтролируемых изменений. К тому же, удобно через какое-то время открыть проект и прочитать историю, посмотреть, как и зачем менялись элементы.

Если говорить о недостатках, то ключевым для некоторых команд может стать отсутствие возможности решать конфликты на уровне слоев в одном артборде, из-за чего параллельная работа над одним экраном невозможна, всегда будет конфликт версий и предложение выбрать один из двух вариантов. В нашей команде такой проблемы нет, так как мы одновременно не работаем над одним артбордом.

Остальные мелкие неровности и шероховатости нивелируются полным контролем над происходящим, больше никаких папок по датам, никаких md-файлов с описанием изменений и кучи исходников на внутреннем хранилище.

Craft

На данный момент мы используем Craft как библиотеку для цветовой палитры и замену нативному Color Inspector. Под рукой не только все цвета, но и названия переменных. Благодаря такому подходу удалось решить еще одну важную проблему. Дизайнеры перестали «пипетить», а разработчики перестали резонно негодовать, почему в двух макетах у одного и того же элемента отличаются значения цвета.

Кто работает в Sketch и использует несколько мониторов знает, что на каждом подключенном мониторе один и тот же цвет взятый пипеткой, в большинстве случаев, будет иметь разный HEX-код.

Lingo

Десктопное приложение, с помощью которого мы решили все проблемы связанные с подключением актуальной библиотеки к новым файлам и обновлением компонентов в уже подключенных проектах.

Можно создать несколько библиотек, разбить библиотеку на категории, проставить теги для каждого элемента, а при импорте элементов выбрать какой элемент добавить, а какой нет. При обновлении существующего компонента в библиотеке, Lingo предложит его заменить, сделать дубликат или отказаться от изменений.

Так же в Lingo можно хранить составные компоненты в виде папок со слоями или артборды целиком. Для нас эта возможность особенно актуальна, так как мы сознательно не делаем компоненты с большим количеством оверрайдов из-за сложностей в поддержке и кастомизации.

Несмотря на то, что в Sketch 47 будут библиотеки символов, которые уже доступны в бета-версии (работают, кстати, круто), мы не спешим уходить с Lingo из-за его возможностей и большей гибкости в работе.

Плагины

Централизованно мы используем три плагина:

• Shared Text Styles для работы с текстовыми стилями. Позволяет экспортить текстовые стили в формате JSON, добавлять стили в новый Sketch-документ и обновлять уже подгруженные.

• Relabel button для работы с кнопками. Одна из лучших реализаций плагинов такого рода, на мой взгляд. Достаточно правильно настроить привязки элементов внутри символа.

• Acronis data. Так как мы достаточно много работаем с таблицами и большими массивами данных, я собрал плагин, который генерирует специализированные значения для этих таблиц (offering items, agents name, schedule options, machines и так далее). Плагин работает на основе dummy data и подтягивает значения из JSON. Перед тем, как собирать кастомное решение, была неудачная попытка подружить единый JSON с Craft, но увы. Как оказалось, Craft не умеет в исходную разметку документа и показывает поля не по порядку.

Иконки

Рано или поздно перед каждым дизайнером, работающим в Sketch, встает проблема повторного использования символа иконки с другим цветом. В частных случаях можно отвязать иконку от символа или держать несколько символов с разными цветами, что не очень актуально, когда иконок много.

Я решил проблему следующим образом: прямоугольники с необходимыми цветами собрал в отдельные символы, а потом эти символы в виде масок добавил к иконкам, у которых может быть несколько цветов. Таким образом изменение цвета становится доступно через overrides.

Несмотря на удобство, у этого способа есть существенный минус. При экспорте SVG в коде будет присутствовать маска. Если на стороне разработки нет способа автоматизировать процесс удаления масок, придется держать отдельную библиотеку чистых иконок.

Компоненты Angular 4

Неважно, насколько прокачана и удобна библиотека пока она существует исключительно в виде Sketch-файла. Если в браузере компонент выглядит не так, как в макетах, библиотека уже неактуальна, а исходники устарели и не соответствуют действительности. Благодаря фронтенд-архитектору Acronis Сергею Сабурову, Кириллу Савёлову и всей команде мониторинга, наши компоненты плавно перетекают в код и работают именно так, как запланировано.

Несмотря на то, что часть новых продуктов и сервисов мы уже начали собирать с помощью текущих компонентов, еще не все фронтенд-команды готовы внедрять и использовать эти компоненты у себя. Где-то фронт написан на Ext JS, где-то используется Vue, и быстрый переход с одного фреймворка или библиотеки на другой технически невозможен по ряду причин.

У каждого компонента есть набор свойств. Свойства позволяют управлять состоянием компонента, его внешним видом и функциональностью. Так выглядит стандартный инпут в Sketch-библиотеке:

А вот так в коде:

Чтобы изменить размер и внешний вид инпута достаточно в свойствах указать: [size] = » 'sm' »

Более сложный пример:

Два типа дропдаунов. В первом случае — это список из значений, во втором — к списку значений добавляется строка поиска. Переключимся на код:

С помощью # selectChild получаем вложенный компонент для активного значения поля, через (select) подписываемся на событие текущего компонента, а с помощью директивы *ngFor проходим по массиву из значений и выводим их в выпадающем списке.

Чтобы включить строку поиска и возможность искать по списку, во втором примере включаем свойство [search]. Более подробно об Angular и работе компонентов на фронтенд-стороне мы расскажем в следующей статье.

Дизайнеры и код

Одна из наших амбициозных и долгосрочных задач — перенести дизайн из Sketch в браузер, чтобы дизайнер мог передавать в разработку не статичные исходники или прототипы, собранные в сторонних приложениях, а готовый код. До того момента, как появились Angular-компоненты, для сложных прототипов я продвигал программу Framer, каждую неделю готовил лекции, рассказывал о принципах и тонкостях работы с Coffee Script. Несмотря на потраченные усилия Framer не прижился по нескольким причинам:

• Низкий порог входа только на начальном этапе.
• Высокий порог входа, если нужно сделать что-то сложнее перелистывания экранов.
• Песочница — код нельзя передать разработчикам.
• Неоправданно долго.

От Framer мы полностью не отказались и изредка собираем в нем шоты для веб-портала Dribbble. Забиваем гвозди микроскопом, да.

Сейчас, в отделе, мы только начинаем делать первые шаги к коду и не заставляем дизайнеров верстать или учить JS, но даем такую возможность. Возможность расти и развиваться, лучше понимать разработчиков и говорить с ними на одном языке.

Заключение

Конечно, мы только в начале пути, но первые результаты не заставили себя долго ждать. Помимо внедрения новых инструментов, оптимизации процессов и ускорения работы удалось оздоровить коммуникацию не только внутри отдела, но и между командами. Мы стали чаще договариваться, обсуждать и принимать совместные решения, получили прозрачный и понятный workflow, который легко масштабировать и добавили еще один вектор развития для дизайнеров в виде работы с кодом.

Несмотря на первые успехи и маленькие победы, задач и проблем которые нужно решить еще очень много. Мы ежедневно тестируем заложенные решения, описываем правила и закладываем базовые принципы, чтобы сделать процесс работы еще более прозрачным и комфортным.

Мы всегда рады опытным дизайнерам. Если вы такой, напишите мне на почту: sergey.nikishkin@acronis.com.

Список ссылок

#дизайн

©  vc.ru