Impress your Web Visitors with real-time Form Validation
Happy New Year! Marketing Technology finds and reports on the latest technology that will enable your business to effectively market to your audience, for acquisition or retention strategies. Subscribe now the Marketing Technology Blog RSS feed or to the Marketing Technology Email to have new content sent directly to your inbox. You'll also find my other business blog helpful, Social Media Domination.
The first impression you usually have as a user of a Web Application is when you fill out a web form. I’m amazed at the number of web forms out there that have zero validation or that wait for you to submit your form contents before telling you what problems that you might have.
My rule of thumb is that anything that is not validated is supported. Anything that can be validated prior to submitting the form must be. With the advent of Ajax, you can even validate data against your database prior to submission. Don’t pick the lazy route - users appreciate the help!
Here are some examples:
- Email Addresses - I don’t mind forms that make you fill out your email address twice to validate them, but the fact that they don’t tell you whether or not they match or are constructed appropriately is inexcusable.
- Passwords - If you’re going to make me type in a password twice, then please validate that the values are the same before posting the form.
- Password Strength - If you require a certain password strength (combination of alphanumeric characters or cases), then provide some feedback for me while I’m typing my password in. Don’t wait for me to submit before telling me it failed.
- Dates - If you’d like the date in a m/d/yyyy format, then allow me to enter the information in a single field by typing those values and formatting them appropriately. If you want leading zeros, put them in after. It’s okay to display one format and save another in your database.
- Today’s Date - Fill it out for me! Why are you asking me to fill in the date when you already know it?!
- Date Format - If you have an international application, you can default a date format based on Internationalization of your application. Of course, it’s good to have an option for users to override that option and select their own.
- Social Security Numbers - it’s pretty simple to add some javascript that automatically jumps from field to field or programmatically put a dash in between values.
- Telephone Numbers - taking Internationalization into consideration, these types of fields also can be simplified by formatting the telephone number in the interface, but saving it in another format that’s efficient for your back-end. Don’t make your users type in parenthesis, spaces, and dashes.
- Maximum Text Length - if you limit the number of characters stored in your database, then DON’T let me type that many characters in! It doesn’t even require difficult validation… it’s just a setting on the textbox.
- Minimum Text Length - if you require a minimum text length, then sound the alarm until I have enough characters.
Here’s an example of a Password Strength function from Geek Wisdom:
UPDATE: 10/26/2007 - I found a neat resource with a JavaScript library available for download for form validation, called LiveValidation.
Good points, but definately not something every online form “needs” in my opinion.
Example:
Is this really a mediocre password?
f46dffe6ff4ffgdfgfjfgyu656hfdt74tyhdtu5674yfgh6uhhye45herdhrt64684hythdfth54y54348fgdcvzse8cn984v3p4m6vq98476m3wuw89ewfucsd8fg67s4v8tw76u340m6tver7nt+s89346vs+0em9u+s+09hrtuhss586ysvne4896vb4865tbv089rt++
It was simply an illustration of the point of the post. I think that’s a fine password! Good luck with it.
Doug
You simply have to attach to your form elements some event handling (keyup, blur, click, etc…) that post the entire form via AJAX to the server, invoking a “check” function that return the corresponding error messages (this passowrd is too simple, that date is in wrong format, etc…)
When the user finally post the form by clicking a submit button, you can still use the “check” server side function to validate a last time the form before inserting the data in a database or some other process.
This way, users are happy with the onthego validation AND developpers are happy with server side only validation development.
That sounds like some solid advice. I’m not a programmer (though I have hacked out a few applications).
Doug
However, I also agree with Nicolas about using Server Side logic in conjunction with AJAX.
Rewrite your title (too misleading, makes one think there is examples and practices being discussed).
If people are not doing this already in their forms, then they are just learning or the form is not important enough to use validation.
Real web programmers know this already and do it.
Sorry about that! My point was definitely not to provide developer feedback - I really was coming from the point of view of a Product Manager. I agree with you - but it’s interesting that some other developers don’t! I think that’s unfortunate.
Thanks for taking the time!
Doug
For most things I work on I find it takes about 50% of the time to get something working, under normal conditions and if users use the system the way I intended. The other 50% of the development time comes from checking their input, ensuring data integrity is maintained, and making the form fields not allow malicious data to be entered.
I wrote a post on how I use InputVerifiers in my hava swing apps, and show how I verify an email text field. The regular expression I use is easily modifiable to validate phone numbers, zipcodes, SSNs, etc.
My blog post is at http://timarcher.com/?q=node/36
Good writeup Doug!
You provided a brilliant example of how validation can mislead users and, worse, drive them away from our site:
Geek Wisdom’s password strength validation from considers tZhKwnUmIss to be a weak password. Not only is this a perfectly strong password but it will also alienate users because it gives them the false impression that logging into your site using this password will be somehow insecure.
It would be much better (and easier) to simply hint users that a good password is at least six characters long and should contain both numbers and letters.
Other questionable validations include user names that need a certain minimum length or may not contain spaces. What’s wrong with the usernames X, john doe, or even #*!ยง? I can handle that.