• Документация
• Конструктор
• Регистрация

Руководство по созданию правильной почтовой формы

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

Поля

Большинство почтовых форм страдают хроническим переизбытком полей — типичный минимальный набор для формы обратной связи: имя, e-mail, тема, текст. Имя обычно запрашивают только для того, чтобы робот мог ответить пользователю что-то вроде: «Уважаемый(ая) $name! Ваше сообщение успешно отправлено!». Почему-то разработчики форм считают, что пользователю будет приятно сначала заполнить имя, а потом получить такой автоматический ответ.

В большинстве случаев тема сообщения тоже никакой полезной функции не выполняет. При обмене большими-большими письмами по электронной почте тема нужна и полезна — она помогает сортировать ветки переписки и искать нужные письма. А при общении через ICQ и отправке SMS тема не прижилась.

Частотность сообщений разной длины (из 120 последовательно полученных сообщений)

Все дело в длине передаваемых сообщений. На приведенной диаграмме показана частотность длин сообщений (в словах), отправленных через форму обратной связи одного сайта. Видно, что подавляющая часть сообщений имеют длину от 2 до 32 слов. Такой формат больше соответствует обмену короткими сообщениями, чем почтовой переписке. Поэтому не просите и не заставляйте пользователя придумывать заголовок для вопроса из нескольких слов.

Форма должна содержать минимум полей, которые следует выбирать исходя из потребности в раздельной обработке данных: если данные должны приниматься и обрабатываться отдельно — разносите их по разным полям, иначе — объединяйте в одно. Например, адрес электронной почты удобно вынести в отдельное поле для проверки правильности ввода и автоматической отправки оповещений. А тему сообщения лучше объединить с текстом.

Проверки данных

Самая простая и очень частая задача — отправить анонимный отзыв или сообщить об ошибке на сайте. Тем более удивительно, что большинство форм обратной связи заведомо с ней не справляются — для отправки сообщения требуется заполнять много обязательных полей.

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

Еще один редкий, но все еще встречающийся рудимент — ограничение длины вводимого текста, строки, числа и размера прикрепляемых файлов. Обычно такие ограничения обусловлены техническими особенностями реализации формы, например, сообщения сохраняются в таблицу БД, где есть жесткое ограничение на длину строковых данных. То есть требования к входным данным подстраиваются под реализацию. Очень давно подобная ситуация была вполне нормальной, когда для отмены ограничений требовалось неадекватное усложнение реализации. При нынешнем же ПО, вычислительных мощностях и скоростях связи основным критерием, ограничивающим данные, должна быть только их адекватность.

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