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'
impossible.
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
for.
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
box)
-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
benefit.
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,
Mathijs
-----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
the
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
to
choose an option, whereas if they use radio buttons, one radio button
will
be a default, and the users may just want to go the easy route.
2. --Populating the drop down boxes with --Select-- meets accessibility
compliance
3. Drop down boxes look better visually!
I would love to hear how others have handled this type of argument when
the
user groups for the same interface are Call Centre Operators and Front
line tellers (with a high turnover rate). Completely different context
of
use.
Thanks in advance.
Helen
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
improve
> 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
literature,
> you will find that this was very much the focus of a lot of
usability/HCI
> 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
used
> 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
and
> difficult to learn, but once learned they should be more efficient
>
> - if users are interrupted or have any other reason why they need to
swap
> from one record to another, have some way of making this easy to do at
high
> speed. I saw one system with a 'suspend' feature that allowed you to
be
> 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
that
> '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
less
> likely entries
>
> - brush off your older techniques such as task analysis to find out
exactly
> what keystrokes are required for the most common transactions. Look
for
> places where the task flow can be optimised to remove keystrokes
>
> - most of all: go and watch the users with their current applications
and
> real task load. They may have found all sorts of workarounds that you
can
> make easier for them.
>
> And a word of caution: As in any other system, 80% of their work will
come
> from 20% of calls where they've got the whole thing memorised, right
down
> to
> things like keying or mousing ahead to where screens will be in a
moment
> when they've loaded. Interfering with that MAY bring benefits but will
also
> 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
than
> 4 minutes. I watched a very similar call dealt with by a novice user:
14
> minutes. The expert totally multitasked in many different
applications,
> 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
the
> 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: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
> MODERATORS: mailto:[log in to unmask]
> SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
> --------------------------------------------------------------
>
>
--------------------------------------------------------------
Tip of the Day: Postings must be in plain text
CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
--------------------------------------------------------------
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: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
--------------------------------------------------------------
|
