One of the things I’ve had on my mind recently has been form design and layout. Specifically in relation to both web and application design though I’m going to stick to web apps here since talking about desktop applications opens another can of worms. In particular I’ve been pondering buttons and form field naming conventions and their usage in guiding users through a form or application.

I’ve built quite a few form-based web applications during the last few years and something I notice on occasion when visiting other sites or using such applications is that buttons are often inconsistently named or placed in a way that is confusing for the user.

A good example might be a Reset or Cancel button. To the uninitiated user, these two buttons could be the same thing and in some cases they are. At the very least, their meanings (intentions) can be easily confused. A more experienced user might know that the Cancel button is used if they change their mind and want to cancel an operation they’re in the midst of whereas the Reset button is used to return the form or application to its default state; as it was when they initiated the session. In many cases, eliminating either button is a good place to start since they’re often not needed at all.

I’ve seen many users inadvertently press the Reset button in a form-based web application for changing their e-mail password thinking that pressing that button will change their password where it instead actually resets the form and clears any entered information. Inevitably this frustrates the user. Changing the label of the button to “Clear Form Values” or something like that might be more appropriate.

Alternatively, highlighting the Submit button or switching the Reset button into a text link might help indicate to the user which button to push to actually submit the form. Using the “tabindex” tag to force a tab order may help avoid such mistakes, but for users who tend to move around using the mouse alone, it provides no protection. Browser defaults may also affect exactly how tabindex values are interpreted. Simply providing a clear button label such as “Change Password” or “Submit Changes” might be enough.

Dealing With Form Fields

Naming form fields appropriately also goes a long way to making forms readable, understandable and therefore usable to users. I’ve seen forms where a field value for “Name” might not actually be asking for your name. There’s also the question of splitting up names as First and Last name. Is it better to record that information as one value and then use either a JavaScript, PHP, MySQL, Java, Perl, ASP, Coldfusion (etc) function to split the value into first and last components by breaking it at the space? What if the user includes a middle initial? What’s easier for the user who actually has to fill out the form?

One field is certainly easier to fill out (and probably faster than two fields) and provided it has an appropriately descriptive label associated with it is likely the best choice. Yes it may require a bit more back-end programming depending on how the recorded data is used, but typically is just as flexible as if the data was recorded into separate fields. This particular case is much a question of business logic as it is ease of use. A good experienced DBA can help here as well as a good understanding of database normalization techniques. A little forward-thinking, experimentation and analysis never hurts either.

Application Flow

The overall flow of an application can also be a determining factor in whether or not someone completes the form and presses the ever-elusive Submit button. This may result in a missed sale if your form doesn’t flow properly or is too complex.

Forms can be simplified by structuring them into related sections and subdividing data collection across multiple pages or by simply removing unnecessary information or allowing users methods to lessen the burden of data entry. An example of progressive disclosure in form design can be easily produced using the Accordion component included with Flash. Progressively display, validate and guide a user through a form. Make the process quick and as painless as possible and you’re more likely to complete a transaction than have a user jump ship.

Excessive complexity is a leading cause of incomplete e-commerce checkout transactions. If your form covers more than 3 or 4 screens, users will frequently give up and leave. Giving a user too much time to reconsider by having long or complex forms will no doubt result in lost sales, errors in user input and a poor overall user experiences.

Building Better Forms

Aside from taking part in user testing with applications, there’s a number of simple things that can be done to improve forms, especially ones where certain information may be requested more than once (eg. billing address, delivery address). For example, providing a method, whether transparent to the user (Javascript, Cookies) or obvious in UI of the form itself, to keep track of certain information such as name, address, postal/zip code, city, state, country can go a long way to reducing the time to complete a form along with improving the user experience.

The key is to make sure that the information collected is:

• Complete
• Correct
• Relevant
• Usable across a site for multiple purposes
• Forward thinking

Having multiple accounts for a single site can compound problems so consolidation of such information is a real boon for users. Apple has done this with their AppleID and O’Reilly just finished a similar project. High profile sites like Apple and O’Reilly generally provide good examples for form-based tools. Macromedia’s site also contains good examples of form-based applications providing a good user experience on their site using both Flash and vanilla HTML.

I think I’m really just starting to scratch the surface of this topic and planting the seeds for further discussion. If you’re interested in talking about this more or have something to add, leave a note in the comments. For now I’ll stop here with a few questions you may want to ask when building form-based applications.

• What kind of naming conventions should be employed?
• Where should the form buttons appear and in what order?
• Are accesskey and tabindex necessary for form elements?
• Are there related legacy applications which should be used as a guideline in designing forms?
• How does the form flow in terms of readability and data entry?
• Are buttons and other interactive form elements labelled properly?
• Are there too many pages/steps to complete a transaction?