What Event to Trigger Javascript Form Field Validation and Formatting?

Question

Let me first say, we validate every field on the server side, so this a question about client-side usability.

What is the conventional wisdom on exactly when to validate and format html form input fields using javascript?

As an example, we have a phone number field. We allow numbers, spaces, parentheses, and hyphens. We want the field to have ten digits. Also, we want the field to look like (123) 456-7890, even if the user doesn't type it that way.

It seems like we can

• 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.
• Some combination of the above (e.g. format on entry and validate on exit, prevent on entry and format on exit, etc.)
• [Added] Wait and do all the validation and formatting when the user clicks submit.

I've seen it done all of these ways, but I can't find information about what is best (or even generally accepted) from a usability perspective, and more importantly, why.

[Edit: Some clarification]

We are absolutely not enforcing any format standards. When I say format, I mean we'll use javascript to rewrite things so they look nice. If the user types 1234567890, we'll change it to (123) 456-7890. There are no "formatting rules" that can fail.

I distinguish this from validation because if they don't type enough numbers, we have to make them fix it.

I guess I should rephrase the question as "what is the conventional wisdom on exactly when to validate and exactly when to format...?

Good info in the answers so far!

EDIT: I'm accepting my own answer below in the hopes that others will find the link as helpful as I did.

Answer 1

I find the first three options to be really annoying. There's nothing worse than being interrupted in the middle of typing something.

Your user's main goal is getting through the form as fast as possible and anything you do that slows them down is just one more reason for them to give up on it entirely.

I also hate being forced to type something like a credit card # or phone # is exactly the right format to satisfy the form. Whenever possible, just give the user a box to type stuff into and don't make them deal with the formatting.

In the case of your phone #, let them enter it however they want, strip out anything you don't like, try to put it back together into the format you want ( (124) 567-8901 ) and throw an error if you can't.

If you absolutely must validate something to a specific format, do it when they submit the form and then highlight the fields that have problems.

Answer 2

It depends per field. But for something like a phone number, it's generally pretty nice to prevent someone from even entering non-digits.

That way, when typing you'll notice that your 1-800-HELLOWORLD phone number isn't showing up correctly and realise that the field only accepts numbers (which you can also highlight with some sort of information field alongside the input field).

That seems to me to be a lot more inuitive and friendly than an awkward modal dialogue, pop-down error field or server-generated message displaying after you're done filling it out.

Of course, always balance the ultimate client-side validation with the ultimate technical requirements to build it. If you start down the path of, say, validating image uploads with Ajax before the page submits, that can be a pretty long road.

Edit: also, consider your audience. The more technically minded are going to be more accepting of "dynamic" forms than, say, people who are more accustomed to the non-Ajax approach to the Internet.

Answer 3

I was going to describe various options but it may be beneficial just to use an existing js framework to handle input masks. Here is a good run down of various options

Answer 4

Personally I think formatting and validating on exit is the least bothersome to the user. Let them enter the number in whatever format they like (and there are a lot of these for a phone number) and then change it to the format you like. Don't force the user to conform to your preferences when you can handle the data in their preferred format.

Also, validation messages when I'm not done typing are annoying, and not being able to put a certain character in a text field is super-annoying.

The only exception I can think of is "is this value available" situations (such as creating a unique username) - in that case immediate feedback is really convenient.

Answer 5

The most user friendly way I've seen to do validation is to have an indicator that shows up next to the input field to indicate the value is invalid. This way you don't interrupt the user as they're typing and yet they can continually see whether or not they've typed a valid entry. I hate having to type information into a long form only to have the thing tell me at the end "Oh, you need to go back and fix field 1".

You can have the indicator be show/hidden as the user types. I use a warning icon when the value is invalid and I set a tooltip on the icon that explains why the value is invalid.

If you have the screen real estate, you could just put text such as "Valid" or "Must be in format XXX-YYY-XXXX".

Keep in mind that when you do per keystroke validation you also need to catch pasted text.

In addition to this, you should also prevent invalid keystrokes to be entered in the first place.

Answer 6

Validate and format it when the user exits the field.

Yes. Provide noninvasive feedback to the user if validation or formatting rules fail. By noninasive I mean don't popup an alert or modal dialog box, thereby forcing the user to click something. Rather dynamically display a message adjacent or underneath the field where validation or formatting failed.

Validate and format on every character entered.

No. I think that hinders usability. Instead provide the user with a tooltip or some other hint as to what the formatting rules are or validation rules are. E.g. for a "required" field the practically ubiquitious asterisk, and for fields with formatting tell the user up front what the expected format is.

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

If you are going to prevent the user from entering invalid characters, tell the user why you just blocked their input, noninvasively. Also,do not steal focus of the field.

So for me the general principles are:

1. Inform the user up front about your validation and formatting rules.
2. Do not assume the user is sighted, so keep web accessiblity and screen readers in mind. (Unless you are developing a web site that has a limited target audience such as an Intranet.)
3. Provide the user with noninvasive feedback, meaning do not make the user click on an alert box or modal dialog upon each failure.
4. Make it obvious which input box failed validation or formatting rules, and tell the user why their input failed.
5. Do not steal the mouse/pointer focus, when providing feedback.
6. Keep tab order in mind, so that when keyboard oriented users complete a field, they can hit tab and go to the next logical input/selection field.

Answer 7

bmb states that they are accepting any format, and changing it to the desired format (xxx) nnn-xxxx. That is very good. The question is the timing of A) the format change, and B) the validation.

A) The format change should be done as the user exits the field. Sooner is annoying and later defeats the purpose of displaying the change at all.

B) Validation is most appropriately performed either on exiting the field or on submitting the form. Sooner is frustrating and confusing to the user. In a long and complex form, with more than one screen, I would favor doing validation on exiting the control to make corrections easier. On a short form, I would do it upon submit to avoid breaking the flow of filling out the form. It is really a judgment call, so test it with real users if at all possible.

Preferably you are testing your work with real users anyway, but if you do not have budget or access for that, a quick and dirty "user" test can help with decisions like this one. You can grab a handful of people who did not work on the software (as close a match to your real end users as possible) and ask them to fill out the form. Instruct them to enter things a specifically to get an error and then watch them correct it. Ask them to talk aloud through what they are doing so you don't need to guess at their thought process. Look for where they have issues and what seems to confuse/annoy them most.

Answer 8

For usability best practices, I suggest reading How To Design The Perfect Form (more precisely Context & Assistance) and Beautiful Forms.

For a form validation framework, check the fValidator and iMask combo, they are complementary and thus work perfectly together.

Answer 9

By far the best answer so far was not an answer but a comment (see above.) I'm adding it as an answer in case anyone misses it in the comment.

See the following article on A List Apart.

Inline Validation in Web Forms by Luke Wroblewski