Формы в Email: Полезный инструмент или полный бред

Нужно ли использовать формы в почтовых рассылках, или это совершенно ненужный инструмент?

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

Зачем это может быть нужно

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

Иногда могут существовать юзкейсы, при которых форма в письме появляется в качестве опции — например, для стимулирования немедленного взаимодействия с пользователями (возможно, нужно попросить его комментарий). В таких случаях простой ссылкой на внешнюю страницу отделаться не удастся.

Возможно, вы встречали в письмах что-то типа этого:

Реализовать это проще всего, добавив ссылку с переменной для записи выбора пользователя на каждый смайл.

Но что, если нужно реализовать что-то похожее на это:

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

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

Форма

Массимо Кассандро решил провести эксперимент, создав простую форму, которая содержит несколько элементов:

  • Поле ввода текста;
  • Две радиокнопки;
  • Чекбокс;
  • Элемент Select;
  • Зону с текстом.

Для каждого из них было установлено дефолтное значение, кроме того у поля ввода текста был атрибут required.

Тест проводился для доктайпов HTML5 и XHTML 1 strict. Обе версии прошли через валидатор W3C. Ниже представлен использовавшийся код:

Вот так это все выглядит в Chrome для Mac:

XHTML-версия практически не отличается от представленного выше.

Участвующие клиенты

Обе версии формы проверены на следующих почтовых программах:

Десктоп:

  • Apple Mail (v.8.2)
  • Thunderbird (OSX, v.31.4)
  • Windows Live Mail 2012 (Windows 7)
  • Outlook 2013 (Windows 7

Мобайл:

  • iPad Mail (IOS 8.2)
  • Gmail App on iPad
  • Yahoo Mail on iPad
  • Outlook for IOS
  • Gmail App on Android (v.5.0.1)
  • Native E-Mail App on Android 4.4.4
  • Yahoo Mail on Android (v.4.8.4)
  • Gmail Inbox Android (v.1.2)

Веб:

  • Gmail
  • Yahoo Mail
  • Outlook.com

Веб-клиенты тестировались в браузере Firefox 35 для OSX.

Результаты

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

Исключением стал лишь Outlook для Windows и iOS. В случае этой программы форма не срендерилась ни на Outlook 2013/Win7 ни на iOS. Элементы формы были либо полностью вырезаны (iOS), либо показаны плейнтекстом (Outlook 2013):

На Outlook.com форма корректно отобразилась, но отправить введенные данные было нельзя.

Возможно вы знаете о том, что Outlook Desktop используется в качестве движка рендеринга HTML Microsoft Word, что многое объясняет. Word разработан для создания документов, а не отображения веб-форм. С чего в Microsoft решили, что использовать его для создания email будет отличной идеей — отдельный вопрос.

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

Более старые версии Outlook, которые использовали движок рендеринга Trident из Internet Explorer, и Outlook 2011 For Mac (использует WebKit) отображают форму корректно, но остается вопрос о возможности отправки данных.

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

Интересный момент — атрибут required был проигнорирован почти всеми email-клиентами. Исключением стали лишь Thunderbird — подсветил помеченные атрибутом поля, но отправить форму можно было и без их заполнения — и Opera Mail — тут поведение было похоже на браузер, с отображением сообщения об ошибке и невозможностью отправки.

К слову, Opera Mail оказался одним из самых быстрых и простых в использовании почтовых клиентов.

Также выяснилось, что Yahoo Mail for iOS — единственный клиент, который отображает результат без использования внешнего браузера. Ценный навык, с точки зрения UX.

Ниже представлена таблица с результатами эксперимента (скриншоты и код доступны в репозитории на GitHub):

  1. Атрибут required проигнорирован.
  2. Поля с required подсвечены в случае, если в них нет данных, но форму можно отправить.
  3. Возникает алерт при отправке.
  4. Текст в форме нельзя вводить и редактировать.
  5. Страница с результатами открывается внутри приложения.

Заключение

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