От автора: реализация адаптивного дизайна 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-подобным языком со своими тегами. Например:
1 |
<mj-text>Your text here</mj-text> |
При компиляции MJML конвертирует свои теги в HTML для всего, начиная от таблиц и заканчивая пользовательскими компонентами, которые они создали для вас. Все с помощью внутреннего движка. Движок берет на себя тяжелую работу по созданию сложной разметки, он протестирован.
У MJML есть ряд стандартных компонентов. Среди них секции, колонки, группы, кнопки, изображения, ссылки социальных сетей (которые очень легко создать), таблицы, аккордеоны и т.д. Есть даже карусель с предварительными стилями, которая должна работать в большинстве клиентов. Все эти компоненты отлично переносятся в адаптивные письма, кроме компонента invoice, который я не смог заставить работать в своих тестах. У всех этих компонентов есть параметры, которые можно передавать в код и настраивать их внешний вид.
Например, компонент social links позволяет сложить иконки вертикально и горизонтально, а также выбирать фоновый цвет иконок. На самом деле параметров, с которыми можно поиграться и которые придают гибкость, гораздо больше. В пакет даже включены файлы логотипов, что огромный плюс.
Предпросмотр простой конфигурации компонента social links:
Можно создать свои компоненты или использовать компоненты, созданные сообществом. На данный момент доступен всего 1 компонент от сообщества.
MJML автоматически обрабатывает адаптивность. То есть компоненты будут переключаться с нескольких колонок (больше элементов в одной строке) до одной колонки (элементы расположены один под другим, а не рядом) без активного вмешательства разработчика. Это очень гибкое решение, которое отлично работает в большинстве случаев. Но разработчик немного теряет контроль над происходящим в шаблоне. Как отмечено в документации, стоит помнить, что:
«Для красоты MJML сейчас поддерживает максимум 4 колонки на секцию.»
Скорее, это больше не красота, а ограничение возможных недостатков при большом количестве колонок. Мне кажется, чем больше колонок, тем менее предсказуем результат.
Как работать с MJML
MJML может работать как командная строка, которую можно установить через npm. Фреймворк может выводить файлы локально с помощью команды:
1 |
$ mjml -r index.mjml -o index.html |
Это можно интегрировать в процедуру построения билда через Gulp или что-то похожее, а также в разработку через команду watch, которая будет обновлять превью при каждом сохранении:
1 |
$ 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=»//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
Источник: //css-tricks.com/
Редакция: Команда webformyself.