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

Question

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

В чем состоит общепринятое мнение именно когда проверять и форматировать поля ввода HTML-формы с помощью JavaScript?

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

Встроенная проверка в веб-формах, Люк Вроблевски

Answer 2

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

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

Проверьте и отформатируйте каждый введенный символ.

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

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

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

Итак, для меня общие принципы таковы:

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

Answer 3

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

Answer 4

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

А) Изменение формата должно выполняться при выходе пользователя из поля.Рано раздражает, а позже вообще не дает смысла отображать изменения.

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

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

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

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

Answer 9

Чтобы узнать о лучших практиках юзабилити, я предлагаю прочитать Как создать идеальную форму (точнее Контекст и помощь) и Красивые Формы.

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