Usable Forms

Teaching, User Interfaces

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.

What should I do when I see bad web design?

User Interfaces

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.

Are you a Microsoft Office guru?

Other

I always considered myself to be pretty proficient at using the Microsoft Office suite, and most of the hints and tips that I find on the web are usually things I already know.  However, I just came across a series of Office tips from Payne consulting, covering Excel, Outlook, Word and PowerPoint, which included quite a few very useful things that I never knew about.   Here are some highlights:

Outlook: Change the subject of a received message.  Just edit it (even though it doesn’t look editable, it is) and then save the message.  Great for messages without subjects, or where the subject no longer reflects what the message is about.

Outlook: Lookout is a free utility that you can download from Microsoft that allows lightning fast search through all your email folders at once, whether local or on the server.

PowerPoint: Holding down both mouse buttons for two seconds will return you to the first slide of a presentation.   You can also configure the right mouse button to go backwards rather than open a menu (Tools > Options > View tab > Uncheck ’show menu on right mouse click’)

PowerPoint: Compress and crop all pictures in your presentation to make the file size smaller.  (Choose Compress Pictures from the Picture toolbar)

Word: Press Shift+F5 when you open a document and it will jump to the last place you were working before you saved it.

Word: You can customise the menu to include a Work menu, and add documents to it for quick access.  Perfect for, I don’t know, thesis chapters, maybe?

Word: Ctrl+Shift+C and Ctrl+Shift+V can be used to copy and paste formats.

Excel: Some toolbar buttons have undocumented opposite actions, accessed by holding down shift when you click them.  So, Shift+Save will Open and vice versa, Shift+Print Preview will Print and vice versa.  Lets you shrink your toolbar to make room for other useful commands.

Excel: You can colour code sheet tabs by right clicking the sheet tab and choosing Tab Color.  OK, I knew about this one, but it’s still cool.

If PDF is unfit for human consumption, then what is this?

Yucky UIs

If Jakob Nielsen thinks that PDF is unfit for human consumption, what would he make of this ebook website

interaction-net-home.jpg

Let’s go through some of the usability crimes that Jakob says PDF is guilty of, and see how this ebook format stacks up:

  • Linear exposition. You have to flip through this book one page at a time.  With a standard website page (or even a PDF document) you can usually at least quickly scroll up and down to jump to places in a document.  With this ebook, you can only go through it one page at a time, and each time you have to briefly wait for the ‘cute’ page turning animation.
  • Jarring user experience. This e-book is a completely different environment with its own completely non-standard controls.

    interaction-net-toolbar.jpgAt least they have tooltips to tell you what the icons mean.

  • Breaks flow. You can say that again!  If you are running Firefox, here is what you see when you first come to the site: just a big white empty frame and a message saying you have to download a plugin.  Not even a page with an explanation of what the plugin is or does so you can evaluate if it is worth it.   And with IE 6, you get all that and a Javascript error too.

    interaction-net-initial.jpg

  • Orphaned location. There’s no standard navigation within these ebooks.  The back button doesn’t work, and typical navigation cues that people use to tell where they are just aren’t present. 
  • Content blob. This ebook is definitely a blob.  The only internal structure is the pages, no navigation and no search.
  • Text fits the printed page, not a computer screen. Well, that’s true of PDF, but this ebook actually fits neither the printed page or the screen.  It takes up probably around a quarter of each.  

I would add some other crimes to this list as well.   The developers of this ebook format say that it is ideal for magazines, catalogues, manuals & brochures, and claim that it allows your content to "look like a book, read like a book and the pages turn just like a real book".  However, it eliminates all of the features of real magazines, catalogues, manuals and brochures that makes them so useful: the ability to quickly skim through to get a overview of the contents, the ability to open to any page at will, the ability to mark or hold several pages at once and quickly flick between them to compare things.

If PDF is unfit for human consumption, then you wouldn’t even feed this ebook to rats.  At least nobody ever used a PDF file as their home page.

Using icons that show both action and state

Yucky UIs

Which of these icons means ‘you are subscribed to email notifications’, and which one means you aren’t?  sub.bmp unsub.bmp

This icon sub.bmp means: You are not subscribed.
This icon unsub.bmp means: You are subscribed.

Obvious, eh?

Even with the tooltips:sub.bmp subtt.bmp and unsub.bmp unsubtt.bmp it isn’t immediately clear what’s going on, especially when you’re in the ’subscribed’ state.

This is a case of trying to use one icon for two different purposes which are at odds with each other: showing action and showing state. The designer intend this icon sub.bmp to convey the idea of a subscribe action: "If you click this button, you will be subscribed".  The button shows the future state.
Likewise, unsub.bmp is supposed to show the unsubscribe action. It is in effect showing a future state of not being subscribed. (Whether a ‘no entry’ symbol is the best for this is another matter entirely).
A similar problem can sometimes be found by developers trying to show the actions ‘lock’ and ‘unlock’ with a padlock icon.

Rather than interpreting these as action buttons indicating a future state, most users will probably see these as a toggle button indicating the current state, and get completely the opposite impression from what is actually going on. The best solution is to implement the buttons as though they were toggling the current state, and make the tooltips reinforce that. Its the user’s natural assumption anyway, so why not take advantage of it?

GUIdebook: Graphical User Interface gallery

User Interfaces

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.

Would you download an exe from this site?

Yucky UIs

Hands up how many people would download an unexpected exe from some site they’d just found on google?  A site with no content except for four exe files?. Not many I’d bet, well, not many sensible ones at least.  So what made the people at this site think this was a good way to provide everyone with access to their product catalogues?

Read More »