1

As for any confusion caused by validation marks next to ‘easy’ questions, could this be solved by scrapping the ‘valid’ mark altogether? Jakob Nielsen touches on something similar to this in a column about usability mistakes in the movies :

“After all, you design for authorized users. There’s no reason to delay them with a special confirmation that yes, they did indeed enter their own passwords correctly.”

Any thoughts on this?

posted at 08:26 am on September 1, 2009 by Reverend Duck

2

Did you test placing the checkmarks to the left of the questions? I generally prefer them there: they line up more easily (so I can scan upward in a straight line rather than jumping around) in left-justified lists, and most lists I see have check marks to the left (much like bullets).

I’d also like to test the theory that giving the check box three states might help: unchecked, checked, and error. That might give a quick and easy way to figure out which need attention, along with the explanation to the right. Of course you’d need a way to make sure the user doesn’t try to check the box.

Finally, it should not come as a surprise that most people didn’t look directly at the green check. I found it quite easy to use peripheral vision to notice the green check appearing, and didn’t need to shift to it.

posted at 09:21 am on September 1, 2009 by Trare Bapho

3 Using the 'while' option only in invalid fields

Regarding the before, while, and after options, has anyone tested the ‘while’ option only when a user is in invalid-marked field? (I would also suggest not using a “please wait…” indicator in this case.) To me it seems to play into the game-y aspect of filling out forms (“make it all green!”), but it can also be considered as a different use case – fixing invalid data.

posted at 09:32 am on September 1, 2009 by yuval

4

I have seen such forms several times, but—I could not tell why—I never implemented it in my websites. Now reading this article I see the advantages of using inline input validation. Not only it is faster, but also it discharges the server and of course the user’s internet connection. Moreover it is less frustrating when you are notified instantly and at the right position as when you have to wait and search for the incorrect input. Thank you for the article, it made me think about using this method.

posted at 09:39 am on September 1, 2009 by patrick_l

5 Nice Data

It’s really nice to see data like this put together. Great to have an immediate reference like this. Thanks!

posted at 10:29 am on September 1, 2009 by Tim Wright

6 Great piece of research

Really well put together piece of data.

We’re about to embark on a pretty major piece of e-commerce development for a pretty niche audience in terms of usability and this study into different types of validation is more than useful to me.

posted at 11:08 am on September 1, 2009 by ubisan

7 Excellent contribution

This research is an excellent contribution.

Some of this basic validation can be undertaken by client-side JavaScript loaded at the same time as the page (e.g. a particular number type, format or range) and others might require separate AJAX-style requests (e.g. the username is not already taken). If the data is sensitive, designers and developers must be careful that the inline validation doesn’t prove to be a security weakness. For example in the username check, it’s quite likely the functionality can be abused to perform username enumeration i.e. identify some or many valid usernames before perhaps attempting to guess matching passwords.

It is also worth being aware of the types of validation that shouldn’t have this inline approach used – the password input validation is probably checking length and the characters included, not whether the correct password matching the username has been typed. So the comments about correct/valid/complete/done need to be applied consistently and consideration given to what is displayed when the subsequent server-side REVALIDATION identifies a problem e.g. the postcode is of the correct format, but doesn’t match anything in the Royal Mail’s postcode database, or appears to be in a different town, region or country, or the user missed some previous step in a multi-stage form.

posted at 02:28 pm on September 1, 2009 by clerkendwellerlondon

8 Keep the validations going

This was a really good piece of advice that I had not thought of before… when a user gets a ‘valid checkmark’ after the first three fields, and suddenly the fourth doesn’t have one (even if it’s a field that doesn’t technically need to be validated), it could slow down the user… so good advice there.

Thanks!

posted at 02:47 pm on September 1, 2009 by web page designer

9 Combination of marks

While reading this article I came up with something I’m going to try next. This should help when using validation marks only on difficult inputs (like username, password, etc. as mentioned in the article). One can put a green valid mark when, for example, the username is correct and valid, and changing also the way the text field looks (hiding the borders, changing tha bgcolor, …). And in fields where the application can’t find out if the data is correct (like last name, phone number, etc.), you can still change the input’s appearance without showing the green valid mark.
What do you think about this alternative? I’ve just came up with this…

posted at 02:58 pm on September 1, 2009 by martinschaer

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)