The first in a series of Learning from Lusers.
[The user] was adamant that the cable was correctly plugged in…. I finally figured out what she meant. She had been checking the other end of the cable, where it plugs into the desktop chassis. I pointed this out to her. She said, quote, “Oh! I didn’t know it had two ends!” (Rinkworks)
Obviously a case of someone new to our universe. Obviously, this user came from a place where cables have only one end and sheets of paper have only one side. Or maybe it depends what you mean by “two ends.” Whenever a user approaches something new, they’ll invoke their own mental models to try to understand it. The models themselves are recalled or assembled by applying certain heuristics, common-sense rules that actually work quite often, but are far from foolproof, especially with certain fools. Perhaps the most important heuristic is thinking by analogy, where the user forms a mental model of the new thing by aligning it with something familiar from experience.
An IT professional regularly deals with the likes of serial port, parallel port, coax, Ethernet, and USB cables, where checking both ends for problems is obvious. But what is the most common cable the average person deals with? What cable experience can they draw on to use as an analogy for a new experience (in this case, involving a monitor cable)? With little doubt the answer is a power cord. When it comes to plugging things in, your basic consumer has plugged more power cords into outlets than all other things combined. This becomes the experience base for all new cables they come across. So go look at your toaster oven. How many ends does the power cord have? Speaking more precisely, how many ends does it make sense to check to see if it’s plugged in correctly? With power cords, all that matters to check is the loose end where the device plugs into something else, and that is exactly what the user above was doing.
It’s not just power cords, by the way. Moving to experiences closer to computers, you see that most peripherals a user is likely plug in have “one-ended” cables: mice, keyboards, computer speakers, microphones, headphones…. Come to think of it, my monitor cable is one-ended. Ironically, the power cord of my computer is about the only two-ended cable that came with it.
Boss tears into [an IT support worker] for failing to keep the PCs running properly. When the rant finally ends, [worker] asks what the problem is. “The boss explains that his CD drive isn’t working. I open up the CD drive, turn the disk over and put it back in. Boss’s comment: ‘At least you’re learning from your mistakes.’” (The Shark Tank)
How can any one not know which way a CD goes in a CD-ROM drive, even psycho bosses? Isn’t label-side-up obviously the way they would have designed it? It makes it easy to check what CD is in the tray just by opening it. Why would anyone think the medium side of the CD should be up?
Applying the analogy heuristic to CDs, the user may have realized that visually, and sometimes functionally, they’re closest to vinyl records. And if you want to play Side 1 of a record, which side do you put up? Obviously Side 1. Generalization: The medium you want to access goes up.
For users with a vinyl record background and the unfortunate knowledge that the unlabeled side of a CD has the data, this error is understandable, even predictable. If it’s predictable, we can design for it. We could include two read heads in the CD drive so the CD can be read either way (which would be a benefit for the blind, by the way). If that’s too expensive, we could at least help the user recover. We could give the CD drive enough hardware to detect if the CD is upside down and send a standard error code for the UI to provide an error message or something.
Father: “Wait! Don’t send that email!” Me: “Why?” Father: “We have to wait until the long-distance rates go down!” (Tech Tales)
Welcome to email. What previous experience do you a think a user will rely on to come to terms with this? Snail mail, of course, which email is deliberately made to emulate, right down to talking about “addresses,” “envelopes,” and so forth. In doing this, we are relying on users applying the analogy heuristic to email. It is the application of the analogy heuristic that helps users understand that to send an email they have to enter the right “address” according to a standard format, much like physical mail. For the most part, this analogy works okay, but users are not compelled to take one metaphor provided by the designers and stick with it. Users sense that email is also different than physical mail, and so they will have no problem mixing in other analogies to try to understand it. In particular, even the most novice user may recognize that email gets to its destination much faster than regular mail by using the phone lines. In other words, it’s not unlike a fax. So perhaps we shouldn’t be surprised that users imagine sending an email is like dialing a fax number for the destination.
“We are going to have a second phone line put in for our computer. What steps do we need to take in order to switch our account over to the new phone number? What about receiving my e-mail? I thought it came to the phone number.” (Rinkworks)
If email is like faxing, then to receive an email requires the sender or at least some intermediary to know the phone number to send it to. How else can something come to you over your phone lines? And so, across the nation countless users can’t understand why they can’t connect to the internet after so carefully entering their own phone number into New Connection Wizard. Why aren’t I getting anything? I gave it the right number!
This is another error for which we can design for easier recovery. If the software always detects a busy signal every time for a particular phone number, then maybe it could suggest to the user to be sure the computer is calling the ISP in order access mail. The message could be worded to introduce the user to how mail retrieval really works.
Often by substituting a different analogy we can prevent such erroneous application of the analogy heuristic. In this case, all we have to do is extend the mail metaphor. What if instead of using cryptic terms like “POP3 server” or “ISP” we talked to users in our documentation and marketing literature about “email post offices”? The user’s email address is not a home address, but an address of an electronic mail box. If we got users thinking that way, it would be clear that the mail doesn’t come to them. They have to go get it from the post office. They have to dial the post office’s phone number.
“It’s not a garage door opener. Try putting it down on the mouse mat.”(Tech Tales)
The mouse. Oh, now there’s something intuitive for you. I mean, going back to the original Macintosh, isn’t the friendly mouse the very symbol of a usable user interface?
There’s nothing intuitive about the mouse. It’s a completely alien piece of hardware, found only with computers. The only clue to its function is the presence of an unlabeled button or two. What’s it for? How do you use it? With so few clues to work with, users are likely to make inferences based on superficial visual or functional similarities. Point it at the screen and click it like a garage door opener or remote control? Why not, if that’s how you’re used to controlling gadgets? It supposed to be some kind of pointer device. Pointer, eh? So you press it against the screen and click the button to point at something, right? Got some office dictation experience in your past? Well, you might just recognize the mouse as a foot pedal. And darn cheaply made one, at that (frankly that one makes a lot of sense: given you need both hands to work the keyboard, why would we want to overload users with another hand control?).
Heck, even the science-fictional über-geek Montgomery Scott mistook a mouse for a microphone in Star Trek IV. In the future, computers will be primarily voice controlled (yeah, right), so Scotty was just thinking by his own analogy, just like any luser. (Parenthetically, Scotty had no trouble using a keyboard. Looks like QWERTY is going to persist into the 23rd century. Sorry, Dvorak evangelists).
Elegant as the mouse may appear, it’s very bland. Can’t we provide it with some visual attributes to make its function more obvious? How about molding in finger indentations so at least users can tell how to hold it?
“Why don’t you just pick the flippin’ thing up, move it to the centre of the desk, and carry on sliding it from there?”, says I, wincing. “Oh, I didn’t realise you could do that. How will it know where I am, if I lift it off the desk?” (Tech Tales)
Ok, say your user figures out the slide-the-mouse-to-move-the-pointer trick. I don’t know how, maybe there was an illustration on the box the computer came in, something ingenious like that. Let’s say the user even figures out which way to hold the mouse (again, that brilliant picture to the rescue). But how does it work? There’s a ball or light in the bottom that seems to be some kind of sensor. Maybe it sets up some sort of sonic infrared grid that establishes its position. No, wait, you slide it over a mouse pad. I mean, you’ve got to have a mouse pad right? It must be something pretty frigging important, otherwise they wouldn’t have included one with the computer, right? Probably imbedded with cobalt-niobium magnetic grains or something. I saw a picture of something called a “graphics tablet” and computer once…. So one day, the user slides the mouse all the way to the edge of the mouse pad and OH MY GOD THE ARROW THINGY IS ONLY HALF WAY ACROSS THE SCREEN WHAT AM I GOING TO DO I CAN’T EVEN REACH “START” TO TURN THE COMPUTER OFF QUICK GET ME A BIGGER MOUSE PAD!
As designers, we can influence the analogies users adopt, sometimes accidentally and for the worse. The very fact that we give the user a mouse pad suggests it serves some technical function. What that function might be is left up to users to figure out via whatever analogies they can come up with. So far, all the separate pieces that came in the box with the computer were a functional integral part of it. So by analogy, why not the mouse pad too?
As novices, with so little relevant experience to draw their analogies from, they might just latch on to our own subtle use of language and metaphor in unexpected ways.
“Don’t you know anything? The Internet isn’t in the wall! It’s all around us!” (waves arms and looks in awe at the ceiling) “You can’t even SEE it!”(Rinkworks)
Did I say that even the most novice users recognize that the internet uses the phone lines? Not necessarily. After all, what does the web, essentially a mass media visual experience, have to do with the telephone? Telephony is not the analogy that is likely to come to mind first. Plugging in a TV cable to your computer makes sense, but a telephone line? Seems more logical to just pick the web out of the air like a television with rabbit ears. Our own metaphors don’t help. We talk about “cyberspace” as if it were some parallel universe to our own, when really it is a bunch of files sitting on big public-access computers connected to the phone system. We should’ve called it “phonefiles.” Too late now, because, hey, it turns out the Internet is all around us these days.
“My laptop won’t connect to the Internet at home anymore.” …Did we configure the laptop for wireless? User: “I don’t know.” Who is your ISP? “I don’t know.” Did you set up your own wireless system at home? “I don’t know.” Hmm, …. Did someone close by move recently? User: “Yes, my upstairs neighbor.”(The Shark Tank)
Bummer, dude. The internet moved. I guess you’ll have to too.
“The icons are all cramped like that. Does that mean the folder’s full?” (Tech Tales)
Consciously or not, we use metaphors in our UI designs to try to communicate functions, capitalizing on the fact that users will apply the analogy heuristics to figure out the functions. But like all metaphors, they have their limits, a point in which the system deviates from the metaphor we use. The graphic imagery we use can have unwanted side effects because there is no way for the user to know the boundaries of the metaphor. We deliberately use a folder metaphor to indicate the organization of files into directories, intentionally invoking the metaphor in the users mind so they can apply it successfully (i.e., organize their files into neat folders). Directories are like file folders, but how much are they like file folders? Quite arbitrarily, a folder packed with icons does not indicate the directory is at some system limit. Why not? That would make an appealing way to indicate a full disk drive. Sometimes the best solution to such metaphor confusion is to give in to it: make the system act like the metaphor dictates. In this case, however, it just happens to be technically impractical given vast capacities of modern hard drives, but novice users will not know these technicalities. To them, it just turns out we do not choose to use that aspect of the metaphor.
I mentioned before how the physical mail metaphor serves email pretty well, but it can still be pushed too far. I wonder about the email client I happen to use, Foxmail, which indicates message priority by the value of a “postage stamp” at the top of the letter. I wonder if some users think that their ISP will charge them extra if they send too many high priority messages. Or if increasing the priority makes the message get to its destination faster, like using some more expensive mail services.
User’s hard drive crashes, and even though [IT support] sends it to a data recovery service, it’s beyond help…. “After telling the user that we could not get the data off the hard drive, she then proceeded to tell me that she didn’t need the data off the hard drive — she needed it off the desktop. Make it happen! I explained to her in gentle terms that the desktop was on the hard drive and that it, too, was inaccessible” (The Shark Tank)
If only avoiding the dangers of hard drive crashes were so easy.
Now take a good look at Windows Explorer. What do we show the users? Why, the files on the hard disks are separate from the files on the Desktop. So why should a hard disk crash affect any files on the Desktop? That’s like thinking scratching a CD can ruin My Documents. Yes, there are good usability reasons to make the Desktop appear as the root of the user interface to the file structure, but it also suggests to the user that the Desktop is a separate physical entity.
“He said he had a huge bunch of old Excel files that he didn’t recognize and no longer wanted. When he deleted them, the computer failed. I asked him just what exactly he did. He said he searched for all the ‘.exe’ files and deleted them.” (Shark Tank)
Well, you have to admit, “exe” is a more sensible extension for Excel spreadsheets than “.xls.” Anyone can make a mistake deciphering an extension, and in this case that anyone was someone working in IT. He joins the ranks of many distinguished and accomplished users who summon the courage one day to explore their computer, and maybe tidy things up an bit, and –holy crap! What are all these documents? All sitting in this “Windows” folder (stupid name; all documents on this computer are Windows documents; can you possibly be more non-specific?). Well, I didn’t make these documents and I’ve never needed them before. And what kind of file names are these? Half of them I can’t even open to see what they are! I say chuck the lot! And that stupid folder too!
At what point in users’ education do they learn that not all files are documents? Some are machinery. How are they supposed to learn this? With our GUIs, we take such pains to make the UI a virtual “desktop,” where each object is a “document” to be created, edited, and sent, and, if desired, discarded. The user buys into our metaphor, and uses the analogy to guide behavior. And how do we reward their cooperation? If it were the physical world, it’s like they find this scrap a paper in the back of a drawer in their desk. It looks like gibberish. So they throw it away. And then their desk collapses into a heap of dust. It doesn’t have to be. We didn’t have to make system files appear like documents in a folder. We could have provided directories for system and program files with an “executable” attribute. Such directories would invoke a more appropriate metaphor, such as an electronics rack or cabinet.
The situation is not helped by the fact that a lot of stuff on our computers is useless junk. Does the user need all those different wallpapers? Or all that clip art? How about all those icons littering the desktop for all those amazingly useful bonus programs included with every Dell? It may be safe, but hardly correct for a user to assume that just because something is included with the computer it must be important. Some of it is just the equivalent of a mouse pad.
Summary Checklist
Problem: In using the analogy heuristic, users may draw on invalid analogies to understand your UI.
Potential Solution: Review your UI design and your users’ backgrounds and identify analogies the user might use. You can also conduct usability tests and surveys to see if certain analogies are likely to be invoked. For each invalid analogy identified, mitigate with one or more of the following:
- Use that analogy –design or re-design the UI to make the analogy valid. This is appropriate only if the analogy is the most common one invoked by users among other competing analogies.
- Remove or change visual attributes that suggest the invalid analogy. Add finger grips to make the mouse look like something to grasp with hand. Use an electronics cabinet or rack metaphor, rather than folders, to contain system files.
- Educate the user against the invalid analogy. Provide documentation and educational materials on the appropriate functionality and limits of any metaphors you use. On packaging, marketing materials, or in the UI itself provide simple diagrams and text, such as a picture labeling computer parts and summarizing their function. In software, explain or warn of departures from the metaphor, such as MS Windows now provides when the user first accesses the Windows folder.
- Support recovery from applying the invalid analogy. Detect when the user is making an error consistent with the wrong analogy and word messages to steer the user towards the right interpretation. Include basic explanations in the knowledge base and dispel common misunderstanding in FAQs. Brief phone support on misperceptions and provide alternative appropriate metaphors or explanations.