CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"ACM SIGCHI WWW Human Factors (Open Discussion)" <[log in to unmask]>
Helen Killingbeck <[log in to unmask]>
Mon, 8 Dec 2008 11:30:04 +0100
Mathijs Panhuijsen <[log in to unmask]>
Mathijs Panhuijsen <[log in to unmask]>
text/plain; charset="US-ASCII"
text/plain (200 lines)
Hello Helen,

1. This is a bad argument. It's possible to display a list of
radiobuttons with none selected initially (even in HTML), thereby
forcing a choice and (if the field is mandatory) making an 'easy route'
2. I'd like to see some authoritative accessibility guidelines that
confirm this --I strongly doubt they exist. In both cases, the control
needs a label, which can explain very accurately what the control is
3. A strange argument, best countered by saying, 'No, they look uglier',
driving home the point that aesthetics are not only irrelevant but also
completely arbitrary.

In the case of a choice with few options, especially 2 like your Yes/No
options, there are some basic usability disadvantages to a dropdown box:

-Selecting an option costs an extra click (one to open the box, another
to select a choice)
-Users don't see which options they can choose from (until they open the
-Implementing a dropdown for a two-way choice is unusual and will
confuse the user (e.g. making them expect to see more options)

All these points violate the Don't Make Me Think principle of good UI
design, and so interrupt a smooth flow of UI use.

One reason to choose for a dropdown box over a set of radiobuttons could
be screen real estate: a box typically takes up less space.
But outside, say, the screen of a mobile, where space is extremely
tight, the space argument only becomes a good reason if the number of
options is large, and/or if the label of each option is long. 
In your case (two options, short labels Yes and No), I wouldn't see the

Anyway, that's just my two cents. 
I think digging through the literature will unearth some hard and
incontrovertible data about 
(a) the prevalence of radiobuttons over dropdowns in your type of
scenario, and
(b) the higher usability of radiobuttons over dropdowns in your type of
scenario (e.g. time taken to complete a task)

Hope this helps,

-----Original Message-----
From: ACM SIGCHI WWW Human Factors (Open Discussion)
[mailto:[log in to unmask]] On Behalf Of Helen Killingbeck
Sent: Saturday, December 06, 2008 00:11
To: [log in to unmask]
Subject: Re: Improving user through put of online forms

Excellent post on improving user throughput and reducing error rates for
online forms.
I am literally banging my head on my desk as I have been advocating for
use of radio button controls for static choices (example Yes  No).

The business logic and the developers' logic however is that:

1.  they want drop down boxes for static options because by putting it
in a
drop down box, with --Select-- as the default, they will force the user
choose an option, whereas if they use radio buttons, one radio button
be a default, and the users may just want to go the easy route.
2. --Populating the drop down boxes with --Select-- meets accessibility
3.  Drop down boxes look better visually!

I would love to hear how others have handled this type of argument when
user groups for the same interface are Call Centre Operators  and  Front
line tellers (with a high turnover rate). Completely different context
Thanks in advance.

On Thu, Dec 4, 2008 at 5:20 PM, Caroline Jarrett <
[log in to unmask]> wrote:

> Matthew Belge
> <snip: description of high-usage forms>
> >
> > My question: Has anything been done for this type of user to help
> their throughput and reduce error rates?
> <snip - some suggestions>
> Hi Matthew
> I'm away from my library right now but if you look back in the
> you will find that this was very much the focus of a lot of
> work in the 1980s and early 1990s.
> Here are some more tips for making high-usage forms efficient:
> - carefully analyse which fields are in fact used a lot and which are
> a
> little. Try to cram as many high-usage fields as possible onto as few
> screens as possible. The resultant screens will be horrible to look at
> difficult to learn, but once learned they should be more efficient
> - if users are interrupted or have any other reason why they need to
> from one record to another, have some way of making this easy to do at
> speed. I saw one system with a 'suspend' feature that allowed you to
> working on two records at once.
> - ensure that the entire suite of forms can be totally accessed using
> keyboard only, and preferably using keypad only. For example, ensure
> 'Enter' will take you to the next field (available on keypad) not just
> 'Tab'.
> - analyse the actual data to provide as many defaults as possible.
> - limit dropdowns to the most likely entries plus 'other' to expand to
> likely entries
> - brush off your older techniques such as task analysis to find out
> what keystrokes are required for the most common transactions. Look
> places where the task flow can be optimised to remove keystrokes
> - most of all: go and watch the users with their current applications
> real task load. They may have found all sorts of workarounds that you
> make easier for them.
> And a word of caution: As in any other system, 80% of their work will
> from 20% of calls where they've got the whole thing memorised, right
> to
> things like keying or mousing ahead to where screens will be in a
> when they've loaded. Interfering with that MAY bring benefits but will
> cause a short-term drop in productivity while they adjust to the new
> screens.
> Anecdote: I did some observations in a call centre a few years ago. I
> watched an expert user (two years experience) deal with a call in less
> 4 minutes. I watched a very similar call dealt with by a novice user:
> minutes. The expert totally multitasked in many different
> moved her mouse to where the next click would be ahead of the screen
> appearing, and never had to use any thought to make any decision on
> computer: all her attention was on the customer. The novice actually
had to
> read the screens and make decisions about them.
> Best
> Caroline Jarrett
>    --------------------------------------------------------------
>        Tip of the Day: Forward out-of-office replies to
>                    mailto:[log in to unmask]
>     CHI-WEB: POSTINGS: mailto:[log in to unmask]
>              MODERATORS: mailto:[log in to unmask]
>    --------------------------------------------------------------

           Tip of the Day: Postings must be in plain text
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]

The contents of this email and any attachments thereto are confidential to the intended recipient(s). They may not be disclosed to, used by or copied in any way by anyone other than the named addressee(s). If you have received this email by mistake, please notify SDL Tridion immediately on +31 (0)20 20 10 500 quoting the name of the sender and the email address to which it has been sent and then delete it from your system. SDL Tridion does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission, nor does SDL Tridion accept liability for any damage caused by any virus transmitted by this email.

    Tip of the Day: Suspend your subscription if using auto replies
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]