Главная > Формы > Валидация Web-Форм: Практика и рекомендации

Валидация Web-Форм: Практика и рекомендации


2 августа 2009, 02:00. Разместил: Mysterious Master
В идеале, пользователи должны внести в онлайн-форму требуемые сведения и успешно произвести её отправку. Однако, люди часто допускают ошибки. Здесь-то и выручает функция подтверждения правильности заполнения онлайн-форм. Её назначение - помочь пользователю удостовериться в полноте предоставленной им информации и её соответствии заданному формату для успешного завершения операции. В этой статье мы затронем не только подтверждение правильности заполнения форм как таковое, но и рассмотрим различные приёмы, методы и способы применения этой функции наряду с программными средствами отслеживания ошибок.

1. Методы подтверждения
2. Что требует подтверждения
3. Сообщение об ошибке
4. Семь раз отмерь
5. Вы - человек?

1. Методы подтверждения

Ввод данных пользователя может подтверждаться на сервере или на компьютере-клиенте (через веб-браузер). То есть, имеются две точки подтверждения - со стороны сервера и со стороны клиента. Разберём преимущества и недостатки обеих.

Процедура подтверждения со стороны сервера

В данном случае, информация поступает на сервер и подтверждается кодами одного из языков этого сервера. При получении отказа в подтверждении, клиенту высылается уведомление, страница, на которой помещена форма, обновляется, выводится сообщение об ошибке. Надёжность этого метода состоит в его способности продолжать работу даже при отключении javascript в браузере и устойчивости ко взлому. С другой стороны, пользователи лишены возможности корректировать заполненную форму до её отсылки, что увеличивает время взаимодействия с сервером.

Исключение составляет подтверждение посредством Ajax. Сигналы Ajax, принимаемые сервером, могут подтверждаться по ходу заполнения формы и получать мгновенный ответ. Здесь мы называем подтверждением приемлемость вводимых данных, например, допустимость конкретного имени пользователя. Подробнее о подтверждении с помощью Ajax можно прочесть в этом отличном пособии для дизайнеров - jQueryForDesigners.
Валидация Web-Форм: Практика и рекомендации

На схеме показаны различия между способами подтверждения со стороны клиента и сервера, а также другие пути решения этой проблемы.

Подтверждение со стороны клиента

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

При подтверждении со стороны клиента, форму нельзя отправить, если получен отказ. Операция производится вами средствами javascript (или через структуры/модули), поэтому сообщение об ошибке выдаётся вместе с отказом.

Основной недостаток этого способа подтверждения - его зависимость от javascript. Отключив javascript, пользователи могут легко отправить некорректную форму. Поэтому подтверждение всегда должно осуществляться с обеих сторон - и клиентом, и сервером. Совмещая эти способы, мы можем получить преимущества обоих: высокую скорость обработки данных, более надёжную процедуру подтверждения и удобство для пользователя.
Валидация Web-Форм: Практика и рекомендации

Компьютер-клиент получает мгновенное подтверждение регистрации на TypePad.

1. Методы подтверждения
2. Что требует подтверждения
3. Сообщение об ошибке
4. Семь раз отмерь
5. Вы - человек?

2. Что требует подтверждения

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

Обязательные сведения

Прежде всего подтверждаться должны, очевидно, обязательные к предоставлению сведения, без указания которых успешное завершение операции невозможно. То есть, подтверждение произойдёт после того, как система удостоверится, что пользователь внёс в форму все необходимые детали, при отсутствии сведений хотя бы в одном из обязательных полей в подтверждении будет отказано. Эти поля должны быть чётко обозначены, чтобы пользователи знали, какие данные следует внести.
Валидация Web-Форм: Практика и рекомендации

На форме добавления комментария в блог Komodo Media обязательные поля отмечены вспомогательной надписью "обязательно к заполнению".

Обычно обязательные поля отмечают астериском (*). Однако, не всем пользователям известно, для чего ставится этот значок. Новички или пожилые люди могут иметь очень смутное представление о значении астериска. Поэтому хорошо бы давать у верхней границы формы пояснение об обязательном заполнении всех отмеченных астериском полей или выделять их как-то иначе. Если все поля обязательные, в астерисках или выделении нет необходимости. Достаточно простого уведомления в том, что заполнять нужно все пункты формы.
Валидация Web-Форм: Практика и рекомендации

Facebook не требует заполнения обязательных полей. Пользователи узнают, что необязательных нет вообще, только нажав кнопку "отправить".

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

Правильный формат

Помимо проверки полноты необходимой информации, операция подтверждения отслеживает соблюдение пользователями заданного формата. Это касается различных данных - адресов электронной почты, URL, дат, телефонных номеров и других. Если сведения предоставлены в неправильном формате, пользователям должно быть сообщено об этом и приведён пример правильного формата. Видимо, легче всего подтверждать "правильность" форматирования, используя регулярные выражения.

Пожалуйста, помните, что зачастую лучше не навязывать пользователям строгий шаблон ввода данных; пусть пишут по-своему, в разных форматах, а приложение заставьте грамотно эту информацию толковать. Пользователь всего лишь хочет выполнить действие, а не вникать в "правильность" форматов и сложности пользовательских интерфейсов. Дайте пользователю напечатать то, что ему нужно, а ПО, при необходимости, поручите соответствующую обработку этих сведений. Такой принцип веб-дизайна часто называют "разрешительным форматом пользовательского интерфейса".
Валидация Web-Форм: Практика и рекомендации

При заполнения формы регистрации на Carbonmade подтверждение проходит корректность формата URL, пользователю отправляется сообщение об ошибке и предлагаются пути её исправления.

Чтобы больше узнать о регулярных выражениях, непременно прочтите "Основное пособие по регулярным выражениям: справки и пояснения" ("Essential Guide To Regular Expressions: Tools and Tutorials") или, если вам уже знакомы азы, - "Ключевые понятия из области применения новейших регулярных выражений" ("Crucial Concepts Behind Advanced Regular Expressions"). В этой статье мы позже вернёмся к обзору приёмов форматирования.

Поля повторного ввода

При передаче сведений, существенных для системы, принято запрашивать повторный ввод этих данных пользователем в добавочном поле. Таким образом, люди могут убедиться в том, что напечатали всё верно. Типичный пример использования таких полей - выбор пароля, хотя они иногда требуются и в других случаях, таких, как указание адреса электронной почты.
Валидация Web-Форм: Практика и рекомендации

Регистрируясь на Photobucket, пользователям пришлось повторно печатать ранее введённый пароль для проверки его правильности.

Поле повторного ввода должно размещаться рядом с ключевым полем (или ниже). Его предназначение должно чётко указываться, например, так: "Введите пароль повторно". Если выявляется расхождение признаков обоих полей, пользователь извещается об этом. Дополнительно можно включать флажок успешного выполнения операции, если признаки СОВПАДАЮТ.

Вторая часть нашего исследования привела к интересным выводам относительно применения полей повторного ввода. Адрес электронной почты требовалось дважды вводить только на 18 % сайтов, а пароль - на 72 % сайтов. К нашему удивлению, оказалось, что крупные сайты, такие как Facebook, LinkedIn, Stumbleupon и Twitter не запрашивают повторный ввод пароля.

1. Методы подтверждения
2. Что требует подтверждения
3. Сообщение об ошибке
4. Семь раз отмерь
5. Вы - человек?

3. Сообщение об ошибке

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

Выводить это сообщение лучше красным шрифтом, так как этот цвет обычно служит предупредительным сигналом, а также его следует снабдить соответствующей иконкой для привлечения большего внимания. Иконка должна быть общеузнаваемой, такой как белый крест в красной окружности. Это облегчит восприятие сообщения людям со слабым зрением. Кроме того, пользователям следует указать поля, при заполнении которых допущены неточности.
Валидация Web-Форм: Практика и рекомендации

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

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

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

Описывайте ошибки или способ их исправления коротко и ясно. Например, если дата проставлена в неверном формате, объясните пользователям, как указывать её правильно: "Даты пишутся в формате дд-мм-гггг". Иногда стоит назначать такие подсказки начальными признаками ваших полей. То есть, пользователь прочтёт указания по заполнению соответствующего пункта непосредственно в поле ввода, а когда он/она начнёт печатать, текст подсказки оттуда исчезнет.

Подтверждение через отправку формы

"Классический" способ выполнения операции подтверждения - через отправку заполненной формы нажатием кнопки "отправить". Подтверждение проводится, и, при выявлении ошибок, форма возвращается пользователю вместе с соответствующим сообщением. Таким образом, процесс заполнения формы не прерывается, что, однако, может быть не всегда на пользу дела. Приступить к исправлению ошибок пользователь сможет только после попытки отправить форму и получения от сервера отказа. Этим способом обычно производится подтверждение со стороны сервера, хотя он применим и со стороны клиента.
Валидация Web-Форм: Практика и рекомендации

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

Подтверждение в реальном времени (или мгновенное подтверждение)

В отличие от предыдущего способа, подтверждение в реальном времени происходит непосредственно при заполнении формы. Это не означает отправки запроса на подтверждение с каждым нажатием клавиши, обычно система ждёт перехода пользователя к следующему полю. Таким образом, человек сразу видит, правильно ли он вводит данные, то есть, доступно ли это имя пользователя, верен ли формат даты. Получение мгновенного подтверждения становится явным при внесении сведений в поле ввода или после перехода курсора на другое поле. Как правило, оно сопровождается текстовым сообщением, пояснением или пиктограммой.
Валидация Web-Форм: Практика и рекомендации

Форма регистрации на сайте Yahoo снабжена распознавателем уникальности пароля, который проверяет его приемлемость, пока вы печатаете текст.

Мгновенное подтверждение следует применять аккуратно и продуманно, так как, не зная меры или его особенностей, вы можете обернуть его себе во вред.
Валидация Web-Форм: Практика и рекомендации

Заполнение формы регистрации на TypePad не только сопровождается мгновенным подтверждением с отправкой сообщений при выявлении различных ошибок, но и отображением корректно введённых данных в особом режиме.

Чего следует избегать?

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

Любопытная деталь из второй части исследования SM: "30 % форм снабжались только сообщением об ошибке вверху (без выделения полей ввода), в то время как у 29 % подсвечивались поля ввода вместе с появлением на той же строке соответствующих подсказок (без сообщений об ошибках вверху страницы)". Всего 25 % задействовали и сообщения об ошибках, и поля ввода.

Удивительнее всего то, что 14 % сайтов до сих пор используют всплывающие окна в кодировке javascript для отображения результатов запроса на подтверждение, а подтверждение кодами Ajax выполняется лишь на 22 % сайтов. Это наглядно демонстрирует большой разброс мнений относительно способов отображения результатов подтверждения.

1. Методы подтверждения
2. Что требует подтверждения
3. Сообщение об ошибке
4. Семь раз отмерь
5. Вы - человек?

4. Семь раз отмерь

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

Подсказки

Если в форму требуется внести не совсем очевидные данные, пользователям могут очень пригодиться подсказки. Разъясняя им порядок ввода конкретных сведений, вы помогаете людям быстрее справляться с этой задачей и избегать возможных ошибок, вызывающих отказ в подтверждении. Подсказки обычно даются простым шрифтом рядом с полем ввода или над ним. По своему виду они должны отличаться от меток полей. Как правило, их печатают мелким сероватым шрифтом. Преимущество подсказок в том, что они всегда видны пользователю, даже при отключении javascript.
Валидация Web-Форм: Практика и рекомендации

На сайте WishListr все поля сопровождаются подсказками с правой стороны.

Флажок справки (всплывающие меню)

В отличие от подсказок, всплывающие меню выдают информацию не сразу, а "по запросу". Обычно их запускают через иконку с вопросительным знаком. Справка открывается наведением курсора на этот значок или щелчком по нему. Смещением курсора с иконки контекстное меню закрывается. Флажок справки позволяет не загромождать страницу обилием текста, особенно если справочное меню большое.
Валидация Web-Форм: Практика и рекомендации

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

Живые подсказки

Как и в предыдущем случае, живые подсказки изначально скрыты от пользователей. С началом ввода текста в определённом поле, соответствующая ему подсказка появляется на экране. Таким образом, их нельзя не заметить, а страница не загромождается лишними элементами. Эти подсказки должны располагаться так, чтобы не закрывать собой другие фрагменты формы. Обычно, они появляются рядом с полем ввода, причём, лучше помещать их справа от него, чтобы не мешать заполнению формы.
Валидация Web-Форм: Практика и рекомендации

Форма регистрации на сайте Digg снабжена живыми подсказками в виде отдельных блоков, разъясняющими заполнение активных в данный момент полей.

Применение трафаретов и переформатирование данных, вводимых пользователем

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

- meioMask
- iMask
- TypeCast
- jQuery Masked input plugin
Валидация Web-Форм: Практика и рекомендации

Учебная страничка Typecast демонстрирует разнообразие способов применения трафаретов.

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

- например, при вводе пользователем URL-адреса без приставки "http://", система могла бы просто добавлять этот элемент к началу URL;
- при указании пользователем даты в формате дд-мм-гггг вместо установленного формата гггг-мм-дд, система может изменить порядок следования символов в записи для приведения её в норму;
- при пропуске пользователем наклонной черты в номере кредитной карты, система может вставлять эти символы между цифрами номера там, где это требуется.
Валидация Web-Форм: Практика и рекомендации

Разновидность трафарета для ввода URL-адреса на сайте Tumblr.

Здесь приведены лишь несколько примеров использования этого приёма. Однако, автоформатирование нужно применять аккуратно, в противном случае оно может создавать вашим пользователям проблемы. Кроме того, вводимая информация не всегда однозначна. Например, если человек написал "www.coolwebmasters", не указав расширение, система не может строить догадки, не расширение ли это ".com", она лучше выдаст отказ в подтверждении.

Здесь вновь уместно вспомнить о "разрешительном формате пользовательского интерфейса". Вместо того, чтобы ограничивать пользователя в выборе форматов ввода, вы можете предоставить ему больше свободы в этом вопросе, а системе поручить анализ поступающей информации. В ряде случаев это увеличило бы нагрузку на сервер; на нём выполнялся бы тщательный разбор поступивших сведений, их обработка и перевод в установленные форматы для выполнения дальнейших действий.
Валидация Web-Форм: Практика и рекомендации

алендарь Google очень умело использует этот приём , отводя одно поле для добавления событий. Пользователи могут вводить информацию в разных форматах (даже писать "завтра" вместо даты); система анализирует эти сведения и сохраняет их как новое событие. Данные, не поддающиеся анализу, толкуются как название события, а пользователю в этом случае приходится заполнять расширенный вариант формы с уже введённым названием. То есть, Google вообще обходится без подтверждения.

Как показало наше исследование, 67 % сайтов используют текстовые подсказки, 10 % из них - живые подсказки. Странно, но всего 26 % этих надписей расположены справа от полей ввода, в остальных же случаях их размещают выше, ниже соответствующих полей и даже слева от них.

1. Методы подтверждения
2. Что требует подтверждения
3. Сообщение об ошибке
4. Семь раз отмерь
5. Вы - человек?

5. Вы - человек?

Говоря о подтверждении правильности заполнения формы, нельзя не упомянуть тест Тьюринга (Captcha). Это существенная часть процедуры подтверждения, так как с его помощью система отличает человека от авторегистратора псевдо-пользователей. Простейший вариант теста Тьюринга - изображение, содержащее буквы, цифры, выражения и поле, в котором это содержимое следует ввести. Первые такие тесты состояли из изображений с числами (например, "8356"), а от пользователя требовалось ввести это число. Если число не было введено верно (или вообще не вводилось), форму было невозможно отправить. Вообще-то, сейчас большинство программ автоматической рассылки спама уже умеют распознавать текст, просто нанесённый на изображение, поэтому, лучше заменить его вопросом, на который способен ответить только человек, например, "Какого цвета солнце?", а ответом назначить "жёлтый" в любых вариантах написания ("ЖЁЛТЫЙ", "жёлтый", "Жёлтый" и т. д.).

Возможно, вас также заинтересует разновидность теста Тьюринга под названием "Приманка" ("Honeypot Captcha"), в основе которой лежит неразличимость скрытых элементов формы для зрения, чтобы с сервера вычислять источник авто-рассылки, заполнивший их. Есть и другой способ: нанести на одно из полей формы метку "Не заполнять", а затем обозначить его как поле, обязательное для заполнения (спасибо Шону МакКулу).
Валидация Web-Форм: Практика и рекомендации

Простой тест Тьюринга требует осмысленного ответа на вопрос.

Тест Тьюринга, описанный выше, стал для многих пользователей камнем преткновения. Слепым, слабовидящим и не умеющим читать людям заполнение онлайн-форм с тестом Тьюринга даётся тяжело или вовсе недоступно. С развитием Интернет-технологий сильно изменились и тесты Тьюринга, так что, сейчас уже есть их модификации, например, ReCaptcha, озвучивающий текст для людей с нарушениями зрения.
Валидация Web-Форм: Практика и рекомендации

Тесты Тьюринга включают еле различимые слова. Вам легко разобрать слово с левой стороны?

Большинство пользователей ненавидят тесты Тьюринга (что вполне оправданно!). Разумеется, людям просто лень заполнять формы. Если не дать им сделать это быстро и без усилий, весьма вероятно, они вообще не станут с ним возиться. И здесь тест Тьюринга явно не способствует повышению активности: распознавание его текста может очень затянуться (если он неразборчив), что часто и происходит на практике. Помните, тест Тьюринга работает на владельцев сайта, а не на пользователей. Поэтому лучше, по возможности, обходиться без него. О тестах Тьюринга и их общедоступности можно прочесть в пособии "Нечитаемые тесты Тьюринга" ("Inaccessibility of CAPTCHA").
Валидация Web-Форм: Практика и рекомендации

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

Автор статьи © Janko Jovanovic
Русский перевод © CoolWebmasters.Com 2009
Вернуться назад