What's a better user experience: highlight errors, or block wrong keystrokes?

Question

I have some information to enter in a text box. The data is structured and only some sequences are valid. For a phone number, for instance, a letter such as A is invalid.

So should I intercept keyboard events and prevent typed letters from reaching the text box, or should I draw some red squiggly lines (or another visual cue) to let my user know the letter is not acceptable? Which is a better user experience?

Answer 1

Overriding a user's control of his or her computer will always be an interruption, and often be perceived as an invasion, of that user's workflow. The web site "isn't supposed to" have control of our computers, so exerting such control will be at least a little alarming.

That said, you broach a really important topic, being the importance of letting a user know their entry is invalid before they fill out an entire set of fields and submit them.

The approach I've found to be the least-intrusive but provide the quickest turn-around response is the flow below.

Essentially, wait for them to fill out their first field, then as they click/tab around a new field (or a field that has been invalidated), check the field that was just completed. If the field that was just completed is valid, print an unobtrusive "good" icon next to it (green, checkmark, happy face, you get the idea). If it fails the validation rules, discretely print a "bad" icon (red, "X", etc.) and a short line about what failed.

But remember, do not interrupt their workflow:

• No pop-ups
• no overlays

When they're finished with the field they moved to, they'll either go back to the invalid field or move on and go back later. Either way, they'll see that they have an edit to make but can do it on their own time.

In the end, they'll have a completely valid form before ever submitting, which means

1. They'll only have to submit once
2. They don't spend time getting mad or frustrated when their submission "fails"
3. They'll like your site more
4. Everyone will have cake

Answer 2

Being on both ends of using a form, here are some guidelines I prefer:

• User inputs should hardly ever be prevented. Meaning if I type the letter 'A' in a phone number field, I would expect to see that 'A'.
• I begin my text field validation on a onBlur() event, and no sooner than that. This gives the user a chance to fix that mis-typed 'A' before I show an error message. Allowing the user to correct an error while still in the input field provides one less chance for an obtrusive "hey, you messed up, dude" kind of message.

Answer 3

If you prevent invalid characters while they type, they could potentially think that their keyboard is malfunctioning. User's like things to work the way they expect them to. If you are going to prevent certain characters on key press, at the very least you should also display an error message near the input at the same time. This way they know why it isn't typing.

Another thing that can get annoying is when you just finished filling out a long form and the site uses server side validation so you have to go back through the form to find what's wrong. I like to use client side validation primarily but fall back on server side. I will display an error either as they are typing or when the input loses focus. That way the user knows right away that there is an issue and knows exactly what the problem is.

Answer 4

I find that preventing users from making mistakes is always 10x harder than I originally thought. Example: Someone's phone number may have an extension, like x2333. I've used the jQuery input mask plugin for credit cards and that worked well. I use Auto-suggest whenever possible.

In any complex system, you will have circumstances that are expensive to detect inline and you need to tell them after the fact. To me, the answer is case-by-case and make sure you cover every edge case.

Answer 5

I would suggest a hybrid of both approaches, but only for strictly-validated fields like phone numbers (SSN, zipcodes, etc ... anything that must be numeric by definition).

Track each keystroke and, when the user types an invalid character, show it ... but immediately signal that something's wrong. Maybe turn the input field red and display a "Please enter numeric characters only" to the right of the field.

Blocking input is a no-no because it can be misinterpreted by the user. They might assume a problem with their machine or input device, not that they weren't supposed to type a letter in a numeric entry box.

Validating after the input is completed can be annoying. Particularly with fields like those used in password creation. Some sites require 6-character passwords with only alphanumeric characters. Others require 9-character passwords and allow any character (including !@#$% and such). Typing a password and only finding out after I've typed it is the most annoying form type I've found and has actually turned me away from several services.

Providing dynamic feedback as the user enters data helps them

1. Know which field had the error while they're still in the field
2. Proactively correct input errors before submitting data
3. Learn from the experience as they go

Blocking input fails on all 3 accounts. Highlighting validation errors after the textbox is filled in fails on all 3 as well.

Answer 6

It depends on the case. If possible use Auto-suggest. If you intercepts user's input, an immediate feedback is crucial. One of the possible solutions is "clue box" that pops up immediately after key is intercepted. You can see it on Windows login screen, it pops up if you press $ sign for instance.

Answer 7

As with most things..depends on context. I have a more specialized take on the topic. Most of the applications I, or my group, work on are technical in nature and are only used by the reasonably trained. As such we can place more responsibility and freedom in the hands of the users than you could with the general public. Briefly, some of the guidelines we use...

• Disregard any invalid entry....block invalid keystrokes.
• Indicate invalid fields, a state that should be all but impossible, by contrast and color*.
• Focus is always under user control. Do not trap the user or prevent a change of focus.
• Never throw a modal warning/error box. Ever.
• Never ask the user questions. Software is a tool not a person. Yes I am sure.
• The Enter/Return keys always mean: Accept changes and move on. Do not change this by using focus on a cancel/exit button as the default on Enter.
• The Escape key always means: Discard and exit.
• Provide auto-completion whenever possible.
• Provide short-cut entry for numerics that have a min/max limit. e.g. If a valid value is between 0.12 and 100.387 then entries greater that 100.387, like 999, are taken as 100.387, etc.
• Establish very clear black and white rules on behavior..rules the user can understand. If this becomes overly complex...re-think it.

Almost all of the examples are user requested and, yes...implementation is sometimes a real bear/nightmare/killer but rarely impossible.

Caveat: Again, these examples are given in the context of a vertical system with a technical user base....not a web general public form, etc. Your mileage my vary.

*Except red. In our business red means: Danger you could be killed...or worse.