Can you imagine a web based user interface that you use without clicking?
Read More »

One important part of designing websites for user interaction is creating effective and usable forms.  There are several main cases where users will have to fill out a form in an ecommerce site:  (1) completing the checkout process, (2) registering with the site, and (3) contacting you for information/quotes etc.  In addition, depending on your site, you might have other functions that require people to fill out html forms.

Generally, people don’t like filling out forms.  They especially don’t like it when they aren’t sure what you are going to do with the information - so always explain why they need to fill out the form at all.  In some cases, it will be relatively clear, so you probably don’t need to explain why you need to collect their address during the checkout process.  But in other cases, it may not be.  Just why are you asking for their fax number?  And what are you going to do with their date of birth?  You should first make sure that you don’t collect any information that you don’t really need.   Don’t collect a whole lot of information just because you can in the hope that you can use it later.  People might suspect that you are planning on selling it, and be much more reluctant to even fill out the form in the first place.  If you do really need some information and it might not immediately be obvious just why, then it can be a good idea to include a brief explanation of what you need it for.

The next thing to consider is the overall layout of the form.  Sometimes forms contain a lot of fields, so that the user has to scroll down to fill them all out.  This can seem a bit daunting, so it may be better to split them over several pages.   This also means you can check the validity of a little bit of the information at a time, and can possibly use information entered on earlier pages to change the options available on the later pages.  On the other hand, if you split across pages, the user has to wait for the page to load each time, and this delay may be annoying, particularly if there are only a few fields on each display.  Also, there should be some logical partitioning of the fields that have been split up, otherwise it will all seem a bit random and disjointed.  Still on the subject of layout, you must pay attention to how the fields are grouped, and how the labels are positioned in relation to the data entry fields.  http://www.lukew.com/resources/articles/web_forms.html has a good discussion of the options with examples.

Next, you should consider the fields themselves.  There are a number of typical cases:

Names:  Input boxes.  make them long enough to hold fairly long names.  Either one single name field, or split into first and last name.  It is best to call these ‘given’ and ‘family’ names as the customs for name order differ between cultures.  If yours is a western audience though, you should put the given name field first.

Addresses:  Two main possibilities:  Either use one large text area, and allow people to use enter to create new lines within it.  This means that you can’t use enter to submit the form.  This is best if you get orders from a very wide variety of areas with different address formats.  The other main choice is multiple lines, say one for street address, suburb, city, country and post/zip code.  Country is usually implemented as a drop down box.  If you only ship to some countries, only put them in the box.  If you truly do ship anywhere on the planet, then make sure you have an up-to-date country list.  If a large proportion of your customers come from one country, you could consider making that the default, otherwise the list should initially say something like ‘please select’.  The size of the field should give an indiciation of how much you expect in each box.  For instance, your post/zip code field should be the approximate length of a typical postcode.

Dates: You can either give an unconstrained field for typing a date in, unconstrained fields for typing in parts of a date (day, month, year seperately), constrained fields for typing in parts or a calendar control on which the user can click to select the date.  If you are collecting birthdates, consider that most people know their birthday, and can more easily type it directly than select it by any other means.  With credit card expiry dates, you should mimic the format it appears on their card.  Either require them to type or select from a dropdown something like 04/08, don’t make them either type or select April 2005, because doing so incurs a bit of cognitive overhead, as they need to internally make the translation.  It isn’t much, but simple things like this can just make the overall experience of using the form so much better.  If you application is very date conscious, and particularly if the range of dates they need to select from is narrow (say, next three months), then consider using calendar controls.  This could be the case for travel bookings, appointment bookings, and things like that.  Being able to see that they are booking for a Saturday and so on can help prevent accidental errors.  If you are giving unconstrained fields and you do want a particular format, make sure you say so, preferably with an example. (eg 24/02/04).  If there is a meaningful default value, fill it in.

Validation:  the first and easiest way to validate is to use the appropriate controls for the information you are trying to get.  Next, you can set maxlength on fields to ensure that people don’t enter too much though.   Make sure the number you set really is the maximum valid value.  There’s no need to set one just because you can.  It’s unnecessary to set it for something like name, for instance.

Make your error messages gentle and constructive.  Imagine you are sitting next you beloved old Aunt Mabel, and she is filling out the form and has made a mistake.  What would you tell her?  This is what you should tell your form users.  Don’t just say ‘error, please correct’, say ‘Please enter your email address before you continue’, and then set the focus to the email address field.   Yes, this requires javascript and a lot more effort, but if the form is important to your site, then it is worth taking the trouble.  Make sure though, that even users without javascript get something useful - this often requires having both server and client side validation.

When they do submit the form, make it obvious that something has happened - display a clear confirmation message.

I quite often come across badly designed websites.  But I always wonder, should I do something about it?  Should I send an email to the company and politely tell them about the usability issues I encountered? 
How would someone react getting an email out of the blue telling them their site sucks?  Even if I could phrase it nicely, would people take this as an insult?  Or as constructive criticism?

I have enough trouble giving constructive criticim to Cecil.  They are relatively well equipped for dealing with bug reports and helpdesk enquiries, but usability problems don’t seem to be handled so well.   A typical interaction goes like this (note, to protect the innocent, this interaction didn’t happen exactly as described here, but this is a fairly typical type of response):

Me: "I notice that your display is truncating the names of files to 20 characters, even though there is enough room on the screen to show 100 characters or more."
(Note: I didn’t think it was necessary to spell out in detail exactly why I would rather see the full file names, I assumed that would be obvious.)

Them: "Thank you for reporting this issue.  This behaviour is by design in order to conserve screen space.  We suggest that if you want to avoid your file names being truncated, then you should keep your filenames to less than 20 characters long."

Then, I’m pretty sure that if the problem is recorded it all, it is entered into their bug tracking system as a priority 20 (lowest priority), where it languishes at the bottom of the list of 5,000 or so bugs they have to fix.

Fancy a walk down GUI memory lane?  Then visit GUIdebook: Graphical User Interface gallery

This is an amazing museum dedicated to preserving the user interfaces of bygone eras.  Have you been fondly remembering the good old days of GeOS on Commodore 64?  Yearning to interact with Windows for Workgroups 3.11 just one more time?  Or just curious as to how the desktop metaphor has evolved over the past 20 or so years?   This site can show you.

With galleries of the interfaces, including icons, sounds, splash screens and desktop screenshots, you can browse through the looks and feels of dozens of now defunct systems and applications.