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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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