Главная » Статьи » Выбор адаптивного email фреймворка: MJML или Foundation for Emails

Выбор адаптивного email фреймворка: MJML или Foundation for Emails

Выбор адаптивного email фреймворка: MJML или Foundation for Emails

От автора: реализация адаптивного дизайна email может затянуться. Строить адаптивный email вообще не просто. Это как вернуться на машине времени в 2001, когда все макеты сайтов строились из таблиц с помощью Dreamweaver и Fireworks. Но есть надежда! Нам доступны инструменты, которые сильно упрощают создание email и больше похожи на программирование современных сайтов. Давайте рассмотрим несколько разных фреймворков, которые решили упростить нам жизнь.

Сначала ситуация

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

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

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

Тем не менее, конечные пользователи и клиенты, привыкшие к «обычному» браузерному вебу, могут хотеть, чтобы просмотр почты был на таком же высоком уровне с точки зрения графики и адаптивности, как и веб-страницы. Поэтому ожидается сложный дизайн: много колонок, разное поведение на мобильных устройствах и десктопе, много изображений и т.д. Все изображения должны быть единообразными и pixel-perfect на всех email клиентах. Как это все можно реализовать?

Вариант 1: написать с нуля

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

Реализуется очень простой дизайн.

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

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

У вас много времени.

Очевидно, что нужно тщательно протестировать дизайн. У Campaign Monitor есть замечательное руководство по CSS, на которое можно ссылаться во время создания. Это как Can I Use, только для email. Далее рекомендую использовать автоматизированные тест сьюты типа Litmus или Email на Acid. Оба инструмента предлагают завершенные тестовые сьюты и предварительный просмотр того, как будет выглядеть ваше письмо в огромном разнообразии клиентов email. Но ждите сюрпризов, потому что часто при просмотре в разных браузерах или ОС один и тот же дизайн в одном клиенте отображается по-разному. Шрифты рендерятся по-другому, меняются margin и т.д.

Вариант 2: используйте шаблон

Другой вариант – использовать один из шаблонов. Можно взять у Sean Powelll по ссылке. Шаблоны решают множество глюков разных email клиентов и платформ. Вариант подходит, если:

Вы работаете один или в маленькой команде

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

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

Вы хотите контролировать весь код и не любите использовать сторонние инструменты.

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

Вариант 3: используйте фреймворк

Если вам подходят следующие утверждения:

Вам придется создать много шаблонов email с общими компонентами.

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

Вы слабо или вообще не контролируете оригинальный дизайн.

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

Сейчас доступны 2 самых интересных и популярных фреймворка MJML и Foundation для Emails. Самое большое преимущество использовать один из них заключается в том, что они уже решили большую часть глюков email клиентов. У них есть заданный рабочий процесс, которому можно следовать одному или командой. Хотя и по-разному, но они очень хорошо работают с адаптивным дизайном.

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

MJML

MJML – внутренний проект Mailjet, компании, специализирующейся на инструментах email маркетинга. Проект open source, работает с собственным HTML-подобным языком со своими тегами. Например:

<mj-text>Your text here</mj-text>

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

У MJML есть ряд стандартных компонентов. Среди них секции, колонки, группы, кнопки, изображения, ссылки социальных сетей (которые очень легко создать), таблицы, аккордеоны и т.д. Есть даже карусель с предварительными стилями, которая должна работать в большинстве клиентов. Все эти компоненты отлично переносятся в адаптивные письма, кроме компонента invoice, который я не смог заставить работать в своих тестах. У всех этих компонентов есть параметры, которые можно передавать в код и настраивать их внешний вид.

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

Предпросмотр простой конфигурации компонента social links:

Можно создать свои компоненты или использовать компоненты, созданные сообществом. На данный момент доступен всего 1 компонент от сообщества.

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

«Для красоты MJML сейчас поддерживает максимум 4 колонки на секцию.»

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

Как работать с MJML

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

$ mjml -r index.mjml -o index.html

Это можно интегрировать в процедуру построения билда через Gulp или что-то похожее, а также в разработку через команду watch, которая будет обновлять превью при каждом сохранении:

$ mjml --watch index.mjml -o index.html

У MJML есть плагины для Atom и Sublime Text. В Atom даже есть реальное превью макета, который можно сгенерировать заново при каждом сохранении. Лично не пробовал, но это очень интересно:

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

Скриншоты работы превью:

Это приложение можно интегрировать с бесплатным профилем Mailjet, который позволяет мгновенно отправлять письма самому себе. Очень удобно для быстрого решения проблем клиентов, если они доступны вам напрямую. (я предложил бы проверять письмо в Outlook на той старой машине на Windows, которая стоит в хранилище, и делать это почаще.)

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

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

Преимущества

Встроенные компоненты

Интеграция с Mailjet

Легкий в использовании с мгновенным превью (на Atom и Desktop App)

Недостатки

Чуть менее надежный, чем Foundation для Emails, если необходим дизайн pixel-perfect

У некоторых компонентов есть параметры, работающие не так, как описано

Desktop App нестабильное

Нет структуры папок для контента (см. Foundation ниже)

Foundation for Emails

Foundation for Emails (ранее известен как lnk) – это фреймворк от компании Zurb, тех же ребят, что подарили нам адаптивный front end фреймворк Foundation for Sites.

При загрузке Starter Kit вы получаете полное окружение для разработки с командами Node.js для запуска проекта. Это настроит Node и даже откроет браузер для просмотра своей работы.

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

Foundation for Emails идет с шаблоном – это отправная точка вашего кода. Шаблон полностью прокомментирован, чтобы вы знали, как расширить его своим кодом. Он поддерживает SASS/SCSS, что крайне удобно для сложных проектов. У фреймворка свой инлайнер, вам не нужно будет думать о конвертировании всего CSS (или SASS/SCSS) в инлайн стили.

За фреймворком стоит движок шаблонов Inky. Как у MJML, у него есть свои теги, которые автоматически конвертируются в HTML при компиляции. Есть теги типа container, row, column, с помощью которых будет создаваться своя сетка. Сетка основана на системе 12 колонок, что позволяет точно разбивать макет. Почему 12? Потому что число делится на 2, 3, 4 и 6, из-за чего очень легко делать макет из 2, 3, 4 или 6 колонок.

Для компиляции кода Foundation for Emails использует <

a href=»https://foundation.zurb.com/emails/docs/panini.html» target=»_blank»>Panini. Panini – кастомная библиотека, компилирующая HTML страницы, используя макеты. Она поддерживает синтаксис Handlebars. Есть несколько хелперов, с помощью которых можно настроить поведение компонентов в зависимости от места использования. Можно создать свои хелперы и забивать все кастомные переменные шаблона своими данными. Очень полезно, если у вас несколько шаблонов с общими компонентами.

Для загрузки доступно несколько встроенный email шаблонов, которые покрывают множество стандартных случаев использования писем (новостные рассылки и анонсы). Есть несколько встроенных компонентов (со своими тегами), в том числе кнопки, меню и выноски (которые бесполезны в письмах, я должен был это отметить).

Главное отличие Foundation for Emails от MJML в том, что первый по умолчанию настроен на десктоп и затем уменьшается под маленькие экраны. В документации сказано, что так сделано потому, что множество десктоп клиентов не поддерживают медиа запросы и макет для большого экрана лучше совместим в email клиентах. Он управляет только одним брейкпоинтом. Вы создаете десктоп и mobile версию, и мобильная версия переключается на определенном числе пикселей, которое можно настроить.

С помощью удобных встроенных классов .hide-for-large и .show-for-large (хотя .hide-for-large может не поддерживаться ни одним клиентом) вы можете решить, будут ли некоторые компоненты видны только на больших или маленьких экранах. С помощью специальных классов можно указать, сколько пространства будет занимать одна колонка. Например, класс .large-6 и .small-12 на теге div создаст колонку на пол экрана на десктопе и на целый экран на мобильном устройстве. Это позволяет создавать крайне специфичные и предсказуемые макеты.

Foundation for Emails чуть более неуклюжий в использовании, чем MJML, как я думаю. Но с ним вы сильнее контролируете макет. Благодаря этому, он идеально подходит для проектов, где необходим pixel-perfect дизайн с особенными различиями между мобильным и десктоп макетами.

Преимущества

Больше контроля над конечным результатом

Встроенные шаблоны

Поддержка Sass

Отличная документация

Недостатки

Большой вес проекта, занимающий много места на диске

Менее интуитивный в использовании, чем предварительно заданные параметры в компонентах MJML

Для кастомных макетов доступно меньше компонентов

Заключение

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

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

Не буду говорить, что один фреймворк лучше другого. Суть статьи не в этом. Я порекомендую MJML и Foundation for Emails для разных случаев:

MJML для быстрых проектов с гибким дизайном

Foundation for Emails для проектов с супер специфичным дизайном, которым необходим жесткий контроль макета

Автор: Paolo Mioni

Источник: https://css-tricks.com/

Редакция: Команда webformyself.