Рекомендации по интерфейсу форм

от автора


Проектирование форм может оказаться настоящей проблемой. Чтобы получилось что-то стоящее и удобное для пользователей необходимо принять во внимание кучу разных рекомендаций и правил. В данной статье я постарался составить полезный список таких рекомендаций. Для его составления я использовал свой опыт и статьи экспертов.

Основные рекомендации и ввод данных

  • Стремитесь к краткости.
  • Убедитесь, что в форме используется один язык (обороты, термины).
  • Если на странице находится только форма и ничего кроме нее, то при загрузке страницы стоит ставить фокус на первое поле формы, это позволит сэкономить немного времени (страница поиска, входа, регистрации).
  • Поддерживайте ясный путь заполнения формы.
  • Избегайте вторичных действий, если это возможно.
  • В противном случае четко разделяйте основное и дополнительные действия.
  • Выравнивайте основное действие так же как и поля формы, это упрощает восприятие формы.
  • Цветная подложка у главной кнопки сделает её более видимой.
  • Отключайте кнопку «Отправить» после того как пользователь на нее нажал, это позволит избежать двойной отправки данных.
  • Еще лучше — показывайте индикатор отправки.

Группировка, табы и многостраничные формы

  • Размещайте похожие поля рядом.
  • Группируйте поля так, чтобы пользователю приходилось переключать раскладку поменьше.
  • Используйте подходящую группировку полей для организации содержимого формы.
  • Используйте минимальное количество визуальных элементов, необходимые для выделения формы.
  • Если форму можно легко разбить на несколько коротких форм, то используйте одну страницу для нее.
  • Если форма содержит большое число вопросов, связанных с несколькими темами – используете несколько страниц.
  • Если форма содержит большое число вопросов по одной теме – используйте длинную страницу.
  • Для мастеров обеспечьте возможность возврата к предыдущим шагам.
  • В мастерах избегайте вложенных шагов, делайте их последовательными.

Поля

  • Оцените целесообразность наличия каждого поля.
  • Ищите возможности для удаления ненужных полей.
  • Не усложняйте одни поля для того чтобы удалить другие.
  • Если возможно ввести данные больше чем одним способом — используйте гибкий ввод, например, при вводе номера телефона.
  • Обеспечение гибкого ввода не делает заполнение простых полей труднее.
  • Используйте маски ввода для ввода конкретных данных, например дат.
  • Маски ввода могут сократить время заполнения поля, т.к. некоторые символы уже будут введены.
  • Если ожидаются только символы определенного типа, то убедитесь что пользователь знает об этом.
  • Если вводится не тот символ — заметно, но не навязчиво уведомите пользователя.
  • Убедитесь, что значения по умолчанию соответствуют целям пользователя.
  • Персонализированные значения по умолчанию позволяют вернувшимся пользователям быстрее заполнить форму, например запоминайте имейл в форме ввода комментария.
  • Помните про заполнение формы с помощью клавиатуры и tab.
  • Используйте tabindex для контроля работы tab.
  • Обеспечьте логичный порядок заполнения полей при проектировании форм.
  • Если формой будут пользоваться для управления большим количеством данных, то у полей необходимо отключить автозаполнение, иначе со временем так будут хранится все возможные значения.
  • Поля недоступные для редактирования и их поля должны выглядеть соответствующим образом.

Подписи

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

  • Избегайте многострочных подписей к полям.
  • Подписи должны четко отражать ожидаемые данные.
  • Старайтесь не помещать на форму необязательные поля, может их вообще не стоит заполнять пользователю.
  • Если большинство полей обязательны для заполнения — выделите необязательные.
  • Если большинство полей необязательные — выделите обязательные.
  • Лучше выделять обязательные поля текстом, но * или выделение шрифтом/цветом тоже подойдет.
  • Название формы должно соответствовать задачам формы.
  • Сведите к минимуму подсказки и советы необходимые для заполнения формы.
  • Помощь должна быть контекстной – находится возле нужного поля и быть полезной.
  • Когда запрашиваете много незнакомых для пользователя данных — используйте динамическую систему помощи, всплывающие подсказки, например.
  • Используйте выравнивание и объединение в группы для показа того, как связаны между собой данные.

Рекомендации по валидации и подсказкам

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

Рекомендации по чекбоксам и радио-кнопкам

  • Флажок и радио-кнопка всегда располагаются слева от подписи.
  • Кастомный дизайн элементов должен быть максимально близок к стандартному представлению.
  • Располагайте списки вертикально, с одним вариантом на строке.
  • Если несколько флажков или радио-кнопок расположено друг под другом, то между ними должно быть одинаковое расстояние.
  • Если нужно использовать их горизонтально, с несколькими вариантами на строке, сделайте достаточно места между ними элементом и подписью, четко выделяя какая надпись куда относится. .
  • Используйте позитивные формулировки для подписей чекбоксов, так, чтобы ясно понятно, что произойдет, когда пользователь выберет его.
  • Пишете подписи так, чтобы пользователи могли понять, что будет если они его выберут, и что будет, если они оставят его пустым.
  • Если вы не можете так сделать, то лучше сделать две радио кнопки, одну для включения возможности, а вторую — для отключения, и написать ясные подписи для каждого случая.
  • Если возможно, используйте радио кнопки вместо коротких выпадающих списков.
  • Всегда ставьте вариант по умолчанию для всех списков радио кнопок.
  • Так как радио кнопки позволяют выбрать только один вариант, убедитесь, что оба варианта не противоречат друг другу, явно отличаются друг от друга.
  • Убедитесь, что радио-кнопки полностью покрывают необходимую сферу данных, если нет, добавьте вариант «другое» и текстовое поле для ввода своего варианта. Это относится и к выпадающим спискам.
  • Позвольте пользователям выбирать опцию кликая не только по чекбоксу/кнопке, но еще и по их подписи: на цель большого размера легче кликнуть, в соотвствии с законом Фиттса. В HTML формах, вы можете легко это достичь, просто окружив каждую надпись тегом label.
  • Используйте чекбоксы и радиокнопки только для смены состояниея, а не как кнопку действия или отправки формы.

Выпадающие списки

  • Если вариантов в списке больше чем 2-3, то их следует отсортировать по алфавиту, это убыстрит поиск нужного элемента.
  • Если предполагается вариант «Другое», то он должен быть в конце.
  • Если вариантов достаточно много, но они разбиваются на группы по смыслу, то это стоит сделать.
  • Если список длинный, но есть группа наиболее популярных значений (около 5-7 шт.), их можно перетащить вверх списка.
  • Если список ооочень длинный, то нужно использовать автокомплит.
  • Если в выпадающем списке только варианты да/нет, то заменяем его на флажок.
  • Если количество значений в выпадающем списке всегда постоянно, и оно меньше 4-5, то такой список разворачивается в горизонтальную группу радио-кнопок.

Рекомендации по кнопкам «Отмена» и «Очистить»

  • Кнопка «Отмена» в хороших интерфейсах не требуется вовсе, т.к. используются другие механизмы навигации – кнопка назад в браузере, хлебные крошки и меню.
  • Кнопку отмены желательно заменять ссылкой, подчеркивая её второстепенность.
  • Кнопку очистить тоже стоит делать ссылкой. Размещать её стоить только в нужных для этого местах, к примеру в фильтрах и поисках.
  • Самая главная проблема заключается в том, что пользователи часто по ошибке нажимают кнопку Reset вместо кнопки Submit. Одно нажатие — и вся кропотливая работа исчезла.
  • Наличие двух кнопок в конце формы вносит неразбериху в интерфейс, и для пользователя затруднительно четко определить свой следующий шаг. Некоторое время зря тратится на рассматривание этой бесполезной кнопки, чтобы разобраться, какую же из двух кнопок надо нажимать.
  • Даже если пользователь действительно желает удалить некоторые данные, которые он ввел в форму, наличие выделенной кнопки для выполнения этой функции может только замедлить его работу, так как перед ни возникают два выбора:
    • отредактировать поля, содержащие неверные данные, заменив старый текст на новый.
    • нажать кнопку Reset и набрать новый текст во все девственно чистые поля формы.

  • Дополнительные варианты выбора только требуют дополнительных мысленных усилий, а при работе с оптимально настроенным интерфейсом будет сэкономлено больше времени, чем потеряно на дополнительное обдумывание действий там, где надо просто перейти к следующему этапу. На выбор одного из двух вариантов уходит не менее одной-двух секунд, так что лучше вообще не ставить пользователя перед этим выбором. Секунда может показаться каплей, но эта капля выливается в 100-миллионные убытки от уменьшения производительности в масштабах года для всей планеты.

ссылка на оригинал статьи http://habrahabr.ru/post/155213/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *