Среди дизайнеров часто обсуждаются вопросы о размещении кнопок (действий) в веб формах. Типичным вопросом из этой дискуссии есть:
Одна сторона дискуссии утверждает что является естественной организация: действия, которые ведут вперед размещаются справа, назад- слева. Другая сторона придерживается мнения что понятие «Первичные » действия (те что двигают людьми вперед ) перевешивает это соображение и что «Вторичные» действия (которые меньше используются) могут быть размещены справа от «Первичных», даже если «Вторичные » ведут на предыдущие шаги. Присутствие хорошо заметных первичных действий по ходу взгляда пользователей (на «линии огня») позволяют сфокусироваться на финальных действиях заполнения формы.
Обе стороны! Одной из причин по которой возникает так много дискуссий на эту тему заключается в том что слишком часто веб-дизайнеры (разработчики) создают «Мастер» (из Windows) в котором пользователи двигаются через цепочку шагов.
В подавляющем большинстве веб-форм люди просто хотят ответить на вопросы, которые им задают и двигаться дальше. Таким образом считая первичным действием «Продолжить» и вторичным действием «Назад» находим в этом новый смысл.
Размещение первичных действий на пути взгляда пользователя (непосредственно под последним вопросом формы) дает понять что он может и должен продвигаться вперед. При перемещении по ходу линейного потока информации (такого как оформление заказа в интернет магазинах ) возвращение на предыдущий этап бывает затруднительно, такие сценарии можно покрыть через проверку введенной информации в финальном окне. В действительности, как показывают исследование, очень мало пользователей используют кнопку «Назад» в формах.
Но все-же есть случаи когда пользователям по каким-то причинам необходимо прыгать по шагам формы. В этих случаях «Назад» и «Вперед » можно считать первичными действиями и размещать их слева направо, соответственно по ходу движения, как пейджер.
Эти рассуждения помогают выбрать нужный вариант размещения кнопок «Назад» и «Вперед».
На рисунке стоит избегать первого варианта, поскольку пользователь может ошибочно выбрать «Назад», приняв его за первичное действие, чем сильно собьётся с пути к финальному шагу. Избежать этой проблемы можно сделав визуально разными эти действия, при этом сохранив порядок (как показано на картинке). Если же «Назад» и «Вперед» являются первичными действиями, то не следует разрывать порядок слева направо ( нижние два примера на рисунке).
Формы, в которых подпись к полю ввода размещена сверху наиболее подвержены проблеме действий «Назад-Вперед», поскольку у них меньше пространства слева от полей ввода. В таком случае сохранение порядка слева направо (Назад-Вперед) может привести к непреднамеренному нажатию кнопки «Назад» вместо того чтоб закончить заполнение формы. Тогда стоит расположить действия: слева «Вперед», справа «Назад», чтоб не мешать продвижению пользователя по форме.
В каждом из этих примеров простые соображения подсказывают дизайнерские решения: показать первичное действие, которое поведет пользователя вперед; не запутывать пользователя размещением функций слева направо (Назад- Вперед); знать когда Назад и Вперед действительно оба первичные действия и отображать их соответственно.
Ответ на вопрос дискуссии лежит не в четком соблюдении положений статьи, а в том чтоб понимать эти рассуждения и действовать соответствующим образом.
Может ли действие которое ведет к предыдущему шагу процесса размещаться справа от действия что ведет вперед ?
Одна сторона дискуссии утверждает что является естественной организация: действия, которые ведут вперед размещаются справа, назад- слева. Другая сторона придерживается мнения что понятие «Первичные » действия (те что двигают людьми вперед ) перевешивает это соображение и что «Вторичные» действия (которые меньше используются) могут быть размещены справа от «Первичных», даже если «Вторичные » ведут на предыдущие шаги. Присутствие хорошо заметных первичных действий по ходу взгляда пользователей (на «линии огня») позволяют сфокусироваться на финальных действиях заполнения формы.
Так кто же прав?
Обе стороны! Одной из причин по которой возникает так много дискуссий на эту тему заключается в том что слишком часто веб-дизайнеры (разработчики) создают «Мастер» (из Windows) в котором пользователи двигаются через цепочку шагов.
В подавляющем большинстве веб-форм люди просто хотят ответить на вопросы, которые им задают и двигаться дальше. Таким образом считая первичным действием «Продолжить» и вторичным действием «Назад» находим в этом новый смысл.
Размещение первичных действий на пути взгляда пользователя (непосредственно под последним вопросом формы) дает понять что он может и должен продвигаться вперед. При перемещении по ходу линейного потока информации (такого как оформление заказа в интернет магазинах ) возвращение на предыдущий этап бывает затруднительно, такие сценарии можно покрыть через проверку введенной информации в финальном окне. В действительности, как показывают исследование, очень мало пользователей используют кнопку «Назад» в формах.
Но все-же есть случаи когда пользователям по каким-то причинам необходимо прыгать по шагам формы. В этих случаях «Назад» и «Вперед » можно считать первичными действиями и размещать их слева направо, соответственно по ходу движения, как пейджер.
Эти рассуждения помогают выбрать нужный вариант размещения кнопок «Назад» и «Вперед».
Так как следует их размещать?
На рисунке стоит избегать первого варианта, поскольку пользователь может ошибочно выбрать «Назад», приняв его за первичное действие, чем сильно собьётся с пути к финальному шагу. Избежать этой проблемы можно сделав визуально разными эти действия, при этом сохранив порядок (как показано на картинке). Если же «Назад» и «Вперед» являются первичными действиями, то не следует разрывать порядок слева направо ( нижние два примера на рисунке).
Что делать если подпись полей сверху?
Формы, в которых подпись к полю ввода размещена сверху наиболее подвержены проблеме действий «Назад-Вперед», поскольку у них меньше пространства слева от полей ввода. В таком случае сохранение порядка слева направо (Назад-Вперед) может привести к непреднамеренному нажатию кнопки «Назад» вместо того чтоб закончить заполнение формы. Тогда стоит расположить действия: слева «Вперед», справа «Назад», чтоб не мешать продвижению пользователя по форме.
В каждом из этих примеров простые соображения подсказывают дизайнерские решения: показать первичное действие, которое поведет пользователя вперед; не запутывать пользователя размещением функций слева направо (Назад- Вперед); знать когда Назад и Вперед действительно оба первичные действия и отображать их соответственно.
Ответ на вопрос дискуссии лежит не в четком соблюдении положений статьи, а в том чтоб понимать эти рассуждения и действовать соответствующим образом.
