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

Question

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

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

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

Похоже, что мы можем

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

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

[Edit: Некоторые разъяснения]

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

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

Я предполагаю, что я должен перефразировать вопрос «что общепринятая на точно, когда для проверки и когда именно форматировать? ...

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

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

Answer 1

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

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

Inline Validation in Web Forms by Luke Wroblewski

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

Я собирался описать различные варианты, но может быть полезно использовать существующую инфраструктуру js для обработки входных масок. Here is a good run down of various options

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

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

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

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

Answer 9

Для удобства использования рекомендуется предложить How To Design The Perfect Form (точнее Context & Assistance) и Beautiful Forms.

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