The second in a series of Learning from Lusers.
On one occasion, a lady came into the store, apparently interested in buying a home computer. After surveying the models on display, she walked over to one and pointed to the monitor and keyboard saying, “I think I need one of these, and one of those….” She then pointed to the CPU and continued, “…but I don’t think I need one of those.” (Rinkworks)
Of course the monitor is equivalent to the computer. All you have to do is look: the screen shows me everything about my computer right in it. The files, the programs, the network, everything. Since that’s where I see them, that’s where they are. I feel sorry for other users with slow computers that require elaborate shutdown procedures and then take forever to turn back on. I just go click this button in the lower right corner of my computer and it goes off; click and the computer is back on with everything exactly how I left it. Why aren’t all computers that good? Except, I would like to trade with yours. I like your wallpaper better. That big beige box on the floor? Oh that’s just the hard drive. I mean the modem. I mean the surge protector.
In our last episode of Learning from Lusers, we covered the analogy heuristic, where a user forms a mental model of something by making an analogy or metaphor to something familiar. Another key heuristic is the proximity heuristic, which assumes that things proximal in space or time are related. Like the analogy heuristic, this is a rule of thumb that is generally useful in understanding the world. If a person trips and falls, there’s a good chance it was caused by something at his or her feet. To control the water flow from a faucet, try the valves beside it. A toaster works better if you put the bread in the toaster, not in the Tupperware beside it. It has only been with the advent of electricity and radio that we regularly experience physically separate things being immediately related, an exception to the vast amount of human experience that requires proximity for a connection.
Also like the analogy heuristic, the proximity heuristic is a human tendency we deliberately exploit in our GUI designs to make them more “intuitive.” We make visual displays of documents arranged neatly in folders to suggest that files are associated with directories. You think tech support is hard now, imagine what it would be like if users couldn’t tell you the location of a file from that imagery. Drag a document from one folder to another, changing the proximity, changes the association. Links related to the content of a web page are located in or near the content. Controls in dialog boxes are organized by relatedness. Move a Screen Resolution slider control away from the “Less” label towards the “More” label gives you more resolution, not less.
Customer: “Ok, I’ve turned the computer off, then on again. It still says, ‘Safe to power off, or press any key to reboot’.” Tech Support: “No, not the monitor switch, the CPU switch.” (Rinkworks)
But like all heuristics, the proximity heuristic has its limits, and this is especially true for electrical and electronic hardware, and even more so for software where nearly any proximity displayed to the user is artificial. The proximity heuristic is what makes users mistake the monitor for the computer and fail to understand what the CPU is for. They don’t do much of anything with the CPU, except maybe to use the built-in drink holder. They might have noticed sounds coming from it or LEDs flashing when saving or retrieving a document, a perception whose temporal proximity suggests it is the hard drive. They might have noticed it lies between the “computer” and the phone line socket, so proximity suggests it is the modem. Otherwise, they can see it lies between the computer and the power outlet. Obviously, a surge protector. Yeah, I went high-end and got a 3 GHz surge protector. You can’t be too safe. Apple recognized this strong tendency starting with the original Macintosh, where their solution was to integrate the monitor with the CPU. It’s the users’ application of the proximity heuristic that contributes to the confusion about the function and criticality of the mouse pad. Of course the mouse pad is important for the mouse to work. Why else would the mouse always be on top of it?
This lead tech designates “Power-on Monday” — that’s the day he reminds users to leave their PCs running overnight so they can be remotely patched and automatically rebooted. “On this particular Power-on Monday, [one user] asks, ‘Should I leave the door unlocked so IT can get to the PC?’” (Shark Tank)
The stronger the relation, the more proximity is likely necessary. Users may be able to understand that they can pull files remotely via a network, but don’t expect them to generalize that an upgrade can be pushed to them from afar. Surely that much work would require someone at the computer feeding in CDs. The only issue is to be sure the computer is left on so the techie won’t have to type a password.
If related things are proximal, it should also be the case that making things proximal produces relations. Put ice cubes in your drink to make it cold. Drag documents to another folder to “move” them. So why are we surprised when a user tries to send a fax by holding the printed document up against the monitor? Or tries to select a document by picking up the mouse and tapping it against document icon? Or tries to burn a CD by dragging and dropping files?
[Tech Assistant]: (being extremely patient, and demonstrating one of our CD burning apps) “Well, it works kind of like this, and you need to use some software that burns CD’s.” [Big Boss]: “You need to use software to do that?” No wonder our companies [sic] value has dropped by 60% in the last twelve months with this genius making decisions for us. (Tech Tales)
Oh, sure, you can burn a CD by drag and dropping now, but the above happened in 2000. Which raises the question: is a luser just a user ahead of his or her time?
“I had recently told my brother to delete old files that he didn’t need anymore and zip any large files to save disk space. He was a little over zealous as I found out. My brother asked me to help him as he could not get a program to run…. I found he had deleted every file except for the icons! Apparently, he thought that if the icons WERE the program as it is what you double click to start it.” (Tech Tales)
In the physical world, you open a tool box to access the tools. In the virtual world you open a program icon to access its functions. By mere proximity (not to mention labeling), the icon is the program as far as the user is concerned: double click it, and the application starts up. The only way to dispose of the toolbox is to throw out the toolbox itself. So what would get rid of a program? All those other files? Why should they be related to the program? They’re nowhere near it. Not even on the desktop.
It doesn’t help, of course, that most files are consistent with the proximity heuristic: you delete the file icon to get rid of the file. Users are just supposed to figure out that if an icon has a little arrow thingy on it, then the icon is supposed to be some sort of remote control.
She clicked on an e-mail address [in a web page] and her mail client popped up! She immediately switched back to her browser and said, “See… Nothing happened!” (Tech Tales)
The proximity heuristic implies that a control’s effect will be in the window that contains it. Note that this implies that dialog boxes are inconsistent with the proximity heuristic, and indeed dialog boxes, especially a long series of them, tend to promote a sense of isolation from affecting objects in a UI. Direct manipulation of objects, in contrast is fully consistent with the proximity heuristic and makes for more intuitive UIs as long as the user can tell what and how to manipulate. In general, it’s more effective if user can modify objects right in the main window rather than go off to a separate page or dialog box to do so.
As for realizing that a link can pop up the email client, links usually repopulate the current browser window with new content, typically loading an entirely new page, which is consistent with the proximity heuristic and reinforces the users’ expectations that links only affect the browser. On the other hand, it’s certainly convenient for the user for a web page to provide a link that opens a blank message in the user’s email client, complete with the proper address entered. Sure beats the user copying and pasting an address. But the email client is spatially distant and visually unconnected to the browser, and so is assumed to be unrelated. Your users may be surprised that it is even technically possible to control an email client from a link in the browser. Not helping in this particular example above is the proliferation of pop-up ads, where navigating to some pages unavoidably presents an irrelevant advertisement window. Such practices trains users to reflexively dismiss anything that pops up almost without any consciousness, but we’ll save that for a later lessons from lusers.
The point here is that to users the browser window marks the boundaries of a universe of objects known as The Web, a place with its own laws and abilities. The desktop, with its email clients, office software, and hierarchically organized personal documents, seems like a different universe, visually and functionally far the Web which is safely confined to its browser window. Thus, the two must not interact. Such an assumption, derived from the proximity heuristic, as well as the analogy heuristic due to the language we use to describe the Web, perhaps contributes to the tendency of certain users to download malware. I suspect a large body of users is unaware that when they “navigate to” a web page, they’re actually downloading copy of it. Not realizing that, it’s hard to recognize that clicking on a link can do anything to one’s computer.
This expert user at a small branch of a very big company sets out one Monday morning to search the Internet [via Internet Explorer]…. To his amazement, he discovered a link to some of his own engineering documents. [Following some links,] he finds more than just a few of his documents. Virtually all of his documents are there. So are all the division’s sales and marketing files, displayed on the Internet Explorer screen. Realizing this information is confidential, he doesn’t hesitate. He diligently highlights and deletes every one of the files. And within seconds, there are sales and marketing people standing at pilot fish’s desk, demanding to know what’s happened to their files. (Shark Tank)
Microsoft has been working for years to get users to consider Internet Explorer and Windows Explorer to be one and the same, and, of course, equally indispensable for the operation of a computer. So they allow users to use IE to browse their hard drives or networks. What difference does it make if the documents are on your computer or on some server out there in cyberspace? This “files are files” attitude results in users deleting application and operating system files as we saw in Of Mice and Metaphors, and can also result in confusion about file ownership.
There’s an enormous functional difference to a user between a private file on one’s own computer which one has full control over, and a public file of unknown pedigree which one has no control over. We should foster a conceptual separation between the web and one’s own files, and exploiting the proximity heuristic is a great way to do it. Any crossover from the web universe to the private universe should be represented as a substantial spatial transversal, whether it’s downloading a shareware program or merely accessing the email client. For example, a link to send email should display the client in the browser as a plug-in with limited capability. Refining the graphic representations of the separation between public and private can go a long way to helping users differentiate between harmless web page behavior and something seeking much greater power over the computer. The user interface should make it visually clear what’s in the user’s house, what’s out on the street, and what is trying to come in the front door. Such a design will do more than a 1000 entirely non-proximal “This requires Admin rights” confirmation message boxes.
“My password is coming up in X’s…. When you receive it it’s not in X’s is it?” (Tech Tales)
The proximity heuristic applies to relations between objects (physical or virtual), and also between objects and their attributes. Seeing is believing, so representing an object in possession of certain attributes (i.e., attributes collocated on the object in the same space) suggests a deep relationship. Indicate the same attribute values in a properties dialog and the connection doesn’t seem quite as real. WYSIWYG depends on this corollary of the proximity heuristic, but perhaps this also explains why some users think they can save disk space by using a smaller font.
As for X’s or *’s appearing in the place of passwords, it’s not much of a leap to believe that is what’s being sent, not that I’m recommending you show the actual password as it’s being typed. Even when there’re no security considerations, I bet an experienced user would be unnerved seeing the password in full view –the proximity heuristic could imply that it’s being sent as plain text out over the network for all to see.
Help me recover a document, user tells [techie]…. “Turns out she created the document but was interrupted and hit ‘close,’ saying no to the ‘save’ dialog box. I did my best not to start laughing but simply explained that a document that was never saved cannot be recovered.” (Shark Tank)
The first thing we do for new users is hammer into their head the importance of saving, saving, saving, and for good reason. The need to save is inconsistent with not only the analogy heuristic (turning off a typewriter does not erase the paper you typed), but also the proximity heuristic. I mean document was right there as closely associated with the computer it can get, and yet it just goes away? What, the computer makes a special effort to throw out my work? Unrecoverable? That document had to have gone somewhere, and it couldn’t get very far (hmm… monitor still warm).
User has trouble attaching a document to an e-mail message –she keeps getting two or three copies…. User clicks once to attach, but the attachment doesn’t appear quickly, so she keeps clicking. Be patient, [the techie] tells her. The process is working, but you need to give it time. “No,” says user. “I put my ear right beside the computer after I try to attach, and it’s completely quiet. It is not working.” (Shark Tank)
Capitalizing on the proximity heuristic is key to making effective feedback. The feedback to a user’s action should be at the location and time of the action as well as indicative of effect of the action. Users notice such feedback and come to rely on it. Like many users, when an hourglass pointer or progress bar is not provided (as is apparently the case above), the user learned to listen for the rattle of disk heads to indicate “working on it.” Increasingly, this is becoming unreliable, with disk reading and writing happening whenever the operating system feels like it, and accessing network drives producing no rattle at all. In the future when solid-state disks become common, it may be necessary to artificially simulate the head rattle sound to supplement visual feedback like progress bars. It’s really not a bad idea.
[Support:] “We should convert it into a .JPG file or a .GIF.” [User:] “I know this (annoyed) I’ve already did it but the file is still too large.” [Support:] “Uhm (a suspect becoming reality…) but HOW did you convert the .BMP file into .JPG?” [User:] “I renamed it, why ? It’s not this way you convert files?” (Tech Tales)
Think about that from the standpoint of the proximity heuristic. The user sees the file name and icon in close proximity suggesting an intimate relation (which there is), the icon indicating type of image format. The user modifies the extension to the name of the file, a key attribute of the file given its close proximity to the file representation (indeed, it’s half of the file representation). The spatially and temporally proximal feedback is a change in the icon, showing the effect of the modification. I mean, surely the icon, being the other half of the file representation, must indicate the basic nature of the file. Surely it’s not some crude sticker slapped on the outside based on an arbitrary three letters at the end of the name. How lame is that?
Since most of the text in TV shows is in all capital letters, his caps-lock key was on. But when it came time to do the credits (which are capitalized in the normal fashion), instead of turning off the caps-lock, he held down the shift key to type the lower case letters. When I showed him the caps-lock feature, he was amazed and thought I was brilliant. (Rinkworks)
O, the caps lock key. One little button. So many mangled passwords. Some may wonder if, like the Ins key, it’s even worth having. The problem isn’t really the presence of the key itself, but its feedback which completely ignores the proximity heuristic. When the caps lock is on, some enduring change needs to be proximal so users recognize the relation between the key and subsequent keyboard behavior. On old mechanical typewriters, depressing the caps lock resulted in it staying depressed, indicating it was setting a mode, not just sending a transitory input like most other keys. Secondly the entire rack of typebars would visually and audibly shift, indicating that the state was related to the type. Two changes, one proximal with the key, one proximal with the type, each temporally proximal to each other: the relations are clear to the users. But what feedback do users get on the modern keyboard? Just a little LED a good twelve inches away.
Modes, where the same user behavior in the same place under different conditions results in different system reactions, are frequently problematic in user interfaces. Users forget, fail to notice, or fail to understand the mode, and thus the system responds with an unintended behavior. The failure to notice a mode indication is frequently due to invalid application of the proximity heuristic, and the caps lock is classic example of such a mode error. In the case of the caps lock key, we can improve matters by:
- Have the key lock down when pressed, providing tactile and visual feedback that a mode has been set. Right now, there’s nothing to distinguish this key from several others which do not set modes.
- Change the cursor in some manner to indicate capitals, perhaps making it larger or adding serifs. This will indicate that the state of typing has changed.
- Mark all the keys affected by the caps lock. You can go fancy and actually change the letters on the keys to upper case using something like an Optimus keyboard. Alternatively, a cheaper approach would be an LED light ring around all affected keys.
“Try hitting shift and 3, then you’ll get the pound sign.” So she hits shift THEN 3 (separately of course) “SEE! I TOLD YOU IT WAS BROKEN!!!”(Tech Tales)
“Quasimodes,” where continual user input maintains a mode, have been suggested to deal with the problems ordinary modes cause, but even they can be problematic when proximity is ignored. The user above would not have been confused if pressing and releasing the shift key were temporally proximal to some equally transient change that is spatially proximal to the keys it effects. That would make it clear that one has to continuously hold it down for it to work. One thinks again of the superior feedback from mechanical typewriters.
It’s also worth pointing out that the Shift key is inconsistent with the analogy heuristic. It appears like the Enter, Tab and other keys. By analogy, why shouldn’t users assume they all act the same? But it doesn’t. Enter and Tab each have a specialized effect when pressed in isolation, but Shift (and Ctrl and Alt) only affect the behavior of other keys. Keys that act differently should appear different. The Caps Lock key is also inconsistent with the analogy heuristic for the same reason.
I also suspect a terminology problem with Shift and Caps Lock. What do their names mean to users today? “Caps lock” sounds geeky, kinda like SysRq. Maybe it locks the cap on the keyboard buffer or something. Or keeps your hat from flying off when it’s windy. “Capital letters” is probably not the first thing that comes to mind when one sees the word “Caps.” “Shift” made sense when there was an actual bank of typebars to physically shift, but how many users today have even used a typewriter? But terminology is a topic for a later edition of Learning from Lusers.
Problem: In using the proximity heuristic, users may misunderstand the relations between things and actions.
Potential Solution: Review your UI design minimizing the spatial and temporal distance among related things and actions, and maximizing the spatial and temporal distance between unrelated things and actions. This can include:
- Keep all the objects of your application within visually cohesive boundaries. Objects with functionally significant differences (e.g., shared versus private data) should appear as separate “universes.”
- Action initiated in a window should have results in that same window. Favor direct manipulation over dialog boxes for actions.
- Have single consolidated representation of each object which receives all inputs. Avoid “remote controlled” objects.
- Consider actions the user may try to create relations by increasing the proximity of the objects you represent (e.g., by drag and drop). Exploit this tendency by making this action effect a command.
- Represent critical attributes of an object as part of the object representation (e.g., do not make such information accessible only in separate “properties” box).
- Feedback should be spatially and temporally close to the point where the action is committed and the objects which the action affects.