Русский
Русский
English
Статистика
Реклама

Дизайн-системы

Баланс между общим и частным в большой компании консистентность, переиспользование кода и поиск чётких метрик

08.10.2020 12:16:26 | Автор: admin

В Яндексе я руковожу службой общих интерфейсов. О них и поговорим. О том, как трудно (но приходится) делать что-то для всех. Позволю себе аналогию: сидишь, пишешь код и захотел пить. Налил себе сразу три стакана из одной бутылки, даже от клавиатуры не отрываясь. А если, к примеру, бутылка оказалась пустой, можно не пить. И по стаканам не разливать. Но если кто-то другой попросит, то придётся идти, ставить чайник, спрашивать: чай или кофе, чёрный или с молоком, нужен ли сахар, если нужен, то сколько, резать бутерброды Это намного сложнее. А когда задача разработать общие компоненты, всё становится совсем сложно. Но мы попробуем разобраться.

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

Это не всё, что у нас есть, но представление получить можно.Это не всё, что у нас есть, но представление получить можно.

Консистентность: плюсы и минусы

+ Пользовательский опыт

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

+ Экономия при разработке

Повторное использование это экономия на дизайне, реализации и дальнейшей поддержке. Но, к сожалению, у него есть дополнительная цена.

- Время поставки до пользователей

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

- Гибкость

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

- Продуктовые метрики

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

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

Часть проблем консистентности это баги. Их находят, исправляют и делают так, чтобы одинаковые сущности вели себя одинаково.

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

Загадочная метрика консистентности

Ключевые сервисы Яндекса обвешаны метриками сверху донизу, но нам пока не удалось найти способ точно посчитать, в каких случаях стоит прикладывать усилия ради единообразия.

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

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

Повторное использование кода

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

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

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

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

Метрика повторного использования

Давайте попробуем найти метрику для оценки успешности библиотеки с универсальными компонентами. Мы в работе используем разные критерии:

  1. Количество скачиваний (как в npm).

  2. Посещаемость сайта с документацией чем выше, тем активнее пользуются библиотекой.

  3. Процент пользователей общей библиотеки от количества фронтендеров в компании.

  4. Процент пользователей на upstream. Кто-то обновляется регулярно, а кто-то однажды подключил библиотеку и с тех пор не получает никаких обновлений.

  5. Количество используемых компонентов из библиотеки. Некоторые разработчики берут только логотип, а другие полный набор.

  6. Количество показов конечным сервисам. Одно дело, когда компонент используется парой человек во внутренней админке, и совсем другое в результатах поисковой выдачи для десятков миллионов пользователей в день.

  7. Ускорение процесса разработки.

  8. Применимость инфраструктуры общей библиотеки для нужд других команд.

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

Универсальный компонент vs. локальные фичи

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

Формула для подсчёта окупаемости общих компонентов.Формула для подсчёта окупаемости общих компонентов.

Разберём формулу: умножаем количество внедрений (подразумевается количество сервисов, где будет использован компонент) на среднюю стоимость разработки того же компонента на любом из сервисов. Делим произведение на количество внедрений (совпадает с тем, что в числителе), умноженное на стоимость внедрения. Так мы учитываем разницу между стоимостью программирования кнопки и внедрением из библиотеки. Добавляем стоимость унификации усилия на то, чтобы вместо конкретной кнопки получить общую:

  • время на написание кода,

  • создание и публикация документации и примеров,

  • обучение пользователей.

Пример расчёта для компонента, который используют три сервиса.Пример расчёта для компонента, который используют три сервиса.

Попробуем проверить. Например, есть три проекта, которым нужен одинаковый компонент. Стоимость разработки пять дней. Пусть стоимость внедрения будет два дня. При этом стоимость унификации в три раза выше, чем у конкретного решения в сервисе. C такими вводными делать общий компонент невыгодно (тут мы не учитываем профит от унификации дизайна).

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

Давайте перейдём от абстрактных примеров к реальным компонентам, которые мы разрабатываем в opensource-пакете @yandex/ui.

Реализация ссылок в Яндексе.Реализация ссылок в Яндексе.

Яндекс у многих ассоциируется с таким списком ссылок. Разумеется, эти ссылки используются и в других сервисах компании. Рассчитаем рентабельность разработки общего компонента для ссылки. Сейчас он внедрён в 104 сервиса. Средняя стоимость разработки такого компонента на отдельном сервисе с запасом один день, стоимость внедрения 2 часа или 0.25 от рабочего дня. Время унификации с учётом написания документации 3 дня.

Считаем выгоду для компонента Link.Считаем выгоду для компонента Link.

Видно, что сделать ссылки универсальными в 3.5 раза выгоднее, чем каждый раз писать с нуля. Хотя, согласитесь, интуитивно казалось, что повторное использование готового компонента на 104 проектах даст больше экономии. Рассмотрим более сложный компонент Select.

Реализация Select в Яндексе.Реализация Select в Яндексе.

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

Считаем выгоду для компонента Select.Считаем выгоду для компонента Select.

И хотя он работает всего на 61 сервисе, видно, что выгода от повторного использования в 11.3 раз выше, чем если бы команды писали компонент самостоятельно. Выгода продолжит расти по мере того, как всё больше сервисов будут внедрять Select. Похоже, мы нашли правильный баланс.

Как же достичь баланса?

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

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

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

Дизайн-система дизайн-систем

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

Изменяя компонент на базовом слое, мы автоматически поставляем его в остальные слои. Именно для создания таких систем разработана методология БЭМ. Для реализации визуальной части есть Whitepaper. А недавно у нас появился themekit, который реализует наследование по слоям для дизайн-токенов.

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

Монорепозиторий

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

  • Canary

    У нас есть возможность выпускать canary-версии общих библиотек с компонентами и сразу проверять, что тесты сервисов не ломаются. Так, ещё на этапе пул-реквеста будет понятно, что изменения стабильны и ничего не затронули. Или наоборот.

  • Авторелизы

    Доставлять изменения в сервисы нужно быстро и дёшево. Без автоматизации править версию во всех зависимостях было бы затруднительно.

  • Умные чейнджлоги

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

А как же технологии?

Проблема более низкого уровня сочетаемость технологий. Почему бы не ввести технофашизм? Выбрать определённые технологии, а остальные запретить. Этот подход кажется логичным, но приведёт к тому, что сервисы перестанут развиваться, не имея свободы пробовать новое.

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

Над балансом придётся поработать.Над балансом придётся поработать.

Выводы и ссылки

Польза от консистентности определённо есть, но мы пока не придумали, как её измерить. Польза от переиспользования кода тоже есть, и она измерима. Однако за ней стоят сложные процессы, которые требуют соблюдения баланса.

О разных подходах к общим компонентам я рассказываю уже давно, и если вам интересна эта тема вот ссылки на другие материалы:

Подробнее..

Архитектура дизайн-системы для нескольких продуктов

10.01.2021 00:06:06 | Автор: admin

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

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

  • Есть несколько продуктов.

  • Один продукт могут делать несколько команд дизайнеров и разработчиков.

  • Есть Web, Mobile и Desktop.

  • Есть много легаси и неконсистентности.

  • Дизайнер в одном продукте может не знать что происходит в другом.

Если будут встречаться технические нюансы, то, прежде всего, подразумевается работа в Figma, но, думаю, что в Sketcha Fernanda все то же самое.

Проблемы существующих подходов к библиотекостроению

С точки зрения дизайнера, хорошая ДС начинается с библиотеки с которой удобно работать.

Опыт разных команд обычно описывается одной из этих схем или их причудливой комбинацией:

Сами же проблемы можно описать следующим образом:

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

  • Библиотека слишком большая. Работая над фичей, дизайнер абстрагируется от перегруженной и сложной библиотеки. Он собирает и детачит компоненты прямо в рабочем файле, надеясь, что однажды они просто перетекут в библиотеку и станут "легальными". Чтож, удачи.

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

  • Это невозможно масштабировать.

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

Принципы и приоритеты

Начать проектирование ДС стоит с формулирования принципов, которые бы исключили приход к чему-то неподходящему. Мне не хотелось изобретать полностью свой велосипед, поэтому многие его детали были позаимствованы у разработки: для дизайн-системы YAGNI и первые две буквы SOLID, а для компонентной базы DRY и KISS.

Принципы это хорошо, но слишком идеализированно. Нужны и приоритеты.

Если нам нужна лучшая конфета, то что важнее, ее шоколадность или вкусность? Конечно же шоколадность, это легко.

Увы, когда пытаешься понять, что важнее для библиотеки, не все ответы столь очевидны.

У нас получилась следующая система весов. Она не полная, но пока решает свои задачи.

  • Управляемость > Консистентность > Кастомность

  • Легкость поддержания > Легкость создания

  • Однозначность > Объем компонентной базы

Уход от зависимостей

Мы решили отказаться от большой-супер-пупер библиотеки, которая обеспечивала нам супер-пупер консистентность.

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

В итоге план действий был следующим:

  1. Складываем в один фигма-файл все наши "консистентные" кнопки, стили, типографику и другие консистентнообразующие элементы. И не подключаем его ни к чему. Теперь это референсная библиотека, на нее можно только смотреть.

  2. Делаем самостоятельные продуктовые библиотеки, наполняя их по образу референсной.

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

Новые правила игры

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

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

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

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

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

Дизайн-система

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

Для каждого компонента на базовом уровне должно быть уже три представления:

  • Компонент в фигме то как он выглядит.

  • Спецификация гайд который рассказывает как компонент работает, где его можно использовать, а где нет и почему.

  • Код.

Все вместе это уже можно считать дизайн-системой на минималках.

Модули

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

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

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

Если посмотреть на всю структуру целиком, то получится такая штука:

Базисов столько же, сколько и продуктов, но все они стараются быть похожими на референс.

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

Что дальше?

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

Подробнее..

Figma плагины для продуктового дизайна. Локальный топчик с видео-инструкцией

25.05.2021 16:13:10 | Автор: admin

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

Номожно накидать локальный местечковый топчик для продуктового дизайнера например. Внём небудет плагинов вдухе смотрите, какая любопытная идея или если вдруг вам когда-нибудь понадобится заменить все картинки нафото Николаса Кейджа. Только ежедневные трудяги. яуверен, этот список будет полезен нетолько UI-дизайнерам исочувствующим. Что-то полезное найдут для себя ивсе остальные фанаты Figma.

В конце статьи будет ссылка на видео-инструкцию.

Иерархия библиотек вOzon

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

Работа внашей команде строится последующей схеме: для каждой Job или User Story мыделаем отдельный файл сэлементарным линейным сценарием. Там мысобираем экраны, пройдя которые пользователь решает свою задачу. Втаких сценариях, конечноже, появляются повторяющиеся паттерны, которые можно переиспользовать вдругих User Story иони достойны переноса вотдельную сценарную библиотеку. Этот подход позволяет нераздувать файлы, держать всю систему под контролем идостаточно свободно вносить правки, затрагивающие множество сценариев.

Сейчас унас вOzon есть несколько типов библиотек:

  • Атомарные токены дизайн-системы.

  • Молекулярные библиотеки сэлементами интерфейса. Изних собираются экраны сценариев.

  • Сценарные библиотеки, вкоторые попадают проектные организмы. Оттуда мыможем централизованно использовать ихвдругих сценариях. Повторюсь, разговор нетолько про сайт ozon.ru компании нашего масштаба имеют огромное количество внутренних продуктов, которые также подчиняются единой дизайн-системе.

Библиотечная иерархияБиблиотечная иерархия

Рабочие лошадки иудобные пони

Нохватит зауми! Вперёд кхит-параду. Ида, тут будут представлены иплатные сокровища, ночто значат деньги, когда дело касается Продукта иПродуктивности.

Master

Community

Этот плагин достоин носить джедайское звание Мастер. Сложно переоценить, сколько времени онсэкономил нашей команде. Яуже рассказывал онём насвоём YouTube-канале, асегодня подчеркну его полезность для продуктовой работы. Мало того, что онумеет перелинковывать инстансы кновому мастер-компоненту, сохраняя все оверрайды, так онещё может делать это сбиблиотечными компонентами.

Тут унас типичная ситуация. Форма собрана измолекулярных библиотечных компонентов. Спроектированы разные её состояния. Становится понятно, что она достойна быть добавленной всценарную библиотеку. Если делать это штатными средствами, придётся перенастраивать кучу экранов. Ноунас есть Master.

Копируем одну изформ ивставляем её всценарную библиотеку. Делаем компонент ипубликуем. Запускаем команду Pick Target Component изарсенала плагина Master. Возвращаемся вфайл сценария ивыделяем все наши формы. Запускаем команду Link Objects toTarget Component.

Дапребудет стобой сила, Master!

Design System Organizer

Community

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

Тут унас локальные цветовые итипографские стили. Надо привязать ихктакимже библиотечным. Идём вбиблиотеку изапускаемDSO. Заходим вцветовые стили, выделяем нужную группу ивыбираем извыпадающего меню Set AsTarget. Возвращаемся внаш файл, запускаем DSO ивыбираем Relink Styles. Бум! Стили теперь тянуться изкомандной библиотеки. Такимже образом перелинковываем другие стили или компоненты.

Style Organizer

Community

Этот штепсель помогает неударять вгрязь лицом перед разработчиками. Проверяем, откуда тянутся стили. Ловим нестильные шейпы итексты. Чиним вручном или автоматическом режиме. Соответствуем высоким стандартам разработки Ozon иублажаем личного беса-перфекциониста.

Вот тут унас типичная ситуация. Наглазок всё впорядке, нотакли это? Стартуем Style Organizer. Ивидим, что один изчёрных квадратов имеет локальный стиль, второй библиотечный, атретий вообще без стиля. Можно пробежаться посписку ошибок вручном режиме, сшивая стили, аможно нажать Auto Fix Color иStyle Organizer будет действоватьсам.

Similayer

Community

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

Давайте выделим слово Zen синего цвета, вне зависимости отстиля текста. Выделяем один синий Zen изапускаем Similayer. Выбираем параметры Fill Style иText Characters.

Удобненько!

Instance Finder

Community

Ищет ивыделяет только инстансы. Зато делает это шустрее Similayer иработает повсему документу, анепоодной странице.

Выделяем мастер или любой изинстансов изапускаем поиск. Можно сразу выделить все найденные настранице инстансы.

Select Layers

Community

Ещё один незаменимыйвыделятель. Чаще всего ловлю им слои по названию (он поддерживает частичное вхождение запроса). В отличииотSimilayer, SelectLayersне требует выделять образец для поиска соответствия и, что крайне важно, может искать только в выделенном.

Вот тут унас мега-вариант инпута. Выделяем поля пароля изапускаем плагин. Пишем название нужного слоя ивуаля! Можем поменять иконку, например.

Sorter

Community

Часто возникает необходимость пронумеровать экраны. Чтобы цифры шли попорядку, фреймы должны быть внужной последовательности впанели слоёв. Sorter может отсортировать ихпоположению налисте (инетолько). После чего ихможно переименовать штатными средствами.

Если попытаться пронумеровать экраны, нерасставив ихвпанели слоёв, получим хаос. Нуок. Выделяем все экраны, запускаем команду Sort Position ипосле этого уже штатный Rename Selection.

Порядочек.

Quantizer

Community

Расставляет элементы всетку сзаданным количеством колонок иотступами. Сильно помогает вработе над вариантами.

Выделяем, что нужно, истартуем Quantizer. Сделаем колонки сотступами по40px.

Кстати, вызнали, что можно таскать объекты всетке закруглые маркеры вцентре? Аменять отступ, хватаясь замаркеры между? Если делать это сShift, шаг будет кратен вашему Nudge Amount.

Swap

Community

Плагин, достойный горячей клавиши. Меняет между собой два любых объекта. Выставляет покоординатам верхнего левого угла.

Выделяем два объекта, запускаем команду Swap и, собственно, всё.

Layer Counter

Community

Карманный бухгалтер для ваших макетов. Подсчитает всё ився. Выделяем, запускаем. Наслаждаемся статистикой.

Если снять галку Include Nested Layers, увидим только количество выделенных фреймов.

Retextifier

Community

Может массово заменять текст ввыделенных блоках. Ноесть досадный недочёт при работе вWindows лишний перевод строки, скоторым можно бороться внешними средствами, заменив символ \n на\r или прогнав текст через сам плагин.

Замечательный инструмент, если умеешь импользоваться иутебя macOS.

НаmacOS: копируем текст, например, колонку изGoogle-таблицы. Выделяем целевые текстовые слои изапускаем плагин. Вставляем текст комбинацией Cmd+Shift+V.

Если увас Windows, действуем немного сложнее. Сначала вставляем скопированный текст вфайл Figma. Выделяем его, запускаем Retextifier, копируем итутже вставляем текст, жмём Change. Копируем изменённый текст, далее действуем как наmacOS. Надеюсь, автор плагина что-то придумает поповоду этого недоразумения.

Copy and Paste Text

Community

Вотличие отпредыдущего, этот плагин вставляет вовсе выделенные слои одинаковый текст избуфера. Безусловно полезно.

Копируем нужный текст, выделяем целевые слои, запускаем команду Paste Text

Find & Replace

Community

Поиск изамена потекстовым слоям споддержкой регулярных выражений (Regex). Для тех, кто умеет врегулярки ипонимает, как это круто.

Сейчас мыпоменяем местами буквы ицифры. Запускаем плагин, включаем поддержку Regex ипишем регулярное выражение. Найти (.*)-(.*) изаменить на$2-$1.

Мистика!

Nisa Text Splitter

Community

Разрезает текстовый блок настроки, сортирует, сшивает, расставляет буллиты имногое другое. Рекомендую.

Давайте расставим фильмы похронологии. Запускаем Nisa Text Splitter ирежем наш блок настрочки. Сортируем поалфавиту Sort byalphabet исшиваем обратно водин блок Join text. Внутри плагина ещё много другой годноты. Например, сразу делать Auto Layout изнарезанного текста.

Change Text to Layer Name

Community

Несамый необходимый штепсель, ночастенько выручает. Меняет текст наназвание слоя. Использую всвязке соштатным Rename Selection.

Выделяем текстовые блоки, применяем Rename Selection, оставляем старое название, добавляем кнему дефис иномер. Запускаем команду Change Text toLayer Name.

Математично!

Data Roulette

Community

Когда работаешь над продуктом, утебя есть постоянно используемые наборы данных. Эти наборы накапливаются икочуют изпродукта впродукт. Data Roulette позволяет хранить ихвGoogle-таблицах ирандомно заполнять ими макеты. Итекстами, ифотками.

Делаем Google-таблицу. Линк нанеё добавляем вData Roulette. Называем целевые слои всоответствии сназваниями колонок таблицы поставив вначало решётку. Можно сделать это вмастер-компоненте. Помере необходимости добавляем вGoogle-таблицу новые колонки.

Рулетка рулит!

Content Reel

Community

Для того, кому лень возиться сGoogle-таблицами, Microsoft наплагинил Content Reel. Только нужно залогиниться. Тогда можно будет создавать свои наборы данных.

Тут всё просто. Выделяем целевые слои, выбираем свой или чужой набор данных, вставляем.

Copypasta

Community

Очень часто нужно что-то добавить навсе экраны сценария. Водно итоже место. ИCopypasta прекрасно решает эту задачку.

Выделяем нужную деталь, запускаем Copypasta, жмём Save selection, выбираем целевые экраны, Duplicate Layers.

Шикарно.

Safely Delete Components

Community

Как ярассказал вначале, мыстараемся неоставлять локальных компонентов врабочем файле сценария. Всё должно тянуться избиблиотек. Заканчивая работу, нужно подчистить засобой.

Safely Delete Components удаляет неиспользуемые мастер-компоненты. Ноэтот плагин нужно использовать состорожностью. Нестоит запускать его вбиблиотеках.

После переноса компонентов всценарную библиотеку, выделяем компоненты локальные изапускаем Safe Delete.

SBOL-Typograph

Community

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

Божечки-Ёжечки!

Хорошо, ногдеже тот самый плагин?

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

Всем удачи напродуктовом фронте!

P.S.: Видео-версию статьи можете посмотреть намоём YouTube-канале.

P.P.S.: Ясерьёзно про комментарии.

Подробнее..

Сколько цветов нужно, чтобы было норм, как эти цвета назвать и как ими пользоваться?

19.03.2021 02:12:40 | Автор: admin

Рассказываю о небольшом цветовом фреймворке, который используется в нашей ДС. Сначала, как обычно, небольшой обзор бест-практисов, а затем мой велосипед. Пойдем по порядку.

Сколько нужно цветов

У нас "Заказчиками" цветов являются продуктовый дизайнер, маркетинг и разработка.

Что нужно для счастья простому дизайнеру?

Что нужно маркетингу?

Что нужно разработке?

Окей, а сколько оттенков каждого из цветов нужно? Не самый простой вопрос, между прочим.

Способ 1

Чтобы сделать один раз и хватило, обычно делают так:

Изменяя яркость и/или насыщенность с каким-либо шагом (он может быть динамическим), генерируется набор из примерно десяти оттенков каждого цвета. Два-три варианта будут использоваться часто, а остальные будут не очень часто.

Чтобы как-то проще ориентироваться какие оттенки используются только в самых красивых макетах, а какие постоянно можно сделать так:

Способ 2

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

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

Ну или наоборот, что тоже не ок:

У нас уже есть отличный брендовый красный, который мы используем для всего, почему бы не использовать его и для ошибок тоже, зачем нам еще один красный?

Совет для самураев, выбравших этот путь

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

Способ 3

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

Именуется это как-то так
Color name / DefaultColor name / HoverColor name / Disabled

Описанное выше есть в том или ином виде в любом проекте. Дальше мой велосипед.

Фреймворк

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

Я разделил набор цветов на 2 части:

Основная часть одинаковая для всех продуктов. Чай.

  • Base палитра серого;

  • BG фон;

  • Functional для всяких функциональных штук вроде ссылок и ошибок.

Дополнительная уникальная надстройка для продукта. Сахар.

  • Brand цвета бренда, используемые в продукте;

  • Promo акцентные цвета для всяких промо-историй.

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

Семантика

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

Для серого оказалось достаточно четырех степеней важности.

Для фона двух.

Цвета для всяких функциональных штук одинаково важны, их разделил по назначению, а не по важности.

Бренд.

У промо-цветов тоже нет каких-либо приоритетов, только названия: желтый, зеленый и т. д.

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

Сдвиги

Сдвиги небольшие отклонения от основного цвета.

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

Градиенты

Для каждого цвета может быть градиент, построенный на его основе, а может и не быть. А может быть только градиент, из которого можно будет получить базовый цвет.

Инверсии

У нас нет темной темы, но часто появляется потребность разместить что-то на контрастном фоне. Например, бахнуть текст не на белом фоне экрана, а на темно-синем банере. Или, вдруг, на одном из экранов использовать не белые карточки на сером фоне, а черные на черном. Для этого используются "инвертированные" версии цветов.

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

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

Нейминг

В фигме структура следующая:

Часть фреймворка / Тип / Группа_Модификатор группы / ИмяTea / Solid / Base / Primary_Inverted / Default Sugar / Gradient / Brand / Secondary / Up

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


Идея со сдвигами была подсмотрена в цветовой схеме Opium.Fill.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru