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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Validate and format it when the user exits the field.

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

Validate and format on every character entered.

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

Intercept keystrokes and prevent the user from entering characters that are wrong.

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

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

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

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

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

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

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

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

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

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

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

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