Ясное доведение изменений до людей с помощью систем

№3 из 6 в серии Releasing Design Systems:
Выходы | Каденция | Версии | Взлом | Зависимости | Процесс

По мере изменения системы ее пользователи захотят воспользоваться преимуществами нового.

«Давайте обновим старую Карту новой блестящей Карточкой», - говорят они. Или, что опасно: «Давайте поместим эту новую кнопку на страницу вместе со всеми старыми».

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

Настолько ли чувствительны дизайнеры к изменениям при работе с таким инструментом, как Sketch? Не так сильно. Они заменяют это тем. Сюда идет новая кнопка, не зная, что старые кнопки используются где-то еще на той или другой странице. Разработчики стремительно выпускают обновления, не указывая ни версию компонента, ни аннотацию обновления по сравнению с тем, что написано сегодня. Возникает трение:

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

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

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

Определить как версию очень просто (используйте SemVer!). Однако определить, что является версионным - по библиотеке или по компоненту, - сложнее. Управление версиями показывает, как все меняется от запуска до прекращения поддержки и окончания срока службы. В этой статье мы пройдем через цикл изменений выходных данных системы: кода, токенов, ресурсов дизайна и документации.

Как версию? Начать с SemVer

Каждое обсуждение выходных данных системы управления версиями начинается и заканчивается отраслевым стандартом Семантическое управление версиями (SemVer).

Версии SemVer в формате MAJOR.MINOR.PATCH, каждая с приращением:

  • MAJOR версия на несовместимые изменения API (то есть что-то ломается),
  • MINOR версия для добавления функций с обратной совместимостью, и
  • PATCH версия для исправлений ошибок с обратной совместимостью.

Daniel O’Connor, AtlassKit Atlassian и Morningstar’s Design System предлагают полезные более подробные примеры, описывающие приложение SemVer к системным функциям.

Управление версиями, давно являющееся отраслевым стандартом управления версиями, становится все более актуальным и в инструментах проектирования. Многие системные команды применяют SemVer к библиотекам символов Sketch в программных инструментах, таких как Abstract и Invision DSM. Вы можете ознакомиться с методологией на http://www.semver.org.

Вывод: настоятельно рекомендуйте дизайнерам изучать SemVer. Это не только поможет им более эффективно общаться с инженерами, но и станет более значимым в сотрудничестве между дизайнерами. Он меняет жизнь!

Что делать в версии? Библиотека или функции внутри

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

Версионирование библиотеки

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

library 1.4.0
├─ visual style
└─ components
   ├─ button
   ├─ button group
   ├─ card
   ├─ checkbox
   ├─ radio button
   └─ ...

Если какой-либо компонент добавляет функцию обратной совместимости, тогда вся библиотека увеличивает младшую версию с 1.4.0 до 1.5.0. Точно так же, если какой-либо компонент имеет критическое изменение, вся библиотека увеличивает старший номер с 1.4.0 до 2.0.0.

Управление версиями «по библиотеке» - это вариант комментариев для команд, разрабатывающих стандартные HTML и CSS. Усыновители обычно интегрируют разметку и стиль в свое приложение и ссылаются на коллективно скомпилированный CSS-код библиотеки, например core.css.

Невозможно включить core.css из 2 или более версий без конфликтов CSS. Единственный способ сделать это - если система поддерживает файлы CSS с пространством имен и в разных версиях. Я не видел, чтобы система так делала. Вместо этого все они работают следующим образом: Хотите кнопку из версии библиотеки 1.4.0? Затем каждый компонент на этой странице должен использовать библиотеку version1.4.0. Иначе все может сломаться.

Управление версиями по компонентам

Управление версиями «по компонентам» позволяет принимающим командам смешивать и сопоставлять версию кнопки 5.3.1 с флажком формы 3.1.0 и переключателем 1.1.0 на одной странице.

library
├─ visual style
└─ components
   ├─ button       5.3.1
   ├─ button group 2.1.0
   ├─ card         3.7.6
   ├─ checkbox     3.1.0
   ├─ radio button 1.1.0
   └─ ...

Разработчикам не нужно беспокоиться о том, когда каждый из них был выпущен, поскольку разметка HTML, стиль и сценарий инкапсулированы и не будут конфликтовать с другими типами компонентов, включенными на ту же страницу. Это может означать, а может и не означать, что вы можете использовать несколько версий одного компонента одновременно. "Могу ли я включить кнопки 1.7.0 в одну часть страницы вместе с кнопками 1.2.0 и 2.5.0 в другом месте на той же странице?" Зависит от того, как работает библиотека.

Управление версиями по компонентам согласовано для команд, использующих модель непрерывного выпуска и использующих среду JavaScript (React, Vue и т. Д.) Или доставляющих веб-компоненты. Они будут вносить гораздо меньшие изменения более модульно и чаще.

Версии системы с течением времени

SemVer позволяет пользователям распознавать ключевые моменты жизненного цикла системы.

  • Выпуски до версии 1.0.0 (0.1.0, 0.2.0, 0.3.0,…) демонстрируют нестабильную системную архитектуру и набор функций. В последние несколько лет этот период длится от трех до шести месяцев до первого крупного релиза для большинства команд.
  • Первый крупный выпуск. Выпуск, обозначенный 1.0.0, считается стабильным и надежным. Это сделано с помпой, сигнализируя о готовности к массовому внедрению. Последующий 1.x.x период может длиться год или больше для систем с версиями библиотек и короче, если версии выполняются отдельными компонентами.
  • Последующие основные выпуски увеличивают версию до 2.0.0, 3.0.0,…. Это сигнализирует о неисправности интерфейса системы. Внимание и корректировка необходимы по мере обновления команды.

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

Опасность восприятия майора

Обозначение 1.0.0 означает обязательство. Дни вольной нестабильности на ранних этапах развития остались позади.

К сожалению, те, кто не знаком с SemVer, неправильно понимают, что означает переход от 1.13.0 к 2.0.0. Это критическое изменение, но не обязательно новые функции и / или предстоящее дорогостоящее обновление. Это определенно не маркетинговая уловка для привлечения внимания. Но вот как многие это воспринимают.

Запуск критического изменения 2.0.0 может быть таким же простым, как изменение класса system-btn--primary на system-button--primary. Или отказ от способа открытия модальных окон с использованием toggleModal вместо openModal и closeModal. Небольшие изменения API, распространяемые по частям через код адепта, могут быть несложными для аудита и дешевыми для исправления.

Эрик Эллиотт описывает более точный подход к описанию изменений с помощью SemVer с breaking.feature.fix метками. Я согласен, эти ярлыки поясняют уровень изменений. Тем не менее, я буду придерживаться системы, которая хорошо работает, несмотря на неоптимальные ярлыки.

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

Планирование критических изменений

После выпуска основной версии, такой как 2.0.0, мы классифицируем идеи новых функций и запросы клиентов как 3.0.0 или Breaking Change с использованием атрибута версии JIRA. Когда мы фиксируем и планируем выпустить 3.0.0 релиз, мы снимаем приоритет с изменений, которые не коснулись новой4.0.0 версии JIRA.

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

Устаревание и прекращение жизни

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

При прекращении поддержки функции учитывайте текущее использование:

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

Когда функция готова к прекращению поддержки, следуйте четко определенному процессу. Документ управления версиями Atlaskit описывает простой процесс:

  1. Сообщайте о намерениях через обычные каналы. Рассмотрим сообщение в блоге.
  2. Выберите график.
  3. Добавьте уведомление в документы.
  4. Выполните команды в репозитории для каждого пакета.
  5. Пообщайтесь в последний раз.
  6. Удалите его из репозитория!

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

На нашей платформе команды создают огромные решения стоимостью в миллионы долларов и уходят прочь. Если мы изменимся, а они не узнают, они действительно расстроятся. Наше сообщение? Мы дадим вам 18 месяцев на то, чтобы отреагировать ».
- Брэндон Ферруа, Salesforce Lightning

Как долго это достаточно долго? Salesforce поддерживает широкую базу разрозненных команд, поэтому сроки ясны и долгие: 18 месяцев. Origami от Financial Times работает с более тесным сообществом разработчиков, что позволяет использовать сжатый период от 3 до 6 месяцев.

Новая функция может существовать рядом со старой. Morningstar расширила компонент уведомлений в 1.9.0 новыми функциями, нарушив при этом API. В течение шести месяцев до 2.0.0 система предлагала как новое «расширенное» уведомление (страница документации по умолчанию), так и устаревшее уведомление (на отдельной странице), связывая их во вводном сообщении.

Salesforce Lightning поддерживает две версии компонента пути.

Мы создали v1 Path, потом… изменился весь дизайн. Неудивительно, что существующий API не работал с новыми приборами. Итак, мы решили отказаться от рекомендаций и в конечном итоге удалить старую версию. Никто не воспользуется этим. Они не могут его найти, код заключен в устаревший миксин, а устаревшие селекторы описаны в метаданных.
- Брэндон Ферруа, Salesforce Lightning

Кодовые практики также могут служить предупреждением. Консоль браузера и терминал могут выдавать предупреждения об устаревании, такие как функция Sass Deprecate в Salesforce UX.

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

Вывод: как только вы перескочите через 1.0.0, установите прогнозируемый период времени для прекращения поддержки функций. Сообщите своему сообществу о предстоящем прекращении поддержки по каналам (код, документация, ресурсы дизайна, объявления).

Согласование версий кода, документации, дизайна и токенов

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

✔︎ Документ версии отдельно от библиотеки, но синхронизировать их

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

  1. Документация кода (реквизиты, классы CSS и т. д.) встроена в файлы кода. Для изменения опечатки в документе требуется выпустить (и увеличить версию) библиотечный код.
  2. Процесс выпуска рассматривает все как монолит. Для более крупных и сложных систем это занимает больше времени и, следовательно, происходит реже.
  3. Инструменты для документации (обычно генератор статических сайтов) переплетаются с тестовыми страницами, что усложняет определение того, является ли дефект ошибкой документа или библиотеки.

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

Следует ли выпускать библиотеку для каждого небольшого изменения документа? Нет. Шаблон UX или описание рабочего процесса могут состоять из страниц, но не содержать кода. Зачем блокировать публикацию до следующего сброса кода и / или увеличивать версию библиотеки для изменения содержимого?

Системные группы, которые я возглавляю, исходят из того, что «сайт документации» (и его содержимое) - это продукт, использующий системную библиотеку. Мы разделяем две кодовые базы.

/doc-site
  /components          ## Doc site-only components
    /code-example-pair
    /do-dont
    /tint-stack
  /docs                ## Doc site content
    /about
    /components
    /contribute
    /getting-started
    /ux-patterns
    /visual-style
/library
  /style               ## Library core style
    /color
    /space
    /typography
  /components          ## Library & testing HTML, CSS, & JS
    /card
    /button
    /icon
    /radio_button

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

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

✔︎ Сохранить документ прошлых версий, по версии

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

Большинство системных документов сайта просто «самое последнее». Но для системы, описывающей кнопку v5.2.1, как команда поддерживает использование v2.11.0?

Система дизайна Morningstar публикует последние в .com/ корне и также предлагает доступ ко всем прошлым версиям сайта с документами в предсказуемых подпапках, таких как .com/v1.13.0/. Доступ к каждой версии осуществляется через ссылку Просмотреть документы для каждой записи в истории выпусков. Не менее важно: ссылки на документы являются относительными, поэтому, попав в документы для v1.13.0, вы остаетесь в пределах документов для v1.13.0.

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

✔︎ Выровнять версии ассетов дизайна с кодом

Библиотеки эскизов и другие ресурсы для дизайна - это территория дизайнеров. «Как мы должны их редактировать?» - спрашивает системный дизайнер. «Мы будем размещать последнюю версию в папке на Google Диске, о которой говорят все». они часто отвечают. Неплохо, но мало.

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

Какая версия (и) какого (ых) компонента (ов) это? Технически может оказаться, что все на странице должно быть из одной и той же версии системы. Смешение дизайнеров и сопоставление версий сводит разработчиков с ума. Это не просто непоследовательно, но технически дорого или невозможно.

Дизайн-система могла бы лучше:

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

Это означает, что без указания версии («Используйте эту последнюю!») Или использования даты последнего обновления (например, System_Sketch_2016_10_31.sketch) должно быть позади. В ресурсах дизайна вы можете указать номер версии в…

… Имя библиотеки символов (или последнее обновление, если версия поддерживается по функциям)…

… Имя символа, особенно если оно находится в иерархии на основе папок…

… Или слой аннотации, особенно если он включен / выключен в иллюстрации.

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

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

✔︎ Рассмотрите возможность управления версиями токенов отдельно от кода

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

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

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

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

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