Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
06 Oct 2006 Everyone knows that computer applications (and the people who write them) just want to help. Learn how poor design decisions can turn the most well-intentioned wizard into a hated enemy, and the most reasonable seeming default into an unreasonable one.
This scene has showed up everywhere from video games to blockbuster films: a
kitchen that looks like it got hit by a tornado, a beleaguered adult, and a small child, utterly coated in spilled food, who proudly announces, "I'm helping!"
On the surface computers seem to have very little in common with small children, but in fact history is rife with examples of computer programs designed to help in just the way a peanut-butter-smeared child might. That
is, by making a bad situation even worse.
My all time favorite program in the hapless-helper category is probably Microsoft Bob, a Windows UI agent that came out sometime around 1995
and was deprecated (to the tune of howling laughter from the user community) not much later. Among other things, Microsoft Bob allowed you to set a password. If you guessed the password wrong too often, however, kindly Bob would suggest that perhaps you had forgotten it, and would like to pick a new one.
This month I'll look at this and other examples of computer helpers that do more harm than good.
The for-dummies interface
I wrote previously in this column about Clippy, one of the most-hated entities in the history of computing. Like Microsoft Bob, Clippy was intended
as a friendly user interface, in this case for Microsoft Office 97. Clippy might have been merely disliked on machines an order of magnitude faster than
those on which he ran. As it was, many office machines were paralyzed by the effort of loading an animated character on top of the already huge Microsoft Office suite.
One of the most disturbing examples of Clippy hate was a much-circulated
in-joke: a plausible-looking screen shot of a Word document with the
text "I just cant take it anymore!" The word cant is underlined as a probable grammatical error, and there's Clippy in the corner saying "Looks like
you're committing suicide!"
The problem with using animated characters as UI agents is that most of them disrupt work rather than speed it. If the program's logic for predicting your next move isn't perfectly accurate, it just gets in the way. Clippy was especially loathed for his near-viral ability to re-enable himself after being told to disappear, although this was disabled in later versions.
Animated gizmos like Clippy and Microsoft Bob pop up because some novice users require them. If your assistance system is purely user-driven, many new users will never find it. What neophyte knows enough to figure out where Word's "business letter" template is? Such guidance works only if the heuristics and resulting automated actions are a good match for the user, however.
A user at a company with strictly formalized rules for the content and
style of business letters could face serious consequences
for simply following the instructions of dancing office supplies.
As long as the heuristics of UI agents are geared to the needs of
novice users (which are, after all, easiest to predict), they'll be an inconvenience to more experienced ones. If you already know what you're trying to do, Clippy and Bob probably probably can't help you do it. And if you don't know what you're doing, they probably can't tell you.
Unreasonable defaults
I recently spent a chunk of time hovering over a scanner, scanning
in hundreds of documents. As I quickly learned, the scanning software
had, well, some quirks. After groveling in the preferences for a while I
managed to convince it to scan documents as images. But for every new
document it selected PDF as the save format. If I wanted a different
format, I had to manually select it from the pop-up menu for every
document I saved. There was no way to re-set the default, and the
program wasn't smart enough to adjust itself after a certain number
of manual settings. No matter how many times I selected TIFF, the
software was certain that this time, surely, I wanted PDF.
Safari's much-vaunted (and admittedly delightful) text-scaling feature
presents another example of what I call an unreasonable default.
While the browser allows you to scale up text size in a particular
window, these changes don't persist. If you middle-click on a link
to open a new window, the new window always starts back at the default text.
The whole idea of text-scaling is that it allows users to politely
abstain from reading microscopic text on pages that specify font size.
If I'm opening a number of windows on a site, I probably want to see the
same text scaling across all the pages. Instead, I get the unreadable
text I originally tried to scale up from. Why is that? Surely, no one
has ever said "Gosh, if only I could get the browser to forget that
preference setting I just made." But for whatever reason, scaling isn't
sticky. It would be nice if you could at least set a permanent scaling
option in the preferences.
Don't get me wrong: I think reasonable defaults are a good thing. But I do wish the unreasonable default wasn't so oddly prevalent. Developers simply decide what they think is the most obvious default, and then forcibly select it for you over and over again. You can't change it no matter what you do. Next time, let users override the default, and make sure the override sticks.
Ads in all the wrong places
It seems odd that the same people who would certainly not expect Clippy to write their letters for them would let similar software generate their banner ads. Keyword matching is a quick-and dirty (or cheap-and-lazy) way to generate targeted banner ads. Rather than figuring out which sites want which ads, or which words best represent a given site, keyword matching lets
clients come up with general rules and produces generic ads based on
those rules.
The trouble is, like Clippy's heuristics, the rules tend to be oversimplified
and, thus, don't always work. Perhaps the most severe example of keyword
matching gone wrong involved an online vendor whose generic ads claimed it had humans available for purchase. There was a major outcry before
people realized that the computer generating the ad text was unaware of the meanings of the words involved.
Go ahead, slow down my day!
Ahh, gotta love those management buzzwords. Workflow
optimization sounds like something that involves seminars in
far-away places. In reality, it often involves yet another misfired
attempt to make users' lives easier.
From a developer's perspective, the idea is simple: you analyze the
steps involved in a task, then make it easier to get through them
quickly by removing redundant steps. For instance, a personal finance
package might use the date of the last-recorded transaction as a default
date for a new transaction. Many programs are optimized to automatically
bring data from previous transactions into new ones. Words are completed
for you as you type.
Good workflow optimization actually does reduce the hassle of daily
tasks. Even something as simple as automatically completing familiar
words in a form can save the user time and optimize performance. When
the personal finance software I use automatically completes category
names for me, I'm glad for the help. In an older version of the
software, however, that same feature was way too aggressive. If you had a
category whose name was a prefix to another category's name, you
couldn't enter it. As soon as you tried to select it, the autocompletion
facility would fill in the longer name. Pre-filling fields correctly
saves time and reduces errors; pre-filling them poorly not only slows
users down, but introduces errors.
The problem with workflow optimization is that developers often fail
to take into account the diversity of workflows. Users performing
different tasks don't need standardized, cookie-cutter assistance from
their tools. A feature that substantially improves performance on one
task might cripple another.
Turn. It. Off.
When designing a so-called helpful feature or interface, start by ensuring that users can turn it off. Oversight is inevitable, and any system will run into some problems it can't solve. Enabling users to pull the plug avoids the most dreaded problem of all: the malfunctioning system from which there is
no escape. Brian Kernighan's most damning statement about the programming language Pascal is just as apt when discussing many helper programs: "There is no escape."
Providing an escape hatch reduces the pressure to make your helpful
idea perfect, with the end result that you might make it very good instead. By taking on a possible task, you allow for some hope of success. Just remember that no matter what the feature -- from autocorrection to automatic timestamps -- there will come a day when it's just not what the user
wants. If you try to accommodate every possible circumstance, the result
will be an incoherent disaster. If you pick a subset of cases and handle them
well, users will actually benefit.
This week's action item: Pretend you're Clippy. Walk up behind a stressed-out coworker and say something to the effect of "Hey, it looks like you're trying to debug a program! I can help you do that. Is the problem (a) crashing; (b) unexpected behavior; or (c) a vague specification?" Have fun,
but be prepared to run.
Resources Learn
- The cranky user: Your language usage matters (Peter Seebach, developerWorks, August 2006): Check your grammar when you design human-computer interactions.
- The cranky user: Usability off the beaten path (Peter Seebach, developerWorks, March 2006): Review this survey of user-centered innovations in computer software and hardware design.
- Microsoft Bob: Annoying enough to have its own Wikipedia entry (as does Clippy).
- Why Pascal is Not My Favorite Programming Language (Brian W. Kernighan, 1981): Learn what the biggest problem with Pascal is -- there is no escape.
- The cranky user columns: Read any of the earlier articles in this column.
- developerWorks' Web zone: Improve your work with info that specializes in Web architecture and development, featuring downloads and products, open source projects, a technical library, training, and events notices.
- developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
Discuss
About the author  | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| 
