[Перевод] UX-команда MailChimp: Разработка [6-я часть книги]
[ 1-я часть книги ][ 2-я часть книги ][ 3-я часть книги ][ 4-я часть книги ][ 5-я часть книги ]
Создание системы адаптивной рассылкиФабио КарнейроСоздание модели адаптивной почтовой рассылки с модульной структурой, которую email-дизайнеры могли бы использовать для обучения и работы, было для нас уникальным по сложности заданием. Несмотря на то, что в библиотеке дизайн-шаблонов рассылки от MailChimp есть огромное количество статей и примеров кода, создание такого уже готового к использованию, работающего кода позволило бы нам объединить всю эту информацию в форме практически полезной референтной модели.
Такой адаптивный шаблон не создавался специально под MailChimp, поэтому мне пришлось работать над ним с учетом самых разных ситуаций, в которых email-дизайнеры могли его использовать. В итоге я сформулировал два тезиса: 1) письма должны создаваться так, чтобы их можно было адаптировать под различные задачи и цели и 2) шаблон должен быть доступным на как можно большем количестве почтовых клиентов.
Достичь доступности использования в разных системах было не так уж сложно. Множество почтовых клиентов просто ужасны, но задача упрощается, как только начинаешь понимать сильные и слабые стороны каждого из них. Это лишь вопрос работы в рамках заданных ограничений.
Требование к возможности подстраивать шаблон под разные задачи было более сложным испытанием. Проектирование и разработка шаблона рассылки для конкретной задачи — вещь довольно простая: можно не ограничивать себя в вопросах дизайна и использовать специализированный HTML-код и CSS для того, чтобы воплотить задуманное в жизнь. Это все потому, что вам известен контекст: вы в курсе, для чего создается письмо, какого рода контент в нем будет представлен, и — в идеале — какими почтовыми клиентами это письмо будет открыто. Но когда вам нужно создать шаблон для того, чтобы с ним могли работать широкие группы людей, цели которых мы далеко не всегда можем заранее описать, такого контекста просто не существует.
Чтобы преодолеть это отсутствие контекста, я решил следовать процессу, подобному тому, который я использовал, чтобы создать шаблоны писем в MailChimp:
Очертите наиболее общий круг вариантов использования рассылки. Для этих вариантов использования создайте дизайн-шаблоны. Разработайте систему независимых объектов в HTML. Дополните полученный код возможностью поддержки разных почтовых клиентов. В коде указывайте комментарии для лучшего его понимания, используйте понятную разметку. И вот как я это сделал: Очертите общий круг вариантов использования
Этот процесс позволяет сформулировать приблизительную идею того, что нужно разработать, и как это сделать.
Практически все электронные письма можно отнести к одной из 4 широких категорий:
«Прочти меня» — это могут быть, например, новостные рассылки, смысл которых состоит в доведении до адресата информации на основе текста или изображений; «Купи меня» — это письма из сферы e-commerce, нацеленные на то, чтобы читатель потратил некоторую сумму; «Присоединись ко мне» — информация о мероприятиях или приглашения, освещающие некоторую активность и содержащие призыв к действию для участия в ней; «Пойми меня» — это письма, отражающие некоторые транзакции, например, чеки или информацию о заказе, и содержащие важные детали и данные и, как правило, ничего больше. В случае создания адаптивного шаблона письма, мне нужно было учитывать все четыре эти сценария.Создайте дизайн-шаблоны
Все эти варианты использования содержат в чем-то пересекающиеся наборы элементов. Например, письма типа «Купи меня», «Присоединись ко мне», «Пойми меня» все могут содержать CTA в форме кнопки, при этом письма типа «Купи меня» и «Прочти меня» базируются на интересном контенте, как правило представленном в виде некоторого количества изображений.
Изучая общие элементы разных групп писем, я начал понимать, как должны выглядеть шаблоны их внешнего вида и в итоге сформулировал список блоков, которые нужно было создать. В итоге в готовую модель вошли 17 различных шаблонов, включая кнопки, группы изображений, подписи, контент, заключенный в блоки, календари и изображения с подписями.
Разработайте систему объектов в HTML
Как только я понял, что именно мне нужно было разрабатывать, я приступил к написанию кода.
Создавая модель, я хотел быть уверенным в том, что любой сможет обратиться к полученному HTML-коду и понять, как он структурирован, использовать нужные дизайн-шаблоны для реализации своих целей, менять стиль письма, не беспокоясь за состояние фреймворка, и сразу же начать использовать полученный результат в email-кампании.
Чтобы соответствовать всем этим требованиям, я написал HTML-код так, чтобы все контент-блоки были одинаково структурированы, а код таким образом можно было легко изучить и понять. Каждый из дизайн-шаблонов для различных видов контента был размещен в отдельной строке таблицы — благодаря этому была достигнута модульная структура итоговой модели. Отдельные элементы стало возможным дублировать или перемещать, просто копируя или перемещая соответствующую строку.
Кроме того, весь проект был построен на минималистичном CSS: всего 4 ruleset’а в стандартном CSS и еще 4 в media query. Помимо этого была использована базовая стилизация самого контента, которая повлияла только на оформление текста и цвет фона. Таким образом, дизайнеры получили возможность написания своего CSS без необходимости ломать голову над влиянием на функциональную составляющую рассылки.
Дополните полученный код
Закончив разработку, я протестировал полученную модель, используя стандартную серию тестов, с помощью браузера и почтового клиента для мобильного устройства. В ходе первого прогона полученное письмо отображалось во всех популярных почтовых клиентах без особых проблем. Однако, моя работа на этом не закончилась: существовали два почтовых клиента, с которыми возникли сложности.
Outlook 2007/2010 и мобильное приложение Gmail для Android — это просто кошмар. С Outlook возникло множество проблем из-за его графического движка на базе Microsoft Word, а приложение Gmail, несмотря на то, что оно — мобильное, не поддерживает media queries. Написание версии письма для Outlook требовало создания очень негибкого, тщательно выверенного кода, а для почтового клиента Gmail нужен был очень «рыхлый» код: неадаптивный, но относительно гибкий.
Обычно мы считаем, что лучше перестраховаться, стараемся сделать нашу рассылку более надежной и учитываем возможность поддержки Outlook — в конце концов, Microsoft железной хваткой держит рынок почтовых приложений для ПК. Но поскольку наша адаптивная модель была задумана для email-дизайнеров, немного разбирающихся в технологиях, я решил встать на противоположную сторону и решил заняться максимальной поддержкой мобильных устройств. Это означало создание множества контент-блоков с использованием выравнивания таблиц. Теперь с приложением Gmail на Android все в порядке.
Вы можете подумать: «А почему только Gmail для Android? Есть ведь и приложение для iOS!» Оно, конечно, есть, но работает оно еще хуже — и не поддерживает вообще ничего. Письма отображаются нормально, но на сегодняшний день о поддержке мобильного приложения можно забыть.
Тем не менее, использование выравнивания таблиц для Gmail — отличное решение для обеспечения гибкости, но оно недостаточно надежно и ведет к сбоям в расположении элементов в (несложно догадаться) Outlook 2007/2010. Проблемы упирались в один исключительно коварный баг в Outlook, который автоматически вставляет разрыв страницы в любой документ длиннее 22 дюймов (или 1700 px). Когда это происходит, выровненные таблицы, обладающие при этом свойством float, начинают расползаться. К счастью, эта проблема, кажется, была решена в Outlook 2013.
Одно из решений — использовать условные CSS и создать отдельный стиль, чтобы преодолеть проблемы с Outlook. В данном случае я решил не усложнять и просто повторил все то, что было сделано ранее с помощью media query для мобильных клиентов. Условные CSS — вещь необязательная, но это неплохой вариант решения проблемы.
После того, как я разобрался с поддержкой Outlook 2007/2010 и Gmail для Android, модель стала надежно работать с большинством почтовых клиентов и при этом обладала достаточным уровнем гибкости.
Обучение с помощью комментариев
Некоторые из этих техник могут быть не всегда понятны тем, кто только начал работать email-дизайнером. Для того, чтобы решить эту проблему, я постарался включить в код объяснения, показывающие, зачем используется тот или иной блок кода и что именно в рамках этого блока происходит.
Я также постарался отметить начало и конец секций, подразумевающих наличие контента, и указать, нужны ли для их заполнения специальные действия.
Сохраняя фокус создаваемой модели на базовых вариантах использования, применяя повторяющиеся дизайн-шаблоны в рамках всего письма, создавая надежный и одновременно гибкий код, мне удалось сделать так, чтобы каждый смог разобраться в адаптивном HTML-шаблоне письма и легко начать работать с ним.
Мы надеемся, что эта модель в сочетании с нашей библиотекой email-шаблонов сможет развеять ауру таинственности и заблуждений, окружающую дизайн писем в HTML. Мы, конечно, еще не закончили нашу работу: и библиотека референсов, и модели писем — проекты, которые я планирую развивать и улучшать на основе полученного фидбека.
Уплотнение текста и относительные размеры шрифтов Мардав ВалаРедизайн MailChimp в 2013 году дал нам возможность тщательно подобрать типографику приложения. Модульной системой верстки («версткой с сеткой») никого сейчас не удивишь, но достичь вертикального ритма в сети (это еще один способ сказать «выровнять контент по модульной сетке») все еще не так-то просто, особенно когда типы отображаемого контента достаточно сильно варьируются. Но после решения проблемы изначального несоответствия дизайна и кода, которая возникает в основном из-за различий в том, как мы воспринимаем (или не воспринимаем) межстрочные интервалы и интерлиньяж в печатных изданиях и веб-медиа, наши команды по дизайну и фронт-энд-разработке начали говорить на одном языке.
Уплотнение текста
Как отметил Ричард Раттер (Richard Rutter), вертикальный ритм любой веб-страницы может быть достигнут за счет аккуратной работы с межстрочными интервалами, границами между объектами и расстоянием между содержимым элемента и его границей. Суть в том, чтобы найти подходящий межстрочный интервал, который задает основу для вычисления размеров полей и отступов.
Хотя приложение MailChimp содержит большой объем контента, крайне небольшая его часть содержит большое количество абзацев текста — почти вся информация представлена в виду списков, форм, таблиц, графиков или блоков данных. Поэтому вместо того, чтобы начинать с больших межстрочных интервалов, которые повлекут за собой большие размеры полей и отступов, мы начали с минимально возможного значения межстрочного интервала — 6 px для каждого элемента приложения. Наша модульная сетка основана на этом значении в 6 px.
Почему 6 px? Мы экспериментировали с большим количеством базовых значений, но поняли, что 6 px путем умножения очень элегантно превращаются в 12 px, 18 px, 242 px и так далее, давая нам отличный диапазон различных значений размеров шрифтов и отступов. Это значение также оказалось отлично применимо к небольшим элементам, таким как кнопки и поля форм. Это обеспечило нам гибкость, необходимую для создания практически любого интерфейса.
В MailChimp изменения происходят постоянно — мы выпускаем новые функции и обновления нашего UI каждые 4 недели — поэтому в наших поисках вертикального ритма нам необходимо было обеспечить системе достаточный уровень гибкости. Ранее в процессе проектирования мы решили применять отступы только внизу элементов, чтобы облегчить процесс создания вертикального ритма. Таким образом, новые модули можно было бы размещать, не нарушая визуальную иерархию на странице. Использование «однонаправленных» отступов помогло нам достичь этой цели.
Простая математика
Поскольку наш интерфейс спроектирован на шестипиксельной модульной сетке, все размеры межстрочных интервалов, отступов и полей должны были быть кратны 6, чтобы задать вертикальный ритм. Размер шрифтов при этом, однако, можно устанавливать любой — не опасаясь нарушить этот вертикальный ритм. Наш основной шрифт имеет размер 15 px — такой шрифт, как нам кажется, оказывается читабелен во всех ситуациях и при этом не перегружает интерфейс.
Согласно лучшим практикам, межстрочный интервал для улучшения читабельности должен в полтора раза превышать высоту шрифта. Если размер нашего шрифта составляет 15 px, то межстрочный интервал в таком случае должен равняться 22,5 px. Но поскольку шаг нашей модульной сетки был величиной в 6 px, мы «растянули» межстрочный интервал до 24 px, создавая прямую зависимость между межстрочными интервалами, отступами и полями для всех модулей. Разобравшись с вычислениями, мы начали применять эти пропорции к элементам нашего приложения.
Для всех заголовков и других размеров шрифтов межстрочный интервал также был установлен на значение, кратное 6 и вычислявшееся в соответствии с размером самого шрифта. В примерах используются измерения в пикселях для простоты представления:
h1 { font-size: 40 px; line-height: 48 px; }
.small-meta { font-size: 13 px; line-height: 18 px; } Исключения из правилИзображения и графики не подчиняются общим правилам и часто «разбивают» модульную сетку. Их размеры часто непредсказуемы — их не всегда можно легко привести в соответствие с шагом сетки. Но несмотря на это вертикальный ритм не нарушается, поскольку границы между объектами, задаваемые отступами и полями, остаются неизменными.
Элементы, имеющие границы, также могут выйти за рамки модульной сетки, так как их размеры добавляются к основным вычислениям, а не встраиваются в систему. Но тут выход простой: вычисляйте высоту элементов с учетом их границ (этот подход может повлечь уменьшение полей над или под элементом на величину границ).
Конечно, пуристы могут возразить, что такой подход приведет к визуальному дисбалансу если высота границ элемента будет больше 1 px — и они будут совершенно правы. Усилия по выравниванию горизонтальных линий и элементов, имеющих границы, по модульной сетке не всегда оправдывают себя, поскольку горизонтальные линии и границы не могут повлиять на вертикальный ритм при правильном подходе к отступам, межстрочным интервалам и полям.
Вот пример того, как мы сократили поля элементов списка на высоту границы в 1 px:
@base-unit: 6 px; .dotted-list { margin-bottom: (@base-unit * 2); li { padding-top: (@base-unit * 2) padding-right: 0; // 1 px less padding bottom padding-bottom: ((@base-unit * 2) — 1); padding-left: 0; border-bottom: 1 px dotted #c0ffee; } } Графики также можно подстроить пропорционально вашей сетке. Если соотношение сторон графика меняется при изменении окна браузера, установить высоту графика и вертикальные отступы пропорционально шагу вашей сетки. Если этого не происходит, установите только величину вертикальных отступов и не меняйте высоту графика.Поскольку высота изображения будет масштабироваться с изменением его ширины, мы не можем полагаться на выравнивание высоты по модульной сетке. В этих случаях надо убедиться, что отступы, окружающие объект, заданы так, чтобы не нарушать вертикальный ритм.
Применение подобных специальных правил в коде и работа с исключениями из правил может внести путаницу. Быстро обсуждение в команде и простой комментарий в коде могут уменьшить ряд сложностей. Документирование изменений в библиотеке шаблонов также имеет большое значение.
Мы обнаружили, что «тонкая настройка» вертикальных промежутков на уровне модулей — проектирование «вне контента» как рекомендует Марк Боултон (Marc Boulton) — процесс гораздо более осмысленный, нежели внесение изменений на глобальном, «постраничном» уровне. Если отдельные модули подогнаны друг к другу по модульной сетке, неважно, где именно они расположены: вертикальный ритм и визуальная иерархия будут автоматически соблюдаться.
Относительные размеры шрифтов
При использовании относительных размеров шрифтов, измеряемых в em (относительная единица длины, равная размеру текущего шрифта), для создания гибкого, масштабируемого проекта, …может оказаться сложнее, чем при указании абсолютных размеров шрифтов в пикселях.
Перевод значений из пикселей в относительные единицы (em) раньше был довольно утомительным занятием. К счастью, мы можем упростить процесс, используя объединенные возможности препроцессоров CSS и повсеместно используемое правило Итана Маркотта (Ethan Marcotte): target ÷ context = result.
Ключ к сохранению порядка среди всей этой путаницы с относительными размерами шрифтов состоит в концентрации на контексте. Для вложенных элементов с относительным размером шрифта контекстом является размер шрифта родительских элементов, выраженный в пикселях, для родительских элементов контекст — размер шрифта основного текста по умолчанию (16 px, если говорить только об основном тексте).
Вот пример HTML-кода на основе этого примера от Treehouse:
Title: Tagline
Задать относительный размер шрифта заголовка и добиться того, чтобы шрифты вложенных строчных элементов определялись без особой путаницы можно следующим образом:// default body font-size @baseFontSize: 16; @h1Size: 24; @h1SpanSize: 18;
h1 { #pxtoem > .font-size (@h1Size, @baseFontSize); // 24 ÷ 16 = 1.5em > span { #pxtoem > .font-size (@h1SpanSize, @h1Size); // 18 ÷ 24 = .75em } } По мере увеличения количества вложенных уровней (это могут быть уровни с вложенными заголовками, абзацами, ссылками и строчными элементами) следить за размерами шрифтов становится все труднее, поэтому такие превентивные меры контроля могут помочь в достижении постоянно ускользающей CSS-нирваны.
