Любить или оставить? Мнение email-разработчиков о фреймворках для email-рассылок

Потенциально непопулярное мнение: нам в Litmus не нравится использовать общедоступные email-фреймворки.

Да, есть свои плюсы в использовании готовых email-компонентов, за обновление которых отвечает кто-то другой. Многие email-разработчики, например Николь Хикман, разработчик прямого маркетинга в Fishawack Health, ежедневно используют общедоступные фреймворки и довольны ими. Это отличный вариант для многих команд.

Но мы в Litmus не считаем их подходящим решением для каждой команды — и у нас есть на то причины!

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

## Что такое email-фреймворк?

**Email-фреймворк — это набор готовых HTML- и CSS-компонентов, которые email-разработчики используют для создания писем.**

### Два вида email-фреймворков:

**Общедоступные фреймворки**, которые используют препроцессоры для упрощения кодинга за счет автоматизации части процесса (например, Maizzle или MJML).

**Готовые блоки HTML-кода**, которые вы создаете сами (например, дизайн-система email-писем).

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

## Преимущества использования общедоступных email-фреймворков

У фреймворков одна главная цель — упростить разработку писем. Вот три причины, по которым open-source фреймворки так привлекательны для некоторых разработчиков.

### 1. Более быстрое время сборки

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

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

«Как мы все знаем, из-за того, что Outlook для Windows плохо работает с div-блоками, для корректного отображения писем в этой почтовой программе требуются «призрачные таблицы» (ghost tables). MJML создает их за вас, что экономит массу времени на кодинге». И это правда. Фреймворки могут помочь командам, которым не хватает времени. Это отличный способ быстро создавать письма. Затем вы можете загрузить их на платформу тестирования, например Litmus, и исправить возникшие ошибки.

### 2. Не требуется обновление

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

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

Если вы столкнулись с проблемой, вы можете обратиться к сообществу. Slack-канал MJML, подобно сообществу Email Geeks, — это место, где разработчики общаются, учатся, устраняют неполадки и поддерживают друг друга.

### 3. Работает вместе с HTML

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

«Если возникает сценарий, требующий кода вне рамок стандартных тегов MJML, можно легко «дописать свое». Тег очень надежен и принимает все виды пользовательского HTML-кода», — объясняет Хикман.

Она также отмечает, что нет почти ничего, чего *нельзя* было бы сделать с помощью MJML; мнение, что пользователи MJML создают только примитивные макеты, ошибочно.

«Я создавала письма со стилями Dark Mode, использовала технику «псевдо-абсолютного позиционирования», описанную Марком Роббинсом и Стивеном Сайо, интерактивные опросы и многое другое — и все это внутри MJML. Это требует глубокого знания HTML, чтобы реализовать такие техники, как и глубокого знания самого MJML, но все это абсолютно выполнимо в рамках фреймворка», — говорит Хикман.

## Недостатки общедоступных email-фреймворков

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

### 1. Специфический язык фреймворка

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

Это может вызвать вопрос: *«Почему я должен учить другой язык, чтобы делать то, что я и так умею?»* Если вы уверены в своих навыках HTML или не хотите тратить время на изучение новых тегов, фреймворки могут вам не понравиться. Поскольку некоторые элементы требуют знания и HTML, и языка фреймворка, вам придется управлять двумя языками, чтобы использовать инструменты на полную мощность.

### 2. Потеря контроля над кодом

Один из самых заметных минусов — потеря полного доступа и контроля над кодом.

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

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

### 3. «Раздутый» код

Добавление кастомного HTML дает больше контроля, но создает лишнюю работу.

«Если макет для десктопа требует, например, трансформации из трех колонок в две (3×2 > 2×3), то для этого нужен HTML-код. В противном случае по умолчанию будет складываться в одну колонку (3×2 > 1×6)», — говорит Хикман.

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

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

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

## Как создать свой собственный email-фреймворк в виде дизайн-системы

Многие используют общедоступные фреймворки, и они полезны. Мы в Litmus используем собственный фреймворк, интегрировав его в дизайн-систему.

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

## Что такое email-дизайн-система?

**Email-дизайн-система — это набор переиспользуемых компонентов, руководствующихся стандартами, которые команды используют для создания брендовых писем более последовательно и эффективно.** По сути, это email-фреймворк, адаптированный под стилистику вашего бренда. В дополнение к визуальным гайдлайнам, наша дизайн-система содержит два критических компонента: партиалы (partials) и сниппеты (snippets).

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

— Сниппеты автоматически генерируют код для настраиваемых элементов, например кнопки призыва к действию (CTA).

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

Создание собственного фреймворка похоже на создание дизайн-системы. Я создал наш email-фреймворк в процессе разработки дизайн-системы. Фактически, я считаю микро-блоки нашей дизайн-системы нашим email-фреймворком. Они достаточно малы и гибки, чтобы использовать их везде.

*Пример библиотеки дизайна Litmus, используемой как дизайн-система/email-фреймворк*

## Как построить email-дизайн-систему

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

### 1. Стройте постепенно и тестируйте по мере готовности

Создание всей дизайн-системы — задача пугающая. А теперь еще и фреймворк? Ого! Но вам не нужно переделывать весь рабочий процесс за одну ночь.

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

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

### 2. Используйте прошлые письма как основу

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

### 3. Создайте систему отслеживания проблем

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

Я или кто-то из команды заполняем форму при обнаружении проблемы. Затем я могу исправить все ошибки разом. Если это экстренная ситуация — например, ESP перестал поддерживать стили в секции head — я меняю это немедленно. Если это мелкая проблема, например неправильное alt-текст изображения, я исправлю это в конце месяца.

### 4. Храните всё в одном месте с Litmus

Design Library от Litmus дает вам централизованное место для хранения, использования и совместной работы над дизайн-системой. Вместо того чтобы начинать с чистого листа для каждого письма, вы можете использовать шаблоны или добавлять партиалы и сниппеты. После сборки письма вы можете автоматически протестировать его в Litmus и синхронизировать с вашей ESP.