Большинство веб форм безжизненны. Пока вы не нажмете на кнопку «Подтвердить» они вам не ответят, но так быть не должно! Проверка в реальном времени может помочь людям заполнять веб-формы быстрее и с меньшими затратами усилий, меньшим количеством ошибок, и (сюрприз!) Больше удовлетворения.

«Inline» проверка выдает людям несколько типов отзыва в реальном времени: подтвердить соответствующий ответ, предложить правильные ответы, и обеспечить регулярное обновление, чтобы помочь людям продолжить заполнять.

Для иcследования «inline» проверки введенных данных использовалась подопытная форма вот такого образца :

Для исследования респондентам предлагалось заполнить форму. Исследование завершалось после того как пользователи заполнят правильно форму.

Что же дало исследование?

Участники были быстрее, более успешны и менее подвержены ошибкам, и более удовлетворены, когда они использовали формы с встроенной проверкой. Eye-Tracking также показал, что они «фиксировались» на форме со встроенной проверкой реже и меньше времени, это означает что для них эти формы были визуально легче чем без встроенной проверки. Это, вероятно потому, что они не просматривают всю форму после подтверждения данных, чтоб исправить какие-то ошибки, вместо этого они решили ошибки по ходу заполнения.

Вот пример запольнения обычной формы :

И пример формы с «inline» проверкой:

Исследование показало, что форма с «inline» проверкой  показала лучшие результаты по всем измеренным параметрам. В частности лучшие результаты были продемонстрированы в :

• 22% увеличение коэффициента успеха,
• 22% уменьшение ошибок,
• 31% увеличение коэффициента удовлетворенности,
• 42% уменьшение времени заполнения,
• 47%-ное снижение числа фиксации взгляда.

Поэтому лучше использовать «inline» проверку в реальном времени для большей лояльности пользователей к вашему сайту, увеличения числа пользователей (поскольку пользователь может бросить заполнять непонятную форму и уйти на сайт конкурента), уменьшение времени на заполнение.

• Eye-traсking
• UX советы для не специалистов
• Iforum — форум интернет деятелей (1.04)

Может ли действие  которое ведет к предыдущему шагу процесса размещаться справа от действия что ведет вперед ?

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

Так кто же прав?

Обе стороны! Одной из причин по которой возникает так много дискуссий на эту тему заключается в том что  слишком часто веб-дизайнеры (разработчики) создают «Мастер» (из Windows)  в котором пользователи двигаются через цепочку шагов.

В подавляющем большинстве веб-форм люди просто хотят ответить на вопросы , которые им задают и двигаться дальше. Таким образом считая первичным действием «Продолжить» и вторичным действием «Назад» находим в этом новый смысл.

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

Но все-же есть случаи когда пользователям по каким-то причинам необходимо прыгать по шагам формы. В этих случаях «Назад» и "Вперед " можно считать первичными действиями и размещать их слева направо, соответственно по ходу движения, как пейджер.

Эти рассуждения помогают выбрать нужный вариант размещения кнопок «Назад» и «Вперед».

Так как следует их размещать?

На рисунке стоит избегать первого варианта, поскольку пользователь может ошибочно выбрать «Назад», приняв его за первичное действие, чем сильно собьётся с пути к финальному шагу. Избежать этой проблемы можно сделав визуально разными эти действия, при этом сохранив порядок (как показано на картинке). Если же «Назад» и «Вперед» являются первичными действиями, то не следует разрывать порядок слева направо ( нижние два примера на рисунке).

Что делать если подпись полей сверху?

Формы , в которых подпись к полю ввода размещена сверху наиболее подвержены проблеме действий «Назад-Вперед», поскольку у них меньше пространства слева от полей ввода. В таком случае сохранение порядка слева направо (Назад-Вперед) может привести к непреднамеренному нажатию кнопки «Назад» вместо того чтоб закончить заполнение формы. Тогда стоит расположить действия: слева  «Вперед», справа  «Назад», чтоб не мешать продвижению пользователя по форме .

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

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

Статья "Previous and Next Actions in Web Forms " , автор Люк Врублевски (Luke Wroblewski) опубликована 21.09.2008 в его блоге http://www.lukew.com/

Перевел Олег Карапузов, сайт Usabilist.com.ua

Читайте также:
• «Глупые» пользователи
• Проектировать сайт для новичков или для продвинутых?
• Зачем нужны юзабилисты?
• Не слушайте пользователей (правило юзабилити)

• Юзабилити Украина 2010
• Полезные ссылки выпуск №1
• Полезные ссылки выпуск №7