Form Validation

Improve upon the paper-form model. Web forms typically follow the mental model of a printed paper form that must be filled out, which is the main reason they are so successful – that is, users know what is expected, and what to do. However, interactive validation of forms should enhance the model rather than merely provide the recreation of a paper form. (See the related Responsive Disclosure pattern)

• Validation should streamline workflow, instead of interrupting and interfering with it. Eliminate extra steps, such as re-entering data already entered; validation should provide as much help as possible so that the user can accomplish the task at hand with minimal distraction, minimal interruption.
• Note that confirmation of email addresses or passwords often requires the user to enter the same things twice, but for good reason!
• Required fields should be indicated in a consistent manner.
• When fields fail validation:
• Error messages should be descriptive – to provide enough information so that an attentive "newbie" could correct the problem. Examples might include "Title must have fewer than 30 characters. Title is currently 35 characters", or "Date 'available to' must be after date 'available from'".
• Error boxes should be formatted in a consistent manner, so users instantly know "aha, this is an error message and I need to do something about it."
• Whenever possible, parse the full form for problems and report all errors at once, instead of stopping to report just the first error encountered.
• Error indicators should be in two places: all listed together at the top of the page for reference, and each inline with the fields that need attention.
• All error messages should be located together in a page, as close to the main heading as possible. This allows users to see all problems at once to get a feel for the scope of work required to fix them – rather than seeing one error to correct, fixing it, and submitting the change – only to find there is another and then another and another.
• Fields containing errors should have indicators inline: first, user attention is drawn to the fields that require fixes, and second, workflow is not hampered by requiring users to scroll up and down between error messages at the top, and a field towards the bottom. Ideally these inline indicators should be accompanied by extended descriptions to help the user identify and correct the problem in that field. These may be visible on the page or accessed via a mouseover tool tip on the indicator.