Какое событие инициирует проверку и форматирование поля формы Javascript?

Question

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

Каков обычный подход к , когда проверяет и форматирует поля ввода html-формы с использованием javascript?

Например, у нас есть поле номера телефона. Мы допускаем числа, пробелы, скобки и дефисы. Мы хотим, чтобы в поле было десять цифр. Кроме того, мы хотим, чтобы поле выглядело как (123) 456-7890, даже если пользователь не вводит его таким образом.

Кажется, мы можем

• Подтвердите и отформатируйте его, когда пользователь выходит из поля.
• Проверить и отформатировать на каждый введенный символ.
• Перехватывать нажатия клавиш и предотвращать пользователь вводит неправильные символы.
• Некоторая комбинация вышеперечисленного (например, форматировать при входе и проверять при выходе, запрещать при входе и форматировать при выходе и т. д.)
• [ Добавлено ] Подождите и выполните все проверки и форматирование, когда пользователь нажимает кнопку Отправить.

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

[ Редактировать : некоторые пояснения]

Мы абсолютно не соблюдаем какие-либо стандарты формата. Когда я говорю «формат», я имею в виду, что мы будем использовать javascript, чтобы переписывать вещи, чтобы они выглядели красиво. Если пользователь введет 1234567890, мы изменим его на (123) 456-7890. Не существует «правил форматирования», которые могут не сработать.

Я отличаю это от проверки, потому что, если они не набирают достаточно чисел, мы должны заставить их исправить это.

Полагаю, мне следует перефразировать вопрос следующим образом: "Каково общепринятое мнение о том, когда именно проверять и когда именно форматировать?"

Хорошая информация в ответах до сих пор!

РЕДАКТИРОВАТЬ : Я принимаю мой собственный ответ ниже в надежде, что другие найдут ссылку столь же полезной, как и я.

Answer 1

Подтвердите и отформатируйте его, когда пользователь покинет поле.

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

Проверка и форматирование для каждого введенного символа.

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

Перехватывать нажатия клавиш и предотвращать ввод неправильных символов.

Если вы собираетесь запретить пользователю вводить недопустимые символы, скажите пользователю, почему вы просто заблокировали его ввод, неинвазивно. Кроме того, не крадите фокус поля.

Так что для меня общие принципы:

1. Информируйте пользователя заранее о ваших правилах проверки и форматирования.
2. Не думайте, что пользователь зрячий, поэтому помните о доступности веб-страниц и программах чтения с экрана. (Если вы не разрабатываете веб-сайт с ограниченной целевой аудиторией, такой как Интранет.)
3. Предоставлять пользователю неинвазивную обратную связь, то есть не заставлять пользователя нажимать на окно предупреждения или модальное диалоговое окно при каждом сбое.
4. Сделайте очевидным, какое поле ввода не прошло проверку или правила форматирования, и сообщите пользователю, почему его ввод не удался.
5. Не крадите фокус мыши / указателя при обратной связи.
6. Следует помнить порядок табуляции, чтобы, когда пользователи, ориентированные на клавиатуру, заполняли поле, они могли нажимать клавишу Tab и переходить к следующему логическому полю ввода / выбора.

Answer 2

Пока что лучшим ответом был не ответ, а комментарий (см. Выше). Я добавляю его как ответ на случай, если кто-то пропустит его в комментарии.

См. Следующую статью в A List Apart.

Встроенная проверка в веб-формах от Luke Wroblewski

Answer 3

bmb заявляет, что они принимают любой формат и меняют его на нужный формат (xxx) nnn-xxxx. Это очень хорошо. Вопрос заключается в том, когда A) изменение формата и B) проверка.

A) Изменение формата должно быть сделано, когда пользователь покидает поле. Рано раздражает, а потом и вовсе отказывается от цели отображения изменений.

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

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

Answer 4

Я собирался описать различные варианты, но может быть полезно просто использовать существующую среду js для обработки масок ввода. Вот хороший список различных вариантов

Answer 5

Для получения рекомендаций по юзабилити я предлагаю прочитать Как создать идеальную форму (точнее Контекст и помощь ) и Красивые формы .

Для платформы проверки формы, проверьте комбо fValidator и iMask , они дополняют друг друга и поэтому прекрасно работают вместе.

Answer 6

Самый удобный для пользователя способ проверки, который я видел, заключается в том, чтобы рядом с полем ввода отображался индикатор, указывающий, что значение недопустимо. Таким образом, вы не прерываете пользователя, когда он печатает, и все же они могут постоянно видеть, набрали ли они правильную запись. Я ненавижу вводить информацию в длинную форму только для того, чтобы в конце она сказала мне: «О, тебе нужно вернуться и исправить поле 1».

Вы можете настроить отображение / скрытие индикатора при вводе пользователем. Я использую значок предупреждения, когда значение недопустимо, и на значке устанавливаю всплывающую подсказку, объясняющую, почему значение недопустимо.

Если у вас есть экранная недвижимость, вы можете просто поместить текст, такой как «Действительный» или «Должен быть в формате XXX-YYY-XXXX».

Имейте в виду, что при проверке нажатий клавиш также необходимо отлавливать вставленный текст.

В дополнение к этому, вы также должны запретить ввод недействительных нажатий клавиш.

Answer 7

Лично я считаю, что форматирование и проверка при выходе наименее утомительна для пользователя. Позвольте им ввести номер в любом формате, который им нравится (а для номера телефона их много), а затем измените его на формат, который вам нравится. Не заставляйте пользователя соответствовать вашим предпочтениям, если вы можете обрабатывать данные в их предпочтительном формате.

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

Единственное исключение, о котором я могу подумать, - это ситуации "доступно это значение" (например, создание уникального имени пользователя) - в этом случае немедленная обратная связь действительно удобна.

Answer 8

Это зависит от поля. Но для чего-то вроде телефонного номера, как правило, неплохо запретить кому-либо даже вводить не цифры.

Таким образом, при наборе вы заметите, что ваш телефонный номер 1-800-HELLOWORLD не отображается правильно, и поймете, что поле принимает только цифры (что можно также выделить с помощью некоторого информационного поля рядом с вводом поле).

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

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

Редактировать: также рассмотрим вашу аудиторию. Более технически мыслящие люди будут больше воспринимать «динамические» формы, чем, скажем, люди, которые более привыкли к не-Ajax-подходу к Интернету.

Answer 9

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

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

Я также ненавижу заставлять печатать что-то вроде кредитной карты # или телефона # - это именно тот формат, который соответствует форме. Когда это возможно, просто дайте пользователю коробку для ввода текста и не заставляйте его разбираться с форматированием.

В случае вашего телефона #, позвольте им ввести его так, как они захотят, вычеркните все, что вам не нравится, попробуйте собрать его обратно в нужный формат ((124) 567-8901) и бросьте ошибка, если вы не можете.

Если вам абсолютно необходимо проверить что-либо в определенном формате, сделайте это, когда они отправят форму, а затем выделите поля, в которых возникли проблемы.