CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Matt Belge <[log in to unmask]>
Reply To:
Matt Belge <[log in to unmask]>
Tue, 9 Dec 2008 08:25:51 -0500
text/plain (408 lines)
I would like to thank all who have contributed to my question regarding
improving user through put of online forms. The question was aimed
specifically at users who work in call centers, where their job is to take
orders from customers on the phone, and then input the information the
customers give them into an online form. Examples of people who have this
kind of job are online retailers for clothing or computers, airline and
hotel reservations, and many other phone centers that deal with customers.


Below is a summary of the responses I got. One respondent, Lisa Neal,
mentioned that there is an expert in online forms and that she has written a
book on the topic. The book is  "Forms that Work: Designing Web Forms for
Usability" by Caroline Jarrett. I went and purchased a copy of the book, and
although I have just begun reading it, it does seem quite worthwhile.  


By fortunate circumstance, Caroline Jarrett did respond to my posted
question, and her response is given below.


Finally, I must point out that during the time people were responding, my
ISP informed me my mail box was overflowing (time for a new ISP!) This means
I may not have received all the responses sent to me. If you sent a response
and don't see it below, please send again and I will repost.


Many thanks!


Matt Belge

[log in to unmask]




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 analyze 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


- analyze 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 optimized 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 memorized, 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


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.



Caroline Jarrett




Hi Matthew,


Agree with Caroline's comments.


I have also done observations in call centres and I wanted to add a further
recommendation. Don't skimp on context of use observations:


- how is the lighting in the centre?

- do folk look happy or stressed?

- what is the pressure level? Look for motivational post-its, visible
awards, a ranking chart and so on. The mood of the centre impacts how people
deal with the software

- make a point of observing the actual workstations in use: do users take
notes on a separate pad of paper and input later? Do they multitask across
multiple apps in multiple windows? How big are their screens, how big to
they set their windows (I recently observed a call-centre where they had
high resolution screens but tended to put everything in a 640x480 window)?


I almost always discover insights we hadn't imagined in workshops and focus
groups by doing context-of-use observations. Given it costs almost nothing
to do, I'd say it's got by far the greatest risk/reward ratio in creative
discovery :-)


Finally I wanted stress another one of Caroline's points, you need to handle
technical failure as well as possible. Consider what happens to the sequence
of forms if the browser crashes. What if the machine crashes?


All the best,





Dug Falby

+44 75 15 66 16 55



Hi Matt:


Thoughts that spring to mind:


Search. Really good search. (What "really good" means being a logical
follow-on question.)


Well thought-out master detail patterns. Sometimes master-detail-detail.

Example: Table of order items, with a detail pane showing the selected item.

Sometimes the master can be viewed in multiple ways. Sometimes the detail
can. Often the master will be a result of a search (above). Maybe it's
obvious, but optimizing these is important where they are used frequently,
and they are used frequently in database & order entry systems.


Good performance. 


Preserving past keyboard accelerators wherever you can. Making sure
everything is keyboard accessible in a logical way.


Customization. Like superhero powers, can be used for good or evil. Does a
single user sit in their own private Idaho all day long? They may benefit
from it. Do different users "specialize" in different tasks? They may
require it. Are there major differences in how the software is used between
installations? Then it will be a product requirement, and customization will
often be done by installers. Do users move between systems so quickly that
workstations are interchangeable? Customization might be counter-productive
there. Customization could mean a lot of things. It could be a boon or a
waste of time. 


I'm sure there are many more, but it's late and that's what springs to mind


Tim Shea

[log in to unmask]




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

Thanks in advance.


Helen Killingbeck



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 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


-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,

(b) the higher usability of radiobuttons over dropdowns in your type of
scenario (e.g. time taken to complete a task)


Hope this helps,





Hi Matt,

Caroline Jarrett is the world's expert on this. Do you know her?

We recently wrote
&article=105-1 together but I know her from CHI.





[log in to unmask]

Vision & Logic









        Tip of the Day: Email mailto:[log in to unmask]
               with any comments, questions or problems
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]