Пост местами интересный, но фрагмент: «Верстка несет в себе определенные сложности. Email-верстка очень специфична. Можно использовать только старые стандарты, нельзя div, следовательно, приходится пользоваться только определенными тегами. Верстальщики не очень любят email, потому что есть большие ограничения и нет возможности пользоваться новыми технологиями.» — заставил посмеяться.
Email верстка действительно очень специфична и этот момент как раз и дает огромный простор для использования новых технологий. Заверстать страницу под пять браузеров — много ума не надо. А вот автоматизировать полную кроссплатформенность — крайне интересная технологическая задача.
Система локализации вызывает небольшое недоумение. Меня вообще удивляет, какого черта ESP берут на себя не свою работу вроде конструкторов писем и систем локализации. Это прямая задача разработчика писем. У ESP всего четыре задачи:
1. Отправлять письма
2. Предоставить механизм быстрой выгрузки шаблонов и привязка этих шаблонов к сегментам базы
3. Предоставить механизм АБ тестирования и автоматического проставления меток по заданному алгоритму
4. Предоставление аналитики
Можете ведь, когда захотите. Это просто охренительная подборка материалов, половину из которых я вижу впервые. Подобный объем информации очень сильно стимулирует развивать свои наработки.
Очень сложно мониторить появление новых статей по данной тематике, но у вас, видимо, выходит хорошо. Если Печкин запилит фид-ленту постов по нашей тематике, то это будет очень круто.
emailframe.work сосет потому что Gmail (Android, iOS & Apps) does not support media queries. Desktop version only.. Как следствие -отваливаются мобильные клиенты мейлру и яндекса.
А вот Zurb Ink как раз наоборот все больше вызывает любопытство. К тому же они анонсировали принципиально новую версию фреймворка. Мне у них не все нравится субъективно, но инструмент определенно хорош, хоть и был когда-то унылым говном. Запасаюсь поп-корном.
Ну и любопытства ради: какая библиотека используется в инлайнере Печкина?
У меня только на iOS стоит 12 почтовых клиентов, которые являются наиболее популярными. Да, у каждого есть свои особенности, но они более-менее приемлемы и при подготовке письма всегда можно найти компромисс. Но случай с номерами телефонов весьма противен. Отсюда и родился топик.
— Outlook (android) — неверный расчет процентов для ширины многоколоночных элементов. Погрешность около 0.2%. Мелочь, но противная.
— Yahoo! (iOS) — нет поддержки CSS3 (не хватает border-radius)
— Google Inbox (iOS, android) — еще более непредсказуемое поведение свойства width, нежели в gmail. В остальном принцип рендеринга схож. Нет поддержки медиазапросов.
— Gmail (iOS, android) — свойство width для блочных элементов и картинок в принципе не поддерживается. В асимметричных по колонкам письмах начинается фарш. Если вы шлете неадаптивное письмо, то клиент пытается его адаптировать по собственным алгоритмам. На Андроиде получается тоже фарш. На iOS есть возможность просмотреть неадаптированный оригинал. Нет поддержки медиазапросов.
— Mail.ru (android, iOS) — в целом ок. Отвратная реализация переноса текста. При трансформации номера телефона в ссылку(и вообще любая трансформация текста в ссылку) сама ссылка не подхватывает цвет оформления из css. Нет поддержки медиазапросов.
— My.com mail — движок идентичен приложению mail.ru
— Yandex mail (web, android) — нет поддержки медиазапросов. На андроид клиенте были замечены погрешности при расчете ширины многоколоночных элементов.
— Sparrow — был идеальным почтовым клиентом за исключением того, что его интерфейс не менялся еще со времен 4-го айфона. Ныне выпилен из эппстора.
— Apple Mail (iOS) — body имеет железобетонный margin:15px; Его никак не победить.
— Mailbox (iOS, android) — в целом прекрасен. Но базовые значения body равны нулю, как и у всех яблочных почтовых клиентов кроме Аутлка и Apple mail. Тем самым все еще уступает Аутлуку.
— Android Mail — Нареканий нет, за исключением рендеринга тех, картинок, исходный размер которых превышает указанный в верстке. Через мои руки прошел десяток телефонов на андроиде и везде, во всех почтовых клиентах на андроиде есть артефакты на таких вот картинках.
Слишком адовый костыль. С другой стороны можно по клику на номер телефона отправлять получателя на страницу контактов на сайте, но это говнарство по отношению к пользователю. Я лучше смирюсь с дефолтным синим цветом.
Слабая попытка подкинуть уголька. Меня не устраивает вариант когда элемент выглядит как ссылка, но не звонит. Либо сильно выбивается из общего стиля, хотя я не оформлял его как ссылку, что кстати по принципу контраста повышает шансы на клик, но я преследую не эти цели. Если я могу влиять на оформление обычных ссылок, то хочу также и оформлять ссылки-звонилки. На циферки пускай теребят маркетологи. Меня интересует логичность поведения элементов интерфейса письма и какой-никакой, но контроль.
Годная статья с познавательной точки зрения. Выше уже привели мой любимый пример с ЖЖ, вот только помнится мне, там была не форма, а просто ответ на письмо. Хотя могу ошибаться.
Так или иначе я не вижу надобности делать формы в письмах. Ведь всегда можно попросить получателя перейти на сайт по ссылке и заполнить форму. Причем те же Авито проводили очень успешные опросы через гуглоопросники. И не надо ничего мудрить. Ведь письмо, прежде всего, способ донести информацию и побудить к действию, а не место, где надо играться с перделками. Ну правда, чем форма на сайте хуже формы в письме? Один дополнительный клик? Я вас умоляю.
Я пришел к тому, что вовсе не использую медиазапросы при верстке писем кроме пары исключений.
Например к нас есть трехколоночная выкладка товаров магазина в письме. Без применения медиазапросов получается по одному товару в строке на смартфонах. Каждый из этих товаров занимает примерно 75% от ширины письма. Для нормальных почтовиков, которые понимают медиазапросы я пишу width:50% для элемента товара и таким образом мы получаем по два товара в строке на мобильном почтовом клиенте. Но это частных случай. В основном все же один товар в строке будет лучше, ибо не нужно напрягать зрение, чтобы его рассмотреть.
Подход Николь кажется громоздким только на первый взгляд. На самом деле о очень хорош. Я перенял у нее многие идеи, но оформил их немного иначе в своем фреймворке. Мои заявления о неработоспособности были на тот момент необоснованными. Я недостаточно хорошо изучил описанный материал.
Также я решил вопрос инлайнинга писем, подключив gulp-inline-css. В процессе работы с ним были выявлены небольшие баги с переносом стилей и Александр, который мне помогает развивать фреймворк отправил разработчику pull-реквест, который был принят. Это приятно.
К тому же Николь тоже внесла корректировки в свой шаблон письма с момента публикации ее статьи. Возможно кому то это покажется интересным. Вот ее профиль на гитхабе.
Литмус только для проверки аутлука. Все вебморды и десктопные клиенты отображают верстку более-менее нормально. Можно ограничиться парой тестов. На андроиде и яблоке ставим все приложения и привязываем к ним один почтовый аккаунт. Забиваем в него письмо и смотрим на все по очереди. Рутина, но не такая уж и большая. У меня это 13 почтовиков на iOS, 6 на ведроиде и 1 на windows phone.
Мне непонятно, зачем делать слайдер в письме. Куда проще сверстать одну большую и четыре маленьких картинки и на каждую повесить ссылку на сайт. Пользователя перенаправит на сайт при клике(тапе) по любой из картинок. И это будет предсказуемым поведением. Не надо заморачиваться со слайдером, который не будет работать в куче почтовиков, так еще и трафик на сайт, вместо того, чтобы получатель занимался подобной ерундой в письме.
тоже раньше путал эти понятия
Email верстка действительно очень специфична и этот момент как раз и дает огромный простор для использования новых технологий. Заверстать страницу под пять браузеров — много ума не надо. А вот автоматизировать полную кроссплатформенность — крайне интересная технологическая задача.
Система локализации вызывает небольшое недоумение. Меня вообще удивляет, какого черта ESP берут на себя не свою работу вроде конструкторов писем и систем локализации. Это прямая задача разработчика писем. У ESP всего четыре задачи:
1. Отправлять письма
2. Предоставить механизм быстрой выгрузки шаблонов и привязка этих шаблонов к сегментам базы
3. Предоставить механизм АБ тестирования и автоматического проставления меток по заданному алгоритму
4. Предоставление аналитики
Очень сложно мониторить появление новых статей по данной тематике, но у вас, видимо, выходит хорошо. Если Печкин запилит фид-ленту постов по нашей тематике, то это будет очень круто.
emailframe.work сосет потому что Gmail (Android, iOS & Apps) does not support media queries. Desktop version only.. Как следствие -отваливаются мобильные клиенты мейлру и яндекса.
А вот Zurb Ink как раз наоборот все больше вызывает любопытство. К тому же они анонсировали принципиально новую версию фреймворка. Мне у них не все нравится субъективно, но инструмент определенно хорош, хоть и был когда-то унылым говном. Запасаюсь поп-корном.
Ну и любопытства ради: какая библиотека используется в инлайнере Печкина?
В предыдущем топике был краткий список нюансов мобильных клиентов:
— Outlook (android) — неверный расчет процентов для ширины многоколоночных элементов. Погрешность около 0.2%. Мелочь, но противная.
— Yahoo! (iOS) — нет поддержки CSS3 (не хватает border-radius)
— Google Inbox (iOS, android) — еще более непредсказуемое поведение свойства width, нежели в gmail. В остальном принцип рендеринга схож. Нет поддержки медиазапросов.
— Gmail (iOS, android) — свойство width для блочных элементов и картинок в принципе не поддерживается. В асимметричных по колонкам письмах начинается фарш. Если вы шлете неадаптивное письмо, то клиент пытается его адаптировать по собственным алгоритмам. На Андроиде получается тоже фарш. На iOS есть возможность просмотреть неадаптированный оригинал. Нет поддержки медиазапросов.
— Mail.ru (android, iOS) — в целом ок. Отвратная реализация переноса текста. При трансформации номера телефона в ссылку(и вообще любая трансформация текста в ссылку) сама ссылка не подхватывает цвет оформления из css. Нет поддержки медиазапросов.
— My.com mail — движок идентичен приложению mail.ru
— Yandex mail (web, android) — нет поддержки медиазапросов. На андроид клиенте были замечены погрешности при расчете ширины многоколоночных элементов.
— Sparrow — был идеальным почтовым клиентом за исключением того, что его интерфейс не менялся еще со времен 4-го айфона. Ныне выпилен из эппстора.
— Apple Mail (iOS) — body имеет железобетонный margin:15px; Его никак не победить.
— Mailbox (iOS, android) — в целом прекрасен. Но базовые значения body равны нулю, как и у всех яблочных почтовых клиентов кроме Аутлка и Apple mail. Тем самым все еще уступает Аутлуку.
— Android Mail — Нареканий нет, за исключением рендеринга тех, картинок, исходный размер которых превышает указанный в верстке. Через мои руки прошел десяток телефонов на андроиде и везде, во всех почтовых клиентах на андроиде есть артефакты на таких вот картинках.
И на это не повлиять без инлайн-вмешательства.
Так или иначе я не вижу надобности делать формы в письмах. Ведь всегда можно попросить получателя перейти на сайт по ссылке и заполнить форму. Причем те же Авито проводили очень успешные опросы через гуглоопросники. И не надо ничего мудрить. Ведь письмо, прежде всего, способ донести информацию и побудить к действию, а не место, где надо играться с перделками. Ну правда, чем форма на сайте хуже формы в письме? Один дополнительный клик? Я вас умоляю.
Например к нас есть трехколоночная выкладка товаров магазина в письме. Без применения медиазапросов получается по одному товару в строке на смартфонах. Каждый из этих товаров занимает примерно 75% от ширины письма. Для нормальных почтовиков, которые понимают медиазапросы я пишу width:50% для элемента товара и таким образом мы получаем по два товара в строке на мобильном почтовом клиенте. Но это частных случай. В основном все же один товар в строке будет лучше, ибо не нужно напрягать зрение, чтобы его рассмотреть.
Подход Николь кажется громоздким только на первый взгляд. На самом деле о очень хорош. Я перенял у нее многие идеи, но оформил их немного иначе в своем фреймворке. Мои заявления о неработоспособности были на тот момент необоснованными. Я недостаточно хорошо изучил описанный материал.
Также я решил вопрос инлайнинга писем, подключив gulp-inline-css. В процессе работы с ним были выявлены небольшие баги с переносом стилей и Александр, который мне помогает развивать фреймворк отправил разработчику pull-реквест, который был принят. Это приятно.
К тому же Николь тоже внесла корректировки в свой шаблон письма с момента публикации ее статьи. Возможно кому то это покажется интересным. Вот ее профиль на гитхабе.