Form Validation: On-blur or On Submit?
I've noticed recently a trend towards validating fields when you leave the field, so the form will immediately let you know whether your email address was valid or your username is unique. Obviously some dependent validations can't be done in this way, but in general terms it seems like a pretty good default approach to form validation.
What do you think? Should validations be performed ASAP or should they wait for a form submission? Obviously it depends - but on what? What would move you towards including or avoiding on blur field validations?
Of course, neither of these should be used to the exclusion of good server-side validation, but that's a different discussion...
For short forms, at least, I prefer the show-me-everything-at once approach (onsubmit). For longer forms, a more incremental approach (onblur) may be better in order to prevent the user from being overwhelmed if there are a lot of issues and to prevent error messages from appearing above or below the fold and out of sight.
Good points all - I should have been more precise.
Firstly, client side validation NEVER removes the need for server side validation. Javascript could be turned off, I could use a tool to modify the form fields and values being sent - you can NEVER rely on user input.
Secondly, I'm thinking the sites where you enter something into a field and as soon as you leave that field it gives you any error message on the right of the field in red text. I personally dislike the forms that tell you the field is wrong while you are still typing in the field like Live validation: http://www.livevalidation.com/examples, but I do like the idea of the message appearing to the right of the field on tabbing to the next field as it provides really immediate feedback rather than having to wait until the form is submitted and then find the elements that were problematic.
Thoughts?
Here's an example of why onblur is better: I just tried submitting this post 3 times in a row, before I realized that an email address was required. The error message is the same weight and color as the rest of the text, plus it appears at the top of the page and I was looking at the bottom at the captcha, so it took 3 tries before I saw it. If a message had appeared as I tabbed out of the empty email box, I never would have had this problem :)
Don't let the user click submit and then yell at them that their form is invalid. Rather, guide them through the process while they're filling out the fields, and don't enable the submit button until the form is good to go.
For Flex 2, see this quickstart: http://www.adobe.com/devnet/flex/quickstart/valida...
There's something to be said for that, but you have to let people know why the submit button isn't enabled. I assume that's what you mean by "guide them through the process", but what's your strategy for providing that guidance?
I think I'd probably keep submit enabled as otherwise users might be confused, but it's interesting to see the various options for handling this class of problem!
The only time I validate onBlur is in an account signup form, where the user is creating their own unique username.
OnBlur of this field, I do an ajax call to check the username they entered against the database. If it's unique, I add a little green "Username OK" below the field. If it's not unique, I add a red "username already taken, please try again" message, and refocus the username field.
I guess my thinking is that it's pretty likely that their username might already be taken, and this saves them submitting the whole form three or four times while they're trying to come up with a username that's unique.
Of course server side check is in place in case they don't have JS enabled.
Agreed. I'd hoped to be able to leave this to my design partners, but they're busy also and don't have the time to research and implement best practices, so here we go!
I agree 100% on the username check, but was also considering passwords matching, maybe even one of those password strength meters, things like that.
Also if someone is tabbing through a form I figure it wouldn't hurt to on blur to check for required fields or any other things like invalid date formats, although I get that if they don't click on the fields you won't get the on blur, so you ALSO need to do an on submit as well as the server side validations.
At least that's my understanding . . .
With this method It's pretty obvious while entering the form where the problems are before the user even hits the submit button. What's neat is that I can use the same validations on the submit to determine if the form is valid and what level (formValidation.getLevel()). I give the user the option to submit anyway if the level is set to warning. If the level is error I show the first error in an evil javascript Alert dialog and then jump to that field when the user hits ok.
To go a step further. I always like to have validation on the server side too. For this purpose I am keeping all validations for a form in a single xml file with both cf and js versions. I still have to keep both versions up to date, but at least they are in the same file. I have a cfc to generate the javascript and cfc file that do the corresponding validations. I am working on setting up automated testing of the rules so I can cross validate my validations, but thats not nearly ready yet.
I could say a lot more, but this is getting to be a long post. . .
For instance, you may be entering information from paper into a web system and you want to fill in the information you have and then go back and enter the missing info. If you are tabing through the fields blur validation will get old really quick.
I guess it depends on your users and the use of the app.
Displaying an indicator next to a field / highlighint the field to show if it is valid / invalid is much much friendlier than displaying all messages at the top of the screen
Validation on blur is preferable to validation soley on submit - its normally much easier to fix something when you have just entered it, rather than after completing the rest of the form
Validation on blur should be suplemented with validation on submit - which should prevent the form from being submitted until it is valid - this gets round the issue of onblur not catching any fields which have not recieved focus.
This should go without saying, but all client side validation must be enforced with server side validation - the client side validation is primarily to improve the user experience.
We have recently finished an app where we are code generating the majority of the forms - and we are also generating spry validation for the majority of fields. This vastly improves the user experience, and removes what is often a drudge for developers, in writing the same validation code over and over again - but I guess I don't need to tell you that Peter!
Hopefully we will release the Illudium templates - once we have had time to make them suitable for public consumption...