Преимущества атомарного дизайна для цифровой трансформации

Фон

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

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

Общий язык для всех

Если вам интересно, что это за методология, прочитайте мою статью об анатомии атомарного дизайна.

Анатомия атомарного дизайна и цифровая трансформация
Разрушение веб-дизайна на молекулярном уровне!medium.com

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

Давайте начнем с того, кто является основными людьми, тесно вовлеченными в создание пользовательских интерфейсов:

UX-дизайнеры
Дизайнеры пользовательского интерфейса
Фронтенд-разработчики
Бизнес-аналитики
Руководитель проекта
Менеджер по продукту
Клиент

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

Сколько времени потребуется, чтобы добавить новую функцию или страницу?
Разработанный компонент будет отображаться по-другому, могу ли я изменить его?
Сколько раз такие компоненты, как кнопки и формы, созданные для одной страницы, будут использоваться где-то еще?
Со сколькими различными состояниями нам нужно работать в этом компоненте? то есть кнопки, например, первичный, вторичный и третичный
Какое количество страниц мы обязались предоставить?
Сколько компонентов нам нужно создать?

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

Оценки могут быть оправданы

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

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

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

Мы можем основываться на следующем:

Y количество времени/баллов для создания HTML
Z количество времени/баллов для написания CSS
T количество времени/баллов для тестирования
U количество времени/баллов на проверку кода
V количество времени/баллов для развертывания

Самое главное, почему легче всего оценить атомы и молекулы? Ну, это то, как компоненты Front-End поставляются с такими библиотеками, как React.js или Vue.js.

Как вы помните, главный блокировщик в проекте — это отсутствие нужных данных. Однако атомы и молекулы можно считать компонентами, которые не имеют состояния (в этом контексте мы имеем в виду, что сами компоненты не содержат никаких данных, предназначенных для пользователя, если им нужен текстовый контент или изображения, они будут получать их из API или общедоступного URL-адреса). Это означает, что мы можем создать компонент в кодовой базе без каких-либо реальных данных или страниц, а затем использовать такой инструмент, как Storybook, для отображения компонента в браузере.

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

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

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

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

Дизайнеры + Разработчики = Друзья

Как разработчик, вы когда-нибудь сталкивались с дизайном, который трудно найти в браузере? Или как дизайнер, вы когда-нибудь видели, чтобы дизайн выглядел иначе в браузере после того, как он был закодирован?

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

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

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

Идея Atomic Design состоит в том, чтобы разрушить этот каскадный процесс и заставить обе команды сотрудничать на раннем этапе, чтобы сформировать ожидания конечного результата. Дизайнеры могут извлечь выгоду из настройки своих проектов атомарным способом, потому что разработчики могут легко спросить о конкретном компоненте о том, как они будут к нему подходить. Также с точки зрения дизайнера часто бывает приятно увидеть, как дизайн выглядит в реальной жизни. Ожидание готовности всей страницы займет время, а ожидание окончательной версии кнопки — нет. Таким образом, они могут заранее изучить ошибки и улучшения, прежде чем все приложение будет выпущено с недостатками дизайна, которых можно было бы избежать в начале.

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

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

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

Прямо к делу ежедневные стендапы

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

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

Трудно прогрессировать без плана

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

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

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

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

Масштабируемость

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

Этого не должно быть.

Основная цель атомарного дизайна — думать о разделах пользовательского интерфейса как о блоках. То, что было сделано в одном приложении, можно переиспользовать в совершенно новом. Как дизайнер, вы можете сэкономить время, работая на уровне страницы с руководством по существующим атомам и молекулам. Разработчики экономят время, не написав код для основных компонентов, и переходят сразу к кодированию сложных организмов. У руководителей проектов будет больше времени для работы, поскольку они будут знать, что интеграция атома X и молекулы Y в организм Z для шаблона A занимает 14 часов работы. Благодаря идее повторного использования это решает наиболее распространенную проблему в пользовательских интерфейсах — несогласованность.

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

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

Наконец-то немного технических подробностей о…

CMS (системы управления контентом)

Когда мы говорим о контенте, часто имеем дело с CMS. Системы управления контентом бывают разных форм и размеров, и здесь определения шаблонов и страниц различаются в зависимости от выбранной CMS. Не вдаваясь в подробности того, как и почему мы используем CMS, часто в них определяются страницы. Безголовые CMS, такие как Contentful и Storyblok, позволяют пользователям создавать страницы, представленные в формате JSON. В конечном итоге реализация того, как этот контент извлекается, может быть не строго на уровне страницы, а на глобальном уровне, где определяются маршруты/пути страницы. Это может быстро стать очень техническим, но дело в том, что может даже не быть никакого кода для определения страницы, все находится в CMS.

Это также относится и к шаблонам. Возможно, мы разбили наши компоненты до такой степени, что они стали отдельными компонентами, используемыми в самой CMS. CMS, такие как Adobe Experience Manager, Storyblok и другие CMS WYSIWYG (что видишь, то и получишь), позволяют разработчикам вводить компоненты, которые становятся частью редактора, чтобы контент-менеджеры могли их перетаскивать. Это приводит к тому, что контент-менеджеры несут ответственность за создание всех шаблонов из CMS.

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

Стайлинг

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

Хотя что значит стайлинг?

Это означает код CSS (каскадная таблица стилей) компонента. CSS — это язык для управления стилями веб-сайтов и веб-приложений.

Реализация CSS настолько самоуверенна, что существует так много разных методов управления стилем компонентов. Можно пойти по пути использования фреймворков CSS, таких как Tailwind CSS и Bootstrap. Фреймворки обеспечивают гибкость написания практически ничего на CSS, поэтому применять атомарный дизайн несложно.

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

Используйте Styled Components, библиотеку для стилей приложений React, создав отдельный файл в каталоге компонента. Однако в JavaScript это рассматривается как CSS.
Вы по-прежнему можете использовать CSS, но импортировать его с помощью JavaScript.
Вы можете создать отдельный каталог для размещения всего CSS отдельно от кода приложения.

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

Существуют такие методологии, как BEM (модификатор блочных элементов), SMACSS (масштабируемая и модульная архитектура для CSS) и OOCSS (объектно-ориентированный CSS). Эти методологии помогают структурировать код, чтобы его можно было легко прочитать для элементов, которым они принадлежат. Ну это очень краткое изложение.

Я оставлю вам несколько предложений, но вы либо ненавидите CSS в JavaScript, либо любите чистые каталоги. Стиль всегда должен иметь простую ссылку на то, где он используется в компоненте. Лично по опыту, БЭМ лучше всего реализовать. Кривая обучения не крутая, а структура стилей соответствует архитектуре компонентов JS.

Состояние

Когда разработчик говорит о состоянии, он имеет в виду управление памятью, а память — хранение данных в коде приложения. Когда Frontend-разработчик говорит о состоянии, он ссылается на него, как описано выше, но также и в том смысле, как React, Vue или любой другой фреймворк/библиотека определяют состояние как. Это огромная сделка для всех веб-приложений, использующих Atomic Design. На самом деле методология доставки компонентов не меняет способ управления состоянием.

Это чисто решается фреймворком или библиотекой. React и Vue разделяют взгляды на управление состоянием, которые могут храниться в компоненте с хуками или данными. Стандартное управление состоянием прекрасно работает с атомами, молекулами и организмами. Иногда нам нужно обмениваться данными между разными компонентами. Обычно это делается на этапе organism. Мы могли бы использовать что-то вроде Redux или Vuex, чтобы достичь этого, создав глобальное состояние. Хотя часто мы имеем дело с API, поэтому решение об использовании как локального, так и глобального управления состоянием в организмах становится решением.

Однако API-интерфейсы, поставляемые через GraphQL, хорошо работают с атомарным дизайном. Используя Apollo Client, на этапе organism мы можем хранить специфичный для компонента запрос в отдельном файле вместе с файлами другого компонента в его каталоге. Клиент Apollo имеет встроенную функциональность кэширования как средство управления состоянием, что приводит к чистому методу управления глобальным состоянием через запросы, которые легко найти в компоненте.

В целом, управление состоянием в Atomic Design определяется исключительно выбранной технологией и целью приложения. Лучший способ сделать это — применить методы, которые библиотеки и платформы требуют от вас, поскольку они лучше всего подходят для страниц. Для атомов и молекул лучше всего управлять своим состоянием. Организмы часто бывают сложными, поэтому представляют собой гибриды с глобальным и локальным состоянием. Обычно они делают вызовы API, а затем решают, где хранить данные. Шаблоны часто не беспокоятся о состоянии.

Заключение

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

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