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

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

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

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

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

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

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

[ Изменить: некоторые пояснения]

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Inline Validation в веб-формах от Luke Wroblewski

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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