25

I've been having a debate (mostly with myself) over the best approach to deal with invalid input in text fields -- validation versus prevention.

Taking a numeric text field as an example, is it better to prevent the entry of non-numeric characters (allowing for special cases like sign, decimal pt., etc.) or allow the entry of whatever and then indicate an error message (typically when focus is left) if the result is invalid?

The first approach is "don't allow the user to do something you know is wrong" but has the disadvantage that it may not be at all obvious what is going on if a keyboard key is typed and nothing happens. It also breaks the expectation that, if you type something in a text field, you expect to see what you typed.

In the past, I've generally leaned towards the prevention approach but in general but feel perhaps, at the field input-level, the validation approach provides a better user experience. Is anyone aware of a best practice here?

Improve this question
3
  • 1
    With prevention, you also might have to deal with pasted values. There are multiple ways to handle this but it's just extra logic that you have to remember to do.
    – SunnySydeUp
    Commented Apr 24, 2014 at 23:05
  • 1
    @SunnySydeUp makes a good point, to expand from my point of view: If you want for example a loyalty card number no spaces, I might have it stored with spaces (e.g. on the email your site just sent me!), paste it in, then edit out the spaces - a form that doesn't let me do this, or stops me leaving the field until I've fixed it (not seen on the web but offline) is seriously offputting.
    – Chris H
    Commented Apr 25, 2014 at 12:51
  • Thanks for the responses everyone! Looks like you all pretty much agree with what I've been feeling.
    – Bill Dagg
    Commented May 1, 2014 at 3:41

5 Answers 5

Reset to default
23

Prevention will likely frustrate a user as they are entering it and it isn't working. Of course this can be fixed with adequate messaging that lets them know why certain characters were rejected.

Some users may also be typing with their heads down and may not see when some characters are rejected. If they are typing 10 characters but only a few within those keystrokes are rejected, they may never know since their head is down.

In general I have preferred validation as it allowed the user to see their error. As you get more complex inputs it may become more difficult for users to understand why some characters are rejected.

Improve this answer
3
  • I go with the validation also because we may have complex pattern that we cannot prevent the user from entering but can be easier validated
    – mmohab
    Commented Apr 25, 2014 at 0:42
  • 1
    Personally I find it exceedingly frustrating when I type in, say, a phone number, only to have the submission rejected for "hyphens not allowed". Sheesh, if they aren't allowed, just ignore them when I'm typing. Of course, the better answer is to accept them, and silently strip them out on the server side.
    – Bryan Oakley
    Commented Oct 16, 2015 at 22:00
  • For numeric inputs where you only allow a certain level of precision (decimals), I also feel there is a good argument to make for automatically rounding the user's input on blur without turning things red and getting in the user's face about it.
    – Matthew Souther
    Commented Nov 19, 2021 at 21:44
13

Preventing the user from doing something that you know is wrong is never about preventing keystrokes in a text box. It is about removing the need for typing altogether if possible for that particular input.

For example:

  • Don't validate dates in a text box, get rid of the text entry and use a date picker control.
  • Have a set number of standard options where the user picks one? Let the user select them from a dropdown / list instead of typing. If you need to give free text entry in addition to this list, use an "other" option and only then allow text entry.

There are many different data entry controls available that are not text boxes. Make sure you consider all your options before plumping for text entry.

Improve this answer
4
  • Fantastic answer. Way to take a step back. I kinda got lost in the weeds ha
    – SwankyLegg
    Commented Apr 25, 2014 at 17:19
  • @Franchesca: Correct, of course -- don't use a text box unless necessary. My particular consideration was numeric input of arbitrary amounts -- not something that could be picked from a list.
    – Bill Dagg
    Commented Apr 25, 2014 at 19:55
  • 9
    I cringe every time a web site forces good typists to reach for the mouse and navigate a clunky date picker. A sequence of precision mouse clicks is a lot more difficult than typing a few numbers. The same goes for drop downs unless they allow me to navigate by typing.
    – ThisIsTheDave
    Commented Apr 30, 2014 at 0:33
  • @ThisIsTheDave I know, but it really depends who you are designing for. I wouldn't force the screen traders at our company to use date pickers, as they like to do everything by keyboard. However, if you are a travel website that grandma uses once a year to book a holiday, you might not focus on this.
    – Franchesca
    Commented Apr 30, 2014 at 12:39
10

There are 3 common solutions to this problem, and depending on your specific use case, a balance of 2 or 3 of them is most likely the best.

As a rule of thumb... give feedback early and often

You can provide the user with feedback:

Before input

Writing succinct, communicative copy is a solid step before. Tooltips, onboarding flows for first-time users, and other tools are at your disposal as well.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

During input

Checking content dynamically during input and providing feedback is equally valuable. In your case, if you'd prefer to accept keystrokes, alert the user immediately. Additionally, like with the social security # or a credit card, you can automatically advance users to the next field (helping them group). With more "complicated" inputs, like an email, check the semantics for a match as soon as possible.

mockup

download bmml source

After input

Validating content after a submission is typically the most frustrating for users because they've expended the most effort. If they went through the trouble to complete a form incorrectly, they're doing repeating trivial actions that don't provide value. Telling users they did something incorrectly is detrimental to the sentiment towards a product, and that's magnified by the amount of effort expended.

In the example below, the notification that the form was filled out incorrectly could have occurred before or during the input, rather than at the end of a series of actions.

mockup

download bmml source

I would discourage you from disallowing certain keystrokes, but if the copy and feedback are clear, you can avoid the headache altogether the overwhelming majority of cases.

Improve this answer
4

Don't prevent (some) keystrokes as that could easily confuse and frustrate the user.

Do provide a clear label to tell the user up-front what type of input would be valid.

Do provide as-you-type validation feedback to guide the user if they have entered an invalid value.

Others have suggested not allowing keystrokes at all for dates and numeric fields. The may be appropriate in some situations, but in many (most?) situations it's often quicker for users to be able to navigate a form / interface using only the keyboard, especially if it's something they use regularly. So, if you go down this route then bear this in mind and maybe include keyboard navigation in whatever interface you provide. However, it may be simplest to just allow normal keyboard input with the suggestions above and then consider offering an additional way to select values (e.g. date picker, drop-down list etc.) as a "shortcut" for those who would prefer to use a mouse / pointer / touch interface.

Improve this answer
0

I don't entirely disagree with many of the answers already provided here. We should generally be forthright about manipulations we do that would surprise a user. But to address the actual example provided (an input field for entering numbers), the W3 spec is opinionated in favor of silently rejecting non-numerical entries.

The very first line of the the MDN Web Docs article calls this out:

<input> elements of type number are used to let the user enter a number. They include built-in validation to reject non-numerical entries.

If you take a second to play with the example provided in the article itself, you'll see that the input does not respond when the user types any characters besides numerical ones and a single decimal.

Obviously it's possible to work around this by using an input element where type="text", but right out the gate, if we're following Jakob's law, I think the right approach is to avoid needless complication and simply ignore it when users type letters in an input where there really only ever should be numbers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.