Road to design system
Работа с UI раньше:
- Тикет с независимыми ссылками figma/zeplin;
- Имплементация.
В чем проблема? Работая по такой схеме мы получили:
- Большое число близких цветов;
- Бесконечное количество текстовых стилей;
- Похожие картинки и иконки по всему проекту;
- Отсутствие какой-либо структуризации в дизайне.
Проблема заключается в том, что отсутствует гибкость решения. Темизация Android приложения в таких условиях потребует огромных ресурсов. Но все можно исправить!
На самом деле – все просто. Отсутствие гибкости – это прямое следствие отсутствия дизайн системы на проекте.
В какой-то момент стало известно, что планируется редизайн. Это могло стать отличным поводом надавить на дизайнеров и запросить дизайн систему. Собственно, так оно и произошло. Что-то может и откидывалось на первых порах, но по итогу мы все же дошли до того максимума, который нам был нужен.
На данный момент дизайн система представлена в виде:
- States & Components. Состояния различных компонент;
- Typography. Перечень всех текстовых стилей, используемых в приложении;
- Colors. Все цвета приложения;
- Icons. Все иконки.
Эти составляющие - как кубики Lego. Нам же, как разработчикам, для реализации теперь необходимо просто правильно сочетать эти кубики между собой и как по инструкции собирать то, что отрисовал дизайнер.
О техническом решении
В арсенале есть два приложения. Весь их новый ui разрабатывается через отдельные ui модули (общие модули). Таким образом, что-то переиспользуется. Например, auth-ui. Для того, чтобы покрасить конкретный модуль в нужные цвета, мы что-то связанное с внешним видом прячем за атрибуты. Это могут быть текстовые стили, цвета, бэкграунды, картинки, иконки и так далее.
Вот атрибуты одного из таких модулей.
И они мне не совсем нравятся по следующей причине: не для всех них очевидно, что и когда применять.
Усложняется все тем, что мы не можем подставить конкретику. Например, мы не можем поменять название roomAdminUiColor1 на что-нибудь с Primary из палитры. Все из-за того, что проекты отличаются дизайн системами.
Нужно как-то абстрагироваться от устройства дизайн системы каждого из приложений.
Решение:
- Единственный способ изменить внешний вид компонента – стиль;
- Чтобы не было пересечений с другой частью приложения, а также с дефолтными стилями из Material Design Components, мы временно, пока полностью не избавимся от старого дизайна, добавляем префиксы / постфиксы;
- Названия стилей не должны раскрывать его внешний вид и должны базироваться на том, как компонент назван в дизайн системе (в идеале);
- Все ресурсы, включая имплементации стилей, находятся внутри каждого из проектов.
Как итог:
- Получаем абстрактные стили. Проекты независимы в области палитр, текстовых стилей и любых других составляющих внешнего вида;
- UI модули не содержат никаких ресурсов;
- Пересечение именований компонентов старого и нового ui исключено вследствие префикса-постфикса.
При имплементации стиля в Paltalk цвета, текстовые стили и иконки не используются напрямую. Они также спрятаны за атрибуты. Такой подход дает преимущества в случае появления новых тем:
- Темная (или любая другая, отличная от оригинальной по палитре) тема. В новой теме просто меняем значения атрибутов цветов на нужные;
- "Тематические" темы (Halloween, Christmas, Easter и так далее). Переопределяем иконки и шрифты под саму тематику.
Более детальная информация, картинки, код, примеры, представлены в выступлении и источниках ниже.
