RTFM? I don't think so.

My husband is always telling me to "RTFM" (read the freakin' manual) whenever I'm fiddling with a new gadget or software. My response is usually some variation of, "But I shouldn't have to!" This is also my philosophy when designing user interfaces. The ultimate goal is to design an interface in such a way that the user intuitively knows what to do rather than to force them to either fail, go through training, read help documents, or some combination thereof.

The traditional web application method of form validation was to wait until the user filled out the entire form and clicked a submit button and then let them know what they did wrong. The validation errors were generally provided with a popup menu - either a single error per submission or a list of errors throughout the form. This method posed several problems, but two major ones. First, the user was forced to fail first and then follow an "exception flow" to correct the issues. Second, the user could not see the error messages while correcting them since the dialogue had to be closed before the user could return to the form.

In more modern web applications, the second of these issues has been corrected by providing "inline" validation error messages. So, the user still has to click submit first, but the error messages are now displayed on the screen near the field, at the top of the form, or both. This is not a bad way to handle form validation, but still doesn't solve the first problem in which the user is being forced to fail before provided with the information necessary to complete the form successfully.

A second more modern method of validation error handling is to provide the error message as soon as the field loses focus. This is also a good way to handle the feedback and at least provides the user with an immediate response, but I don't think that it is the whole answer. The focus should be to PREVENT failure in the first place so that it truly becomes the exception instead of the rule.

To be honest, I do not think that many of my projects have come close to achieving the level of intuitiveness that I think they should. Not to say that the interfaces that I design aren't generally intuitive, but I almost always have to stop short of what I would consider a truly ideal solution. So, what is "ideal"? Since this could be a huge topic, let's narrow it down to form-based data entry. Here are a few goals I would work towards when designing a form:

1. Provide input such that the user knows intuitively what to put in each field to help prevent them from making mistakes.
2. Provide minimal help/instructions only when absolutely necessary and make them as visual as possible.
3. Let the user know immediately if they have made a mistake.

Providing Instructions
We often want to provide the user with instructions in attempt to achieve goal #1, but this may sometimes be complicated by goal #2. Providing TOO MUCH instruction can be just as bad as providing too little. If you provide instructions for fields that the user already knows how to fill out, he/she may not read the more important instructions for fields where the help is truly needed. Generally, the more text provided to the user to read on a form, the less of it the user is likely to read (particularly if most of it is unnecessary). It is better to provide instructions that are as short and as visual as possible - and only when necessary. Here are a few examples:

Near the field
This is probably the way that I have most often displayed instructions or hints. It is fairly common and likely carried over from old paper forms. The positive is that it's visual - the user doesn't have to read it to gain understanding. The negative is that it's very passive and may be easily missed.


In the field
This method is a bit harder to miss since the instruction is right in the field, but it is typically hidden when the field has focus, so the user does not get the instruction when it's most needed.


On hover or focus (tooltips)
This is similar to the "near the field" display, but is shown only when the user's cursor hovers over or enters the field. This might pull the users attention better than the always-visible instructions.


As an input mask
Whenever field formatting is an issue, I think the best possible solution is input masking. This has, until recently, been rarely seen on the web, but I remember using it in Access database design many years ago. With the many RIA tools now available, this method of instruction is much more accessible.


Here are a couple of links to open-source input mask components:

• Flex
  
• Javascript
  

Other Visual Cues
There are other visual cues can help to let the user know what to enter into a form field:

Field sizes
The size of a field can give the user a visual hint of what is expected. For example, if you want the user to enter a 2-digit state abbreviation rather than a full state name, it is helpful to have a smaller field. If all of the fields in the form are sized appropriately to the amount of data expected, the user may only need to glance at the labels. In addition, having the fields in the expected order (when there is an expected order) will help the user to flow through the entry quickly.


Multiple fields
I have mixed feelings about this one. Multiple fields are often used for inputs with specific patterns such as phone numbers, credit card numbers, and serial numbers. I do think that this helps to set the user's expectations of what should be entered, but because all of these behave a little differently, there can be usability issues. For example, does the form automatically jump to the next field when you've entered the correct number of characters in the first one or not? I personally think that input masks are a better solution and provide basically the same visual cue.

Character Restrictions
Another interesting challenge in helping the user complete forms is character restrictions - maximum characters and data types. For maximum characters, we typically just set the cap on the field and when the user reaches it, he/she is unable to enter more. I think that this is acceptable and expected for short fields, but for longer text entry, the running tally of characters seems helpful. This is typically done by displaying the maximum number of characters next to the field and then showing a "### of ###" total as the user types.

As for data types, Flex has a "restrict" property that can be set on a text input that disallows the wrong type of character. I think that this solution falls into the category of protecting the user from failure, but it doesn't (by default) provide any feedback to the user so that they understand why they can't enter anything else into the field. In this case, I think it might be good to provide an instruction triggered when the user tries to enter something other than what the field has been restricted to accept.

Success or Failure
I have talked to designers that are of the opinion that a success notification should be provided for each field, but I personally don't think that's necessary. I would recommend providing success messages only for particularly difficult fields, such as serial numbers, and only providing negative feedback when necessary for more common fields. This should meet user's expectations and keep the form nice and clean - no need to distract the user from the data entry without a good reason.

How do you know if you've succeeded?
I am a huge advocate of performing several formal usability studies throughout the design and development process. I am *always* caught by surprise at some of the issues that a usability study will turn up. It isn't always easy to sell this to clients - it is a somewhat new idea and will of course cost more money up front - but I explain that it is the QA of the design and a necessary part of the application development process. If usability issues can be caught during the design phase instead of after development is complete, it will save the client money in the end by reducing necessary rework and increasing user acceptance. As they say, you only get one chance to make a first impression.