DonnaM » 2005 » October

Archive for October, 2005

It’s not about size, it’s about context – radio buttons or drop-downs

Friday, October 21st, 2005

I’ve spent an extraordinary amount of time this week thinking about radio buttons. And I’d like to tell you what I’ve concluded.

I’m designing a complex web form with lots of fields to fill in, most of which are text fields or mutually exclusive option lists. My decision, for a public-facing website, is between drop-down lists and radio buttons.

The popular guideline, and I have found this written in many many places, is that it depends on the size of the list. If the list is long use a drop-down, if it is short use radio buttons.

But in real life, when you actually think about what you are trying to achieve, it is rarely as simple as black and white guidelines.

I’ve been thinking about the decision more deeply and have concluded that it has nothing to do with length of a list, and everything to do with the user context.

For this design decision, the following user contexts are the most relevant:

  • Familiarity with the domain – when users are unfamiliar with the domain (or the fields to fill in) they need additional assistance to understand what they are being asked to do. Radio buttons assist by showing all options on the screen, communicating the domain/field at a glance. However, when users are familiar with the domain it is OK to hide the options in a drop-down list – users can determine what they need to supply from the label (think of a list of States as an example).
  • Task efficiency – On a long form, or something that will be used frequently, users want to complete it quickly. A drop-down list requires the user to read the label, interpret it, click on the box, locate the correct item and click on it again. A radio button list allows the user to read the label and list at one glance, locate the correct item and click on it. Radio buttons are far easier and faster to interpret and select.
  • Screen real estate – In the GUI days, screen real estate was a real issue. Drop-down lists were preferred to radio buttons simply because they took up less room. Most of us are now designing for browsers and this isn’t as important. Not only do we have no control over the window anyway, but there’s a magic gadget called a scroll bar.
  • Size of list – In the GUI days, this was the determining attribute – long lists used drop-downs, short lists used radio buttons. In reality, there is little cognitive difference. The size of the list doesn’t change, so the time to identify the correct item and select it is similar between the two situations. However, as mentioned above, a radio button list may be faster as it doesn’t need to be opened and can be easier to take in at a glance.
  • Frequency of use – For infrequent users, radio buttons are clearly better, due to the concepts outlined above. For frequent users, two things are relevant. Spatial familiarity is important – we become familiar with placement of items on a screen and can fill them in quickly by remembering the spatial placement of items in radio button lists. However, frequent users often use a keyboard; in which case, drop-down lists are better as they allow people to type the first letter of the list and use the keyboard to get to the target item.
  • Interface balance – It is still important that the screen has overall balance and directs the eye appropriately to the flow of the form. When the factors above are equal, go with whatever balances the interface.

It should be clear from the above description that my preference is often for a radio button list, particularly for complex interfaces for infrequent visitors with imperfect domain knowledge.

I’m not usually one to issue declarations or write guidelines, so please don’t take this as a list of rules. Instead, please think about your situation, your users and your domain, and make a decision based on that. Don’t listen to stupid, glib rules that were written 15 years ago ;)

Canberra WSG – Inaugural meeting (and I’m speaking)

Friday, October 21st, 2005

The first Canberra Web Standards Group meeting will be held on Friday 11 November between 4-6pm.

There are two fabulous speakers ;)

  • Dean Jackson from the W3C will be talking about the WC3 and its role and relevance today.
  • I will be talking about designing usable rich internet applications (using technologies like AJAX).

Where: National Library of Australia
Venue: Training Room AB
When: Friday 11 November
Time: 4-6pm
RSVP: canberra@webstandardsgroup.org
Cost: Free

IA Summit call for papers

Monday, October 17th, 2005

The Information Architecture Summit call for papers was released a few weeks ago. The deadline is October 31 for session proposals, and December 5 for posters. In addition to the regular presentations and panels there will be a research track this year.

If you’re doing interesting work with navigation, classification, user research, tagging, metadata, interaction design, etc.–consider submitting something. The summit is March 23 to 27, 2006 in Vancouver.

I’ll be there!

PS – I stole these words straight from Gene (so that’s why they may be familiar)…

How to position an elephant

Friday, October 14th, 2005

This made me laugh until I cried: Relatively positioning an elephant (see the comments)

Marketing for freelancers

Thursday, October 13th, 2005

I’ve been freelancing for only 5 months and I just realised something about all my clients so far – they have all come from different sources.

These include:

  • My first gig – personal contacts via LinkedIn
  • Next – someone I met from a local user experience group
  • Current contract – from one of the job boards
  • Current mentoring client – from an article in Digital Web, then through my website
  • One that I turned down – from a product demo I attended years ago, and kept loosely in touch with the vendor
  • Next contract (not confirmed)- a previous speaking engagement, then keeping in touch on a professional level

That’s interesting, isn’t it. Shows that it is more about being out there and people knowing I’m available than any sort of direct marketing.

Writeboard – I wouldn’t use that (or would I?)

Wednesday, October 5th, 2005

I spent a little time on the weekend looking at 37 Signals new product – Writeboard. If you haven’t seen it already, they describe it as:

“shareable, web based text documents that let you save every edit, roll back any version, and easily compare changes. Use Writeboard to write solo or collaborate with others”

I like 37 Signals products, and use backpack a lot. But reading about Writeboard, I couldn’t imagine a use for it at the moment.

So today I was driving to work and a great idea for an article/workshop/series of blog posts popped into my head. By the time I got to work I’d thought it through and wanted to write it down. Where to write it? I didn’t want to hand write it on paper. I didn’t have my tablet with me (this would be my usual first choice). I hate Word. Putting it into the ‘notes’ area of backpack didn’t feel quite right (and would stop me from using the notes area as ‘notes’).

Ahah! Writeboard actually seemed like a good solution.

So I got to work, and went into the site. Created a new writeboard, wrote up the idea and saved it. Yay – idea out of my head and written down.

Then I remembered that the blurb said I could connect it to my backpack. I have a backpack page for articles and speaking ideas already. I went into my backpack and, just like magic, there’s a tab with ‘Writeboards’ at the top, and a link to import. I imported my new baby and it sat in the list of writeboards. It was a bit lonely there, and I really wanted it to connect to my articles page. Just like magic, there’s a link at the bottom of the page that lets me link a writeboard. Linked and done!

How easy was that! This probably sounds stupidly marketese (well, it does to me), but it was completely real. I had an idea, wrote it down and linked it to my existing ideas within about 3 minutes. I hardly had to think about the process at all. I spent bits of the rest of the days adding extra ideas when they came to me, and have a decent outline all ready. When I’m ready, I can send it to someone and they can review it.

Now this is what usable software should be about…