When and how to validate forms in a usability perspective?

Question

I am implementing a business application and wounder what's the best way to validate forms, and when.

An example is a form where three textfields where a currency amount is expected. A valid input is of the form D.dd where d is a digit and D is one or more digits.

When to validate?

• When the user is typing (e.g. validate the input after every char is typed). A problem is if the input needs to be in an invalid state before it gets valid.

• When the focus of the textfield is lost.

• When the users press the submit button.

How to validate?

• Prevent "invalid" characters beeing typed e.g. letters in a number or a currency field.

• Show an error indication (e.g. red border or show the input value in red text-color).

• Prevent the user moving focus (it's important that the default value is valid in this case) and show error indication.

My current solution is to have a valid default value e.g. 0.00 for currency and 1 for quantity. And prevent letters beeing typed in currency and number fields. Sometimes the input needs to be in a invalid state, so I only validate when the focus is leaving the field. If the value is invalid, I keep the focus and show an indication. An empty field will be filled with the default value. But I don't know if this is good usability practice.

Answer 1

One solution is to wait for a period of inactivity in that form field (say 1 second) before validating it. Of course you should also validate as soon as the focus has moved.

• Preventing invalid characters from being typed is not a good idea if the person typing has no clear indication why that character won't work. Rather show some validation error for the field the explains the problem. Something like "Please don't use numbers". An exception is when it is very clear. Something like $_ makes it clear that I'm looking for a number. Whether you should require it in a D.dd form (as you suggest) is another story. If I say $1, or $1.0 or $1.00, you can fairly assume that I'm talking about one dollar. If it's clear to you, don't force someone to fill in according to your format just because that's how you would like it. Let the computers do that work.

• There are a few ways of indicating errors. One common one is to change the background or border colour of the field, and another is showing an error icon on the right of the field. Only testing will make it clear which is best for your customers given your design.

• Don't prevent someone moving focus. It is annoying and has very low discoverability as to why focus can't be moved. Let people fill the form in in whatever order they like. You an always prevent the form from being submitted if something is left out.

Answer 2

There is a core problem with character level validation, which is that is is not sufficient. If you are doing this using javascript, as I presume, then you must also validate when the data is presented at the code back end, because the user can turn javascript off.

So it has become more common to validate on submit - and do the same validation at both ends ( roughly ). This also has the advantage of taking everything that they have entered, and validating it at once - so any dependencies can be done then.

And validating it only once they have completed a field at least, means that the entire entered values can be checked as to whether it is possibly compatible.

Answer 3

I wouldn't just use feedback on incorrect inputs, but also show what the input does, if applicable. This is a good way of avoiding internationalisation issues.

So if you have dates, don't just reject certain formats, but output the text-parsed date next to it. If you type 10/02/11 show 'sun, October 2, 2011' next to it, so there is absolutely no way to misinterpret it as February 10. In currencies, show $ 1.00 - then there can't be confusion about decimal separator symbols.

Non-invasive ways of providing feedback should go first (indicating issues while typing or when removing focus) but it should not be blocking too much, and not preventing to move focus.

The validation on (or before) submission could be more blocking: not submitting until problems are fixed. I am not sure wether users prefer a disabled submit button until the form is filled out correctly over error messages on submission or vice versa. But if you disable the submit-button you may need to indicate why near the button (and not just near the fields that are incorrect), especially on longer forms.

Then also validate on acceptance, as client side validation is never safe, and provide accurate information back to the user in that case too.