Это вторая часть перевода интересного исследования, которое проводили авторы популярного интернет сайта Smashing Magazine. Первую часть вы пожете прочитать здесь. В этот раз авторы затрагивают вопросы капчи, сообщения «Спасибо за регистрацию», кнопки «Отмена» на формах и некоторые другие интересные вопросы.
3. Функциональность форм
В первой части нашего исследования мы рассмотрели как расположение ссылок на подписку и форм регистрации, так и их внешний вид. Те не менее, не имеет значения, как привлекательно выглядит дизайн, если формы не работают как надо, число заполненных форм будет невелико. Давайте рассмотрим теперь как функционал форм подписки, так и связанные с ними типичные проблемы, паттерны и решения, применяемые в дизайне таких форм.
3.1. Hover, active, focus — эффекты от использования?
Очевидно, чтобы улучшить число заполняемых форм дизайнеры пытаются избежать отвлечения внимания во всех видах и предлагают чистые, точно выраженные и простые веб-формы. По существу, это и есть причина того, почему визуальные эффекты используются очень редко, если вообще используются.
- 84% веб-форм которые мы рассматривали не имели каких либо эффектов с hover, active или focus;
- 16% использовали очень слабые hover-эффекты.
3.2. Помощь, поддержка, советы: статически или динамически?
Порой подписи к полю ввода недостаточно, однако, пользователям необходимо знать какую информацию они должны предоставить. Какие символы разрешены в имени пользователя? Сколько символов должно быть в пароле? Будет или указанный e-mail автоматически являться логином на сервисе.
Подсказки и советы (Hints and tooltips) обеспечивают поддержку пользователей для того, чтобы минимизировать количество повторного введения информации. Кроме того, нет ничего более раздражающего, чем поля ввода, которые не принимают пользовательских данных, хотя те выглядят правильными. Чтобы избежать этого дизайнеры используют (чаще всего) ненавязчивые и четкие подсказки.
57% рассмотренных веб-форм предлагают статическую помощь — советы, которые объясняют пользователю, что ожидается от пользовательского ввода; эти советы явно расположены следом за полем ввода. 10% советов появляются по требованию — чаще всего после нажатия на какую-нибудь иконку помощи или, когда пользователь вводит информацию в поле ввода.
3.3. Помощь, поддержка, советы: где они расположены?
Когда пользователю предлагается поддержка, важно быть уверенным, что помощь не просто предлагается, но легко находится и понимается пользователями. Очень важно быть уверенными, что пользователи не ошибутся, сопоставляя подсказку и поле ввода. Чтобы достигнуть этого, вам необходимо знать, где пользователи ожидают увидеть подсказку. Так как же располагаются подсказки и помощь чаще всего на форме?
Если подсказки и помощь присутствуют, то они расположены:
- ниже поля ввода (57%);
- с правой стороны поля ввода (26%);
- над полем ввода (13%);
- слева от поля ввода (4%).
Мы обнаружили явную тенденцию располагать подсказки прямо под полем ввода. Обычно такие подсказки имеют немного измененный цвет, в большинстве случаев светлее, чем основное содержимое.
3.4. Валидация ввода: статическая или Ajax?
Несмотря на то, что в последние годы Ajax буквально наводнил веб-сайты с богатым пользовательским взаимодействием, он все еще достиг критической массы среди популярных веб-сервисов. К удивлению, мы не обнаружили устойчивой тенденции использования Ajax. «Классическая» техника валидации, которая проверяет ввод после того, как пользователь нажал на кнопку submit более популярна, чем проверка в реальном времени через Javascript.
Согласно нашему исследованию,
- 30% всех форм отображают только сообщение об ошибке сверху формы (поля ввода не подсвечиваются);
- 29% подсвечивают поля ввода с соответствующими сообщениями сразу за полем ввода (сверху страницы не выводится никаких сообщений об ошибках);
- 25% использую оба способа: сообщения об ошибках и сообщения в полях ввода;
- 22% используют проверку в реальном времени через Ajax;
- 14% используют предупреждения об ошибках через Javascript;
- 1% использует системное сообщение со ссылкой «вернуться назад» (“go back”-link).
3.5. Дизайн сообщений об ошибках
Как вы могли заметить, мы определили шесть разных типов проверки на ошибки. Интересно, что 14% форм продолжают использовать окна сообщений через Javascript (Javascript-error-windows) для сообщения о проблемах (например, YouSendIt, Mail.ru, Newsvine, Clipmarks, Yandex, смотрите скриншоты ниже), и только 22% содержат хотя бы частичную проверку на основе Ajax (в основном, для проверки доступных имен пользователей). И что еще интереснее, нет ни одного сайта, на котором не было бы вообще никакой проверки.
Newsvine использует JavaScript-сообщения чтобы показать информацию об ошибке.
Обычно, дизайнеры стремятся сообщить об ошибках используя: а) сообщения об ошибках после нажатия на кнопку submit и/или б) визуально подсвечивают «некорректные» поля ввода. В первом случае ошибки обычно представлены в виде списка с буллитами (bulleted) сверху страницы перед формой. Во втором случае, обычно, у «ошибочного» поля ввода меняется цвет границы вместе с подписью к полю (в большинстве случаев с красным цветом текста и красным фоном).
Иногда дизайнеры совмещают обе техники и используют как сообщение об ошибке, так и подсветку полей ввода. К примеру, рассмотрим форму подписки на Ning (смотрите изображение ниже) с совмещением обеих техник.
Обычно, красный цвет используется, чтобы показать ошибки, но это не обязательно всегда так. Tickspot, Mixx.com и Furl используют желтый цвет, чтобы сообщать о проблемах, возникших при заполнении форм.
Но как бы там ни было, единственный цвет, который используется чтобы сообщить об успешной регистрации, это зеленый цвет. В 97% веб-сайтов этот цвет использовался для того, чтобы визуально подсветить успешное действие.
3.6. Есть ли необходимость подтверждать e-mail?
Только в 18% случаев присутствует необходимость подтверждать свой e-mail (например, Odeo, Ning). Если быть честными, мы не видим каких-либо разумных обоснований для требования от пользователя повторного ввода e-mail, в конце концов, пользователи видят, что они ввели, потому что поле ввода e-mail не закрыто звездочками (is not starred out). Вы согласны?
3.7. Есть ли необходимость подтверждать пароль?
Выглядит разумно запрашивать подтверждение ввода, если пользователь не видит информацию, которую он набрал (вместо этого он/она видит звездочки). Однако, множество сайтов решило убрать одно поле ввода, чтобы минимизировать время требуемое для завершения заполнения формы.
В 72% случаев подтверждение пароля считается важным. Однако, многие крупные сайты, такие как Facebook, Friendster, LinkedIn, Stumbleupon, Pownce и Twitter не требуют подтверждения пароля.
3.8. Используется ли капча?
Хотя пользователи были бы очень рады тому, чтобы капча исчезла, она необходима на практике из-за того, что веб-сайтам требуется сделать невозможным множественную регистрацию учетных записей спам-ботами, иными словами, сайтам требуется фильтровать спамерские учетные записи в базе данных.
Согласно нашему исследованию,
- 52% сайтов не используют капчу;
- в 39% случаев невозможно обновить капчу без обновления веб-формы. Что очень печально с точки зрения юзабилити.
Тем не менее, мы не обнаружили однозначной тенденции сайтов использовать или не использовать капчу. В любом случае, если вы используете капчу, пожалуйста, убедитесь, в том, что она легко читаема или в том, что пользователь может обновить капчу в случае, если она не читаема. Некоторые сайты не имеют возможность обновить капчу, но Digg, AOL, Slashdot, Google and Last.fm предлагают пользователям прослушать капчу в случае, когда капча неразборчива.
3.9. Используется ли кнопка «отмена» (cancel-button)?
Когда мы решили определить дизайнерские решения при дизайне веб-форм, мы ожидали, что формы подписки не будут содержать кнопку «отмена», так как на самом деле для пользователя не требуется отменить заполнение формы после того, как все поля были заполнены. И мы частично ошиблись.
Кнопка «отмена» используется только в 8% случаев. В некоторых из этих случаев, кнопка «отмена» располагается справа после секции «условий и соглашений» (например, Zoho Writer). Таким образом, если пользователи не хотят соглашаться с требованиями сервиса, они могут прервать процесс. С другой стороны, некоторые сервисы предлагают выбрать платежный план перед регистрацией (например, Crazyegg). В этом случае, при выборе неправильного плана они могут вернуться назад, нажав кнопку «отмена» и выбрать план, который считают нужным.
Отдельно от этого: мы так и не поняли, почему Dzone расположили кнопку «отмена» слева в своей форме подписки.
Если кнопка «отмена» используется, она расположена с правой стороны от кнопки submit (4%). В сайтах, рассмотренных в этой статье кнопки «отмена» и submit ни чем не отличались друг от друга и были расположены рядом. С точки зрения юзабилити имеет смысл использовать четкое визуальное разделение между кнопками с основными действиями и кнопками с дополнительными действиями и сделать значительное расстояние между ними, чтобы четко их разделить.
3.10. Выравнивание кнопки submit (submit-button)
В зависимости от разметки формы имеет смысл расположить кнопку submit слева, справа или посередине. Дизайнеры отдают предпочтение выравниванию по левому краю (56%), затем следуют выровненные посередине кнопки (26%).
Выровненная по правому краю кнопка submit остается популярной (17%), чаще всего используется дизайнерами, чтобы указать на следующий шаг регистрации. В таких случаях, submit-кнопки чаще всего называются «Продолжить» или «Далее». Причина: в обычных прикладных приложениях кнопки «Далее» также часто располагаются справа.
3.11. Сообщение «Спасибо вам»
Всего несколько лет назад большинство сервисов предлагали простое «спасибо вам»-сообщение после успешной регистрации (обычно со ссылкой на страницу логина), сегодня большинство сайтов пытаются мотивировать пользователей сразу же исследовать сервис.
- 45% форм просят, от только что зарегистрированных пользователей, заполнить еще информацию, найти друзей в сетях, посоветовать сайт друзьям или заполнить его или ее профиль;
- 33% форм предлагают к исследованию «места для посещения» и функции в привлекательном, дружелюбном виде;
- 4% предлагают простое «Спасибо вам» сообщение;
- 2% перенаправляют на главную страницу.
Дополнительные результаты исследования:
- порядок переключения клавишей tab был правильным в 99% случаев (за исключением habrahabr.ru) [прим. перев. — спасибо Kalan и kurokikaze за подсказку перевода];
- 24% форм используют разговорный стиль, пытаются обратится к пользовательским потребностям через подписи. Информационные фразы вроде «Как вас зовут?», «Пожалуйста, вам e-mail», или «Мне бы хотелось...» примерные варианты;
- 38% сайтов предпочитают оставаться формальными и используют деловой стиль, дружелюбно спрашивая пользователей (например, «Ваше имя», «Подтвердите пароль» и т.д.);
- 38% сайтов используют системный стиль, пользователей спрашивают через фразы «Login», «Пароль пользователя», «Местоположение» и т.д.
Заключение
Давайте подведем итог и кратко рассмотрим результаты исследования. Пожалуйста, имейте в виду, что все это касается только форм подписки.
- формы подписки не содержат эффектов hover, active или focus (84%);
- подсказки и помощь чаще всего статические (57%) или динамические (33%) и расположены ниже поля ввода (57%) или справа от поля ввода (26%);
- статическая валидация популярнее динамической — нет тенденции к использованию Ajax;
- подтверждение e-mail не используется (82%);
- используется подтверждение пароля (72%);
- капча может использоваться, а может и не использоваться (48% vs. 52%);
- кнопка «отмена» не используется (92%);
- кнопка submit расположена слева (56%) или по центру (26%);
- «Спасибо вам»-сообщение мотивирует пользователей продолжить исследовать сервисы на сайте (45%).
