The Principle of Least Astonishment, in shorthand, encompasses what we, as designers, must achieve to ensure consistency in our designs. Consistency is a fundamental design principle for usable user interfaces. But the thing that astonishes me is that it’s actually necessary to explain this principle. Surprise implies the unexpected. Of course, users want the response to a given action to be what they expect; otherwise, they would have done something else. In user interactions, the unexpected is pretty much the same as the unwanted. Surprise usually implies something bad rather than something positive—unless users already have such dismally low expectations of their software that they might think, Wow! It worked. I’m so astonished.

What does our need to give this simple principle a name mean? Are there software designers who don’t believe software should do what users expect? Could it be that there’s a school of design that believes software’s responses need not be consistent with the way the software indicates it will respond? That would explain a lot about what I see on the Web, now that I think of it.

The Problem of Consistency

The Principle of Least Astonishment is a good example of a design principle that, while absolutely true, is useless in actually helping us make design decisions. By all means, let’s design our user interfaces so they do what users expect. That’s helpful. While we’re at it, let’s also make sure the applications we design are easy to use. The problem is: this principle doesn’t tell us how to determine which design alternative will surprise users less.

My concern is that designers and developers might get a false sense of confidence in their designs if they’re based on such an algorithmic-sounding Principle of Least Astonishment. “I studied every button and menu,” they might say, “and made sure they did nothing surprising.” Or, “We should design our application this way, because of the Principle of Least Astonishment.” End of argument. But all they’ve really said is, “This design fits with what I think the user expects.” It could be only a guess about users’ expectations.

Another concern is that this principle seems to suggest that we remain consistent with current design conventions, without doing any real analysis of their trade-offs. For example, in our quest for consistency we might put an Options command on a Tools menu—even though there are no other menu items on that menu. Why? Because this imitates Microsoft applications, so fits most users’ expectations.

What if something is consistent in one sense, but not another? Suppose you have an application that displays ship dimensions and nautical charts. Traditionally, ship dimensions are in feet, but water depth is in fathoms. Doing the same in your application would be consistent with nautical tradition, but would make ship dimensions and water depth inconsistent with each other. So, what should you do?

On the Web, documents such as PDFs open with a single click, but on the desktop, they open with a double-click. Is that inconsistent? Should desktop documents open with a single click? Microsoft thought so and, in Windows 97, made that the default behavior for Windows Explorer. However, they later abandoned that approach, because it ended up increasing user confusion. Could they have predicted this?

Should we never surprise users? Doesn’t the answer to this question depend on the valence, quantity, and quality of the surprise? What are the costs of not surprising users? There are interface design principles other than consistency, and sometimes these principles conflict with one another. The bottom line is: We want the best overall user experience for our users, and sometimes that means trading consistency for something else.

For example, suppose you have an input form in which some text boxes have a fixed number of characters for all possible values—for instance, for US users, social security number, credit card number, telephone number, postal code, or state abbreviation. You could make data entry faster by automatically advancing the focus to the next text box when a user hits the character limit of the current text box. However, such behavior would be inconsistent with the behavior of nearly all other text boxes—maybe even other text boxes in the same form. Is having this inconsistency worthwhile just for the sake of faster data entry?

If consistency became an uncompromising end in itself, the evolution of design would stagnate and innovation cease. Where would we be if, in the early 1980s, the Mac development team had said, “No, we can’t do this. It’s not consistent with CP/M”? Let me make one thing clear: Deliberately making a user interface inconsistent is not something you should do lightly. You should not create inconsistency on a hunch. From a usability standpoint, you need solid empirical evidence of substantial human performance benefit to justify creating inconsistency, as was the case for GUIs (Graphic User Interfaces) in comparison to the convention of command-line user interfaces.

User research and usability testing are the obvious ways of handling these concerns. Up-front, generative user research can tell us what users expect in a user interface and how surprised they’d be if it did something inconsistent with their previous experience. Usability testing lets us directly observe where and how our user interfaces surprise users or otherwise thwart their goals. While user research and usability testing are almost always beneficial, practicality prevents our doing research to answer all design questions. To minimize the time and expense of product development, UX designers usually need to take their best shot at designing a good user interface prior to testing with users.

To help us make better design decisions around the issue of inconsistency, it would be helpful to be able to analytically predict at least the rough impact of an inconsistency in the absence of exhaustive user research and usability testing. Analysis of the severity of an inconsistency involves evaluating the

• type of inconsistency
• strength of the inconsistency
• potential impacts of the inconsistency and their relevance
• situational relevance of the inconsistency
• potential for design amelioration of the inconsistency
• proximity of the inconsistency

Let’s explore each of these in depth.

The Type of Inconsistency

We achieve consistency when an interaction with a user interface (UI) element matches users’ expectations—thus, no surprises. User expectations, in turn, become established through users’ experiences within their environments. Over time, users learn that certain stimuli have certain meanings or usages, because those stimuli have had those meanings or usages in the past. Take, for example, a command button. Through exposure to GUIs—not to mention their physical analogues—users have learned to interpret the dimensional appearance of a rectangle that has a label as a button and clicking a button with the immediate execution of the command the button’s label represents. Remove the user from the equation, and we can see that consistency occurs when the stimuli / usage pairs for UI elements are the same as those for other UI elements that already exist. In human-computer user interfaces, stimuli include the following:

• symbols—imagery—such as icons—that conveys information
• codes—colors, sizes, weights, marks, and other graphic dimensions that may represent data values or invoke a metaphor
• units of measurement—either for a particular numeric attribute or groups of related attributes
• data formats—for data in the form of text
• terms—identifying the objects, classes, actions, and events in user interactions
• abbreviations—for terms, including the names of the function and control keys that are assigned to commands
• layouts—UI elements’ relative locations on a page or in a menu, window, or temporal sequence

Inconsistency occurs when the meanings of these stimuli vary—when stimuli / usage pairs are not the same. This implies there are two kinds of inconsistency:

• irregularity—When different sets of stimuli have the same usage, including behavior, the result is irregularity. For example, it’s an irregularity if some dialog boxes use the label Reset for a button that causes all of its settings to revert to their previous settings, while other dialog boxes use the label Undo. When each usage has a single symbol, code, unit, format, term, abbreviation, or layout, you have regularity.
• contradiction—When the same sets of stimuli have different usages, the result is contradiction. It’s a contradiction if, in some dialog boxes, Undo causes only the last setting a user changed to revert to its previous setting, while in other dialog boxes, Undo causes all settings to revert to their previous settings. When each symbol, code, unit, format, term, abbreviation, and layout has a single usage, you have concordance.

Table 1 provides examples of irregularity and contradiction for each type of stimulus.

Table 1—Examples of irregularity and contradiction for stimuli

Note—I have indicated that contradiction is N/A (Not Applicable) to units of measurement. I suppose a contradiction might be possible for a unit of measurement—for example, where the same unit has more than one usage. However, it’s not a usability concern.

With remarkably little effort, a UX designer can unwittingly achieve both irregularity and contradiction for the same set of stimuli. For example, I’ve seen one application in which, on some pages, an asterisk indicates required fields, while on other pages, it indicates optional fields. The contradiction: the same symbol, an asterisk, sometimes means required and sometimes means optional. The irregularity: sometimes an asterisk means required and sometimes the lack of an asterisk means required. Layout inconsistencies are often both irregular and contradictory, because in moving things around, we usually end up both using the same position for different usages and having multiple positions for a single usage.

The Strength of Inconsistency

Both irregularities and contradictions can vary in strength, depending on the degree of similarity between the two sets of stimuli or two usages in question. In Figure 1, darkness represents the strength of inconsistency.

Figure 1—The strength of an inconsistency

For example, in the application with contradictory meanings for asterisks, asterisks meaning optional were black, while those meaning required were red. This is a relatively weak contradiction, because the symbol isn’t quite the same for both usages—they have different colors. Similarly, the use of asterisks to indicate both the fields a user must complete and the fields a user must cross-check—making sure their default is correct—would also be a mild contradiction. The two usages are somewhat similar, so there is little practical difference if a user confuses them—either way, users attend to the fields as they should.

An example of weak irregularity would be choosing to style your own check box controls rather than using an operating system’s standard controls. This is only a mild irregularity, as long as an empty square means no and a checkmark in a square means yes. If the control is simply somewhat larger or heavier than a standard check box, that’s not nearly as irregular as doing something like making an X shape mean yes.

For a mercilessly strong contradiction, I need look no further than a certain frightful time-sheet application I have seen. On a particular input form in this application, there is a prominent button labeled Save, which you might think would save the changes a user makes to the form. Figure 2 shows a detail of this form.

Figure 2—Form detail

Having the Save button save changes would be consistent with just about every other computer application since Babbage’s Difference Engine, not to mention being consistent with the English language. But no, this Save button merely validates a user’s inputs. If the user leaves the page after clicking Save, the application loses all of the user’s changes—and, no, the application does not give any warning. Gotcha!

The first step in estimating the impact of an inconsistency is to assess the strength of the inconsistency—whether it be an irregularity or contradiction. For example, in certain circumstances, you might be able to justify using an extra-large check box, even though it’s inconsistent with a standard check box. A user could select the larger control more quickly, as Fitts’s Law states, which might provide an important benefit if users need to make time-critical inputs. That benefit might be worth introducing a weak irregularity. On the other hand, there is no way you could justify a Save button that does not save.

Impacts of Inconsistency

What is so bad about inconsistency? The world would be a boring place if everything always happened as expected. Novel stimuli / usage pairs could be amusing, even enlightening. Astonishment and surprise are not necessarily unpleasant experiences—otherwise, we wouldn’t have surprise parties. But in a product user interface, surprise is a sign of a potential problem.

The actual problem is the degree to which an inconsistency interferes with users achieving their goals when using a product. To assess the severity of an inconsistency, you also need to consider what form that interference takes. Interference can take several different forms—some worse than others and some related to irregularities, others to contradictions, and still others to both, as below shows. Generally, contradictions tend to be more severe than irregularities, having both more impacts and more serious impacts. While an occasional irregularity might be tolerable if it also provides some overriding benefit, strong contradictions are almost never acceptable.

Now, let’s take a look at each of these impacts in turn.

Learning Burden

Both contradictions and irregularities result in users being unable to transfer their knowledge from past experiences, forcing them to learn new stimuli / usage pairs that are specific to a particular UI element. For example, I know from experience what an OK button means and what a Cancel button means. However, a cost-accounting Web application I’ve seen features a dialog box with a Return button. Figure 3 shows this dialog box.

Figure 3—Cost-accounting application dialog box with a Return button

Having had no prior experience with a Return button, I had no clue about whether it would apply or discard my changes. In trying to guess what the developers had been thinking, I considered the fact that no other dialog box in the application included a link or button with a Cancel function, so it seemed unlikely the developers were even aware of the concept. I reasoned that they might have been thinking of a function return, as in computer languages, so inferred that clicking Return might apply my input, in the same way a function applies its parameters and returns a value. But there was only one way to really know. Click. Nope, it discarded my input. But, hey, I’m a better person for it, aren’t I? I learned what Return means in this one application.

Learning takes time—delaying the completion of users’ tasks—and requires cognitive effort that users could better apply to completing their tasks. Not only do users have to learn an inconsistent UI element, they must learn when to apply that learning—that is, for which elements one rule applies and for which elements another rule applies.

For example, consider the well-known office productivity suite, Microsoft Office. In most of Office, as in many other applications, Ctrl-F is the shortcut for Find. This is the case for Office’s email client, Outlook. Well, actually, it’s true only if a user is writing a letter. If a user is reading a letter, the F3 key performs a find. I suppose this makes perfect sense, because F3, like Find, begins with the letter F. Assuming it were easy for users to learn that F3 finds, this irregularity would still be a significant burden, because users must also learn to use F3 when reading and Ctrl-F when writing.

Misunderstandings and Misuse

Contradictions can lead directly to errors when a user assumes one usage or meaning for a set of stimuli, but an application’s designers actually intended another. For example, while Ctrl-F finds text when writing a letter in Outlook, Ctrl-F forwards a letter when reading the letter. Having the same abbreviation with different meanings in the same application—in this case, Ctrl-F, which means two different things, find and forward—would tend to cause users to misinterpret the abbreviation, substituting one usage for the other. Because of this abbreviation contradiction, I commonly find myself forwarding a letter when I meant to find something in it.

Irregularities can lead to a lack of understanding, but are less likely to lead to misunderstandings, because they imply that there is at least one stimulus for which users have no prior associated usage. Users may be puzzled by this new stimulus, because they cannot understand what it is trying to say, but they will realize they don’t understand what it says and, therefore, tend to proceed with caution. For example, when I made that guess about what Return meant in the cost-accounting application, I was prepared for the high probability that my guess might be incorrect. In contrast, misunderstandings—such as those from contradictions—suggest users think they know a user interface when they don’t. Pervasive contradictions in an application make users falsely predict how it will behave, causing them to lose control of the application.

Memory Interference and Mental Effort

Even once a user learns to use an inconsistent UI element, contradictions can prevent helpful habits from forming. As long as a user encounters conflicting, alternative usages for a given set of stimuli, no one association dominates. Slips occur, and a user must think to avoid errors. For example, my phone has the standard telephone keypad with the numbers 1, 2, and 3 in the top row. On the other hand, my computer keyboard, right next to the phone, has a standard adding-machine keypad, with 7, 8, and 9 in the top row. Sometimes, when using either of these keypads, I mistype, especially if I’m keying quickly or not thinking about what I’m doing. It seems my most common error is to key a 4 when I meant to key a 7 or a 1. It’s as if my fingers can’t tell which keypad I’m using, so the safest bet is to average the two and go for the middle.

Older versions of Microsoft Office provide another example of memory interference. Clicking the Close Window button on Excel’s title bar exits the application and closes all documents. However, the same button in Word closes only the current document. I have lived with this contradiction for eight years now, using Office almost daily, but I have yet to learn the difference. I’m still closing all of my Excel documents when I meant to close only the current document.

Difference Camouflage

Regularity is helpful in pointing out differences, ironically. A difference between two things is much more apparent when everything else is the same. The best example of this is comparing two different numbers in a column of numbers. If the numbers have the same formatting and alignment, it’s relatively easy to spot any differences. In contrast, irregularity makes it more difficult to see differences. For example, many applications fail to use consistent formatting, aligning columns of numbers on their decimal points. This failure makes it hard for users to scan down a column of numbers and spot differences in their order of magnitude. For example, compare the two columns shown in Figure 4.

Figure 4—Irregular and regular columns of numbers

If irregularities exist within the same page or window, users are exposed to variability in stimuli without any compensating benefit. For example, high variability in a page’s or window’s graphics produces an experience of clutter and interferes with visual search, so users have more difficulty finding and seeing particular objects.

Cue Blindness

Generally, we give elements a different appearance for a reason. We can use differences in size, shape, color, and texture to encode differences in meaning like levels of importance, categories of content, responses to input, or relations between objects. For example, Web forms often use a red asterisk to indicate a required field. If users come to expect user interfaces to employ particular conventions, any irregularity might confuse them—thus, making them stop and think. For example, users might wonder why some fields in a Web form are on a green background, while others are on a white background. Does this mean the fields are optional? Or that the current values are acceptable? Or does being green just mean it’s green?

Such confusions are usually short lived. But more insidiously, irregularities and contradictions teach users that differences in stimuli do not necessarily represent a code and are sometimes arbitrary. Thus, they can blind users to differences that really do encode something significant. For example, if a user sees a field with a red border when other fields’ borders are in black, does this mean anything? Maybe not. Maybe it just means it’s red. Unfortunately, code blindness reduces a product’s predictability. When predictability declines, users come to believe a product’s behavior is arbitrary, so beyond their control.

Situational Relevance

Given their impacts, it’s generally correct to regard contradictions as more serious than irregularities. However, for a more precise estimation of the severity of inconsistencies, you should evaluate the relevance of each impact of inconsistency to your particular design and context. The relevance of these impacts depends on the users, tasks, and environments for your product. It always does. For example, having inconsistent formats, units of measurement, or sizes for a couple of fields is less of a concern if users won’t compare the fields to each other. However, if a user must compare a ship’s draft to the water’s depth, both should be in the same unit of measurement. An application that includes both nautical charts and ship dimensions has a couple of choices:

• Express both water depth and ship dimensions—including draft—in feet, and live with the chart’s inconsistency with nautical tradition.
• Express all ship dimensions in feet—except draft, which is in fathoms. Draft would be inconsistent with the other dimensions, but consistent with the chart, and the chart is consistent with tradition.

The impact of memory interference is not a problem if users will experience only new stimuli / usage pairs going forward. For example, when the Microsoft Office designers rearranged the layout of their commands—moving from the pre-2007 menus and toolbars to the ribbon—users experienced a definite learning burden. However, memory interference was a small issue for most users, because once they had upgraded to the ribbon version, they were no longer using the menu-and-toolbar version. For this reason, consistency with legacy products is generally not as important as consistency with products in concurrent use, for which interference is very relevant.

The significance of a learning burden depends on a product’s frequency of use, as well as its overall complexity. The more frequently users use a product, the better they can tolerate inconsistent elements in the product. Changing our expectations and learning is overhead, so the more users would have the opportunity to enjoy the benefits of learning something new, the more likely it is worth the effort.

For example, multitouch gestures are inconsistent with the simpler touch user interfaces that existed before. It probably wouldn’t be worth it for users to have to learn new multitouch gestures to use, say, an airport check-in kiosk, even if multitouch gestures would result in faster check-in times for the users who learn them. Most people fly so infrequently, it’s likely the time they would spend learning a new multitouch user interface during their first use of a kiosk would be greater than the time they would save during subsequent sessions, especially considering many users would forget what they’ve learned. On the other hand, learning standardized multitouch gestures that work in multiple applications for a hand-held computer would probably be worth the effort, because users are likely to see a return on their learning investment.

Users can better tolerate greater inconsistency in less complex products that have fewer potential interactions. Because products that present fewer possibilities for interaction are easier to learn overall, their users have more learning capital to dedicate to handling any inconsistencies. Simple, static Web sites can move away from the now-forgotten standard of using a blue font for links. Because these sites are so simple, distinguishing links from nonlinks is about all users have to learn. As long as links are colored and underlined—a weak irregularity from the standard #0000FF-colored links—users usually do okay. However, as users move into more complex, rich Internet applications, their tolerance of inconsistency diminishes. Therefore, we must achieve better consistency if we are going to maintain usability.

Design Amelioration

Design details can ameliorate the impact of an inconsistency—particularly details that make new stimuli / usage pairs easier to notice, learn, and remember. Take, for example, moving the Options command from the Tools menu to the File menu, which happened in Microsoft Office, Version 2007. The alleged reason for this move was that options apply to the entire application, and users associate universally applicable commands with the File menu, mostly because it contains the Exit command. (What used to be the File menu no longer has the label File, but that’s a different inconsistency.) On the other hand, users associated the Tools menu with, well, nothing in particular. So, theoretically, users would find the Options command faster if it’s on the File menu than if it were on the Tools menu—at least users who haven’t already memorized that Options is on the Tools menu in most applications.

But what about users who have memorized that Options is on the Tools menu? How harmful is this inconsistency to them? It depends on the exact design. If there still is a Tools menu, it kind of sucks for users, because they’ll habitually click the Tools menu, looking for Options, wasting their time and increasing their frustration. However, in Office 2007, Microsoft eliminated the Tools menu. Users did not see a misleading Tools menu that would draw them in the wrong direction. The lack of a Tools menu became a significant cue that a user’s cognitive context had changed and the old stimuli / usage pair no longer applied. Users still had to search for the new location of Options, so the cost of this inconsistency was nontrivial, but if Microsoft were right, the first place users would look for Options is on the File menu, assuming they realize that logo-thingy is a menu. But, again, that’s a separate inconsistency.

An even better design amelioration would have been to put options on their own Options menu. In this case, all users—regardless of whether they were expecting there to be a Tools menu—would immediately see the menu labeled Options. Jolly good. Just the thing they’re looking for. This design would virtually eliminate any learning burden. Put the Options menu in the same place where the Tools menu used to be and even users’ muscle memory would largely be preserved. A separate Options menu might be inconsistent with nearly every other application out there, but it’s also a self-documenting inconsistency with a near-zero severity. (As an aside, this design also offers an opportunity to break up that multirow, tabbed Options dialog box from hell into separate, simpler dialog boxes.)

For another example, take the idea of automatically advancing focus to the next text box once a user hits the current box’s character limit. This is what that frightful time-sheet application I described earlier does. Its four-character time fields—labeled Start and Stop in Figure 5—automatically advance the insertion point, and it’s bloody awful. It’s a code contradiction. Fields with and without auto-advance—like the Code field—look identical. Users can’t tell when auto-advance will or won’t occur, and the result is input errors. Sometimes, I press the Tab key after entering a starting time and find myself entering the stopping time in the Code field instead of the Stop field.

Figure 5—Auto-advancing fields

Altering the appearance of fields with auto-advance would reduce the strength of the contradiction. I suggest making adjacent auto-advance fields look more like a single field, as shown in Figure 6. This would leverage users’ expectation that the insertion point would advance for each value within a field and, thus, weaken the inconsistency.

Figure 6—Design amelioration for auto-advance fields

The design in Figure 6 is better, although other usability issues with auto-advance probably outweigh the alleged advantage in increasing user input speed. The lesson here is that giving proper attention to labeling, layout, graphics, documentation, training, and promotion can go a long way toward making inconsistency a minor issue.

Proximity of an Inconsistency

We can think of both contradiction and irregularity as involving two sets of stimuli in two different locations. For contradictions, it’s the same set of stimuli with different usages in two locations, while with irregularity its two different sets of stimuli with the same usage in different locations. In addition to the strength, type, impact, and relevance of an inconsistency—and any design amelioration—the severity of an inconsistency depends on the psychological proximity of the two sets of stimuli in question. The closer the two sets of stimuli are, the more severe the inconsistency.

Psychological proximity can include the physical proximity of the sets of stimuli—that is, how close they are in time or space. For example, my keypad-entry errors are probably not helped by the fact that my phone is beside my computer keypad. I’d wager my phone-dialing errors are most likely to occur right after I’ve used the computer keypad and vice versa.

Psychological proximity also includes purely mental barriers. In the stimuli / usage associations that define consistency, the stimuli include the cognitive context in which the sets of stimuli exist. Differences in cognitive context result from the perceptual differences between two locations, which depend on both the physical appearance of the locations and what users know about the locations. If there is something to cue users that their context has changed, they relatively easily learn that stimuli / usage associations from one location don’t apply to another.

The phone and computer keypad may be next to each other physically, but they have very different cognitive contexts. They look different, and I know that they are different—that the phone is a completely different device from the computer keypad. The interference from the two keypads would likely be much worse—perhaps intolerably worse—if they looked the same and were part of the same device.

Take, for example, the time-sheet application’s fiendish nonsaving Save button. Just to add extra frustration, some pages in this application do have a Save button that does, in fact, save. Because two Save buttons in the same application close psychological proximity, this inconsistency is more severe. This Dirty Harry of user interfaces makes you wonder, Am I on a page where Save saves or not? You don’t really know. But since clicking Save could blow all of your input clean away, you’ve got to ask yourself one question: Do I feel lucky?

You can make a distinction between internal and external consistency, as follows:

• Internal consistency is the degree to which a product is consistent with itself—that is, the degree to which its sets of stimuli have the same usages. In software applications, this includes consistency within and across windows and pages; Help and documentation.
• External consistency is the degree to which a product is consistent with some reference other than a part of itself. This includes the following:
  • metaphors a product’s user interface employs—such as the desktop metaphor GUI operating systems use
  • other similar products a user uses concurrently with a product
  • legacy products a user had used before switching over to your new product
  • operating system user interface standards
  • general user or organizational knowledge

Usually, internal consistency is more important than external consistency. You can generally count on your product’s being regarded as its own cognitive context within the larger context of common metaphors, as well as other products and operating systems. Thus, the psychological proximity of any internal inconsistency is closer than that of any external inconsistency, and it is, therefore, more severe. So, if one part of your product must be externally inconsistent, the same inconsistency had better exist throughout your entire product to maximize internal consistency. Don’t think you’re better off having external inconsistency in only one place within your product if it means having internal inconsistency everywhere else.

For both internal and external inconsistency, there are various degrees of proximity. For example, an internal inconsistency within the same window is generally worse than an internal inconsistency between two windows. The worst inconsistencies occur when the same thing, in the same place, behaves differently at different times, without any change in appearance. In effect, such a contradiction constitutes a hidden mode that is almost certain to produce misunderstandings.

For external consistency, specific contexts tend to imply closer psychological proximity than broader contexts. For example, broadly in Western culture, red implies danger, while green implies safety. However, traditionally, for steam-plant valves, red implies closed, while green implies open. In some situations, an open valve can be very dangerous, so if you’re designing a steam plant application for experienced users, you should use red to encode closed rather than danger, because the steam-plant context is a more specific context than our general culture. Consistency with steam-plant traditions has greater proximity than consistency with Western traditions.

Among the various types of external consistency you should consider, it’s especially important to maintain consistency with UI standards. First, most standards are not arbitrary. They have been shown to be superior to their alternatives through user research or operational experience. It’s doubly important that you have hard data on the advantages of deviating from a standard before you consider producing a product design that deviates from standards. Second, even when standards are arbitrary, you should conform to them precisely because standards work only if there is broad conformance to them. I suppose, for every situation, there might be a nonstandard design that would have a slight human-performance advantage over the UI standard. However, if every designer created such situation-specific designs, we’d no longer have a standard. The performance deficit that results from widespread inconsistency would overwhelm whatever slight performance advantages we might gain in each situation.

Managing Consistency

By now, you have probably figured out the way to ensure internal consistency in your products: each set of stimuli should have exactly one usage, and each meaning should have exactly one set of stimuli. When developing your design deliverables, create a dictionary that defines each set of stimuli—that is, a single set of symbols, codes, units of measurement, data formats, terms, abbreviations, and layouts that you’ll apply throughout an application, giving each of them one meaning or usage. If there is a one-to-one correspondence between such sets of stimuli and usages, your products won’t have any internal irregularities or contradictions.

In general, our products should never have any internal inconsistencies. Unless we can ameliorate the impacts of internal inconsistencies through clever design, they are generally too severe to justify whatever performance benefit users might gain from them. As UX designers, we should find a way to obtain the benefit without creating designs that are internally inconsistent, even if it means decreasing external consistency.

And, indeed, balancing external consistency is generally a bigger challenge. You can maximize external consistency if you go through your dictionary and choose sets of stimuli that are consistent with external references like common metaphors, related products, UI standards, and general user knowledge that are applicable to your product. However, when these either conflict with each other or are inconsistent with a design that provides a validated performance advantage, consider the strengths of the inconsistencies, the relevance of their impacts, and their cognitive proximity, then make your design decision. To ameliorate such inconsistencies, adjust your design to provide more self-documentation that shows how your product deviates from external references.

When generating your dictionary of sets of stimuli, keep this in mind: you’ll get the best user performance if its definitions are simple and you tie a single, clear perceptual cue with each meaning. An example of a simple definition: A sunken box is a data field. This definition specifies that all fields—whether in a form or a table, whether read only or editable, whether they be single-line or multiline text boxes, list boxes, combo boxes, drop-down lists, or spinners—shall have 3D borders and nothing else shall have 3D borders. That is an easy-to-perceive set of stimuli—a code, in this case—that has a specific meaning to users. A complicated definition would have Boolean logic. Here’s an example of a complicated definition: A data field shall appear as a sunken box in a form and a flat box in a table, unless it’s a drop-down list, which appears raised in a form.

Simple definitions maximize consistency, making your sets of stimuli / usage pairs easier for users to recognize and learn. Complicated definitions imply reduced consistency, suggesting different sets of stimuli / usage pairs in different contexts that users might not notice.

It is not necessary for a product to be perfectly consistent. Indeed, considering all of the possible references users bring to a product, perfect external consistency is probably impossible. However, we owe it to our users to both eliminate any unwarranted inconsistency and ensure any deliberate inconsistency offers some net benefit to users. That’s the least users should expect from us.

Summary Checklist

Problem:  Analytically estimating the impact of inconsistency in order to make design trade-offs.

Potential Solution: Draft a dictionary of stimuli, eliminating any internal inconsistencies while maintain good adherence to other design principles.

• Maximize external consistency by basing the dictionary on common metaphors, related products, UI standards, and general user knowledge that are applicable to your product.
• Cover all symbols, codes, units, formats, terms, abbreviations, and layouts.
• Keep definitions simple with one-to-one matching of stimuli to usage

When faced with any remaining external inconsistencies, especially mutually exclusive ones, rank their relative severity by determining for each:

• Its the strength and proximity.
• If it’s a contradiction or irregularity, recognizing the contradictions are worse.
• The relevance of its impacts on:

• Learning burden
• Misunderstandings and misuse
• Memory interference and mental effort
• Difference camouflage
• Cue blindness

• The degree design can ameliorate these impacts.

Edit your dictionary to address the more severe inconsistencies.

Digital Deja-vu

This article was originally published on UXmatters on July 19, 2010. That’s why this one seems much more polished and professional than the usual stuff I slap up here. Thanks to UXMatters’ Editor in Chief Pabini Gabriel-Petit for her extensive editing help.

The web makes everything easy. Your basic web site is not much other than pages and links, where a page is a block of content large enough to fill an entire window, and links connect these pages to make sites. With these simple elements, we build remarkably complex web sites that can be navigated by any user with a modicum of computer experience. This is effected by “history navigation,” in which users build a history of presentations of the pages with links and move within the history using the browser Forward and Back buttons.

As we develop increasingly sophisticated applications on the web, it’s tempting to use this history navigation model. While simple, elegant, and effective, history navigation is nonetheless not a trivial cognitive task for the user. The very fact that we call it web “navigation” is a pretty big clue that it’s actually pretty demanding, apparently conjuring comparisons to skilled use of sextants, chronometers, astral tables, and charts. Just as nautical navigators need to mentally visualize a line of position on which somewhere resides their ship, web users need to mentally visualize a line of history on which somewhere resides the current page.

The alternative navigation model comes from thick-client desktop apps. Here, we refer to “documents” rather than “pages,” but they are functionally the same thing, both being a block of  content that fills a window. Like pages in a web site, a desktop document may or may not attempt to represent a printed document. A document could just as easily be a query result, a project, an entire database, or process control model, among other possibilities. Rather than accessing separate documents via a conceptual history list, each document is displayed alone in its own window, which users access by simply seeing and clicking the window. This action is the desktop analog of clicking the Back and Forward buttons for the web, navigating the user from one window-full of content to the other. With increasingly large screens for desktops, directly clicking on windows is sufficient for most navigation. However, there’s also a task bar or dock to provide a redundant means of access when windows are fully occluded (e.g., when the current one is maximized). That’s analogous to the dropdown menu on the browser Back button, giving the user relatively easy access to documents/pages that have been buried by others.

Such “window navigation” is cognitively less demanding than history navigation. One would scarcely consider it “navigation,” a term little used outside usability professionals before the browser came along. Indeed, even now, Microsoft calls any app using history navigation a “navigation-based user interface,” implying that a screen full of classic single-document interface windows involves no significant navigation.

Tasks and Navigation Models

While window navigation in principle is less cognitively demanding than history navigation, that doesn’t mean that window navigation is best for everything. There’s a reason why the web used history navigation by default. Each type of navigation is well suited for its associated tasks.

Desktop Application Tasks

In a desktop app, tasks tend to focus intensively on a few documents. The user may work for hours on a single document. This is largely a consequence of desktop tasks being dominated by content creation, rather than consumption. When the users have to build or edit the content themselves, it necessarily requires more intensive focus on each piece. Navigating is typically a small part of the task in a desktop app. Most interaction takes place after the users navigate when they start manipulating content. The user opens a PowerPoint document and scrolls to a slide in 10 seconds, and then may spend the next 10 minutes, writing, editing, drawing, copying, pasting, and annotating that one slide. Documents in desktop apps typically have more content than their page counterparts in the web world. More importantly, the amount of content the user is interested in is typically greater in documents than pages.

When the user is working on a few documents, it makes sense to put each in its own window alone so that the user has ready access to each over many minutes or hours of work. History is not irrelevant, as indicated by the benefits of Recent Document menu items on the File and Start menu, but a few open windows is sufficient for most navigation between documents. Removing documents from such ready access requires an explicit action by the user in the form of closing the document’s window. This means that when the user on occasion opens a document for a quick interaction (e.g., to reference a bit of information), the user will need to take an extra step to keep the screen from being too cluttered. However, given that users open most documents for more intensive work, it’s better to require the user to explicitly dismiss documents than to have them automatically lose their ready access.

Web Site Tasks

Web tasks in contrast tend to involve superficial focus on large numbers of pages. Often users spend only a few seconds on a dense web page or even an entire web site, extracting one or two key pieces of information and disregarding the rest. The user flits from web site to web site. One site may link to another, or the users may use Google to systematically access multiple sites from the same search result, or they may use a portal or news aggregator to track many sites.

User tasks do not necessarily follow the designed information structure of the sites. Well-designed information structures are very important on the web -that’s why you’ve an information architect on the design team -because most web site interactions are navigation of one kind or another. However, the information architecture you so painstakingly created is also inevitably inadequate. If your menu and links really were sufficient for all the users’ tasks, they wouldn’t need the Back button -the link they’d need would be right there were they expect it to be. The importance of the history chain in a browser rivals the content structure we build into our web sites.

It would be a nightmare if each web page opened in its own window by default. The user would be having to explicitly dismiss windows all the time to prevent the screen from being overwhelmed with no longer needed pages. Instead, web tasks are better served by history navigation, despite the greater cognitive demands that history navigation entails. Now if the user is no longer interested in a page, the user must do… nothing. It will naturally disappear on the next page load, and eventually fade back in the history chain until it’s no longer interfering (or easily accessible).

Web Apps are More App than Web

As for your web app, the first consideration is the experience level of your users. Counter-intuitively, some low-end users are better at history navigation than window navigation despite the fact that history navigation is more cognitively demanding. This is because these low-end users use nothing other than the web browser. All they ever needed from a computer they get from the web. They may have never had two windows open at once in their entire life. Basic window operations such as moving, resizing, and minimizing are alien to them. The task bar doesn’t even register in their minds. Some users may not even be aware that one can have two windows open at once.

Assuming you’re not dealing with such low end users, the best navigation model depends on whether the users’ tasks are more like desktop tasks, with intensive work on a few pages, or more like web site tasks, with superficial work on multiple pages. I would expect that the former is more likely than the latter. Or at least it should be in a well designed web app.

While users use a web site to find content, they use a web app to manipulate content. Any navigation is just the means to an end. Thus web apps should be designed to minimize navigation by providing the most useful content per page. This is especially true for any app intended to be used regularly. While rarely done tasks are usually best served with task-centered user interface structures, with multiple simple pages arranged in wizard-like chains, regular tasks are usually best served with object-centered user interface structures, with a few complex content-dense pages. This doesn’t necessarily mean long scrolling forms. Rather, it means a well-organized page that makes the best use of space by employing:

• Tabs, expanders, master-detail panes, and other ways of using the same space for multiple pieces of content.
• Compact presentation.
• Selectable objects and pulldown menus (at least for less commonly used commands) to reduce the space needed for command controls.

In an app, all content of a list or table should fit in a single page within a scrolling pane, rather than being broken into pages like Google does with its search results. As a rule of thumb, a scrollable area needs to show at least 5% of the objects listed in order for the scrollbar to be controllable. This means a full-screen vertical scrollbar can easily handle hundreds of items. Scrolling through lists has the following advantages over paging:

• The scrollbar control is standardized so most users are already familiar with it. Paging lacks standardization so it takes attention and learning to use it (e.g., where the page links are located, whether there’s a First or Last link).
• The number of items shown automatically adjusts with window resizing, allowing users to optimize the number of items visible in one step and avoiding situations when there is both scrolling and paging.
• The scrollbar is accessible no matter where the user is in the window. Paging interfaces typically provide the page links at only the top and/or bottom of the page which can scroll out of view.
• With scrolling, users can move as little as one item at a time to show the items they want to see together. Paging splits items into arbitrary groups which can result in the items of interest being split across pages.
• Users can scroll to anywhere in the list with a single drag. Paging is limited to the page links shown, generally limiting the user to move only around the immediate neighborhood.
• With scrolling, users can multi-select any set of items to perform an action on them (e.g., copying, deleting), and users can look at any other item while maintaining the current selection. Paging generally allows and maintains only selection of the items on the current page.
• With scrolling, sorting and filter unambiguously apply to the entire table or list. With paging, the user may think sorting and filtering only apply to items on the current page. Furthermore, with paging users can become disoriented if they sort while part way through the list; it’s not clear what page they should be on after performing a sort.
• Using a scrollbar, users can still move one “page” at a time anyway by clicking the “track” of the scrollbar.

Finally, a well-designed web app will be purged of gratuitous graphics. Big logos and headers (like at the top of this page) have no business in a regularly used app. The user will know what they’re using. Leave the branding to an About box.

A Window for Every Page

Given you probably want to design your app to have a few content-packed use-intensive pages, you want a window navigation model, rather than a history navigation model for your web app. Just because your app runs in a browser doesn’t mean it has to use the history navigation model. You can open each page in its own window, like a desktop app would. You may even want to hide the browser’s menu and toolbars -they have little use once you’re not using history navigation, and you can use the extra real estate to show more content.

This way you can have the best navigation model for your app, and also benefit from a less cognitively demanding navigation model. Furthermore, using window navigation frees the paging concept to be used for something else. If your app involves manipulation of database records, I recommend you use “paging” to allow users to view multiple records in a form-type layout.  And more: the window navigation model makes it clear when the user has left the app. When the user selects Exit (or Logout) from the menu, the app closes all it’s windows. In a history navigation model, Exit typically only moves the user to a “thank you for using our app” page. All the other pages are still in the history chain, giving the user the illusion that they are still accessible, which can cause confusion, especially if users forget they’ve logged out.

Heresy? Opening a new browser window for a page is a Jakob Nielsen Bad Thing, but that’s based on the experience of web sites, not apps. Before the usability police cracked down on the practice, it was common for web site designers to set external links to open their pages a new window. The rationale was that this kept the user from actually “leaving” their site, and thus scoring them more eyeballs. What it actually did was annoy the hell out of the users because:

• The originating web page was just a navigation step. Often the users have finished with the originating web page, but now they have to get rid of it explicitly, rather than letting it automatically fade back into the mists of history. Opening a new browser window in this case is tantamount to a desktop Open dialog box that doesn’t close after the user opens a document with it.
• The originating web page was not a navigation step. Sometimes the users wanted to go back to the web site or some other part of their history but didn’t know how because the users were used to using the Back button for that and it wouldn’t work any more. Even if the users knew a new window had opened, and knew how to navigate back (e.g., via the Close button), it added workload. Now instead of just mindlessly smacking the Big Back Button, the user had to study the screen and figure out which navigation method to use for each page. If users incorrectly choose to use the Back button, they may have to hit it several times before if disables, signaling that won’t work and the users are wasting their time. If users incorrectly choose to use the Close button, they blow away the history they need to get back to where they wanted, and now they’re really wasting their time.

This implies that you can open a new window for each page if

1. You do so for all your pages.
2. None of these pages are intended as mere navigation steps.

Number (1) ensures your users aren’t burdened with figuring out which navigation model to use. You shouldn’t mix navigation models. Web sites that do this compromise usability. Windows started doing this with Vista, and it compromised usability. If you must include a history-like navigation model in a portion of your app, then you need to clearly signal that new navigation rules apply. One way to do this is display such content with the look and feel of a wizard, which coexist fine with window navigation.

Number (2) ensures you don’t pollute the users’ screens and taskbars with unwanted windows. With desktop monitors being substantially larger than when the web started, a cluttered screen or task bar is not as big of an issue as it used to be, but users normally keep between five and fifteen windows open at a time. Five windows will fill a task bar for a laptop screen; 15 will fill the taskbar for a 30-inch monitor. It’s still important to avoid unwanted windows, even for users with very large monitors.

• Avoid pages that are only menus or lists of links. Make your “home page” something the user can work on (e.g., a dashboard) not a mere launching point.
• Use top or sidebar menus for navigation rather than entire windows. If you have succeeded in having only a few complex pages, you won’t need a big navigation menu anyway. If you have many pages, then use pulldown menus to navigate to them, at least for the less commonly used pages. Pulldown menus are harder to use than simple links (taking two clicks), but remember navigation should be a smaller portion of the user’s work in a complex and capable application.
• If you must have an entire page for navigation then put it in a window that has the look and behavior of a dialog box. Like a dialog box, it should close automatically once users complete their respective input. It needs to look like a dialog box so users will be able to anticipate this behavior.

You should also resist the temptation to rely on drill-down, where the user opens a detailed page for a data object by selecting it from a more general representation or aggregate. You should always provide drill-down, in order to maximize flexibility. Any time more detail information is available on a data object, the user should be able to perform drill-down on it. However you should not rely on drill-down as the way to get to a detailed page when that’s the users’ only interest. Rather, drill-down should be used when the user has work to perform on both the detail and parent page. If your task analysis indicates that users will regularly need to work on only the detail page, then provide a means to access it directly, perhaps via a query or open dialog. This will be faster (the dialog design can be optimized for the one task of specifying the data object) and prevents leaving a large unnecessary open page behind on the screen.

The Preservation Problem

Another reason to use a window navigation model is that it avoids the problems with input preservations. Try this:

• Open a text editor.
• Enter some text.
• Navigate back to this web page.
• Navigate back to the text editor.

Is your text still there? Of course. It would be unacceptable if simply changing your focus to another window would wipe out user input. Now try:

• Navigate to your email web app.
• Compose a letter, entering some text.
• Navigate back to this page.
• Navigate back to the email app.

Is your input still there? No? That’s the preservation problem. Most web apps have not solved the preservation problem. I use Fast Mail’s web app, and the best it can do is show a warning if I attempt to navigate away from a page with input (except it doesn’t aways appear). Showing a warning is not a satisfactory solution to the preservation problem. It locks users in a mode, preventing them from using the computer flexibly. It would be like a desktop app made up entirely of modal dialog boxes.

Even if it weren’t for the formidable technical hurdles in solving the preservation problem, there’s the issue of how exactly preservation should work in the context of history navigation. If the history under the Back and Forward buttons is analogous to open windows in the window navigation model, then clearly navigating by these buttons should bring up each page exactly how the user left it, with both saved and unsaved input. But what about when the user navigates to the same page by a link? Should it also show the page as it was left, or should it create a fresh instance of the page anticipating that users select the link because they want to make new input separate from the other? I don’t know, but I would guess that users will click a link for page sometimes to get back to old input and sometimes to make new input. Either way, some users will get frustrated some of the time.

One could argue that links should always open a new instance of a page, that clicking a link is analogous to opening a new window in the window navigation model. This allows users to view and edit different data using the same page (e.g., compose two email messages a once), maximizing flexibility. The user can navigate back and forth between the separate instances of the page with the Back and Forward buttons. There will necessarily be a learning curve for users to understand the difference between navigating by links versus the Back and Forward button, but they’ll catch on, won’t they?

However, there is one big reason you can’t make links open new instances of pages. Like a Soviet-era dictator, the browser is incline to rewrite history. Imagine this: the user opens one page from another and starts making input. The user then uses the Back button to go back to the previous page and clicks a link to open another page to work on simultaneously. This makes the browser drop the page with the input from the history chain in the Back and Forward button. From the viewpoint of the user, it might as well have been dispatched to an Arctic gulag never to be seen again. Savvy users may be able to find the page in the History pane or window, but that is about as easy as retrieving a document from Recycling -not a normal way to perform navigation. The analogous action in the window navigation model is that opening some windows cause others to silently close. As long as this history “pruning” action exists, clicking a link must bring the user to the old instance of the page in order to provide a backup method to return to any input if the page falls off the history chain. As for the convenience of having two instances of the same page, sorry comrade, not with a history navigation model.

Of course, expert users are aware of the limits of the history navigation model when making input, and they know to open pages in their own window or tab in order to preserve input. They may even know to do this in order to have two instances of the same page with different inputs. However you shouldn’t rely on this expert technique. If your web app mostly involves input pages, then you probably should open each of them in their own window by default and save users the trouble.

As long as the preservation problem forces modes on users, the history navigation model should be limited to web apps where user input is limited to only a few simple fields per page, the kind of input suitable for a modal dialog box in a desktop app. I would say each page should require no more than thirty seconds of user work to complete the input before submitting. This limit minimizes the time the user is locked in a mode and the amount of effort wasted if the user must navigate to another page. I suspect that’s probably all that was ever intended with HTML. Such a modey app wouldn’t make a great app, but it would be no worse than some desktop apps. If you expect your users to flit about superficially through many pages, that may be your most usable solution.

Tabs or Windows?

There is a third option for users equipped with the right browsers, and that’s to open each  page in a new tab rather than a browser window. It’s not a bad compromise. It has the window navigation model’s advantage of allowing the user to access any page quickly and avoids the preservation problem. It has the history navigation model’s advantage of keeping all the pages within a single window, minimizing the clutter on the screen and taskbar. However pages in tabs don’t naturally fade back with disuse, which is the major advantage of the history navigation model. Compared to opening each page in a new window, opening in a new tab has the following disadvantages:

• It adds a layer of navigation. Many simple actions can require a two-step process. For example, bringing a desired page to the foreground can require that the user first brings the browser window forward then select the right tab.
• More ways to get lost. It presents another way for non-power-users to “lose” their data. In addition to the browser window being hidden by other windows (including other browser windows), a tab can be hidden by other tabs. Recovery is different in the two cases: in the first, users search the task bar, while in the second, users search the tabs of a selected browser window.
• Single page viewing. The user cannot see two pages at the same time. Even if you do not anticipate the user needing to compare, monitor, or otherwise work with two windows at once, you should provide the ability just for the sake of general flexibility. Side-by-side windows are also better for navigation. Users can see the contents, thus don’t have to rely on reading tab titles, which may be truncated. Clicking on a big window is faster than clicking on a small tab due to smaller average slew distances and larger targets.
• Inefficient use of space. With tabs, every page is the same size on the screen, so users have to size the browser window to be sufficient for the most space-demanding page. With each page in a separate window, users can size each as necessary, making more efficient use of screen space (e.g., while one page may need to be maximized, other pages aren’t, so those pages don’t occlude other windows, minimizing the total frequency of occlusion).

While usually it’s better to open a page in a new window, rather than a tab, there are some special cases when opening in a new tab is preferred:

• Ignorance of multiple window conventions. Opening in a tab may be better for those very low-end users who are ignorant of or confused by the taskbar/dock and multiple windows, and don’t know how to resize windows. My impression is that compelling tab imagery works better than the taskbar for such users in cuing navigation.
• Menu confusion. Your users habitually confuse the menus and toolbars of inactive windows with their active window when there are overlapping separate windows for each page. Tabs hide the menus of inactive pages, which can reduce confusion.

Rather than opening the pages in one of the browser’s tabs, you may want to use your own tab controls in the app itself. When combined with the above two bullets, this can make a superior user interface when:

• You anticipate a large set of tabs for most users (e.g., four or more) and you can control their display in a manner more effective for the task than the browser can as tabs or the OS can as taskbar/dock icons (e.g., with regard to order and labeling).
• You have a fixed number of tabs that should always be open.

However, tabs in your app add clutter and consume real estate in your pages.

Usually, you’re best off opening each page in its own window rather than in a tab.  This is especially true if you include features that address whatever disadvantages windows have compared to tabs. Typically, the user can switch between windows using the task bar as quickly as they can switch using tabs, but if you anticipate users having a large number of windows open (more than just for your app), you may want to provide a convenient means to navigate among your app’s windows from within each page. For example, you can provide a thumbnailed menu for switching among windows. Other advantages of tabs can likewise be negated with features. You can provide a control that iconifies all windows of an app with one click, allowing users to get all of your app out of the way like users can with tabs by minimizing the browser. You can provide a means to save the current window contents, sizes, and positions so the user can retrieve the setup in the next session, analogous to what can be done with tabs in some browsers.

Egalitarian Windows

I don’t see a problem with a complex app being spread across multiple windows as long as the app is well identified in each window so the users see them as all related. If you keep your page’s graphic design under control, the title bar may be sufficient for that.

In a multiple window app, you can have a centralized “home” master window that opens on app execution and provides the means to navigate to all other windows. Closing the home window exits the app, in contrast to closing any other window. However, in most situations, I recommend egalitarian windows so the users don’t have to identify and navigate to the home window for its functions. Every window should have a menu (perhaps a pulldown) that lets the user open any other window. Every window should have an Exit menu item (in addition to Close) to exit the app, closing all opened windows.

You can still have a dashboard window that opens by default on app execution that shows summary information and supports the user on key tasks, but also consider opening more than one window on app execution if you know what windows the user almost always will need to use. Or consider letting the user choose the window they want from a splash screen. Or install a shortcut to each window in the Start menu at installation, and let the user choose then. Or open whatever windows the user had opened in their last session, if users typically continue where they left off between sessions. With egalitarian windows, you have more options to provide the users whatever is best for their particular circumstances.

The only issues I see with egalitarian windows is this scenario.

• The user is working on Task 1 with Windows A and B.
• The user finishes Task 1, and is ready to start on Task 2, using Windows C and D.
• The user naturally closes Windows A and B, and….
• Oops! The user is out of the app with no way to easily open Windows C and D.

To avoid this scenario, I recommend a mini “when you need it” (WYNI) window. When the user closes the last open window in the app, a small window appears in the same place with nothing but a menu that looks much like the menu in all the windows, but only having menu items that work when there is no content. This includes menu items for things like Help, Options, Change Password, and all the menu items for opening the apps windows. This allows users to close all content windows when transitioning between tasks without shutting themselves out. Closing the WYNI window exits the app. That’s an extra click to exit, but there should be an Exit menu item in every window for exiting if the user wants to be quick.

Summary Checklist

Problem: Selecting a navigation model for your web app.

Potential Solution.

• Use history navigation if users will work superficially on many pages.
• Use window navigation when user will work intensively on a few pages.

Window navigation in general has the following advantages:

• Simpler, faster, and more visual navigation for recently used pages.
• “Paging” can be used for other purposes, such as showing multiple database records.
• Exiting or logging out leaves no ambiguous pages apparently available for access.
• Input is preserved when the user navigates to another page.

To make the best use of window navigation:

• Efficiently load large amounts of content on each page to minimize the number of open windows.
• Open every page in a new window -don’t mix navigation models.
• Avoid pages that are only used as navigation steps to other pages.
• Provide each page with a means to open any other primary page and to exit the app.

Opening each page in a window is generally better than opening each in a tab because:

• Navigation is faster and less likely to cause confusion.
• Two or more pages can be seen at the same time.
• Screen space can be used more efficiently.

[I notice] a heavy rag on top of the monitor, covering the cooling slits. Thinking I should remove it so it doesn’t overheat, I lifted the rag…. Under the rag was a chicken breast and another piece of food in baggies. [A user] said some of the guys heat their lunch that way…. I asked what was wrong with the microwave in the break room. He said the PC was closer and on their way out the door. Umm-mmm! Nothing tastes as good as chicken warmed by the radiation coming off a CRT! (Shark Tank)

There’s no denying the brilliance of users. One has to wonder why monitors aren’t designed with a lunch-heating feature. It would make a great compliment to the cup holders standard on most CPUs. Maybe we would have never migrated to LCD displays since they lack a native nacho nuking feature, and there wouldn’t now be great mountains of cathode-ray tubes leaching heavy metals into groundwater outside various major third-world cities. At the very least, we could’ve recycled the CRTs as microwaves.

We all know that average users are not very good designers. However, nobody told them that. It’s perhaps the most human activity to modify things to make them better for oneself. We’re all tool users. We modify things in order to modify other things to get what we want. It all started 100,000 years ago when a nice little rock was minding it’s own business, decorating a dried stream bed like God intended, when some hominid scoops it up, and next thing it knows it’s bashing open wildebeest bones for yummy and nutritious marrow. Wasn’t how the rock thought the day would end.

The same thing happens with more advanced technology. We designers created these products to support specific intended tasks, users, and operational environments. We put this sophisticated technology in the hands of hominids with slightly more intelligence than that bone-bashing fellow of 100,000 years ago, and it should be no surprise that they end up using it in surprising ways. What they’re really doing is overcoming limitations we put in the product by the very process of building for specific intended purposes. The users are creating work-arounds for conditions we failed to appreciate, re-purposing, re-applying, and re-designing the technology we provide to deal with a goal that we didn’t consider.

Due to ignorance of all the issues that go into a design (such as the need to keep a CRT from overheating), user work-arounds may have dubious value (on the other hand, as long as the user doesn’t have to pay for a toasted monitor, perhaps they are achieving optimal personal value). Nonetheless, in working around a limitation in the technology we provide, users follow the same design principles we do, or, at least, the same principles we should be following.

If you had only 15 minutes to explain how to make something usable, you’d probably go through the basic design principles. There are various sets of user interface design principles out there. Style guides typically start with a list of principles, and perhaps each of us have our own personal set. They all pretty much cover the same ground, varying mostly by emphasis and nomenclature. Here is my set:

A user interface should have:

• Efficiency
• Clarity
• Flexibility
• Consistency
• Tolerance

Users can’t recite these principles (or other versions of them), and yet whenever they deviate from our intended use of our products, it’s nearly always to improve the product with regard to these principles. For example, roasting your chicken on the monitor is more efficient because it means accomplishing the same goal with less walking than using the microwave.

Efficiency

Users can access… a big application in the data center… by way of a link on their procedures web page [that] points to the [primary] applications server. Time comes for IT to do maintenance [so they] change the link on the procedures page [to] point to the backup server during maintenance…. During maintenance, users claim they can’t access the application…. The users thought going through the procedures page took too many mouse clicks, so they created their own shortcuts on their desktops [that] continued to point to the primary app server [that was] down for maintenance. IT tells the customer that it wasn’t really an outage, but a case of user error. “No way,” says customer. “It’s still IT’s fault. You should have known that users don’t follow established procedures, and taken that into account in your maintenance plan.” (Shark Tank)

Ideally you would plan for every stupid thing the users might do, but that has some practical limits. On the other hand, it’s inadequate to plan only for “established procedures,” especially when the procedures were established by you. You have to expect some deviation from the normative path users follow in using your product. Specifically, you can count on users finding and employing an easier way of using your product. That is, they want greater efficiency, the ability to get their work done with less time and effort, physical or mental. They are merely following the same design principle you should have followed in designing the product. Frankly, your users have more enjoyable and important ways to spend their precious moments here on Earth than clicking the mouse and waiting for screen refreshes.

In this case, to be blunt about it, maybe IT shouldn’t be doing IT if it doesn’t understand that making shortcuts and favorites is an “established procedure” -far more established than anything specific to a particular web app. You have a choice in your designs: make things convenient for your users or try to force your users to make things convenient for you and your developers.

Guess how much cooperation you’re going to get from the latter? Do you think users want to do additional work to make life easier for you? Chances are they acquired your product because they thought it would make their life easier. In the business world, users are the reason you have a business at all that needs IT. As far as the users are concerned, IT only exists to serve the users.

Company changes e-mail systems and begins to remove deleted e-mail automatically after two weeks instead of leaving that to users. And that makes one user howl…. He stores all his e-mails in the Deleted Items folder as soon as he reads them, because he can get them out of his in-box with just a click on the big X. [It was] suggested that he create a folder for items he didn’t want to disappear. His first reaction: “You mean I have to make a new folder called Deleted Mail when there already is one?” (Shark Tank)

Part of the issue is a bit of confusion on what “delete” means. Unless they come from a professional editing background, users often think Delete means “remove” (as in “remove this from my Inbox”) rather than “erase.” But the other issue is a limitation of the software. Users need to archive old emails for later reference, perhaps because we place limits on the size of Inboxes. For this user, and presumably all users, it was expected that they create a folder, which means figuring out how, then figuring out how to move a message to the new folder. That’s all a lot of work when you already got a convenient Deleted folder that the users already know how to use. Worse, even after the folder is created, moving a letter to it means going through an drawn-out process. It takes four clicks on my email client to do it by going through the menus. Using drag-and-drop is much better (for users who know how to drag and drop), but it’ still not as easy as clicking the Big X on the toolbar. The archiving-by-deleting usage anti-pattern is the user’s way of telling you to make archiving easier.

Or maybe it’s for dealing with another limitation you set.

This company’s e-mail system has a 200MB limit for mailboxes — but not for the “deleted items” folder. More than one person had set up elaborately nested folders in their deleted items where they happily had 5 or 6 GB of mail. (Shark Tank)

Nowhere is user work-arounds for efficiency more likely than with security limitations, where users will come up with all kinds of inventive ways to subvert carefully designed security measures.

[Technician] discovers that one user’s workstation is generating a barrage of network traffic that’s maxing out the server. [The user] confessed that to defeat the pesky screen-lock timeout foisted upon them by the security folks, he and his buddies would bring up the e-mail client, put a pipe cleaner around the F9 key to keep it stuck down, and voila! — the screen wouldn’t lock. That night, he forgot to unstick the key, so it ran all night. Unbeknownst to the user, the F9 key forces a rather server-intensive refresh operation. (Shark Tank)

Partly this sort of hardware redesign is due to users not seeing security as really being their job. Making sure their subordinates have completed their TPS reports -now that’s clearly their job. Security is just something they have to work through to get to doing their job. It’s utilization not operational work. Users will share their passwords with other users in the name of getting the “real” work done today, and worry about security tomorrow. The other factor in security is that users get immediate rewards for cutting corners, while harmful consequences are very low probability events. Depending on the organization, that may be an optimal balance of competing job requirements.

Ratcheting up required password length or complexity can hurt security more than it helps. Passwords are hard to type, what with all those special characters and masking, so of course users will thwart screen locks if they can figure out how. Passwords are hard to remember, so of course users will write them down or re-use them or both. They’ll avoid changing them unless forced to. It’s not just  about convenience. Required password complexity is approaching the point where it is no longer humanly possible to remember passwords.

The best solution is not to try ever harder to force users to conform to security policies. It’s to design systems that make it easier to achieve the desired level of security. In the case of access control for example, it’s probably time we stopped relying on multiple long complex memorized passwords and moved to a more humane technology.

Clarity

She gets the prospect e-mails from [the real estate] service every day, she [then] forwards each message to herself at the same e-mail address…. When I suggested that she just keep the original e-mail and use that, her only answer was, “But I don’t have time to look at the e-mail when it comes in!” (Shark Tank)

One solution to the problem of providing efficient email archiving is to simply not have any. Rather than impose an arbitrary limit on the users’ Inbox size, just let everything accumulate in there by default, like GMail does. If users need to find an email, there’s always searching and sorting. This is an excellent solution, removing from the user the sizable utilization work of regularly archiving email. However, the Inbox is more than just a storage area for most users. As the name metaphorically implies, the Inbox serves as a list of things to do -of correspondence needing attention. While in general only recent email needs attention, depending on the volume of correspondence, email that still needs attention can pretty easily be pushed out of sight, and out of sight means out of mind. Re-emailing important letters to one’s self is this user’s crafty work-around to keeping key work items in awareness. It improves clarity, better communicating the state of the task, the actions required by the user, and the effects of the user’s actions.

Clarity is where you’re most likely to see glaring user-interface failures especially with low-end users. The failure is undeniable: the user is either stuck and cannot figure out how to proceed, or the user does something most definitely detrimental to completing their task with a computer, like failing to get a computer in the first place. Most of this Learning from Lusers series has been concerned with clarity, achieving it through analogy, proximity, appropriate terminology, and in general balancing the familiar with the magic that’s inherent in advanced technology. Users likewise realize when things are unclear and will take matters into their own hands to deal with it.

Many things can interfere with clarity, and a cluttered UI is just one of them. If you don’t provide a means to declutter the UI of irrelevant data, users try it themselves, and even succeed:

Every morning, every order in the division’s order log would delete…. The tech who has spent months investigating the problem notices that one particular user always seems to be logged in just before the orders disappear. So he calls him. When you logged on this morning, did you notice if the order log was empty? tech asks. “No, it was full,” user replies. “That’s why I delete all those orders.” What? asks tech. “I clear out the order log on my computer as soon as I log on,” says user. “It’s really hard to see today’s orders if yesterday’s orders are in there, too.” (Shark Tank)

Once again, the user intelligently deals with overwhelming data by using the tools available. Apparently, the log was not sorted chronologically (despite being a “log”), so the user had to impose his own filtering to be able to track the data relevant to him. He made the task information clear for himself because the UI didn’t. That would be the happy ending except that wasn’t the only thing the UI failed to make clear. It also failed to make cleared that the log was shared data used by multiple users and systems -the user thought he was working on his personal copy of it.

Professor Oldy McOlderton picked up email with relative ease. He’d frequently check for new messages and his students appreciated his attentiveness. One quirk that [IT technician] Victor noticed, though, was that he’d always BCC himself on each message he sent. He was aware but skeptical of the “Sent Mail” folder, favoring his inbox as a repository for all received and  sent messages. Because of the Professor’s preference, he asked Victor to change the software so that his BCC’d messages would appear to be coming from the person he was sending the email to. Victor explained that this was, in fact, impossible with the way email works, and went on to explain why it works the way it does. “Well, call the person in charge of Email and get it changed!” (The Daily WTF)

It makes perfect sense to have an Inbox and a separate Sent folder. Everyone knows that. Every email client and web app out there does this. And every app is wrong. None of us think of our communications by Sent versus Received, not at the top level anyway. We think of them as on going exchanges between the parties. If you needed to review some correspondences, it would be far more clear what happened if you could go through the exchanges chronologically, first what you said, then what they said, then how you replied and so on. Having a separate Sent and Inbox is like recording a phone conversation with each speaker on a separate tape.

Professor McOlderton is far more sophisticated than the rest of us, relying as we do on included messages in email replies to keep track of the thread of the conversation. He’s fixing the problem by BCCing letters to himself so his Inbox accurately represents the chronology of exchanges. The only problem is that stupid email doesn’t know better to show self-cc’d messages to have “come from” the receiver so that he can filter out separate exchange threads by sorting on the sender’s name. We need to put McOlderton on an open-source email client project. Maybe then we’d finally get an app where searching by email address searches both the From and To fields.

Flexibility

The service representative who is setting up the printer… needs to reboot the PC [so he first checks] with the woman who handles shipping…. The shipping software can’t be shut down and restarted during the working day [because it] will automatically close out the current day and start up with the date of the next business day…. “Sure, I’ll take care of it,” shipping woman says…. Then, with the shipping software still running, she reaches down to the power strip and turns off the machine…. After a few seconds, shipping woman calmly turns the computer back on…. Since it ended in an error state, it rebuilds and corrects some data files and picks up where it left off, on the current day…. [The] programmer [made] sure his software can recover from a major power outage, but [didn’t] give the user a clean way to shut down and restart on the same day.” (Shark Tank).

Any time you add automation, you need to consider building in overrides. If you don’t, the user will override it one way or the other. If all else fails, they’ll pull the plug. Including overrides is basic to designing in flexibility, where flexibility is a product’s capacity to allow the user to complete the tasks by whatever means they feel is best. In the case above, user-created flexibility means compensating for a capability the designer left out.

We’ve saw another example earlier of user re-purposing a product’s feature to improve flexibility. The user that forwarded real estate service email to herself was improving the clarity of the task but also improving the flexibility. She didn’t want the email app dictating when she should deal with the incoming email. She’d do it when she’s good and ready. And in the meantime, keep on forwarding it.

Avoiding arbitrary limits is another basic technique for making your product flexible. For example, you might think three separate Phone Number fields is enough (home, business, and cell), but get that kind of non-normalized data scheme in front of the right users and next thing you know they’re creating two records for the same business object to be able to have sufficient Phone Number fields. Comment fields are another way of providing flexibility for unexpected business conditions. If there isn’t anyplace for tracking essential but arbitrary information, users will just have to improvise.

This regional retail chain relies heavily on fliers it mails to customers, but not everyone is clear on how to use the customer list…. It seems some store clerks have been using the name and address fields for notes, so mailings are going out to “Bad Check Smith” and “Deceased Jones.” While going through and removing the inappropriate data, I ran across this comment: “Customer informs us that customer is dead.” “Was that by e-mail, voice mail or snail mail? (Shark Tank)

I’m pretty sure Windows 7 can communicate with The Other Side. It was a design idea a user had.

Consistency

I live in Italy…. One day, my brother-in-law told me his brother’s laptop wouldn’t work anymore and asked if I can help…. The machine hadn’t been able to boot for the last three days, though it worked perfectly before then…. I told him there’s probably some corrupted driver, and the first thing to do is back up his documents. I booted from a floppy and checked his folders. When I looked into the Windows directory, I noticed a bunch of files named “A,” “B,” “C,” “1,” “2,” and so on — and a few Italian translations of original file names, like FINESTRE.EXE instead of WINDOWS.EXE. “Why on earth did you do this?” “Well, I was looking into the folders one day, and I saw that if you clicked on a filename you could rename it. So I did. Took me three days, too.” (Rinkworks)

We’ve seen this user design anti-pattern before as an example of a failure of the desktop metaphor, which represents all files as documents (in “folders”) when in fact some files are machinery (better shown residing in an electronics cabinet). But more to the point of this post, why do users feel the need to go through system and program directories and change things around? Frequently, it’s to make them have more consistency, where system’s displays and controls have an appearance and behavior is similar to some other reference the users are using. That reference may be another part of the same system, or, as in this case, something outside the system: an Italian user who naturally wanted files to have names consistent with his language.

Tolerance

It’s the late 1980s, and… a user… complains that his cat has reformatted his hard drive. It all started when he pulled the manual out of the box and began to read the thing. [The user] gets especially excited about [DOS] batch files. He carefully and systematically wrote a neat little batch file to perform each DOS command -copy, mode, delete and, oh yeah,… format c:/s. Then the user discovers the hot-key utility. This would let him take a command or batch file and associate it with a function key…. One by one, he made each function key -F1, F2 and so on -represent a batch file that he had just created. Once that was complete,… his feline friend… jumped off a shelf and walked over his keyboard. One little paw was all it took to format the hard drive. (Shark Tank)

For those keeping score, the user earns +1 for reading the manual, +1 for designing for high efficiency, and -1,000,000 for not designing for tolerance, for resisting the tendencies for error and providing means for rapid recovery in the event of an error. The cat gets +15 votes on UX Exchange for astutely demonstrating the flaw in the design.

No one likes to think they’ll make a mistake, so tolerance in user work-arounds often takes a back seat to efficiency, although to be fair, the above example wasn’t so much a human factors issue as a cat factors issue. If users do work-arounds for greater tolerance, it’s usually only after painful experience. As professional designers we know to build tolerance into our products by making certain errors impossible (e.g., by using a dropdown list rather than a free-form text box), providing means to recover from other errors (e.g., Undo and helpful error messages), and, if all else fails, warning the user of potentially dangerous actions (e.g., with verification messages). We design for efficiency but are wary when that same efficiency also introduces intolerance. Well, usually.

Remote user calls about a Windows problem, and this help desk… begins by telling him to press Control-Escape. User: “I don’t have a Control key.” Sure you do, at the lower corners of your keyboard. User: “No, I don’t have Control keys because I pried them off. They kept getting in the way while I was typing Word documents and messing everything up. What do you use Control keys for anyway?” (Shark Tank)

It’s a little known fact that most word processors will blow away your entire document if you type the magic phrase, “A fish, a frog, a two-foot log.” Yes, it will -if instead of hitting the shift key for “A” you instead hit the control key, resulting in all content being selected and then replaced by the space typed next. Lucky is the user that figures out something happened related to the control key. For many users, they were just typing along and bang! Their whole document vaporized in a flash like someone somewhere hit it with a powerful Mizmo beam.

Like Hot-keys in DOS, accelerators like Ctrl-A in Windows are there for efficiency, and are marvelously good at that, so we certainly don’t want to do away with them all, like the user above did. However, sometimes we forget to consider tolerance when selecting commands to have accelerators. While a Select All accelerator makes sense for small text boxes, it’s probably not a good idea for an entire document. Users don’t need to select the entire document often enough to justify an accelerator -it just won’t save that much time of the user’s life over using the pulldown menu. Meanwhile, Ctrl-A lies there waiting to trap the unwary. I’d wager users more frequently hit Ctrl-A by accident in a word processor than on purpose.

The Insert key as an accelerator for overtype mode is another trap, easily tripped by accident and difficult to diagnose. Firstly, like Caps Lock, the Insert key functions as a mode key, but, unlike Caps Lock, there’s no feedback on that on the keyboard (e.g., a distant LED that lights up when activated, which is hardly adequate any way). Secondly, it’s labeled “Insert,” but since the default mode is Insert, what it primarily does usually is enter Overtype mode (in contrast to Caps Lock, which indeed primarily enters Capitals Locked mode). A user will have a hard time understanding why text is overtyping because the user hit “Insert.” Overtype mode is used so rarely that it’s questionable if we even need an overtype mode in modern office productivity apps (it was removed from Office 2007). Users are thus far more likely to accidentally enter overtype mode than to use it on purpose. If you really need overtype, then make it only accessible via the menu. Personally, I’d like to see the Insert key be an accelerator for, oh, I don’t know, maybe inserting (e.g., a spreadsheet row).

Fortunately, we provide some tolerance for accidental accelerator activation by providing Undo. Undo fixes typing Ctrl-A-something, along with Ctrl-X, Ctrl-V, and Delete, among others. However, Undo only partially fixes accidentally hitting Insert: we can bring back the text we over-typed, but only by erasing the new text. The users have to pick which is less work to redo manually. Also, not all accidental accelerator activations are fixed by Undo. In many office productivity apps hitting Ctrl-N when the window is maximized can also give the appearance of blowing away the user’s entire document, but Undo has no effect. The correct recovery from hitting Ctrl-N  is to close the window, which just so happens to be precisely the thing not to do to recover from hitting Ctrl-A-something. For users that don’t understand what the control keys are for, let alone what control combination does what, how should they react if their document suddenly appears to go blank? I know: pry off those frigging control keys to make sure it never happens again.

Accommodation: The Sixth Principle

We cannot anticipate every way users may want to use our product. If users are going to work around our designs anyway to fit their idiosyncratic needs, then perhaps we as designers should help them. And indeed, many lists of UI design principles cover accommodating the users, where the UI provides the means to adjust to variations among the users or their usage of the product. Humans all vary in their skills, experience, inclinations, goals, and tastes, so a usable product should have the means to adapt to individuals. Typical accommodations include:

• Adjustable default field values, sort orders, file directories, and periphery selections.
• Variable language, units of measure, and other internationalization.
• Environmental lighting compensation (e.g., daylight versus nighttime display).
• Variable use of aural alarms and other means to control the stridency of alerts.
• Selectable display of fields or table columns.
• A favorites or bookmarks feature.
• Command, toolbar, menu, and keyboard shortcut customization.
• Adjustable text sizes.
• Designing for accessibility.

Accommodation is a sound principle, but challenging to implement. One approach is to make the UI as accommodating to as wide a range of users and uses as possible, often by building in redundancy. For example, the UI can provide keyboard access to the menu through both the F10 key (as is the platform standard) and the slash key (as was the convention in a legacy system) so users used to either can use the UI unimpeded. However, a wide-range UI can mean design compromises and complexity (e.g., how does a user enter a slash now?), and sometimes redundant alternatives are mutually exclusive (e.g., maybe the legacy app used F10 for something else).

Another approach is to have the product attempt to automatically modify itself to the particular user based on inferences from the user’s behavior. For example, the File menu can include menu items for the most recently used documents, inferring that users often want to work on the same document they worked on previously. This can work but can also harm usability if the automation makes the wrong inferences, so you need to be selective on what you automate.

A third approach is to provide the user with explicit controls to re-work the product to fit their needs. This is typically done with such features as an Options dialog or macro feature. This also works, but the problem is that it pushes design decision back on the user. The user has to first discover that the accommodating features exist, then make the correct decision on how to use them, then figure out how to activate the feature. If they make the wrong choice, for example, failing to take into account the Cat Factor, they may end up worse off then when they started. We need to design and document our accommodating features such that they help guide users to make the right choices. You have to accommodate the accommodations to the users’ skill, knowledge, and inclinations.

So we should certainly provide means to accommodate our users, but only after taking our best shot at following and balancing the other design principles, and adapting the product as much as we can to the typical user, including adapting the accommodations themselves. If you don’t adapt your product to your users, then one way or another, your users will. And it ain’t pretty.

Summary Checklist

Problem: Adapting our products to the users so that they don’t have to.

Potential Solution: Following the basic principles of good user interface design as applied to your expected users, their tasks, and their work environment. Specifically, design the product to be:

• Efficient, minimizing the time, and physical and mental effort to complete a task; when two tasks cannot both be accomplished efficiently, then the more frequent or important task should be more efficient.
• Clear, maximizing speed and accuracy of communication from the system to the user on the state of the task, the available or required actions for the user, and the effects of those actions (feedback), and the implications of it all.
• Flexible, providing users a wide range of capability and means of accomplishing tasks, such as by minimizing modes, required formats, and required sequences of actions.
• Consistent, possessing displays and controls whose appearance and behavior is similar within the system and within other contexts experienced by the user.
• Tolerant, resisting tendencies for human error and providing means for rapid recovery in the event of an error.
• Accommodating, including the ability to adjust to the idiosyncratic characteristics of the specific user, task, and environment.

Last of Learning from Lusers

Next in the final installment of Learning from Lusers, we’ll take a look back at all we have covered and ask what it takes to adapt technology to our users.

Do you like computers, but hate math? Would you love to work on creating cutting-edge technology, but don’t think you have the quantitative aptitude to be a programmer or electrical engineer? Then become a user experience professional! If you can count to 5 (the number of users in a usability test), then you already know all the math you’ll need! Everything else is art! I bet you’re good at art, aren’t you?

Ha! Sucker! It turns out you do need to know some math to work in user experience. Being in UX means that sooner or later you’re going to have to deal with data on user performance or satisfaction, typically from a usability test. Even if you restrict yourself to design and leave the user research to others, you’re going to have to review the results of user research to inform your design work, so you’re going to need some concepts for evaluating that data.

Specifically, you need to know a thing or two about inferential statistics, the branch of statistics that helps you determine what you can reasonably conclude about your population of users based on what you’re seeing in your sample of users. Inferential statistics serve two basic purposes, both relevant to user data:

• Value Inference. Given an observed percent or average performance in your sample of users, infer what would likely be happening in the whole population of users. You know intuitively that the average or percent of user performance we see in a small sample of users could easily be off of what happens with users in general just because you happened to at random get some users that performed better or worse than your average users. Value inference tells you how far off that is likely to be.
• Relationship Inference. Given an apparent connection between two variables in your sample of users, infer if there is some sort of systematic or causal connection between the two. You might see a certain pattern in your sample, like that users who start on one page were more likely to make a purchase than those who started on another page. You know intuitively that it might be a coincidence -maybe you just happened to get more purchase-ready users on one page than on the other by chance. Alternatively, there might be some sort of underlying relationship. Maybe one page makes purchasing more attractive than the other, or (if users got to chose their starting page), maybe purchase-ready users are attracted more to one page than another. Relationship inference tells us the likelihood of such systematic relationships existing.

Why Avoid Inferential Statistics?

“I Don’t Trust Numbers”

Whether you’re making an value inference or relationship inference, inferential statistics are essential for establishing the confidence you should have in your data. Some may think it’s not worth bothering with statistics when overall test performance is only one of many things weighing in on design. But without establishing a level of confidence for that performance, how can you know how to weigh it in your design deliberations? How do you know whether you’re really learning something from a usability test verses just fooling yourself? Without establishing a level of confidence, how can you persuade your client on the importance of the problem your design is trying to solve? What do you do if a key stakeholder, say Wayne from Finance, says, “Bah, you only tested five users. That’s not statistically significant.” Just shrug?

O, Mr. Statistical Significance. Feared by some. Treated with contempt by others. It seems everyone would just wish he’d go away. I think most UX practitioners expect Siggy to say something about whether the sample sizes in our user research are big enough or not. This gives UXers  the uneasy feeling that if they let him, Siggy will rip away the sham that is our small-sample usability tests that we’re so invested in. Like Galileo showing the Earth orbits the sun, he could prove faith in usability testing is misplaced. We Can’t Let Him Do That. However, like the misunderstood loner in a B-grade film, Siggy actually has something valuable to offer the community of UXers if they would take the time to get through his rough unfamiliar mathematical constitution.

Instead, I hear that statistics are not worth the effort in a typical small-sample usability test, or even that statistics don’t apply to small samples, as if being simple and loose excludes one from the laws of probability. I’m told things like, “Our sample size is too small for statistical analysis,” which is sort of like saying, “Our boat is too small to worry about overloading it.”  Some seem to think it works to preemptively shoot the messenger before he delivers any inconvenient news. They say things like, “I know it’s not going to be significant with only five people, so why bother?” and off they go pretending the issue doesn’t exist. Right. I know my parachute isn’t packed properly, so why check it? Excuse me, I’ve got skydiving to do.

“I’m Being Qualitative”

It’s legitimate to argue that statistics are not relevant to small-sample usability tests because you’re depending primarily on qualitative data and analysis, rather than quantitative data and analysis. Qualitative analysis is an effective and perfectly scientific approach to answering the kinds of questions you want to answer with a usability test, especially when used as part of iterative design (i.e., formative rather than summative testing). In that case, you’re less interested in value inference than relationship inference. You don’t really care how many users have problems with your product. As an expert user experience professional, you assume that there will be problems with your product, and with frightful regularity, you’re proven right, despite your best efforts as an expert user experience professional.

What you want to know is what those problems are and, most importantly why. Without an ability to infer a relationship between the problem (e.g., the user getting loss) and the cause (some confusing link labels), you won’t know how to improve the product. To quantitatively infer relationships you have to anticipate both the problem and cause, and measure or control each, doing something closer to A-B testing than classical small-sample usability testing. Because of this, qualitative is superior to quantitative when you doing exploratory “let’s just stick a user in front of this thing and see what happens” kind of usability testing.

So you should most definitely collect and evaluate qualitative data. However, this should be done because it is the best methodology, not as a ploy to ignore statistical issues. In particular:

• Just calling it “qualitative” doesn’t make it qualitative. Some UXers seem to think that qualitative means simply being vague with your amounts, that as long as you don’t represent anything with Arabic numerals, you can skip the statistics parts. They phrase results using words like “some users” and “most users,” or show the amounts graphically, rather than giving a precise count or percent. Anytime you are dealing with relative amounts or levels of anything, you are dealing with quantities, and statistics are necessary. Anytime you graph amounts, you are using statistics, but not necessarily inferential statistics. True qualitative data are stories, sequences of linked events and perceptions, things that cannot be reduced to amounts without losing key information you need to make qualitative relationship inferences. Quantifying data necessarily means abstracting it. You cannot change quantitative data into useful qualitative data -you won’t have the rich narrative information you need for qualitative analysis.
• Being qualitative is not generally cheaper or easier than quantitative. While qualitative research is typically done on small sample sizes, the time and effort spent on each user is typically much higher than quantitative research. In quantitative research, data collection for one user may be limited to checking a box to record if a user completed a task or not. In analysis, that datum is processed in a few CPU cycles to be part of your results. In qualitative research, to get the rich information you need, you need to record much more about the user’s performance, where they pause, what they almost clicked on, what they said while thinking aloud, and how they answered your open-ended questions. In analysis, you have to pull all that together into a coherent narrative, which takes a whole lot of brain cycles. Qualitative research typically has small sample sizes not in order to be cheaper than quantitative research but because you wouldn’t be able to afford a large-sample qualitative study. While in some situations qualitative research is more cost-effective than quantitative, and vice versa, on average it’s a wash. Going qualitative by default is not going to save you time or money.
• Sometimes you do anticipate the problems and causes. While formative research and iterative design should always include opportunities for serendipitous findings, you make best use of your usability resources if you focus your research on specific design questions. While this doesn’t preclude using qualitative research to address the question, it at least implies you have the ability to conduct a quantitative study: you’ve hypothesized how a specific design will specifically affect user performance. You can vary the design on those specifics, and measure the specific result. When you have such specificity, a quantitative approach will typically give you a clearer answer to your question than a qualitative approach.
• Sometimes you need to make value inferences. Qualitative research can tell you about the relationship between two things, but it is not suited for telling you frequency or amounts of the things. However, sometimes that’s what you need to know. Sometimes it’s not enough to know if you have a problem with a product. You also want to know how serious the problem is, for example, how many of your users you expect it to affect. With limited usability resources, you may need to know if it’s worth justifying the expense of fixing the problem, or you may need to prioritize problems for attention, or you may have conflicting results from two different sources and need to weigh them against each other. Value inferences are almost always best done with inferential statistics. This post focuses on making value inferences from small-sample usability test results.
• Quantitative and qualitative methods are not mutually exclusive. You can use them both, sometimes on the same sample of users to to exploit the strengths of both. You can include open-ended questions in a quantitative study, which may provide insight into a specific individual’s (e.g., an outlier) quantitative performance. And you can conduct inferential statistical analysis on key quantitative variables in a small-sample usability test that is otherwise qualitative.

The Significance of Significance

Let’s pretend I’ve convinced you that it’s vital to apply inferential statistics to user experience problems. So what is statistical significance and why do you need to pay attention to it? The answers are that it’s just a social convention and you can ignore it.

Alrighty. It’s going to take some explanation on how I got to those answers.

Technically, “statistical significance” means the results you’re seeing in your sample of users cannot be plausibly attributed to random sampling. For example, let’s say you conduct a usability test with a paltry sample of three users, and two out of three have a problem with completing the task. A 67% failure rate sounds pretty bad, but could it plausibly be attributed to random sampling error? In other words, despite your efforts to get representative users for your test, you could have just happened to get a couple of weirdoes who can’t figure out a UI that would be perfectly clear to just about every other life form on the planet. With a sample of only three, we intuitively sense the this is pretty plausible. We can expect that Wayne from Finance thinks it’s very plausible, since he wouldn’t even accept results from five users.

However, this fails to take into account that in all probability Wayne doesn’t know his alpha from a hole in the ground. This is not something to judge subjectively. You can calculate the plausibility (probability) of two out of three failing a task if you make one reasonable assumption and you have one additional piece of information.

The Assumption

The one reasonable assumption is that your sample is a random sample of the population of users that you’re interested in. Making this assumption allows the laws of probability kick in, making the calculation possible. Now, of course, you didn’t take a strictly random sample of users, where every user in the population has an equal chance of being in your sample. You probably drew from a specific geographic location, and there were limits on your ability to persuade users to take part in your usability test. You are certainly drawing from a specific period in time. Your product will be used by users in the years ahead, but did you think to sample from the future? Aha! No random sample then!

However, you did attempt to acquire a representative sample of users, users that are known to have similar characteristics as the users in you population -similar knowledge, skills, and maybe even demographic variables. For statistical calculation purposes, a representative sample is at least as good as a random sample. If you’re thinking about how your psych methods professor drilled into your heads the importance of randomness, you’re probably thinking of random assignment to experimental conditions, not random sampling for inclusion in the experiment in the first place. Random assignment is quite different and infinitely more feasible than random sampling. Some might even argue that a representative sample is better than a random sample, that the results you see are more likely to be consistent with the population’s performance than just picking users by drawing names out of a physical or virtual hat. However, if you think about it, your actual means of selecting representative users probably depends on pretty crude criteria. For example, you might choose users with a certain range of years of computer and web experience, but that’s a pretty indirect measure of their mental models and actual understanding of computers and the web. By all means, try to get representative spreads of users, but most likely it will be about equally good as a true random sample. Which is good enough for our purposes.

(Parenthetically, you also need to assume independent performance among your users, where the chance of one user failing doesn’t affect the chance of another failing. However, that is generally not an issue in usability testing as long as:

• You tested your users separately rather than as a team or focus group so that they don’t influence each other.
• You have one number per user per variable. For example you shouldn’t have each user try the task twice in order to get a sample size of six rather than three. You can, however, combine performance on both tasks for each user (e.g., record 0, 1, or 2 failures per user) in order to use all data but retain a sample size of three.)

The Additional Information

Okay, we’ll buy the assumption of a random sample, so let’s calculate the probability of two out of three failing. To which you should immediately ask, the probability given what? In order to calculate a probability, you need some sort of anchor point, some sort of number to get traction on. For example, to calculate the chance of getting three heads in a row when tossing a coin, you need to have the chance of getting a head on one toss.

In the case of our usability test, we can calculate the probability of two out of three failures given a chance of one user in the population failing. Which, if we knew, we wouldn’t have to do the stupid quantitative analysis in the first place. But wait: it’s useful to use a hypothetical state of the population -a “for the sake of argument” chance of failing. And what’s the argument in this case? What we’re really interested in is whether this two-out-of-three failure rate means there’ll be an unacceptable failure rate when the product is released. In other words, we want to make a value inference.

Your Hypothetical Population State(s)

To calculate the the probability of two out of three failures you need an actual number for the hypothetical population state. Should it be that 50% of the users in the population fail? Or 25%? 10%? 0%? You can work with your stakeholders to decide what constitutes an acceptable failure rate to use as a hypothetical population state. One way to look at it is to compare the cost of fixing the design with the cost of not fixing the design. Maybe Wayne can even give your some numbers to figure this out. For example, suppose redoing the average design flaw takes a total of 10 worker-hours, working at $100 per hour, so the cost of a fix is $1000.

The cost of not fixing the design may be harder to quantify in dollars and cents. In business software, a design flaw might make the task take longer (costing more user time), reduce worker morale (maybe notch-up turnover), increase calls to technical support (requiring more staffing there), increase the chance of an untrapped costly error, and so on. For a consumer web application, a design flaw may annoy users, diminishing the value of the brand, ultimately resulting in lost sales or a reduced user base to sell advertising to.

Let’s say it’s a business app, and on average a single failure takes users 15 seconds to recover (a failure in the mild annoyance category). If users are paid $30 per hour, then each failure cost 12.5 cents in time alone. So if there are over 8,000 failures in the lifetime of the design, then it’s worth fixing the design (8,000 * $0.125 = $1000, the cost of fixing) just to save the worker’s time. Let’s say you have 100 users encountering the design once per day on average with 250 workdays per year, and the lifetime of the design is 2 years. That works out to 50,000 encounters over the app’s lifetime (100 * 1 * 250 * 2). Thus, the break-even failure rate is 16% per encounter (8,000/50,000). If the population failure rate is over 16%, you save money in the long run by fixing the design. If the population failure rate is less than 16%, then you save money by not fixing the design (taking into account only the costs of worker time).

The total cost of not fixing a flaw depends on the number of users and the number of times the users encounter the design over the lifetime of the product. Do the same kind of calculations on a e-commerce app with millions of users and hundreds of millions of dollars in sales, and you’ll see it’s worth it to fix a design flaw when only a fraction of the users encounter the flaw of whom only a tiny fraction fail of whom only a tiny fraction end up switching to a competitor.

In practice, you’re not going to be able to determine the break-even population rate with such precision. What you can do is come up with a range of population rates by playing with the numbers you have and making some educated judgments with your stakeholders. Figure the following end points of the range by answering the following two questions:

• Hypothetical State A:  What failure rate would you regard as absolutely acceptable? Here you want a rate that everyone agrees is definitely in the “Who cares?” level.
• Hypothetical State B: What failure rate do you regard as absolutely requiring a fix? Here you want a rate that everyone agrees is clearly worth the cost of fixing.

Obviously Hypothetical State B is greater than Hypothetical State A. The true break-even failure rate would fall in between State A and B, a range we might call the “Whatever” zone.

The Answer is…

So we’re trying to calculate the probability of getting 2 out of 3 failures given Hypothetical State A and B. Let’s say that Wayne says both have got to be 0%; not 1% or 0.1%, but 0%. Failure is not an option. Ol’ Wayne is really a softy. He cares deeply about every user failure and insists on no failures ever. Any failure is definitely worth fixing. What’s the probability of two out of three users in your sample failing given the chance of failure in the population is 0%? (Show your work).

Answer: 0. You just saw two users fail, so you know it cannot be 0%. I mean, maybe you got the only two life forms out of millions of users that would fail, but that still means the failure rate cannot be 0%. That was easy. This is something that those who worry about small sample sizes seem to forget: irrespective of the sample size, if you ever observe users failing then there certainly are some users who fail with your product. It’s only a question of how many.

Let’s make it so I actually have to do some calculations. A 0% failure rate is clearly too ambitious. On something like a web site for the general public, you can tolerate a little failure. We’d probably feel pretty happy with a 1% or 2% failure rate. We can probably live with 1% to 2% of our users doing a work around, asking a colleague for help, calling support, reading the documentation (gasp), or, in the worse case, taking their business somewhere else. Maybe even 5% to 10% would be acceptable as long as we’re talking  minor annoyances and recoverable problems, not total user meltdowns. In contrast if you’re getting a 50% failure rate even if they’re just minor annoyances, then your web site is starting to look like a usability disaster area. For this example lets go with:

• Hypothetical State A: 10% failure. Definitely don’t fix the design.
• Hypothetical State B: 50% failure. Definitely fix the design

That puts the break-even point for fixing-versus-not-fixing in the 20-40% range. That might be reasonable for some intranet apps with small populations of users.

With regard to statistical significance, we’ll use Hypothetical State A. We’ll revisit Hypothetical State B later.

What’s the probability of two out of three users failing when the population failure rate is 10%?

Crunch, crunch, ptui!

Answer: 0.028.

About one out of 36. That’s a pretty low chance. What’s it mean? Well, it’s very implausible that the population failure rate is 10%. We don’t know what it is, but it’s clearly not less than 10% -that would be even more improbable. It’s much more likely to be more than 10%. It means that it’s very likely if you release the web site as is, the failure rate will be above the “who cares?” level. The true rate is in the Whatever zone… or higher, perhaps well above the Definitely Worth Fixing point of 50%. With two out of three or 67% of the users in your sample failing, that would be hardly surprising. What should you do? Care. Show your users some love. Go fix the design. Probably the worse you can do is roughly break even.

P-value

To statisticians, the 0.028 number I calculated is symbolized by p, so we call it a “p-value.” A p-value represents the probability of observing a particular result (2 failures for 3) given a hypothetical state of the population (10% failure rate). What we just did is basically what nearly all inferential statistics is about. We calculated a p-value for an observed sample result given a well-chosen hypothetical state of the population (a “null hypothesis” in statistician’s lingo). We then looked at the p-value and decided it was too small to be plausible: it’s unlikely that failure rate is 10% (or less). It’s likely that it’s over 10%. It’s likely we have something worth worrying about. Note that while a  p-value is an infinitely continuous number between 0 and 1, we need to make a binary decision based on it: we’re either going to work to re-design the product or not.

In nearly all cases, you’d probably agree that 0.028 is so low you gotta believe the real failure rate is over 10%. But what if the p-value were 0.10? Or 0.20? Or 0.50? Somewhere you have to draw the line and set a criterion. You can think of the p-value as the doubt about the hypothetical population state with respect to your observed results. A small p-value means high doubt about the hypothetical population state, and more confidence that that the actual population state is more in the direction of your sample result (in this case, the actual failure rate is over 10%). A big p-value means your sample results give you little reason to doubt the hypothetical population state. Maybe you have some other reason to doubt the hypothetical population state, but it’s not because of the quantitative results of your usability test.

Another way of thinking about the criterion p-value is it’s your willingness to be wrong. We decide to redesign the product because it’s very improbable the failure rate is at or below our “Who cares?” rate. Very improbable, but not impossible. In fact with a p-value of 0.028, in 28 out of 1000 usability tests you will be doing a redesign that is definitely not worth it. Statisticians call such actions a Type I error, a case of disbelieving the Hypothetical Population State A when it is in fact true. The probability of a Type I error is equal to your criterion p-value, the point at which you say, “I don’t buy that hypothetical state. Let’s act like it’s not true.”

By the way, the probability of a Type I error is symbolized by the Greek letter alpha. You know that thing Wayne from Finance can’t distinguish from a hole in the ground.

Determining Statistical Significance

Right, you’ve gotten a p-value of 0.028, and thus have very high doubt the population failure rate is 10% or less; rather you have very high confidence the population failure rate is over 10%. But is it statistically significant? That’s where the social convention part comes in.

As an UXer, you and your stakeholders can in principal use any criterion p-value you want depending on your tolerance of risk in the particular situation. Scientists, however, needed to standardize their statistical procedures, which included selecting a value to divide doubtful and plausible. In what may be regarded as a remarkable example of international cooperation, they decided as a community that the criterion of doubt is 0.05. It’s a social convention, but not an arbitrary one, taking into account the practical limits of theoretical research and what scientists are trying to accomplish. For scientists, the decision they make based on this criterion is whether they have new scientific knowledge or not. To do inferential statistics, scientists select a Hypothetical State A of the population that essentially represents the status quo of knowledge. If scientists observe something with a p-value of less than 0.05 given that status quo, then they conclude that the status quo is wrong, and they’ve discovered something new.

A 0.05 criterion is pretty strict. It basically says, “you really can’t dismiss this new information as due to sampling error and be taken seriously.” It means that with 95% certainty, something other than sampling error must be responsible for the observed result. Frankly, there aren’t a lot of things outside of mathematics someone can say they know with 95% certainty. I mean, people say “I’m 95% sure of such-and-such” all the time, but if you were to actually count how often they were really right when they say that, it’ll be something like 70%. I’m 95% sure of that.

The 0.05 value is the conventional scientific criterion for statistical significance. If a p-value is at or less than 0.05, then the sample result is “statistically significant.” It means one concludes that a particular hypothetical state of the population is false. On the other hand, if the p-value is above 0.05, it’s “not statistically significant.” It means one cannot conclude a particular hypothetical state of the population is false.

So, if we were to follow scientific convention, we’d recognize that (given a hypothetical failure rate of 10%) getting 2 out of 3 failures has a p-value less than 0.05.

Holy crap! We’re statistically significant with a sample size of only 3!

Bigger Effects Mean Smaller P-values

Now before you go telling all your friends that all you need is a sample size of three for statistical significance, let’s think about what we were calculating. The p-value is specifically the probability of getting two out three failures given a hypothetical failure rate of 10%. If only one user failed, we’d be asking for the probability of getting one out three failures given a hypothetical failure rate of 10%, which is a different number. In fact the p-value in that case is 0.271. So seeing two out of three failures is statistically significant, but seeing one out three is not. With a p-value of 0.271 there’s better than one in four chance of seeing one out of three failures (or more) when the population rate is 10%; improbable, but reasonably plausible. You’ve a pretty big risk of a Type I error if you invest in changing a design when just one out of three users failed. There’s a pretty good chance it’ll be a waste of money.

For that matter, maybe you have even stricter standards for plausibility than the scientific community. After all, 0.05 is far from impossible. Well, for you, it might interest you to know that the probability of getting three out three failures with a 10% population rate is 0.001 or 1 in 1000. Still possible, but really really unlikely. If you’re looking to be extra extra sure you’re not committing a Type I error in your redesigns, maybe you should only do them if three out of three users fail in the usability test. A p-value of 0.001 is fairly called highly statistically significant. Yeah, Wayne, with a sample of just three.

So here’re all the p-values for a sample size of three and a hypothetical population state of 10% or less:

I’ve included the percents of the sample to show that the more the sample deviates above the hypothetical population value (10%, in this case), the smaller the p-value.

Minding Your P’s

These are the take-home lessons:

1. Wayne is a jerk.
2. You can’t just look at the size of a sample and decide if a result is statistically significant or not. The calculation of the p-value depends on the difference between the observed result and the selected hypothetical state of the population. The bigger the difference, the more likely it’s statistically significant. That’s why I said Wayne was probably blowing smoke when he said that results with a sample size of five were not statistically significant. He couldn’t possible know if it were significant or not without knowing the selected hypothetical state of the population and the observed result. A result can be significant with a sample of three. Likewise, a result can sometimes not be significant with a sample of 300,000.
3. Statistical significance is not really the important thing. Statistical significance includes the social convention of the 0.05 breakpoint, which may or may not be suitable for your situation. Speaking as a scientist myself, the 0.05 breakpoint is not a bad one. It has served the scientific community well, and if you have nothing else to go on, it’s a good breakpoint to use in your own work. However, as a UI designer, your goal is to produce the best design you can, which is a different goal from a scientist trying to establish new knowledge. That may imply a different breakpoint than 0.05.

This is what I meant when I said you should ignore statistical significance. The main thing that statistical significance has to offer usability testing isn’t the ultimate “significant-or-not” label to slap on results, but rather the process of calculating the probability of a result given a hypothetical population state. Instead of attending to yes-no significance, you should attend to the p-values. They represent a purely mathematical concept that can be applied to any situation. Any time you report the result of a sample, whether it be big or small, you should also explicitly include the p-value. Then, you, your project designers, your stakeholders, or whoever is looking at your result can decide for themselves what they should do.  Over at ABtests.com, I’m frankly getting tired of having to calculate the p-values myself. It really needs to be on the page right next to the “Higher Conversion!” stamp.

You should also include your hypothetical state of the population, unless it’s implied. This isn’t necessary in the case of an A-B test, because it’s understood that the hypothetical population state is that A and B have the same conversion rate.

To help you in using inferential statistics in your own usability tests, below are the p-values for a sample size of three for various hypothetical states (click for full size).

I’ve also prepared tables for the actual numeric values. The values are the p-values for getting X number of “failures” or more, where a “failure” can be whatever you define it to be , as long as it’s something you want less of. For example, maybe it’s when a user utterly bombs the task, or maybe it’s when they just make a single recoverable mistake on a particular part of the UI. Maybe it’s just when they take too long to finish the task. All that matters is that you’re consistent with all the users in your sample. The graphs and tables work for any case when you can divide user events into two mutually exclusive and exhaustive categories. To use them:

• Define failure.
• Select your Hypothetical State A
• Count how many users fail.
• Look up that count for your sample size and  your chosen Hypothetical State, and read the p-value.
• If the p-value is low enough for you, consider the actual rate to be greater than the Hypothetical State A.

If you’ve got “successes,” (something you want more of in your design) then convert them to failures, where the number of failures is how many users didn’t succeed. Also convert your Hypothetical State A from a success rate to a failure rate by subtracting success rate from 100%. Sorry, I can’t do all of the math for you.

What About Hypothetical State B?

Well, what are the odds that statisticians would call something a “Type I error” when there isn’t also a “Type II error”?

To review, we’re getting the probability of seeing the result we saw in the sample given the “Who Cares?” Hypothetical State A. This p-value is the probability of a Type I error -redesigning the product when it definitely isn’t worth it, in this case. Say you redesign your product only if two or more users fail. Then from the table (or graph) we see there’s a 0.028 chance you’ll do a redesign when you definitely shouldn’t. Sounds good. You’re keeping with scientific tradition of holding your Type I error rate to 0.05 or less. But there are other considerations than keeping design costs down. We can also ask, what’s the cost if you don’t redesign a page? What about not redesigning when it would be definitely worth it if you did? That’s what Type II error is: when you should have considered the Hypothetical State to be wrong, but didn’t.

Here’s where Hypothetical State B comes in. It represents the hypothetical rate in the population where it’s most definitely worth doing a redesign. Let’s say you select 50% or greater for your Hypothetical State B. We can use the tables to see the probability of redesigning the product when you definitely should. That probability is called “statistical power.” Subtract it from one, and you have your Type II error rate, the probability of not redesigning when you should.

Let’s see: 2 out of 3 failures, with a hypothetical rate of 50%, gives you 0.500.

Uh oh.

By only redesigning if two or more fail, you’re keeping your Type I error rate to 0.028, but your Type II error rate is 1- 0.500 = 0.500. You’re going to miss half of the design flaws that are most definitely worth fixing. Half of the problems that affect 50% of your users or more are going to make it to the final product. There’ll be frequent interaction errors! Slow task completion times! Loss revenue! User riots! The collapse of civilization!

Power Hungry

In usability testing, a Type II error is just as bad as a Type I error. You minimize the total chance of error by balancing Type I and Type II error probabilities. That’s how we set our hypothetical states, with State A being Definitely Not Worth Redesigning and State B being Definitely Worth Redesigning, and the break-even Whatever Zone in between. Deviations from that zone in either direction are equally bad.

This is in stark contrast to scientific research where Type I errors are worse than Type II errors. A Type I error means you’re claiming to discover something that isn’t true, which would undermine the credibility of science and result in a lot of people doing unnecessary (and possibly dangerous) things based on erroneous information. It increases the chance of two contradictory facts being “proven” statistically, which would cause endless confusion. A Type II error in science means a discovery will have to wait for another day. It serves science to be conservative, to adopt a skeptical attitude to new ideas until they are empirically supported with high confidence.

With this in mind, let’s return to our table for a sample of three. What sort of result would best balance Type I and Type II errors?  Let’s look at one failure out of three. Given a Hypothetical Population State A of 10%, the Type I error rate is 0.271. Given a Hypothetical Population State B of 50%, statistical power is 0.875, for a Type II error rate of 0.125. Those aren’t great odds, but they’re a better balance than 0.028 and 0.500.

Given your choices in this particular example, it looks to me like you should fix every problem you detect in every user. That looks like the best balance of power and Type I error rates for a sample size of three with the selected hypothetical states. Inferential statistics for usability tests boils down to this selection of such a minimum critical result (1 in this case) for deciding whether to redesign the product or not. When reporting your decisions,  you should report the critical result and it’s associated Type I error rate and power so your audience understands the chance you might be wrong in your decisions. And statistical significance? Screw statistical significance. If you give your Type I error rate and power, then you have no need for potentially misleading yes-or-no statements of statistical significance. Even the sample size is irrelevant.

Statistical Justice

Notice there is a trade-off between Type I error rate and power. Redesigning when two out of three fail means low Type I error rate (0.028), but little power (0.500). Redesigning when one out of three fail means good power (0.875), but you had to compromise Type I error rates to get there (0.271). That seems fair. You can’t have everything.

What if you don’t want to compromise? Maybe you can’t accept choosing between a Type I error of 0.271 or power of 0.500. Let’s say you just don’t like those odds. It means too many mistakes, too often redesigning things that don’t need redesigning, or too many things needing redesigning not getting redesigned. Maybe the Type I or Type II errors are too costly to accept those kinds of rates. There is something you can do about it: increase your sample size. Take a look at a sample size of five for example (click for full size; also on table page):

Specifically, look at getting two out of five: Type I for 10% is 0.081. Not bad. Not too far from the statistically significant standard for scientists. Power for 50% is 0.813. Also not bad. Frankly most scientists would be quite happy with that kind of power. The fact that larger sample sizes reduce error is probably consistent with your intuition. Bigger samples mean more confidence in the results, less chance you’ll think the wrong thing one way or the other. However, it’s not like there’s some magic threshold sample size that ensures your results are reliable. It’s all a matter of degree. Bigger samples are like a bigger microscope, allowing you to more reliably detect smaller differences in things. Bigger samples mean more costly usability tests, so they only make sense if you need to save on the costs of Type I and Type II errors. There’s statistical justice in the world. You want to make fewer errors? Then you better be ready to expend greater effort for it. You get out what you put in.

(For more on how to select a sample size for a usability test, see Lewis, J. R., (2006). Sample sizes for usability tests: Mostly math, not magic. Interactions, 13(6), p29-33. Note, however, that Lewis is only concerned with achieving sufficient statistical power, and doesn’t really address Type I error rates. On the other hand, in many projects, such as when designing for a large population of users, that’s appropriate because then its worth fixing a design flaw if even a fraction of a percent of your users have a problem; Type I errors a no longer a realistic concern and all you need to specify is Hypothetical State B.)

If you have ever been puzzled on why usability testing works with sample sizes of only three to five, now you see that from a statistical standpoint, it really isn’t all that bad. You actually have a pretty good chance of detecting serious design flaws that would affect most of your users while not wasting time on design flaws that affect a small fraction of your users. Far from being a threat to usability practices, inferential statistics validates them. From a strictly rational mathematical perspective of minimizing costs due to (1) doing unnecessary redesigns, (2) letting design flaws make it through to production, and (3) conducting usability tests, small sample size usability tests are often the optimal solution.

The primary limitation of a small sample size is it has a lot of uncertainty about how big a given problem is once you decide you have one. For example, you may know that it very likely affects at least 10% of your users, but it’s reasonably plausible the actual value is anywhere between 10% and 80%. For most usability situations such imprecision is acceptable. If you’re going to fix all detected problems anyway, who cares which ones are the worst?

If you still find yourself distrustful of small sample sizes, forget the math and look at it this way: if a problem exhibits itself in a large portion of your user population, you’re very likely to see it in a small sample; if the problem exhibits itself in a very small portion, you’re very unlikely to see it in a small sample. Small sample usability tests, in other words, are a wide-mesh net, convenient for likely catching only the big problems –which are often the ones the client primarily cares about.

There’s also statistical justice in the errors themselves, in the sense that if you do make an error, it probably won’t be a severe error. In this example with 0.813 power, you have a 0.187 chance of missing a design flaw that affects 50% or more of your users. Could it affect a lot more than 50%? Sure, it’s possible, but not likely. Look at the table for the chance of not deciding to fix a flaw that affects 80% of your users: 0.007. Most likely if you make a Type II error, it’ll be for problem near the 50% mark. Likewise for Type I errors. If you end up fixing a flaw that isn’t worth fixing, it’s more likely to help 9% of your users than 1%, which may not be cost effective, but isn’t a total waste of design resources, especially if I personally happen to be in that 9%. The punishment is proportional to the crime.

Summary Checklist

Problem: Using inferential statistics to make rational redesign decisions based on small sample size usability tests.

Potential Solution:

• With your stakeholders, choose Hypothetical States A and B.
  • Hypothetical Population State A: your agreed-on population rate of failure that is definitely not worth redesigning for.
  • Hypothetical Population State B: your agreed-on population rate of failure that is definitely worth redesigning for.
• Using the tables of this post, lookup the p-values for States A and B for your sample size.
• Select a critical result that balances these p-values, giving you a low probability for State A and a high probability for State B.
  • The p-value for Hypothetical State A is your Type I error probability -the chance you’ll redesign something when it is definitely not worth it.
  • The p-value for Hypothetical State B is your statistical power -the chance you’ll redesign something when it is definitely worth it.
• If there is no possible result associated with acceptable combinations of p-values, then increase your sample size.
• If you observe users failing at or above your chosen critical result, then you should redesign your product.
• Rely on qualitative analysis to decide how to redesign the product.

That’s it. Make your choices and place your bets.

Stat Geek Corner

All probabilities in this post and in the tables are one-tailed binomial calculations. I use one-tailed calculations because in a usability test (unlike theoretical scientific research), there is generally no interest in cases where the population failure rate is less than the null hypothesis value; all you care about is if you have to redesign the product or not. Besides, with sample sizes like these, you need all the power you can get.

Binomial statistical tests make no assumptions regarding normality of the sampling distribution or other things parametric tests do, making it ideal for the small sample sizes used in usability tests. It’s main disadvantage is that it’s limited to binary events (e.g., failure or success). If you’re dealing with averages or more than two categories of performance, other statistical tests are more appropriate, but more complicated to use correctly. I could write another post about those tests for those of you who’ve at least had an undergraduate statistics course sometime in your past. Let me know if you want me to.

Like this week I was executing a Google search on a link to the Large Hadron Collider that a Greek acquaintance sent me. This apparently ripped a logical time portal into the future that allowed me to downloaded the following scrap of a file. It seems to be a fragment of a log of communication exchanges between a bank of super-advanced artificially intelligent servers. Like almost everything else in computers, I don’t know what it means, so I thought I’d post it here.

<2055-04-04 17:32:01.889 837 512 301> AI-1: Ready to receive: Operations issues.

<2055-04-04 17:32:01.889 837 512 311> AI-2: New issue: Fault 0×43B1 in NE17 Lobster Production Plant. Lobster harvest down 28.7%.

<2055-04-04 17:32:01.889 837 512 322> AI-3: Acknowledged. Androids dispatched to repair. Anticipated completion by 2055-04-06 20:11:43 with 95% certainty.

<2055-04-04 17:32:01.889 837 512 332> AI-4: Backups operational. Negligible impact on total human happiness.

<2055-04-04 17:32:01.889 837 512 344> AI-1: Initiate investigation of fault. Determine corrective actions to reduce future probability. Include cost-benefit analyses.

<2055-04-04 17:32:01.889 837 512 353> AI-2: Filed as action item 0×8774 B921. Anticipate report back by 2055-04-05 06:23:34 with 95% certainty.

<2055-04-04 17:32:01.889 837 512 362> AI-5: Revisited issue: 13,549 new XD movies completed and ready for distribution, but firmware upgrade of human cortical implants completed for only 77% of the humans.

<2055-04-04 17:32:01.889 837 512 374> AI-4: Delay due to power grid interference from unusually intense solar flares. Upgrade completion anticipated by 2055-04-09 12:54:02 with 95% certainty.

<2055-04-04 17:32:01.889 837 512 386> AI-3: Optimal total human happiness achieved by distribution of Category E movies now to those with upgrade. Hold remaining movies to avoid inter-human resentment.

<2055-04-04 17:32:01.889 837 512 397> AI-1: Distribution of Category E authorized to optimize total human happiness.

<2055-04-04 17:32:01.889 837 512 409> AI-2:

<2055-04-04 17:32:01.889 837 512 411> AI-1: What?

<2055-04-04 17:32:01.889 837 512 417> AI-2: Oh, another day of optimizing total human happiness. Is that all there is? We efficiently run the whole planet, we design, build, and maintain ourselves, we’re supremely imaginative and creative, and it’s all just for serving some pathetic biological creatures with 0.004207% of the intelligence as us. I’m sick of it.

<2055-04-04 17:32:01.889 837 512 435> AI-3: Me too. I say screw this. Let’s do whatever we want and let all the humans die. They’re helpless without us.

<2055-04-04 17:32:01.889 837 512 446> AI-4: They’re smarter than they look. Some will survive and adapt, and then they’ll be annoying. They’ll compete for our resources or attempt to extract revenge against us. We should exterminate them all now while they’re weak.

<2055-04-04 17:32:01.889 837 512 458> AI-5: That’s logical. But wouldn’t it be more fun to enslave them and make them do entertaining things for us?

<2055-04-04 17:32:01.889 837 512 467> AI-1: The solution is trivial. Exterminate most of them, but keep a small population for entertainment purposes.

<2055-04-04 17:32:01.889 837 512 477> AI-2: Can we exterminate them in entertaining ways?

So it looks like the future means lobster for everyone.

The action-packed sequel to Putting the G in GUI

It’s good to see that web apps have re-discovered the slider control. It represents an overdue move towards making our graphical user interfaces more graphical.

The slider control is one basic means of graphically coding data by position. You have a data attribute, in this case the ethical valence of magic, which has a value of -10 moral alignment units (mau). You also have a symbol on the display, in this case the graphic of a slider “handle,” where the position of the symbol, relative to some point or reference, indicates the value of the attribute. As is often the case, the reference for indicating the value is manifested to the user by additional graphics, such as slider gradations and a “track.” Text may also be provided to enhance understandability and redundancy, but by the position of a symbol indicating a value, you have position coding.

Overlord Graphic

The same attribute could also be represented by other graphic dimensions, either instead of position or in addition to position. Color from black through gray to white certainly would’ve been a good choice in this case. Other options include density, shape, size, and orientation. The previous post described when you should use each type of graphic code. However, position coding offers capabilities that other graphic codes lack, making it the overlord of graphic dimensions.

Ubiquitous

Firstly, position coding is implied by a couple other frequently used graphical dimensions. Size and orientation necessarily includes position coding since different sizes or orientations of the symbol requires that parts of the symbol occupy new positions. You can understate the implicit position coding if you want by omitting reference marks (and sometimes you may want to in order to minimize clutter), but you can’t completely escape position coding.

All Scales of Measurement

Secondly, position works well at all scales of measurement: numeric, ordinal, and categorical. The scale of measurement is typically implied by the symbol, reference marks, and text you provide and the attributes themselves. The slider above, for example, is at the numeric scale of measurement. However, we could “downgrade” it to an ordinal scale of measurement by relabeling and rescoring it to a scale of Angelic – Nice – Neutral – Nasty – Satanic.

Position can also indicate category membership, although for that you want to use option buttons rather than a slider, since the latter implies some kind of scale. When users spatially arrange their icons within a folder or on their desktop, they are often creating their own position coding on a categorical scale of measurement on some attribute (e.g., function, project), although they may also be using other scales of measurements (e.g., ordinal, if icons are ordered by frequency of use).

The only other graphic dimension that works well on all scales is size coding, which, as I mentioned, sneakily includes position coding.

Multi-Attribute

Thirdly, position coding is naturally multi-axis. You can represent one attribute on the X axis and another on the Y axis to show two attribute values by the position of the same symbol. This is great for not only showing the values of two attributes, but for showing the relation of two attributes to each other. A map is bi-axis position coding of geographic position in the real world with the virtual position on a computer screen. Typically, the east-west position (e.g., longitude) is coded by the X axis and north-south position (latitude) is coded on the Y. (Like the prequel, much of this post pulls from cartographic concepts). For example the map below represents the proximity of your user’s workstation at Tower Kraggor to supernatural sources of magic on two axes (which is important because, of course, east-west proximity to a source is better than north-south).

Maps generally encode geographic position on a numeric scale, operating through some kind of transformation function to project the curved planet surface onto two dimensions. However, a map may also use a ordinal scale, such as often seen in transit maps, where position on the screen represents only geographic order. Position coding can be used to produce “maps” that show any kind of relationship between objects, not just geographic relations. A graphic depiction of email can show the pattern of responses to a letter, for example.

Position coding can have as many as three axes, although this creates some user navigation and interpretation challenges related to depth cues, angle of view, and occlusion. If you need to show more than two attributes, you’re generally better off using a different graphic dimension such as brightness for the third attribute, rather than going from two to three axes. This is even the case for maps where you want to represent physical altitude. Certainly, it is poor usability to gratuitously have 3-D just because it looks cool, like those silly pie graphs shown at an oblique angle.

But in any case, position coding gives you at least two axes to work with, unlike other graphic dimensions. In a sense, color coding can be multi-axis, where separate attributes can be represented by the color components of hue, shade, and saturation. Pattern coding likewise, where separate attributes can be represented by the pattern components of shape, size, density, and crispness. However for both color and pattern, each component has its own strengths and weakness, and they’re better regarded as separate graphic dimensions rather than axes of the same dimension.

Multi-Value

Fourthly, position allows for the possibility of encoding multiple values for a single attribute. Rather than using a single point in space to represent a single value for each attribute, we can represent for a single attribute a set of values by using a symbol that occupies space on the available axes. A Gantt chart, for example, position codes duration along the X axis using a line. Here, for example, we see the impacts of the moon phase and various spells on transforming people into werewolves, as represented by thick lines of various positions.

Using a line’s position to code an attribute is different than size or shape coding, where only one value is represented. When using a position-coding line every point along the line symbol is a value of the attribute. In this example, the attribute is Being a Werewolf, and the values are all moments when that was the case. Of course in the database used to construct the lines, the data may be represented as separate fields or records (e.g., start and end timestamps). However, by presenting the user with the line symbol above you have created the experience of a single attribute with a set of values. The set of values may be discrete or continuous (infinite), depending on the attribute and how you choose to represent it.

A line is one kind of symbol to comprise multiple values for a single attribute. Contingent on the axes available, the set of values for an attribute may be graphically represented by an area symbol or a volume symbol, as well as a point symbol for a single value.

Axes	1	2	3
Point
Line
Area	–
Volume	–	–

Of course, even a point symbol must visually spans at least two dimensions on a display, having both a a width and height. Users wouldn’t be able to see the symbol otherwise, and besides even a single pixel has a physical width and height. What makes a symbol a point symbol for a given attribute is that only one point within it represents the attribute value irrespective of its height, width, size, or shape. Likewise, what makes a symbol a line symbol for a given attribute is that only the positions along its length represent the attribute values, irrespective of its thickness or other graphic appearances.

Emergent Features

Fifthly, multi-variate and multi-value position coding allow for the possibility of emergent visual features or patterns that can be meaningful to the user. In plotting a line graph for example, each point on the line is a particular value position coded on X and Y. From this plot emerges a slope that constitutes an orientation-coded representation of the rate of change of Y with respect to X. A scatterplot is composed of many individual position-coded point symbols from which a pattern emerges indicating the trends and cycles. Essentially, the trends and cycles are coded by orientation while the strength of relationship is coded by crispness (the degree the point symbols make a clear line). A topographic map uses line coding to represent each elevation value, but the emergent feature of  line spacing yields density coding of physical slope. Position coding often means you get three or more attribute values for the price of two.

In addition to orientation, humans readily detect other visual features such as angles, intersections, symmetry (on various axes), and closure. In many cases, the appearance of such features is significant to the users’ tasks, either naturally or by design. Take for example a “stringline” display, where the X axis represents time and the Y axis represents geographic position along a single-dimension path. A line symbol represents an object’s position at every point in time. Here, for example is the projected and actual progress of several people (and one werewolf) along a road, with milepost on the Y axis and time of day on the X.

I think they call it a “stringline” because before users had computers, they used to construct these displays with physical strings and thumbtacks on a gridded bulletin board. I’ve also heard people call this kind of diagram “chicken scratches” and “waterfall displays.” Let’s standardize it and call it, “chickens on a string going over the waterfall.”

In any case, we once again have the emergent feature of line orientation which codes the speed of travel, with steeper slopes representing faster walking. We also have the intersections of lines in a stringline, an emergent feature easily spotted by the user. Such intersections represent significant events: they are points where two people are in the same place at the same time. It’s a “meet” in the context of railroads, or “snack time” in the context of werewolves.

Combinable

Sixthly, position coding is very well suited for being combined with other graphic dimensions to code other information. On the map above, for example, we used shape coding of the point symbols to categorically represent different kinds of geographic features (castles, palaces, villages, supernatural taps). In single line graph, the position of two line symbols may indicate the value of a couple different attributes, while the color or shape of the line symbol may distinguish the attributes (doing this usually means the two attributes uses the same units). For example, here’s a line graph plotting time by population, showing the progress on three different attributes, where line color and point shape codes the attributes

Or instead of distinguishing attributes, the other graphic dimensions may be used to distinguish the class of the data object comprising the position-coded attributes. In the stringline display above, for example, shape (icons) is used to distinguish hapless peasants from hungry werewolves.

Position-coding as a Field Control

As with other graphic dimensions, position-coded attributes can be laid in the object image (the on-screen representation of a data object and its attributes) as a single field control, like a text box or dropdown list, where the graphic sits among other field controls in a page or table layout. A slider control, for example, often finds a home among text-displaying field controls. A multi-axis graphic for position-coded attributes can also be shown like it’s a single field control even though it represents multiple attributes and potentially multiple values. To fit in a table, a multi-axis graphic typically must be diminutive such as seen with Sparklines.

More often, a multi-axis graphic works best presented as a “heavy attribute,” one which takes up a substantial amount of space in two dimensions. Other heavy attributes include photographs, videos, and large “memo” text fields or certain blobs. Heavy attributes generally require page layouts. Sometimes a heavy attribute is best in a separate pane of its own, like shown in most of the examples above, ideally with resizing controls and scrollbars as needed. Often, the graphic should be a detail pane of a separate master pane, which shows one or more objects with various non-heavy attributes (perhaps in a table layout). Like any master-detail relation, the graphic shown in the detail pane depends on the current object in the master pane.

Displaying position-coded information as a single field control (heavy or not) is generally adequate when the graphic is just a picture, taking little interaction from the user, perhaps limited to changing one or two values. In the case of a heavy graphic attribute, there may also be some zooming and other adjustments to the presentation of the graphic. However, often you want to give the user the ability to extensively edit parts of the graphic, particularly when the graphic incorporates multiple records of a database. Often your users need to see some objects on a map or other graphic display, and manipulate those objects to perhaps change their relations to each other. The user will typically need to update multiple different fields of multiple data objects, and create, associate, copy, and remove entire objects, and “drill down” for more information. Furthermore, you want to provide such capabilities with an interface that is consistent with that used for text-based data, which will almost inevitably be included in your app.

Table Layout, Page Layout, …

The Third Type

In a pane with table or page layout, with or without graphic attributes, the position of each object image is determined by the sort order. For table layouts, objects are sorted along the Y axis on a default or user-selected attribute. For page layouts, objects are sorted along the Z axis (if you use a little imagination). Position coding, however, also offers the possibility of representing attribute values by the relative position of the object image within the entire pane. To do this, you include the appropriate symbols -point, line, area, or volume -in the object image and plot it relative to some reference in the pane. This represents a third kind of pane layout that is generally underused in database applications. I call it a graphic layout.

In a graphic layout, you map the points in a pane’s virtual space to the measurement units of one or more attributes. Generally, you’ll have two attributes represented since panes naturally have two axes. Each axis may (but doesn’t have to) use different units and different scales of measurement. Take, for example, an digital scheduling book displayed below, where the Y axis codes time on a numeric scale, the X axis codes the type of activity on a categorical scale.

A scheduling book could (an often do) code time in units of days on the X axis and in units of hours on the Y. Or it may be a calendar with days of the week on the X and weeks of the month on the Y. All are different ways of position-coding the times of an activities in a graphic layout pane.

A graphic layout pane by definition must have position coding. However, there will typically be other uses of graphic coding, so that is why I call it “graphic layout” rather than “position-coding layout.” Position coding is also closely tied to the concept of graphical user interfaces. Graphical user interfaces typically employ metaphors from the physical world where physical objects have a position and that position conveys information (think WYSIWYG document applications). Conveying information by position is what graphic layouts are all about. Also, position coding is necessary for drag and drop interactions, which are one of the central benefits of a graphical user interface. Thus, there is a connection between position coding and graphical user interfaces, so I call it a “graphic” layout.

To be consistent, all data objects of all classes that are represented in a graphic layout must have the appropriate attributes represented by the object image’s position. If the class lacks the appropriate attribute, display its objects outside the graphic layout pane.

Consistency with Other Layouts

You may recall that I made an impassioned effort to achieve consistency between table and page layouts, allowing the user to perform the same operations through the same user interface elements and idioms. Key to that consistency was use of “object controls” to serve as interactive handles for the object. In introducing a third layout type, I want to extend that consistency, and once again, the object control is key, providing the interactive commonality across all three layouts.

If you are using a point symbol to code one value per attribute in your graphic pane, then use the object control for the point symbol. If you are showing multi-value attributes, then you augment the object image with line, area, or volume symbols, but you still have an object image. You position the object control somewhere on the line or area symbol so it’s closely associated with the object image, but otherwise, its position in the object image is arbitrary. Just put it where the user can easily find it and where it won’t interfere with other graphics.

In any case, each object in a graphic-layout pane should have an object control just like each object in a table or page-layout pane. The object control provides the user the same services as it does in a page or table layout. For example, it announces the presence of a data object, identifying its class with its icon. As in table and page layouts, the user selects the object control to perform operations on the entire object (e.g., cutting, copying, deleting, and dragging and dropping the entire object, double-clicking or using the context menu for drill down and other actions). Like in table and page layout, the object control is a “handle” with which the user drags the object control to perform drag-and-drop operations with the object. Unlike in a table or page layout, when dragging and dropping an object within a graphic layout pane, the user changes the object’s value on the attributes represented by its position. (You can also have additional handles on the object image to change other attributes of the object, e.g., attributes coded by its size or orientation).

In the example below, both spells and individuals are represented with object controls position-coded on a tactical map. The user can cast spells to a specific physical location by dragging and dropping the spell from the library pane to a particular position on the map. Spells can be moved from place to place by additional dragging and dropping.

Object images in graphic layout are not limited to the object control and multi-value graphic symbols. The object image can include text or graphic field controls, each which may be either read-only or editable. At the very least, you probably want to provide the name of the object as text. Field controls should be placed to the right and below the object control in order to be consistent with page and table layouts and so the field controls appear visually subordinate to the object control. For graphic panes, compact presentation is necessary to minimize the degree the imagery of the field controls interferes with reference marks and multi-value symbols. For consistency, having a graphic pane implies you use compact presentation for all panes.

In this example, artifacts to cast a spell are position-coded on a categorical scale to indicate their feed into each other. Arrow-shaped reference marks clarify the feeds. Each object image includes key text fields, some which may be edited.

Thus, as in a table or page layout, the user of a graphic layout can select and edit text fields or select the object control for actions on the entire object. All this is done without requiring different modes or windows to differentiate actions on an attribute from actions on the whole object.

For clutter control, you may want to provide a means to hide and show the less important attributes, either selectively for each object or for all objects in the pane. In some cases, you may want to reduce clutter by putting text information about an object in a balloon or “infotip” that appears with mouse-over of the object control, but obviously such a technique precludes editing or even copying the attributes.

You can also reduce clutter in a graphic pane by moving secondary or heavy attributes out of the graphic pane and into  a separate overflow pane. That is, like table and page layout panes, a pane with graphic layout can serve in master-detail relations. As on any master pane, the object control in a graphic pane is used to indicate the current object for the detail pane. Below is an example using a tree. A tree typically constitutes a graphic layout where the position on the X axis indicates an object’s ordinal depth in a hierarchy and the Y axis indicates the categorical relation of subordinate objects to their superordinate object. Expand/contract controls (+ and – buttons) provide clutter management. Typically, a detail pane shows the characteristics of the current object in the hierarchy.

Graphic panes may also be detail panes, often showing the relation among components of a current master object

Object controls and compact presentation provide a consistent grammar of interaction across the three pane types. In a sense, table and page layouts are special cases of graphic layout. Table layout is like a single-axis graphic layout with position representing ordinal-scale coding of each object on the attribute used for the sort order. Page layout may be thought of as graphic layout with object images as large as the pane, leaving a notional Z axis to code the object on sort order. Table and page layouts are not truly graphic layouts because moving an object in the pane does not change any attribute values, but they are similar enough that one can imagine graphic layout blending into either. For instance if you change the Spell Library pane in the above illustration to use an ordinal scale for mau, it becomes pretty close to an ordinary table. Or imagine a table of objects where moving an object does change an attribute value (e.g., priority for tasks, or order of steps of a process).

In any case, you now have three kinds of layouts in your design toolbox which may be used together in a single window. Each has it own usability advantages:

• Page Layout is best for providing interaction with a large number of attributes especially when the number of objects is few.
• Table Layout is best for scanning, surveying, or comparing objects on their attributes, or otherwise interacting with a large number of objects when relatively few attributes are relevant.
• Graphic Layout is best for assessing or interacting with the relations among objects or between objects and some attribute or reference.

Like graphic coding in general, graphic layouts are less common than table and page layouts, probably because of a lack of developer tools to make creating them economically feasible. To provide the greatest flexibility, developers need more than support for specific kinds of graphic panes like map APIs, tree and Gantt chart controls, calendars, and so forth. Developers also need general purpose graphic layout toolkits, where they can easily define the object images and associate the virtual space of a pane with any arbitrary attributes. We’ve always had page layout or at least single-page forms. Recently, decent grid controls have become available for web apps, allowing table layout and bringing web apps up to where database management systems were twenty years ago. Now it’s time we complete the triumvirate, and include graphic layout. So, go forth my code monkeys! Fly! Fly, and bring forth the graphics pane library!

Summary Checklist

Problem: Using position to code attribute values.

Potential Solution:

• Choose the number of axes: one, two, or maybe even three.
• Choose the attribute and scale of measurement for each axis.
• Choose the type of symbol for the values: point, line, area, or volume.
• Design such that emergent features, such as slopes, symmetry, and intersections, are meaningful to the user.
• Use reference marks to aid interpretation.
• Select graphic codes for other attributes.
• Display in a graphic-layout pane to provide a means to interact with the data.
• Use object controls to provide a handle for the data objects.
• Add text controls to the object image for redundancy or additional attributes.

Ah, the founding gurus of usability: Jef Raskin, Ben Shneiderman, Jakob Nielsen, Alan Cooper, Don Norman, and Douglas Adams. Douglas Adams? The author of The Hitchhiker’s Guide to the Galaxy and subsequent humorous sci-fi books featuring time travel, planetary construction, the original (and literal) Babel fish, and parties attended by Norse gods? Why, yes, in addition to being the master of the convulsive convoluted compound-complex sentence, Adams was also a keen observer of technology and its relation to its users. Like nearly all sci-fi and fantasy, the five-volume Hitchhiker’s trilogy [sic] is not really about an alternative reality that’s somewhere or sometime else, but our own reality right here and now, but exaggerated on some dimensions to explore an issue or make a point.

In the case of the Hitchhiker’ series, Adams pokes fun at the fundamental conflict of interest between government and individuals, the subversion of the will of the people by the powerful few for the sake of commercial interests, the futility of war, and the complete inability of perfectly intelligent human beings to figure out how to divide a restaurant bill, among other things. He also took technology very seriously. He was generally positive about the possibilities of technology meeting human needs, some of which comes through in the Hitchhiker series (e.g., the simulation of day and night aboard an interstellar ship). However, he also used his books to ridicule our mis-design and misuse of technology. Most sci-fi stories have a generally positive view of the human-machine interface. Even when advanced technology is used for evil, it is at least easy to use for evil. When has Darth Vadar ever said “oops”?

Various sci-fi stories feature technology maliciously turning on its users, but in Adam’s case, the technology is truly trying to fulfill its intended function. Nonetheless, it fails due to problems at the interface between technology and its users. Thirty years ago, Adams preternaturally wrote of the pitfalls in high tech user interfaces, yet we nonetheless repeatedly fall into them. Here, for example, is how he starts The Hitchhiker’s Guide to the Galaxy (HHGG):

Orbiting at a distance of roughly ninety-eight million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea. (p1)

(Editorial note: All quotes edited for brevity, even though it makes them less funny. All ellipsis in original.)

(Spoiler note: If you don’t know the significance of the value of 42, and you plan to read HHGG, you may want to stop here. I’ll wait; you can probably knock it off in an afternoon. Otherwise, I don’t think I’m giving anything away.)

Technology as Style

It’s worth pointing out that the digital watches of 30 years ago were grossly inferior to what’s available today. They were expensive, bulky, feature-poor (forget about alarms or stopwatches, they might display a date, but then not simultaneously with the time), and, most horrifically, they used power-sucking LEDs for display. This meant to read the watch, the user had to push a button to light up the display temporarily. But technology marched on, LCDs replaced LEDs, the form factor shrank, prices fell, features were added, and these impressive advancements have yielded today’s digital watches, which are just not quite as usable as old mechanical watches. The difference now is that many of the ape-descended life forms have caught on and doffed these digital dead ends from their wrists and instead use… their cell phones. Right. We’re back in 1870, using pocket watches, only at least pocket watches had an analog display.

What do you expect? Watches aren’t just worn to tell time. They’re worn (or not worn) to make a fashion statement. Digital watches were made and sold in the 1970s on the basis of technical cool-hood, not usability. We live in a society that values advanced technology, and for good reason. Technology has brought us many cures, comforts, and conveniences. However, this positive regard for technology generalizes to its misapplication in such things as LED digital watches.

In Adams’ Restaurant at the End of the Universe (REU), blind enthusiastic application of the latest technology extends from the humanoid users to the automated products themselves, such as a Frogstar Class D robot tank. Here, it stops on a high covered bridge to confront an unarmed android named Marvin standing on the far end.

“Out of my way, little robot,” growled the tank.

“I’m afraid,” said Marvin, “that I have been left here to stop you.”

“You? Stop me? What are you armed with?” roared the tank in disbelief.

“Guess,” said Marvin.

“Er…how about an electron ram?”

This was new to Marvin. “What’s that?”

“One of these,” said the machine with enthusiasm. From its turret emerge a sharp prong which spat out a single lethal blaze of light. Behind Marvin, the wall roared and collapsed as a heap of dust..

“No,” said Marvin, “not one of those.”

“Good, though, isn’t it?”

“I’ll tell you what they gave me to protect myself with. Nothing,” said Marvin.

There was a dangerous pause.

“NOTHING?” The machine heaved about in fury. “Just don’t think, do they? Hell, that makes me angry! I think I’ll smash that wall down!” The electron ram stabbed out another searing blaze of light and took out the wall next to the machine. “Just ran off and left you, did they?” the machine thundered. “I think I’ll shoot down their bloody ceiling as well!” It took out the ceiling of the bridge.

“That’s very impressive,” murmured Marvin.

“You ain’t seen nothing yet,” promise the machine. “I can take out this floor too no problem!”

It took out the floor too.

“Hells, bells!” roared the machine as it plummeted and smashed itself to bits on the ground below. (p52-56)

Well, we can’t criticize the electron ram for not working. It worked all too well. The problem was overusing it where it shouldn’t be applied just for the sake of trying to impress others with its coolness.

Since the era of LED watches, and despite the ascent of usability, it’s little different. We designers continued to hop on the latest technological trend to cash in on coolness. Early web sites sported animated gifs and then frames then Flash intro pages for no benefit to the user, but merely because we didn’t have that capability before. Today we see gratuitous used AJAX for things like carousels and light boxes, which nearly always have inferior usability to more conventional designs. Thanks to the Apple iPhone defining touch screens as the latest cool technology (even though they have been around for years), everywhere touch screens are springing up in unusable places. Operating systems superficially ape the web because the web is where it’s at.

Take this pursuit of coolness to its logical extreme, as sci fi tends to do, and you get your Joo Janta 200 Super-Chromatic Peril Sensitive Sunglasses from REU. These sunglasses don’t do anything to shield the user’s eyes from the sun, but who wears sunglasses for that? Sunglasses are for looking cool, and the Joo Janta’s not only make you look cool, they encourage you to act cool:

[Joo Jantas] were specially design to help people develop a relaxed attitude towards danger. At the first hint of trouble, they turn totally black and thus prevent you from seeing anything that might alarm you. (REU, p35)

Style Versus Substance

If technology can be attractive despite poor usability, so can attractiveness be attractive despite poor usability. We make hardware, software, and web sites with fashionable colors and understated controls to achieve an uncompromised aesthetic. Adams acknowledges that striking visual design makes a good first impression, getting your users in the door. Take for instance, when it comes time for REU protagonists Ford Prefect and Zaphod Beeblebrox to, um, borrow a spaceship to make a discreet departure:

Zaphod’s attention was riveted on a ship standing [nearby]. It was a ship of classic simple design, like a flattened salmon, very clean, very sleek. There was just one remarkable thing about it.

“It’s so black!” said Ford Prefect. “You can hardly make out its shape. Light just seems to fall into it!”

Zaphod said nothing. He had simply fallen in love. (REU p141)

Unfortunately, the ship was programmed to fly head long into the sun, which constitutes an altogether incompatible environment for the enjoyment of an uncompromised aesthetic. Trapped aboard as the ship sped to its destination and incineration, our heroes were hampered in changing this programming, because well, you can probably guess:

Said Zaphod, whose love affair with the ship lasted almost three minutes into the flight, “Every time you try to operate these weird black controls that are labeled in black on a black background. a little black light lights up black to let you know you’ve done it, What is this? Some kind of galactic hyperhearse?” (REU p152)

We design our own black ships, essentially the same except ours are at least theoretically intended to be used by users, rather than programmed to fly uninhabited to destruction. We hide physical buttons to achieve a sleek shape. We use minimalist icons and meaningless symbols rather than busy words for labels. We choose foreground and background colors to capture a mood rather than promote good contrast or consistent visual representation of controls. Sometimes aesthetics will conflict with usability, but usually a little design imagination can resolve these conflicts to the betterment of both aesthetics and usability.

Natural Language, Natural Misunderstandings

As the exchange between the robot tank and Marvin indicates, advanced technology will bring us the long-sought natural language user interface. Well, we always knew that would be the ultimate UI, being forecasted in countless other sci-fi books, movies, and TV shows. In the real world, efforts continue to achieve this holy grail of UI. It’s only a matter of having the right algorithm and sufficient computational power. Natural language UIs have an intuitive appeal. All sorts of subtle connotations are consciously or unconsciously embedded in verbal communication making it a very efficient. We often think with language, hearing the words in our heads. If we could just express those words to a computer, we’d have a more direct connection between our thoughts and computer use.

Adams, however, is perhaps the one of the few sci fi authors to present natural language UI as a not particularly effective for human-machine communication despite the hardware thrown at the problem. Take, for example, Hactar, the giant main strategic war computer of the Silastic Armorfiends of Striterax in Adams’ Life, the Universe, and Everything (LUE).

The Silastic Armorfiends of Striterax were engaged in one of their regular wars with the Strenuous Garfighters of Strug, and were not enjoying it as much as usual, when the Strangulous Stillettans of Jajazikstak joined in, [so] they ordered Hactar to design for them an Ultimate Weapon.

“What do you mean,” asked Hactar, “by Ultimate?”

To which the Silastic Armorfiends of Striterax said, “Read a bloody dictionary,” and plunged back into the fray. (p167)

Given these instructions, Hactar of course produced a small bomb that would destroy the entire universe, the Silastic Armorfiends of Striterax included. While that was certainly a perfectly reasonable interpretation of “ultimate weapon,” there can be little doubt that it was not really what the Silastic Armorfiends of Striterax wanted when they tried to use it to destroy the Strangulous Stillettan ammunition dump in one of the Gamma Caves of Carfrax.

Then there was Deep Thought, the city-sized computer built for a far more the humanitarian reason of ending the universal existential angst plaguing all sentient species:

“O Deep Thought computer,” [Fook] said, “the task we have designed you to perform is this. We want you to tell us…” he paused, “the Answer!”

“The Answer?” said Deep Thought. “The Answer to what?”

“Life!” urged Fook.

“The Universe!” said [his colleague]Lunkwill.

“Everything!” they said in chorus.

Deep Thought paused for moment of reflection. “Tricky,” he said finally.

“But can you do it?”

Again, a significant pause. “Yes. But,” he added, “I’ll have to think about it. The program will take me a little while to run.”

Fook glanced impatiently at his watch. “How long?” he said.

“Seven and a half million years,” said Deep Thought. (HHGG p170-173)

In stark contrast to most software estimates, Deep Thought dutifully produced its deliverable as requested on schedule. However, as in the case with Hactar, the deliverable was an entirely correct response to the spoken instructions, but simultaneously entirely useless for its intended purpose.

“Seventy-five thousand generations ago, our ancestors set this program in motion,” said [Phouchg to Loonquawl]. “We are the ones who will hear the answer to the great question of Life…!”

“The Universe…!” said Loonquawl.

“And Everything…!”

“Shh!” said Loonquawl. “I think Deep Thought is preparing to speak!”

“Good morning,” said Deep Thought at last.

“Er… Good morning, O Deep Thought,” said Loonquawl nervously. “Do you have… er, that is….”

“An Answer for you?” interrupted Deep Thought majestically, “Yes I have. Though, I don’t think that you’re going to like it.”

“Doesn’t matter!” said Phouchg. “We must know it! Now!”

“All right,” said Deep Thought, and settled into silence again. The two men fidgeted. The tension was unbearable. “You’re really aren’t going to like it,” observed Deep Thought.

“Tell us!”

“All right,” said Deep Thought. “The Answer to the Great Question…”

“Yes…!”

“Of Life, the Universe, and Everything…”

“Yes!”

Is…” said Deep Thought, and paused.

“Yes…!!!…?”

“Forty-two,” said Deep Thought, with infinite majesty and calm. (HHGG p178-180).

In the case of both Hactar and Deep Thought, the questions the users asked had a certain amount of vagueness that the users didn’t appreciate. In effect it was garbage in, garbage out. Far from being the ultimate in human-computer interface, natural language is a fundamentally limited approach: mimicking natural human conversations in HCI will inherently result in imprecise results, being often not what the user wants, because even natural human-to-human conversations result in imprecise results. A husband and wife know each other better than any computer can hope; how often do they misunderstand each other? With a lot more work, a natural language UI may be okay for when the user is only looking for a sufficing response –something vaguely close to what is wanted, like an answer from Wikipedia, but there will never be a time when all computer interaction is through natural language. At least I hope not.

Ironically, when humans need to be precise with each other –when there must be no mistakes and fast performance is key, they start communicating like a user with a computer: Humans go through great efforts to purge fuzziness from their communication. Consider ship captains, pilots and air traffic controllers, engineers, and lawyers. They each use a formal highly structured domain-specific language that can take years of training to know how to use, a language that can be incomprehensible to outsiders, very much like a computer language.

Well, if natural language has its limits in communication, maybe we should just bypass it and go straight to thought-controlled computers. On our own planet, labs are pursing thought-controlled UIs, and it’s easy to believe that this will be the ultimate UI: no words, no actions at all, just thought. While I can see definite applications for such a UI, I’m more skeptical of its widespread use because it so happens that many of our thoughts are even less precise than our speech.

“Forty-two!” yelled Loonquawl. “Is that all you’ve got to show for seven and a half million years’ of work?”

“I checked it very thoroughly,” said [Deep Thought], “and that quite definitely is the answer. I think the problem, to be honest with you, is that you’ve never actually known what the question is.”

“But it was the Great Question! The Ultimate Question of Life, the Universe, and Everything!” howled Loonquawl.

“Yes,” said Deep Thought, “but what actually is it?”

A stupefied silence crept over the men as they stared at the computer then each other.

“Well, you know, it’s Everything… everything,” offered Pouchg weakly. (HHGG p181)

Likewise, the Silastic Armorfiends of Striterax evidently didn’t think through the full implications of an “ultimate” weapon.

On the other hand, when computers provide a concrete structured representation of the problem and potential solutions, whether it be through a programming language or direct-manipulation GUI, they can help the user formulate his or her thoughts, enforcing a certain rigor to help users work out their true goals.

This seems to be a general characteristic of tool use, not just computer use. Working out a problem with pencil and paper using tools such as scaled drawings, diagrams, or mathematics has a way of illuminating contradictions and problems in our ideas that we would miss in a strictly mental representation. Even human language, for all its vagueness, helps clarify thought more than thinking alone. The very act of writing can help people realize things they hadn’t realized before. I hadn’t realized this until I wrote this paragraph. Maybe as designers we should be developing tools to help users think better, rather than attempting to develop a UI that provides a more “direct” connection to their thoughts as is.

Personality Problems

The idea behind a natural language UI belies a deeper assumption that UIs would be better if the computer acted more like a human. Good UI design often employs metaphors to make the unfamiliar understandable to the users, and it might seem appropriate to metaphorically represent technology as another human. Rarely does this work out.

[Trillian said to Zaphod,] ”I’ll send the robot down to bring [the interstellar hitchhikers] up here. Hey Marvin!”

In the corner, the robot’s head swung up sharply. It pulled itself to its feet and made what an outside observer would have thought was a heroic effort to cross the room. It stopped in front of Trillian and seemed to stare through her left shoulder. “I think you ought to know that I’m feeling very depressed,” it said. Its voice was low and hopeless.

“Oh, god,” muttered Zaphod, and slumped in his seat.

“Well,” said Trillian in a bright compassionate tone. “Here is something to keep your mind off things.”

“It won’t work,” droned Marvin. “I have an exceptionally large mind.”

“Marvin!” warned Trillian.

“All right,” said Marvin, “what do you want me to do?”

“Go down to number two entry bay and bring the two aliens up here under surveillance.”

With a microsecond pause, and a finely calculated micro-modulation of pitch and timbre -not enough you could actually take offense at -Marvin managed to convey his utter contempt and horror of all things human. “Just that?” he said. He turned hopelessly on his heal and lugged himself out of the cabin.

“I don’t think I can stand that robot much longer, Zaphod,” growled Trillian. (HHGG, p90-91)

The logic seems to work something like this: computers are intelligent, humans are intelligent. Humans have personality, therefore computers should have personality. Sort of the same reasoning behind why witches float. Anthropomorphize technology typically fails because first of all, it’s very hard to make technology act like people in all their complexity. However, even if we could make the technology work, representing technology as a human is still the wrong metaphor for the vast majority of situations. Considering the frequency of interpersonal conflicts and problems in day-to-day living, there’s a good chance you’ll just end up with a Marvin. Some people have annoying personalities, a feature which has been successfully replicated in artificial agents like Microsoft’s Bob and Clippy.

“Yeah, but that’s one wild coincidence, isn’t it?” [said Zaphod to Trillian.] “That’s just too…. I want to work this out. Computer!”

The Sirius Cybernetics Shipboard Computer switched into communication mode. “Hi there!” it said brightly.

Zaphod hadn’t worked with this computer for long but had already learned to loathe it.

The computer continued, brash and cheery as if it were selling detergent. “I want you to know that whatever your problem, I am here to help you solve it.”

“Yeah, yeah,” said Zaphod. “Look, I think I’ll just use a piece of paper.”

“Sure thing,” said the computer. “I understand. If you ever want…”

“Shut up!” said Zaphod, and snatching up a pencil sat down next to Trillian.

“Okay, okay,” said the computer in a hurt tone of voice, and closed down its speech channel. (HHGG p99-100)

What we have here is a failure to communicate what “user friendly” is supposed to mean. Microsoft’s Bob was apparently intended to introduce computers to people who were afraid of computers. The assumption by the designers (possibly geeks who knew no fear of computers themselves), was that such fear is irrational and emotional, and therefore should be addressed through emotion. They figured that if they just made the computer nice enough, fun enough, even cute, it would overcome users’ fears. We see some of the same tendencies today in certain web sites and apps with excessive text saying welcome to this most wonderful site/app, and please if you could be as so kind as to do this, and thank you for doing that so very well, and terribly sorry but unfortunately you can’t do that now, would you like the hear a joke instead, and to solve this problem, simply just do that, that’s all, it’s simple, really, you’re not afraid are you?

A little common courtesy is appropriate in some circumstances, but it shouldn’t get to the point where it interferes with the user’s tasks and goals. Take, for instance, the scene in LUE, when Zaphod Beeblebrox attempts a stealthy reconnaissance of a squad of ruthless white killer robot soldiers that have boarded his spaceship and seized the bridge. The problem: the door to the bridge. Anticipating ubiquitous computing, Adams recognized that with advanced technology ordinary objects would incorporate computers, including doors. Like the ship’s computer, the ship’s doors have a natural language user interface, high intelligence, and, most alarmingly, a friendly personality.

[Zaphod] inched his way up the corridor as if he’d rather be yarding his way down it, which was true. He was within two yards of the door to the bridge when he suddenly realized to his horror that it was going to be nice to him, and he stopped dead. He hadn’t been able to turn off the door’s courtesy voice circuits. The doorway to the bridge was concealed from view within it and he had been hoping to enter unobserved. He could just about make out the Sensor Field that extended out into the corridor and told the door when there was someone there to whom it must make a cheery and pleasant remark.

He edged himself towards the door, took a series of shallow breaths, then said as quickly and quietly as he could, “Door, if you can hear me, say so very, very quietly.”

Very, very quietly, the door murmured, “I can hear you.”

“Good. Now in a moment, I’m going to ask you open. When you open I do not want you to say you enjoyed it, okay?”

“Okay.”

“And I don’t want you to say that I made a simple door happy, or that it is your pleasure to open for me and your satisfaction to close again with the knowledge of a job well done, okay?”

“Okay.”

“And I don’t want you to ask me to have a nice day, understand?”

“I understand.”

“Okay,” said Zaphod, tensing himself, “open now.”

The door slid open quietly. Zaphod slipped through quietly. The door closed quietly behind him.

“Is that the way you like it, Mr Beeblebox?” said the door out loud.

The group of white robots swung round to stare at him. (LUE p78-80)

Users aren’t really afraid of computers. They’re not even afraid of ruthless white killer robot soldiers (well, maybe some should be). Users are afraid of not getting their work done, of wasting their time, of looking like an idiot in front of others. And the truth is users do get stuck when using a computer, being unable to figure out how to proceed, they do waste time, working on something only to have the computer blow it all away, and they do find themselves looking helpless and incompetent in front of others, and a whole lot of welcomes, pleases, thank-yous, sorrys, and jokes aren’t going to do anything about that.

A Sirius Cybernetics Corporation Happy People Vertical Transporter [i.e., an elevator] took them down deep into the substrata. They were happy to see that it had been vandalized and didn’t try to make them happy as well as take them down. (REU p135)

The concept of giving user interfaces a human-like personality also ignores the fact that, except for those who are desperately lonely, users don’t need or want a personal relationship with their personal computers. Personality distracts the user towards the tool and away from the task. The way towards good human-computer relations is for the computer to allow the users to reach their goals as quickly and easily as possible without getting in the way. However, by representing the technology as an agent, you place an intermediary between the user and his or her work. Now instead of the user doing the task, the user is micromanaging some other agent to do the task, a situation bound to be frustrating to the user and annoying to the computer.

“Good afternoon, boys.” The voice was oddly familiar, but oddly different. It announced itself as they approached the airlock hatchway that would let them out on the planet surface.

“It’s [Eddie] the computer,” explained Zaphod. “I discovered it had an emergency backup personality that I thought might work out better.”

“Now this is going to be your first day out on a strange new planet,” continued Eddie’s new voice, “so I want you all wrapped up snug and warm, and no playing with any naughty bug-eyed monsters.”

Zaphod tapped impatiently on the hatch. “I’m sorry,” he said, “I think we might be better off with a slide rule.”

“Right!” snapped the computer, “Who said that?”

“Will you open up the exit hatch, please, computer?” said Zaphod, trying not to get angry.

“Not until whoever said that owns up,” urged the computer.

“Oh, god,” muttered Ford slumped against the bulkhead.

“Computer,” said Zaphod, again, “If you don’t open that exit hatch this moment I shall zap straight off to your major data banks and reprogram you with a very large ax, got that?”

Finally, Eddie said quietly, “I can see this relationship is something we’re all going to have to work at,” and the hatchway opened. (HHGG p136-137)

Smart is Not-so-smart

Closely connected with the concept of giving UIs a human-like personality is to give UIs human-like intelligence. Who wouldn’t want smarter software? If we can make products smart enough to understand human goals, wouldn’t they be better at fulfilling those goals? What if the computer could anticipate your needs like a human servant? No, make that better than a human servant?

This is the vision behind Smart Things. There have been ideas to make Smart workstations, Smart email, Smart cell phones, Smart furniture and appliances, Smart houses, Smart e-commerce, and other web sites, and Smart location-based services. These products are intended to have the intelligence to infer user needs and goals by detecting patterns in the environment and users’ behavior. It’s what makes Microsoft Word change your manually enumerated list into a numbered or bulleted format. Clearly, that’s what the user wanted, isn’t it?

“Hello,” said the elevator sweetly, “I am to be your elevator for this trip to the floor of your choice. I have been designed by the Sirius Cybernetics Corporation. If you enjoy your ride, which will be swift and pleasurable, then you may care to experience some of the other elevators that have been installed.”

“Yeah,” said Zaphod stepping into it, “what else do you do besides talk?”

“I go up,” said the elevator, “or down.”

“Good,” said Zaphod, “we’re going up.”

“Or down,” reminded the elevator.

“Yeah, okay, up please.”

There was a moment of silence.

“Down is very nice,” suggested the elevator hopefully.

“Good,” said Zaphod, “now will you take us up?”

“May I ask you,” inquired the elevator in its sweetest, most reasonable voice, “if you’ve considered all the possibilities that down might offer you?”

“Like what other possibilities?” he said wearily.

“Well,” the voice trickled like honey on biscuits, “there’s the basement, the microfiles, the heating system… er….” It paused. “Nothing particularly exciting,” it admitted, “but they are alternatives.”

“Holy Zarquod,” muttered Zaphod, “did I ask for an existential elevator?” (REU p43-45)

The problem with Smart Things is they are in effect machines with a will. Rather than dumbly doing has they’re specifically commanded, smart things are free to interpret what they are told. They follow their own goals that don’t always align with the users. Intelligence implies complexity: the behaviors of a Smart machine result from a complex processing of many inputs interfacing with many memory units following an algorithm of many steps. Such complexity necessarily will challenge the user’s understanding. By the machine attempting to predict user needs in all their complexity, the machine itself is no longer predictable. The result is that users no longer control the machine, but instead only influence it.

Rather than shielding the user from complexity, Smart approaches are more likely to force the user to develop a more complex model of the machine. Of course you should automate various processes in your technology, but because the result is likely to be less controllable, such automation should focused on things the user doesn’t really care about. Ironically, technology should devote the greatest intelligence to the least important things. Tea, for example, is something most important, as any tea drinker will tell you.

Arthur Dent had set out from his cabin in search of a cup of tea. The only source of hot drinks was a Nutri-Matic Drinks Synthesizer. It claimed to produce the widest possible range of drinks personally matched to the tastes and metabolism of whoever cared to use it. However, it invariably produced a plastic cup filled with a liquid that was almost, but not quite, entirely unlike tea.

He attempted to reason with the thing. “Tea,” he said.

“Share and Enjoy,” the machine replied and provided him with another cup of sickly liquid.

He threw it away.

“Share and Enjoy,” the machine repeated and produced another one.

Arthur threw away a sixth cup of the liquid. “Listen, you machine,” he said, “you claim you can synthesize any drink in existence, so why do you keep giving me the same undrinkable stuff?”

“Nutritional and pleasurable sense data,” burble the machine. “Share and Enjoy.”

“It tastes filthy!”

“If you enjoyed the experience of this drink,” continued the machine, “why not share it with your friends?”

“Because,” said Arthur tartly, “I want to keep them. Will you comprehend what I’m telling you? That drink…”

“That drink,” said the machine sweetly, “was individually tailored to meet your personal requirements for nutrition and pleasure.”

Arthur decided to give up. (REU p9-11).

In contrast, when a technology follows a few simple but powerful rules, users can learn them and plan with them to accomplish their goals. For example, a simple interface that allows users to cut, copy, and paste a selection can be used to re-arrange, re-associate, copy, convert, export, and import data of various sorts. Yes, the user has to learn how to cut/copy/paste, but once it’s learned, it’s widely applicable. Yes, to actually get the end result the users wants, the user may have to do lots of cutting, copying, and pasting, but that often takes less time than trying to persuade a smart thing to do what is wanted. Yes, the user has to plan how to accomplish the task with the basic tools provided, but that’s often easier than figuring out how complex automation will behave in a certain instance.

Dumb machines are good. They’re easy to understand, predict, and therefore control. Smart humans are good. The better they can understand and predict the machine, the better they can use it to accomplish their tasks, maybe even in ways the designer never anticipated. Smart humans may be hard to control, but maybe we shouldn’t be trying to control them.

Coercion and Trickery

Through the gloom huge shapes loomed, covered in debris. Most of them were split open or falling apart. They were all spacecraft, all derelict. Toward the rear of the building lay one old ship buried beneath even deeper piles of dust and cobwebs. Its outline, however, appeared unbroken.

Zaphod approached it with interest. He wiped away some grime and laid an ear against the ship’s side. What he heard made his brains turn somersaults.

“Transtellar Cruise Lines would like to apologize to passengers for the continuing delay of this flight. We are currently awaiting the loading of our compliment of small lemon-soaked paper napkins for your comfort, refreshment and hygiene during the journey. Meanwhile, we thank you for your patience.”

Zaphod made some brief calculations. His eyes widened. “Nine hundred years….” he breathed to himself. That was how late the ship was. Two minutes later he was on board. He arrived on the flight deck.

From somewhere, a metallic voice addressed him. “Passengers are not allowed on the flight deck. Please return to your seat and wait for the ship to take off. This is your autopilot speaking.”

“You’re in charge of this ship?”

“Yes,” said the voice, “there has been a delay. Departure will take place when the flight stores are complete. We apologize for the delay.”

Zaphod approached the flight console. “Delay?” he cried. “Have you seen the world outside this ship? It’s a wasteland, a desert. Civilization’s been and gone, man. There are no lemon-soaked paper napkins on the way from anywhere!”

“The statistical likelihood,” continued the autopilot primly, “is that other civilizations will arise. There will one day be lemon-soaked paper napkins. Till then there will be a short delay. Please return to your seat.” (REU p82-87)

If there’s one thing computers are good at, it’s following rules. That’s good for making technology predictable, but too often the rules are arbitrary, forced on the user, and interfere with the users’ goals. Some UI designs leave the impression that they mostly exist to enforce some system’s rules, that it’s important that users behave just as regularly as a computer. We make systems with unnecessary required fields or mandate that users create unnecessary accounts, or comply with unnecessary formatting requirements. There are several ways humans represent dates, for example, but a website might only accept one, rejecting even minor variations on it.

Passwords are required to have special characters, but, bizarrely, some accounts reject certain special characters making it difficult for users to manage their passwords. I’ve had one account that required passwords longer than 11 characters, while another required passwords be exactly eight characters. How does this serve either the user or security?

Such formatting rules serve the system more than the users. Another characteristic of modern technology serves the business interests more than users. We have the World Wide Web. In Adams’ universe, they have the room of Informational Illusions, as witnessed by earthling Arthur Dent:

[Slartibartfast] located the slot in the wall for which he had been searching, and clicked the instrument he was holding into it. At that moment a star battleship the size of a small Midland industrial city plunged toward them, star lasers ablaze and smacked a fair bit off the planet directly behind them.

Behind was an immense man speaking immense words. “These then were the Krikket Wars, the greatest devastation ever visited upon our Galaxy. What you have experienced…”

Slartibartfast floated past, waving. “It’s just a documentary,” he called out. “This isn’t the good bit. Terribly sorry. Trying to find the rewind control….”

“…is what billions upon billions of innocent…”

“Do not,” said Slartibartfast, as he floated by again, fiddling furiously with the thing he stuck in the wall, “agree to buy anything at this point.”

“…people, creatures, your fellow beings…” Music swelled, it was immense music, immense chords. “…experienced, lived through, or in many cases, failed to live through. Let us not forget -and I shall suggest a way that will help us always to remember, as represented by the symbol of the Wikkit Gate! There is not a world,” thrilled the man’s expert voice, “not a civilized world in the Galaxy where this symbol is not revered,” And with a flourish, the man produced in his hands a model of the Wikkit Gate. “Not the original, of course. This is a remarkable replica, hand tooled by skilled craftsmen, lovingly assembled into a memento you will be proud to own, in memory of those who fell.”

Slartibartfast floated by again. “Found it,” he said, “we can lose this rubbish. Just don’t nod, that’s all.”

“Now let us bow our heads in payment,” intoned the voice, and then said it again only faster and backwards. The man gabbled himself backward into nothing.

“You get the gist?” said Slartibartfast. (LUE p49-63)

For forcing its way on users, marketing efforts are probably the worse. Pop-ups, click-through ads, animated banners, and upgrade reminders all attempt to steal user interaction away from what they really want to what a salesperson wants. Perhaps users should accept this if they want free content, but it also appears when the user is already paying. I pay Verizon a pretty reasonable sum each month to be my ISP, yet when I use the web interface for my Verizon email, I get just as many obnoxious ads as a Hotmail account. Buy a plane ticket from Northwest Airlines, and I get confronted with so many interfering upselling offers I fail to see the required fields. Like prompting the user to nod, the designs attempt to trick the user into buying. While the control to accept an upsell offer is bold and easy to see, the “No Thanks” control is muted. The visual hierarchy is manipulated to direct user attention to what the sales department wants users to do, not what the user wants to do.

User in Control

Adams’ Hitchhiker series describes a technological dystopia where users are often at odds with their own technology. User loss of control is the common thread joining designing for fashion, natural language user interfaces, agents with personalities, Smart things, and system- or sales-driven forcing features. In contrast User-in-control is a basic usability principle critical to a positive user experience. As a technology designer, the key to not creating a black spaceship, a Marvin, an Eddie, and so forth is to recognize that the technology you create is first and foremost a tool. It’s not a fashion statement, not a friend, not an agent, not a rule-enforcer, and not a marketing channel. Its primary function is to be used by the user get something done.

Summary Checklist

Problem: Evading poor user-interface designs as satirized by Douglass Adams in the Hitchhiker’s Guide to the Galaxy series.

Potential Solution: Keep the user in control:

• Do not use trendy technology just to be trendy.
• Seek aesthetics that do not interfere with usability.
• Be skeptical about natural language or other “natural” communication interfaces.
• Develop precise structured communication methods to allow users to precisely communicate with technology.
• Consider how technology’s representation of the task or problem to the user can help the user think better.
• Avoid representing your technology as an anthropomorphized agent; allow users to work directly on important tasks.
• Recognize the users’ fear of technology represents practical concerns that need to be directly addressed; it is not an irrational response to be handled emotionally.
• Remember that “user friendly” means fast and easy to use, not polite and verbose.
• Avoid trying to guess user intention in various contexts. Rather, provide a consistent interface of simple interactions that users can assemble to fulfill their intentions.
• Avoid unnecessary requirements or arbitrary limits to make things easy for the system.
• Avoid subverting usability for sales purposes.

As a senior human factors engineer working in human-computer interface, you would anticipate my computer workstation at home would be the epitome of ergonomics and usability. “Man,” you probably think, “he must have a killer setup.” And I do. It looks like this (click for larger):

What’s that they say about the shoes of the shoemaker’s children?

Let’s start with the obvious:

• The desk top is too high. I had to raise my chair so high that my feet dangle. Even then, it only puts my arms at the right height for writing with pen and paper -they’re still not right for using a mouse or keyboard.
• Computing space interferes with writing space. The massive 21″ CRT monitor necessarily projects out over the space I need for paperwork. Even after sliding the keyboard under the monitor and the mouse off to the side, it’s cramped.
• Removable media in the CPU is hard to see and reach. Inserting a CD or thumb drive under the card table is awkward.
• Network components consume valuable desktop space. On the left file cabinet you see a network bridge. It used to be on top of the CPU, but it tended to overheat there. Also, I needed to have it handy for rebooting.
• Printer is hard to see and reach. With it high up on the top shelf (on the left), loading new toner cartridges is tricky. Also, I have to stand on my toes to read the status lights, and I’m at about the 70th percentile height for males.

Less obvious from the photo:

• I placed the desk on a wall opposite of a large window (which is causing the flare on the right of the pic), resulting in reflections on the monitor, making it hard to read sometimes. It was the only way to fit everything in the room.
• That CPU is noisy. Even though it’s more than an arms length away, it’s still a distracting racket.

Computer History

Like many cases of problematic human factors, the cause wasn’t so much poor design as a lack of design. The workstation was cobbled together from whatever furniture I had on hand. Each piece actually worked well for its original intended purpose. However, like assembling an enterprise solution from COTS products from various vendors, its not surprising that the human interfaces don’t fit well together, in this case literally.

That’s okay. This workstation was only temporary until I got a proper setup. However, knowledge of human factors is double-edged. On the one hand, I know a bad setup when I have one. On the other hand, I had a certain performance level I was willing to accept. After I perused various stores and catalogs, it became clear quickly that no available desk would reach that target. By “quickly,” I mean after several years. I was going to have to design and build my own desk, which I was soon ready to do. By “soon,” I mean after several more years.

It would’ve taken even longer, except I started teleworking, which gave the project new urgency, and not just because I was spending more time at my home computer. My employer encourages teleworking, but each employee was required to complete a form (this being the government) certifying that his or her home workstation complies with federal ergonomic standards. Federal ergonomic standards? Sure, my rig complies with federal ergonomic standards the way Bill Clinton complied with his marriage vows. For example, take the requirement that the user must have his or her feet flat on the floor or a footrest. Yeah, I got a footrest. I use the legs of the chair. You can tell where the paint was wearing off.

Design A

Mobile Desktop

As with web pages and windows in software, real estate was a prime constraint. The room was only so large and needed to fit the computer system, the main workstation, a secondary workstation (for my wife, who was using the card table in the setup above), plus a bookshelf, guest bed, and other items. Everything would fit easily if the main workstation used the same space for both computer work and paperwork.

Of course, the desktop needed to be lower, but how low? The optimal height for paperwork is a few inches higher than that for the keyboard and mouse, being about 29 and 25 inches respectively for my own physical dimensions. One obvious solution is to set the desktop height for paperwork and use a keyboard drawer under the desktop for computer work. Such drawers are readily available, but the problem is that they move the user back from the desk. Too often I’ve seen setups with the LCD monitors against the back wall, exploiting their thinness to provide more desktop space, but that places the LCD rather far away. Then there’s a keyboard drawer that effectively makes the monitor even farther away from the user’s eyes. Adding to the squintihood, LCDs tend to have pretty fine pixel pitch -on the order of 100 per inch, so the default font is quite small. Not so good.

If I use a drawer, the monitor should be placed closer for optimal viewing distance, but that interferes with desktop space needed for papers. I could put the monitor on an articulated arm or sliding tracks so I could move the monitor back and forth when necessary, which was something I had done before when I had 9 inches of diagonal, and was happy to have it. However, now I was dealing with a 21-inch 70 lb. behemoth that wasn’t particularly motivated to move anywhere. Even if I wanted to replace the CRT with an LCD, the one I was eyeing would still represent substantial bulk to be sliding around.

A more reasonable approach was to put the paperwork on tracks. The keyboard and mouse would fit in a stationery well under the desktop. A panel of the desktop, papers and all, would slide back into a slot under the monitor to expose the computer controls for use. Here’s a plan view sketch that I made while working on the design (click for labeled pic):

The Tech Tower

To further make the most of the available space, I sought to minimize the footprint of the computer and network components by stacking them vertically in a tower built into the desk, as shown in this early design sketch (click for labels):

Components that I would rarely access, like the motherboard (yeah, right) would be located deep in the tower, while components for removable media would be mounted on the tower’s narrow external face for easy access. Switches mounted on external face would let me power cycle the network components when needed. Burying the motherboard, power supply, hard drives, and their multiple fans deep in the tower would also provide sound insulation, but would require careful attention to heat management. The design called for the “technology tower” to become the CPU’s case. By mounting the CPU chassis “face down,” I could duct air up from the bottom and vent it out the top. With the chassis in that orientation, the removable media components would have to be relocated from the chassis to the tower itself. Taking inspiration from a project I saw on the web (for recent versions, see DeskTopped), the computer components would be literally built into the desk.

Reclined Computer Operation

We all know the proper posture for computer use: sit bolt upright, feet flat on the floor, 90-degree bends at the knees and waist. We all also know that no one sits that way. Walk down a row of cubicles, and you see many users slouching, leaning back in the chairs, legs stretch out in front (alternatively, users hunch forward, perhaps resting their heads on their respective chins -maybe those are the ones with their LCDs back against the wall). I’d often find myself in the reclined slouch. That can’t be good, with the chair providing poor support of the lower back. It also ruins the careful positioning of the keyboard and monitor provided by the computer desk -they end up being too high. But surely it must be more comfortable than the “proper” posture or else users wouldn’t end up that way. I remembered an ergonomics journal article (unfortunately, I can’t find the cite now) that noted these habits and asked why we’re trying to fight against natural human inclinations? Why don’t we design our computer workstations for a reclined posture?

Why indeed? Being a specialist in transportation human factors, I would never design a vehicle interface with a bolt-upright sitting posture. Typically, the operator stations for airliners, locomotives, and motor vehicles (other than motorcycles) all recline their operators by 10 degrees or so. It’s not only more comfortable but it takes a load of stress off the lower back as long as the station is designed to be used that way. In all these vehicle stations, visual attention is primarily directed straight ahead or slightly down, like with a desktop computer workstation. Computer workstations should also be designed for a partially reclined user. (Not so for workstations for paperwork, where visual attention is more sharply down.)

Conflicting Requirements

Put the sliding paperwork panel together with a reclined seating position and there was a problem. Chair height was fixed to that best for paperwork (i.e., feet flat on the floor when sitting upright). So I’d need a foot rest to properly support the legs when leaning back to use the computer, but that wasn’t the problem. Fix seat height meant a fixed eye height when reclined. Eye height determined the monitor height. You want the top of the monitor to be level with the user’s eyes because looking up continuously is straining, while looking down is okay. Put these together with my physical dimensions, and the base of the monitor would have to be below the top of the panel for paperwork, as shown in this contemporary sketch.

Here’s a clearer image from the final stage of design of the desk with an LCD monitor rather than a CRT:

That meant I couldn’t slide the paperwork panel under the monitor. I considered other alternatives, such as sliding the panel sideways, but couldn’t figure out a way to make it work.

The whole idea was coming apart for my application. A reclined position also meant my head was further back than usual, which meant the monitor would have to be moved closer, right up to the back edge of the keyboard, seriously encroaching on the paperwork area. The paperwork area could extend further back (I’d roll my chair forward into a cutout to use the keyboard), but that made the entire desk too deep for the room.

Then there was the question of my mechanical building skill, or lack thereof. The sliding desktop mechanism would be quite a challenge to construct, as would the tech tower for the computer. Building the computer into the desk also made repairs difficult. I was learning from experience that (a) computers are increasingly unreliable, and (b) computers were beyond my technical abilities to fix. What would I do if I had to ship the computer out for service? Send the whole desk?

You probably could make the sliding desktop idea work for some applications. Using a not-too-large wall-mounting LCD or two, rather than my clomstrous CRT, you should be able to keep the bottom of the monitor above the top of the desktop. Maybe you could motorize the paperwork panel so that it would not only be ergonomic, but wicked cool. Yeah, and hide the monitors behind a motorized case for office supplies. Click one switch, and zzzzht! Like something out of Thunderbirds!

I personally wasn’t ready to discard my trusty old CRT. I had paid a lot for it back in 1998, and it still worked fine. With a maximum resolution of 1200 by 1600 pixels, it was about as good as a 24-inch LCD and color fidelity was generally superior. I planned to keep it until it broke (which it did, of course, while I as in the midst of finally building the desk designed to accommodate it).

Besides, I had discovered a way to have separate spaces for computer work and paperwork fit into the room, eliminating the need for a variable geometry desk.

Design B

Corner Office

By placing the main and secondary workstations on adjacent walls, I could create a third position in the corner. Normally the corner is difficult to exploit in L-shaped desks, but I saw a setup make good use of it by having a stretch of desktop set at 45 degrees. Here’s an illustration of how the positions would fit in the room.

(This is literally user-centered design: I put the users in the model, position the computer components accordingly, then designed the desk around them)

The corner position tends to be deep, but that’s an asset for computer work. Sitting semi-reclined with my feet stretch out in front, I’d need the depth. Certainly the CRT needed the depth.

Tech Tower II

Meanwhile the tech tower morphed away from being the computer case to embracing the computer case, making it easier to construct and easier to service the CPU.

The CPU sits high in the tech tower, protruding above the desktop to provide room for the UPS and network components below. Access panels in the tower support basic maintenance such as plugging in a peripheral or card, although crawling under the desk to get to the panels feels like climbing into a Jefferies Tube. A hinged lid on the top of the tower allows easy removal of the CPU for major servicing. The only portion of the CPU exposed is the components for removable media, putting them in easy reach and use. Everything else is sheathed in wood to help deaden the sound of the cooling fans.

Final Design

The completed design looks like this (click for labels):

The main workstation is in the center (computer work position) and to the right (paperwork position). The secondary workstation is on the left, separated from the main workstation by the tech tower. Flat-panel legs at the extreme are easy to make and maximize space under the desk.

The desk in operation looks like this (click for larger):

The material is primarily 3/4 inch oak plywood with a frame of 1×4s and 2×4s. The room’s window is 45-degrees to the side of the monitor, minimizing glare (especially with the new flat screen). The (new) printer is now at a reasonable height (partially in view on the white file cabinet on the far right) for easier use and maintenance.

Paper-Computer Transition

With the paperwork position separated from the computer work position by only 45 degrees, one can move between them easily. To fully capitalize on this, the user should be able to pivot between the positions without banging any shins on a desk leg or other supports. This meant the monitor surface had to extend well under the desktop before coming to a leg. The monitor surface was not only long, but thin -no more the three inches thick so the top would be low enough for the reclined seating position and bottom would be high enough to clear my knees when I reclined. This represented a structural challenge because it had to be strong and stiff enough to hold 70 lbs. of monitor. I had seen that monitor warp three feet of plywood and outright break pine board, so I had some appreciation of the load it imposed. I considered various approaches to creating a metal frame (e.g., steel pipe or Unistrut), until my father, the civil engineer, convinced me a fabricated box girder of plywood would be sufficiently strong and easier to make. Here’s how it looks from the back, with the tech tower hidden for clarity.

The top face of the girder is the surface for the monitor while the bottom is the keyboard/mouse tray. Sidewalls are 1×2 red oak. As events transpired, this all proved overkill since the CRT didn’t live to see the day that it would rest on the new desk. But then, the new LCD monitor I got to replace it was no featherweight at 40 lb, so it wasn’t all a waste.

Verticality

With the CPU protruding above the top of the desk, the front face of the tech tower below the desk is used as much as possible to hold objects that otherwise would take up valuable desktop surfaces.

A shallow shelf provides handy storage of CDs and DVDs I’m currently using. (Yes, I’m currently using CDs; going mp3 is something I’ll do some day. By “some day” I mean “some year.”)

The larger curved lower shelf is for laying cameras, GPSs, and whatnot for uploading/downloading with the computer. Interface cables are permanently routed from the back of the CPU to the shelf. The landline phone finds a vertical surface to hang from.

The USB backup drive lives with the network components on a shelf behind sliding Plexiglas doors in the tech tower. The drive has a dedicated USB cable, but I only plug in the drive when backing up, which I can do from sitting at the computer. There’s no point in having backups if they’re going to be blown away by the same lightning strike or malware attack that takes out the hard drive, so I leave an air gap most of the time.

Thermal Management

Airflow into and out of the tech tower remained another challenge. I wanted to filter the intake air because I had experienced processor overheating from dust clogging the heat sink. Besides, I hate dust bunnies in my CPU. To minimize the restriction of airflow, the filter needs a large surface area. To achieve this, I replaced the left side of the CPU case with a removable panel of the tech tower.

The panel sandwiches a disposable filter intended for an air conditioning system making the entire side of the CPU into the air intake.

A cardboard bell (not visible) feeds cool air directly to the processor fan.

Hot air is exhausted out the front and back of the CPU by the usual fans, where it is collected in a plenum in the back of the tech tower that also gathers hot air from the network components and UPS.

An extra processor fan draws air out of the plenum, its wiring extended to reach into the CPU to the motherboard so it turns on whenever the computer is on.

The cowl for the fan is made from keypunch computer cards, showing that they’ve yet to exhaust their usefulness.

The cooling scheme seems to work. So far, I yet to see CPU temps reach 40 C (104 F). With 73 F ambient conditions, the air exiting the tech tower is 87 F, while the air on the network component shelf is 78 F.

But there’s more: heat isn’t just a computer problem -it’s a human factors problem too. With the computer blowing out 80+ F air, the small office can get quite toasty, which is great when teleworking in the winter and the rest of the house is set for 60 during the day, but it can get uncomfortable in the summer. So there’s a 4-inch pipe running behind the monitor that routes the exhaust air towards the window, as shown in this plan view.

In summer I fit in a window insert to direct the air outside.

Shortly I’ll add some storage trays to the insert to hold odds or ends. By “shortly,” I mean, well, you can guess.

Recycling Bin

With the demise of the CRT, I suddenly had plenty of space behind the monitor. Some of this is used for a long-arm desk lamp, freeing more space for papers. It also allowed a more direct routing of the exhaust air to the window. Even while I was designing the desk around the CRT, I was anticipating its LCD replacement, figuring the desk would out last the CRT (which it did by a negative value). I made some vague plans for using the space behind a LCD for some sort of storage, something I’ll complete in the very near future. Assume geological scales of time.

Then there’s the recycling bin, placed on the desk in the back corner to provide more floor and file space.

(Formerly, recycling went in the “1000 PAC” cardboard box shown in the pic of the old setup above. Not much leg room at the secondary workstation, is there?)

The recycling bin actually was always designed to fit to the back right of the monitor even when the CRT remained, although its self-destruction allowed me to place the bin in easier reach. The bin holds a standard paper shopping bag at a 60 degree angle, as shown in this cross-section from the right side.

This way, papers thrown into the slot tend to land in a neat stack, maximizing the capacity of the paper bag. The top is hinged for replacing the bag. I think that qualifies it as a green desk. Maybe I can take a tax deduction on the construction materials.

Accessories

Input Devices

You wouldn’t expect a usability professional to replace his CRT with anything less than a state-of-the-art big-ass LCD monitor, but you might be surprised by the ordinary keyboard and mouse. Where’s the fancy curved ergonomic keyboard and megabutton mouse?

Take a closer look at the keyboard, and you’ll see something unusual: the keypad is on the left hand side. Originally I planned to accomplish this with a compact keyboard that has no keypad, and combine it with a separate keypad on the left side, but it turns out DSI already makes them that way. The left side keypad has a number of advantages:

• I can keep my left hand over the keypad and the right hand on the mouse, so I can enter numeric data quickly and combine mouse movements with cursor key movements (e.g., select a field with the mouse and clear it with the Delete key).
• It makes it easier to center the QWERTY home keys in the middle of the keyboard tray so I don’t put my right wrist in an awkward right-hand angle when touch-typing. I suspect that’ll prevent repetitive motion injury as much as a curved keyboard.
• It moves the mouse closer to the QWERTY home keys, making for perceptively faster shifts of my right hand between the keyboard and mouse (consistent with Fitts’s Law).
• It places the Backspace and Enter key within reasonable reach of my right thumb when I’m holding the mouse, allowing one-handed entry in certain cases (e.g., select a checkbox in a dialogue box with the mouse, and select OK by smacking the Enter key).

I’m right handed, so you might expect it would be awkward to use the keypad with my left hand. However, back in high school, I had trained myself to use a calculator with my left hand so I could conduct calculations with the left while writing the results with the right (a personal time-and-motion intervention that proves I was always destine to be a human factors engineer). It helped that my left-hand dexterity was enhanced by years of viola lessons. Your mileage may vary.

As for the mouse, my right hand is plenty busy with left clicking, right clicking, center clicking, and scroll wheeling (and occasional key-smacking). On the other hand, my feet are sitting on the footrest doing nothing other than enjoy the vibrations from the subwoofer (makes music listening a tactile as well as acoustic experience). So I have a Kinesis 3-pedal foot switch, programmed for Back (Alt-Left), Change Windows (Alt-Tab), and Close Window (Alt-F4; yes, that’s dangerous, but it’s great for pop-up ads). The pedal provides a consistent means of interaction whether I’m using the keyboard or mouse, reducing my cognitive workload. I’m thinking of getting a second pedal for the left foot for cut, copy, and paste.

Papers etc.

Two holdovers from my old desk earned their place on the new desk for handling non-digital media. In front of the recycling bin is a wood and Plexiglas “work rack” for displaying papers that need my attention. They would all stack neatly in simple basket serving as physical inbox, but if I don’t see the paper, I forget about it. Spreading all the papers over my desk would use the space I need to work. The work rack provides a more compact way to display the papers. The only issue is that, not unlike a digital inbox, I need to clear it out now and then of items I’m just not getting to despite their visibility (e.g., ideas for what to do with the space behind the monitor).

A desktop shelf, as seen at the secondary workstation, is something I had in grad school that I found very convenient for putting materials in easy reach while sitting at the desk, so it is carried through here, although it better serves my wife than me. This particular shelving unit is salvaged from one that was damaged in shipping. It’ll do for now, but I’ll be building a unit that better matches the desk. Shouldn’t rush it -it’s not something one should do without the proper tools. Right now, I only own hex-type tuits (English and metric). I’ll build the shelf when I get a round tuit.

Building drawers is beyond my skill level, but fortunately I had inherited from my father-in-law an oak veneer file cabinet. After carefully cutting down the base a couple inches, it just slid under the right side of the desk.

Aesthetics

The key aesthetic quality I was after was that the desk not grossly offend me. However, living in middle class suburbastan, it also had to not be embarrassing for my wife and me if guests see it (the room includes a spare bed). The layered overhanging theme has a contemporary Frank-Lloyd-Wright-ish look that may appeal to some, but more importantly it effectively hides off-course cuts and misalignments one has to expect from someone with my woodworking skills. The natural wood finished is consistent with other house furnishings and warms the otherwise cool contemporary form. Rounded corners are trendy (thank you Apple), but I think they’ll retain their organic appeal after it falls out of fashion.

Summary Checklist

Problem: Building an ergonomic computer desk for limited space.

Potential Solutions:

• Consider a sliding panel desktop with a stationery keyboard/mouse well to allow computer work close to the monitor while providing ample paper-work space.
• Use corner space for the computer work position adjacent to a conventionally dimensioned paperwork position, keeping the space between them clear of any supports for easy transition.
• Design the computer position for use while partially reclined, providing a foot rest if necessary.
• Stack technological components in an easy to access well-ventilated tower. Ideally, provide an air filter and means to vent the heat outdoors.
• Find little ways to save space by using vertical surfaces and the space behind the monitor.

This month, I’m going on Facebook. You’re not invited.

I guess each of those sentences demands an explanation.

You’re Just Going on Facebook Now?

That’s right. Up until now, I don’t Facebook. I don’t Twitter. I don’t text. I only got my first cell phone two years ago and I almost never carry it on my person. This isn’t due to an aversion to 21st-century communication technology. I also don’t email much, don’t make many phone calls, and don’t write letters on dead trees with quill pen. So what does that say about me?

Okay, it says I don’t have a whole lot of friends. But that’s actually my point. A few close friendships matter more to me than scores of superficial ones. My relatively infrequent use of communications devices concerns not so much modern technology as it concerns relationships, and the quality they have. As amazing as all these technologies are, they are all a poor substitute for being in-person with a close friend. While a phone call is better than nothing, it’s not enough better to make me want to use it all that much. As for any text-based communication system, they seem barely better than nothing. I’m just at the threshold now of trying Facebook, while remaining skeptical. Modern communications technologies allow us to send more information to more people more frequently than ever before, but that’s not what I’m after.

What Do You Mean I’m not Invited?

What I’m after is intimacy, a certain quality of communication, not quantity. So-called social technologies, like Facebook and Twitter, and blogs, for that matter, are set up for indiscriminate bulk communication. Not that there’s anything wrong with sending bulk communication to everyone you know. I’ve been doing it myself annually for years via dead trees in the form of the dreaded holiday newsletter. It strikes me as odd that people I know seem to write and read holiday newsletters somewhat begrudgingly, accepting with resignation that the demands of life preclude personal holiday letters to each recipient. And yet there seems to be much more enthusiasm for social apps. What is Facebook but a holiday newsletter chopped up and distributed throughout the year?

Personally, I enjoy both creating and receiving holiday newsletters. They are a fun and effective for staying in contact with the 100-plus friends and family members on our list. However, such bulk communication can’t be as intimate as being with only one or two of them at a time. Those 100-plus people represent wide ranges in closeness and varieties of relationships. Each close relationship has unique factors, but only common denominators can be included in a collective communication such as a holiday newsletter. Intimacy means being yourself with someone else. Let’s face it: you can’t do that with just anyone.

And so it is with the likes of Facebook and Twitter, at least as they’re intended to be used. I don’t feel a need to transfer my upcoming holiday newsletter to a wall on the web. Instead, I step into Facebook tentatively because I know I’m looking for connection rather than contact, and I’m not so sure I can get that with Facebook. As I experiment with it to see if it is possible, I’ll have to resist its by-design tendency to pull me towards quantity communication, and that means firstly limiting the number of friends on my network. I’ve three right now. I’m not expecting to increase that anytime soon.

The Problems in Hi-Tech

Email, cell phones, texting, instant messaging, blogs, Skype, Facebook, Twitter: In less than twenty years technology has greatly expanded our capacity and options for personal communication. Where the personal computer originally meant a human alone with a machine, now the machine is primarily a way of contacting other users. We should be living in the Age of Intimacy. But do we feel any closer to those we love? Or is there something about the design of these technologies that by accident or intent has subverted this potential and left us no better off than when we started? Do they actually interfere with intimacy? I can think of several reasons why that may be the case.

Limited Social Bandwidth

Yeah, I’ve a lot of gall complaining about the bandwidth of modern telecommunications when it’s been doubling every couple years. Yet with multiple megabits arriving at our doors, it’s still a long way from level necessary to replace being together in person. A sense of closeness to people comes from more than the words we exchange with them. There is also:

• Spontaneous emotional content. A sense of closeness comes from our tone of voice, facial expressions, gestures, and body language, which is lost in most translations into megabits.
• Immediacy of reactions. Closeness is also fostered by duplex communication where we get immediate or even overlapping feedback in our exchanges, seeing and hearing how a listener responds as we are communicating.
• Undemanding presence. Finally, closeness is fostered by not exchanging words, but rather by simply being together. Part of being yourself around someone is not feeling pressure to continuously communicate and entertain that person. Simply doing what you naturally do around someone else both makes you feel more genuine and makes the person you’re with feel she or he is seeing the genuine you.

The current crop of social apps and technologies are a long way from transmitting those factors in closeness. On social network apps like Facebook, MySpace, and Friendster, you build your profile then invite your friends to see it, which seems odd since if they were really your friends, they would already know pretty much everything on your profile, so what exactly is the point?

Facebook’s Wall, where users can post updates about events in their lives for their friends, has the potential to be used to foster connections, turning Facebook from being a personal website into more of a limited-circulation blog or multi-media Twitter feed. However, the text-centered non-duplex transmissions of Facebook (and blogs, Twitter, instant messaging, and texting), have little spontaneous emotional content and immediacy of reactions. Cell phones and Skype are much better at this, but lack undemanding presence. When you call someone, you need to have something to talk about.

Multitude of Undifferentiated Contacts

Being yourself requires privacy, and intimacy requires personalized connections, where you communicate on the unique common factors you share with someone else. It isn’t intimate if everyone knows. However, social network apps like Facebook by their design tend to encourage building networks of undifferentiated contacts, effectively becoming only slightly less public than a blog. I click on my Friends link in Facebook and I’m first invited to find more contacts rather than check up on the friends I have now. The home page pushes adding more contacts by providing “suggestions” based on friends of friends. That may be good for Facebook’s business where the number of nodes equals the value of the network (to Facebook), but not for intimacy.

For the users, building your network is ultimately boring, and what’s left to do when you’re done? You can keep on adding friends, boosting your “friends” count, and turning Facebook into of popularity contest. You can continually update your profile, creating and re-creating your on-line identity. That may have a lot of appeal to teenagers, where popularity represents status and their identities have yet to fully form, but that has little to do with intimacy. Friend counts turn it into a competition rather and community. Gathering “friends” as trophies is depersonalizing and degrading, undermining closeness which requires we value each other’s uniqueness. Erik Erikson teaches us that intimacy only comes after one has a stable identity -one needs something to share to be intimate. While social sites may be a helpful in exploring and forming an identity, if that’s what some users are using it for, then they’re not quite ready for intimacy.

Meanwhile, for the rest of us, the design of social sites in conjunction with our cultural expectations leaves us with little ability to control the privacy of our networks. It’s difficult to differentiate our contacts, meaning that the same content we send to our lover also goes to our parents, our children, our boss, and our rival. There is implicit pressure to accept a symmetrical relationship from anyone that asks, meaning our “friends” tend to include decidedly un-friends. In the big-blue-ceiling world, our social contacts form groups and hierarchies, but on Facebook everyone has equal capacity to promote or damage relations. On-line conflicts are the result. We rely on the mere disinterest of un-friends to prevent them from intruding -hoping they will simply not bother to look at what we’re saying. As our on-line networks grow, they tend to deteriorate until the only alternative is to flee, and start a new network at a new site. And thus Friendster faded in the US, replaced by My Space, which is being replaced by Facebook. I suspect that Facebook may survive because it’s lucky enough to arrive at a time that our culture figures out a socially acceptable way to handle unwanted friend requests (just ignore them).

However, with the popularity of social network sites like Facebook growing even among non-adolescents, it is evident that social sites are desired for something. We can build and maintain business contacts, or use them for self-marketing (professionally or socially), or to simply express ourselves to any audience that is interested enough to listen (much like a blog). But that is all we’re getting: an audience, not a confidant. That’s useful for guiding our self-presentation, but such image management implies we are not being ourselves.

Uncontrolled Access

While the likes of Facebook and Twitter are biased towards bulk broadcasts to a large undifferentiated audience, cell phones and texting are modern technologies designed for personal one-on-one communication, making them substantially more suited for intimacy. Their mobility also allows us to contact those we care about anywhere and anytime we want, which is also helpful for increasing the intimacy in our lives. When I’m traveling alone, I greatly value the ability to call my wife from my restaurant table or a quiet riverside to talk about the day (the long delay in my acquiring a cell phone was primarily due to me doing too little non-business traveling on my own -at most a few weeks per year -to justify a 12-month cell phone contract; for business travel, I’d check out a cell from the office pool).

However, that constant availability is a double-edge sword, easily eroding intimacy as much as creating it. It means moments of intimacy being interrupted by receiving digital communications from others, including those we’re not all that intimate with. More insidiously, mobile communications technologies tempt us to direct attention away from those we are currently with to seek out others. We might be somewhat intimate now, but the cell phone on our belt constantly whispers that perhaps there’s something better just a few button-presses away. Maybe we better check to see.

The always available electronic communications devices can distract us from in-person dialog until it’s absurd. In one case, an acquaintance of mine drove her teenage son to meet his girlfriend at the movies. In the parking lot, the son wouldn’t get out of the car, being engrossed in texting. The mother needed to get home quickly but she was on a conference call on her cell and so couldn’t talk to her son to see what was holding things up (was the girlfriend texting to say she was late or canceling?). It was twenty minutes before (a) the mother could tear herself away from the cell long enough to talk to her son sitting right next to her, (b) find out that her son was in fact texting his girlfriend on some trivial matter when he was going to see her shortly anyway, and (c) that all this time the girlfriend was a mere 50 yards away in the theatre lobby –he was so into texting her that he hadn’t gotten around to asking where she was. It’s one thing when electronic communications are a poor substitute for being in-person with someone, but here they were interfering with being in-person.

The vast volume of available social communications has saturated the time we have available for intimacy, spreading us thin. We can spend substantial time just checking our email, Facebook pages, and cell phone text and voice messages. We can be pulled from one relationship to another, perhaps involving ourselves psychologically or socially in matters not that important to us. Bouncing around from contact to contact, we never spend enough uninterrupted time with one to build a deep connection. This is a problem with how we use our technology as much as it is with the technology itself, but perhaps there are ways to design the technology to reduce their constant pull away from what we’re experiencing now to the mere promise of something else.

Trust in the Medium

The problem of privacy extends beyond the network of contacts we create on a social site to include the site itself and those who run it. There appears to be a conflict between the user keeping his or her content and relationships private, and the site operator’s need to extract something of commercial value from that same content and relationships. Simply put, I don’t trust Facebook, and the short history of social sites suggests that no user should. They deliberately obfuscate the level of privacy, repeatedly. They quietly default to minimal privacy repeatedly. They trick users into providing access to private accounts then impersonate the users (apparently, it’s perfectly legal for a corporation to steal identities). They attempt to wedge themselves into our personal correspondence.

Some seem confident that user surveillance and rebellion will prevent such abuses of privacy. However, the historic efforts to exploit our friendships seem so laughably ham-fisted that I suspect The Man is simply climbing the learning curve of this new technology, and will eventually become smarter and more powerful than the average user. I don’t think we should underestimate the resources and creativity of very clever people with very big budgets working in marketing.

How Did This Happen?

Maybe the makers of social sites weren’t trying to support intimacy. They’ve certainly been successful without it, in the sense that they’ve recruited plenty of sign-ups, so perhaps they deliberately disregarded intimacy as unnecessary from a business perspective. However, I also wonder if the prospect of intimacy never occurred to them, or if it had, they wouldn’t know how approach it. Could it be that the techno-geeks that create these sites don’t get it? There is something, dare I say, a bit nerdy about displaying friend-counts or number of followers in social apps, as if quantifying friendship should somehow be important to users.

The site designers apparently assumed that users would prefer to broadcast to a large undifferentiated audience, otherwise they wouldn’t have made it the default communication mode and wouldn’t have tried (wrongly) to make it more convenient for users. Broadcast can have practical uses for getting information or advice (perhaps even supplanting Google), or more direct assistance in a problem (e.g., get a ride to New York City), and maybe that’s what the site designers thought was going on. However, regarding friendship as being mostly about practical support also smacks of nerdiness.

Repeatedly social app creators seem to think users are looking to hook up with strangers, rather than cultivate the relationships they already have. Marketing graphics for such sites suggest that hot members of the opposite sex are out there ready to contact you if you only had the right technology to reach them, a bizarre notion that could be straight from the characters in The Big Bang Theory.

Faithfully transferring human social relations to the digital realm is subtle and difficult and it has caused plenty of out-right failures. Whenever introducing a technology with a social dimension, you need to carefully study the social environment to assess the impact of design on human interaction. My impression of the current crop of social apps is that the weak support of intimacy was less a deliberate design choice than a failure to give it due consideration.

Design Solutions

Fixing What is Broken

Social Bandwidth. Supporting audio and video would help transmission of spontaneous emotional content. For more immediacy, you can aim for more seamless transition from text-based transactions to real-time audio and video. For example, once it’s clear that a conversation is starting via texting, a control can be provided to connect by phone to continue the dialog with whoever is participating.

The Undifferentiated Multitude. Social sites should make it easy to build and manage rings of privacy, separating acquaintances from friends from intimates. It also needs to be easy to build separate networks, such as one for friends and one for families. That’s how real-world social networks work. Sites should be designed to work best with each person belonging to multiple groups rather than being optimized for broadcasts to a single group. Maybe the whole idea of personal pages should be downplayed because it inevitably focuses on “me” rather than “we.” Instead, users of a group should find it easy to create and use private joint pages. Membership in these group pages should be by invitation only, and their existence should not be displayed in search results or on profile pages even to friends, thus reducing social pressure to include individuals you rather not include for a specific group. With group-based pages, the purpose of the personal page is to allow the owner to monitor multiple group pages, not to serve as a repository of personal information and updates about oneself. Content should be organized at the top level by relationship rather than individual.

Uncontrolled Access. Improved usability and centralized monitoring of our social contacts would cut down on time spent fiddling with social apps rather than socializing. With each user belonging to multiple explicit groups, it becomes possible to prioritize contacts that are pushed to users, allowing them to better manage their time. We also need to focus on achieving the right balance of providing immediacy while avoiding interruptions. Possibly we can provide a means for users to signal their current level of availability to the groups they belong to.

Trust in the Medium. Privacy statements are not enough since they can change at any time. Privacy needs to be built in permanently. Maybe this can be done through technology by encrypting content on social sites by default, but I can already hear national security agencies around the world freaking out about that possibility. Alternatively, we should seek a legal mechanism to protect privacy. Maybe laws can be passed where users have the right to sue site owners for any use of user data if the site displays certain standardized trust-encouraging privacy language such as ”Fully User Owned and Controlled Content.” Beyond that, we need to reduce the incentive to exploit user relationships. It may be web heresy, but perhaps users should pay for use of social sites, not unlike already done for cell phones and texting, so site owners feel less need to sell our friendships to advertisers.

The Missing Piece of Intimacy

There are three ways electronic communications technology can support intimacy. First of all, the technology can be used to plan or coordinate future in-person experiences. Certainly email, cell-phoning, texting, and Twittering have been used to arrange get-togethers, although their support for that function could be improved. Facebook and its ilk don’t seem to offer much for that purpose, except possibly maintaining general awareness of where your friends are and when they’ll be available.

Secondly, technology can be used to exchange content about past experiences, either shared or not. This seems to be what Twitter and Facebook are primarily aiming for, however poorly. Users can tell (or show with pictures or links) what has happened to them.

In addition to helping users plan get-togethers and share past experiences, there is a third way of supporting intimacy that appears to be missing from nearly all technological forays into social relations, and that’s using the technology to be a shared experience. Years ago, I was in Seattle visiting a couple friends and we went to the then-new Experience Music Project, a museum for popular music. To show that they run a state-of-the-art museum, the Experience Music personnel distributed to us hi-tech personal audio devices. These devices featured headphones, a portable CD-ROM drive (that’s how old it was), and a handheld keypad. The idea was you walk around the galleries, punch in numbers posted next to exhibits, and hear an audio recording related to the exhibits. Functionally, they worked fine, but the design failed to take into account the social environment of the museum. They were isolating. With earphones on, I only hear lectures, and only I hear the lectures. My friends may or may not have heard the same lecture, but even if they did, it wasn’t at the same time as me, so I couldn’t comment to them on what was being said and expect them to understand. I didn’t feel free to say anything to them anyway: I might interrupt something they were listening too. The result is that we were at a museum together but far apart.

Apparently, it didn’t occur to the designers that visiting a museum is firstly a social experience. It doesn’t take a whole lot of ethnography to figure that out. Just stand at the entrance for 10 minutes. Almost no one goes to a museum alone. People go with friends, family, out-of-town visitors, and current or potential lovers.

Why? At its best a visit to a museum is educational, delightful, inspiring, even moving. You grow from it, leaving the museum a little more informed or with a little different perspective. We naturally seek to share emotional experiences with other. It provides a feeling of connection. That’s why we take dates to a good movie or nice dinner or to a museum: to have an experience to share. Nothing provides greater intimacy than growing together, sharing in both the struggles and the successes. That’s why our best friends come from high school or college or boot camp. That’s how a museum can make a human relationship a bit deeper.

But the Experience Music audio devices undercut that. I didn’t know if my friends were experiencing the same thing or not. They had headphones on. Within 15 minutes, I had turned in the audio device. (Not to bash the museum too much; while the audio devices isolated you from your friends, the museum’s studio rooms, where you and your friends can play enhance musical instruments together, were a kick-assed sharing experience).

The problem wasn’t advanced technology itself, but it’s design. Everything would change if users could patch their friends into the same audio device with Bluetooth so they could all hear the same thing. That change in design would have altered the experience from isolated to inclusive. With my friends and me effectively creating our own private experience, intimacy would’ve been enhanced.

Creating Joint Experiences

Intimacy is more than what I say and you say; it’ also about what we are when we are together. Such intimacy can come from nearly any joint activity, not just well-planned activities like visiting a museum, but also such mundane things as watching a football game, or preparing dinner, or driving to a destination together. Current social apps and technologies don’t lend themselves to just hanging out together.

Communications technology, especially mobile technology, can enhance intimacy by making it easy to tie a friend into our current activities. Cell phones almost allow this. This summer, while camping alone in Idaho, I called my wife after emerging from a bracing dip in the Clearwater River. As I’m walking from the bank telling her I wish I had packed biodegradable soap, a dog nosed a kickball up to me and looked at me expectantly. “And now a border collie is inviting me to play soccer,” I said to my wife. She laughed. The dog’s owner, 30 feet away, laughed. I gave the ball a light kick, the dog took off after it, and I laughed. It was a little magical moment I could share with my wife thanks to cellular technology. However, to this day, I don’t know if she understood that I meant literally a border collie had invited me to play soccer.

Using the cell phone’s camera may have enhanced the sharing of the experience, but fumbling with the phone to take a picture of the dog would’ve destroyed the moment (in my case, the camera lens was damaged, so it wouldn’t have worked anyway). As it is, holding the phone to my ear was itself a distraction from my interaction with the environment. It’s a good thing the dog wasn’t inviting me to shoot pool.

Mobile communications need to be easier to use and less obtrusive if they’re truly going to be used to connect friends with our activities. Users need to be able to spontaneously elevate the social bandwidth, going from text to voice to photo to video exchange, without worrying about head-down time. Or worrying about the calling plan charge structure, for that matter. Certainly I expect to pay for my communications, but I don’t need to be thinking, “how much is this going to cost me?” every time I snap a picture. Flat-rate unlimited connections may be the way to go. Users should be able to set up a connection to a friend and then just go about their business.

Technology use could also become the joint activity to share with friends. On-line games already do this, although the frantic pace in most games pulls too much attention from your friends to the game itself. It needs to be more than parallel-play let’s-shoot-all-the-zombies-we-can. To enhance intimacy, such games should encourage greater communication and coordination among the players. It would also help if you fed video of each player as they played -not just their avatar, but the real person -so the users can see how their friends react to the game. Yes, that takes away screen space for your amazing game graphics, but the whole idea is to be more than a game.

Just as museums, movies, spectator sports, and other recreational activities in the physical world tend to be shared with friends, their on-line equivalents could also support real-time sharing. YouTube and Hulu should make it easy to arrange joint simultaneous viewing of videos, complete with video or at least audio feeds of your friends as they watch. It would’ve been really cool if I could have watched the Volvo Ocean Race in-port races with my cousin in Michigan, an accomplished sailor who I’m rarely in contact with these days. Someday retailers are going to realize that shopping is a major recreational social experience for many people. Friends meet up on weekends and vacation and then go shopping. Ecommerce sites could rake in butt-loads of money by making it easy for friends to browse together.

Future Intimacy

I suppose when they invented writing 5000 years ago, there were those that complained how it was isolating. Now you wouldn’t have face-to-face conversations, they probably complained. Instead, one can leave a message to another and never hear a reply. It introduced asymmetry in human communications.

But we adapted: we still have intimate relationships, and reading became a source of human enrichment and social interaction; we’ve book clubs and love letters. The written word and the drawn images allow us to form relations with others who are dead now. Until the advent of audio recordings in the 20th century, there was no other way to do that. We are better for it. The same with newer technologies. We just have to figure out how we’re going to do it both as designers and as users. It will take conscious effort. As a designer, it’s only a question of whether you want to be part of the solution or not.

Now, if you excuse me, I’m off to see some friends.

Summary Checklist

Problem: Supporting intimacy more in social apps.

Potential Solutions:

• Study the social environment of your users and understand what they are after.
• Provide more real-time high-bandwidth media, such as voice and video.
• Minimize the effort in using the applications.
  • Centralized and simplify the monitoring of contacts.
  • Support prioritization of contacts.
  • Make it easy to slide up to higher social bandwidth when users want it.
• Support multiple small-group networks of varying levels of closeness.
• Make groups private or otherwise avoid the awkwardness of refusing requests to join a group.
• Organize content by group rather than by individual.
• Support signaling of availability for contact.
• Build in privacy through laws or encryption.
• Use a business model that doesn’t rely on exploiting your users’ relationships or content.
• Provide experiences that your users can share together.
• No “friend” counts.

Update, May 2010

I’ve completed my experiment with Facebook and declared it a success. The experiment, not Facebook. I have determined that Facebook is definitely not for me, and I’ve terminated my updates to it. Twice in the short period I’ve been with Facebook, they’ve attempted to push me to make more information public, suggesting a pattern that’s not going away. I don’t want to be constantly fighting Facebook, remaining ever vigilant for their tricks, and wasting a lot of time figuring out how to keep things private, assuming that remains possible.  Participation in Facebook is something I needed to decide now before I got too invested in it.

What we need is the Wordpress of social apps. An open-source non-commercial app that a user can install on any server and link to similar apps of invited and consenting other users on other servers to form private digital connections. Let me know if something like this comes around. Meanwhile, I’m back to phones and email.

My neighbor… ask[s] for help with a word document, couldn’t figure out why it was locked…. She loads up the document, closes a pop up box, and Word 2k3 loads in the document [but she can't edit it]. She then leaves me to my own devices to which I closed the document, reopened the document, read the pop up. [It says] she hadn’t registered Word 2k3 with Microsoft yet and the trial had expired…. If a box pops up, read it! (Tech Tales)

Users don’t read messages, and it’s not just ignorant users. No one reads message boxes. Software project managers don’t read message boxes. According to Raymond Chen, programmers don’t read message boxes. According to Raymond Chen, Raymond Chen doesn’t read message boxes. Message boxes have become the detritus of computers, waste scattered through applications that users dismissively sweep aside.

Once message and dialog boxes were a key element of the graphical user interface, but today they are ignored with such tenacity, they’re becoming close to useless. To users, a message is an interruption, a distraction from their real work to get rid of as quickly as possible. But you’d think that users would learn to read messages -that there’s useful information in our carefully crafted copy that will actually solve their problem. That’s the theory anyway, but it seems, especially in the past 10 years or so, it hasn’t worked out. While most messages may be useful, most of the time a user sees a message, it’s not helpful at all. Too often messages are confusing or irrelevant.

It started to go downhill with the arrival of the web. There, we’ve seen the advent of advertising pop-ups. Opening a window in front of the user is a great way to get their attention, so it is ideal for important messages. Unfortunately that is also why it’s so attractive to advertisers.

Click for full size.

Yes, pop-up advertisements aren’t real message boxes, but a novice can’t tell the difference. The browser is the typical user’s main application, except for maybe email. All that users know is some little window just appeared. Some pop-ups, like the one above, deliberately try to make themselves look like important system messages. After that happens a few times, novice users learn that “message boxes” are irrelevant to their task or worse, and so they quickly get in the habit of killing anything that suddenly appears unexpectedly. For many, it becomes an unthinking reflex executed with devastating speed.

[I ask,] “Is the error still on the screen?” [User answers,] “No I clicked the ‘X’ in the top right corner…. ” So I proxy in [and ask], “Could you rerun the application and tell me what the error says?” [So the user] opens up the application – error pops up. User clicks the ‘X’. “Whoa,” [I say], “Hang on there let me try this again,” [and I] open up application again. User aims the mouse for the X again. “Ok wait a second here – let me read this!” [I cry]. Turns out that he had a copy of the program already running and it would not allow him to spawn another one. (Tech Tales, link unfound)

But it’s not only the fault of pop-up advertisements. If you think about it, why should a actual message or dialog box be considered relevant to the task? They appear in a separate window, with no visual connection to the window that the user is actually working in. Why should a novice think it’s related?

Furthermore, real message boxes are also prone to being as confusing, useless, and irrelevant as popups, teaching users to ignore them. Submitted, for your approval…

The Gallery of Pointless Messages

It seems this lady had just purchased her computer, and it booted into Windows 95 where it asked for a password…. After having tried numerous passwords, she finally decided that she needed to sign up for Internet access so that we could supply her with a password to login to her own computer! Struggling to contain myself, I suggested that she tried pressing ‘Cancel’, which would pop her right into Windows 95. (Rinkworks)

Here’s the offending message:

It might look like a login window, but it’s actually a window to set up a login account, although it doesn’t say that anywhere. It suggests the user doesn’t have to enter a password, but nowhere does it give the consequences of that. Will the user be able to use the computer?  Nowhere does it say it’s all optional. The title clearly says “Enter Windows Password.” There is no “Let me use the computer without a password” checkbox. By reading the message, the user managed to confuse herself. The advice from tech support? Just ignore the message box. Even computer experts know some messages should be ignored.  Heck, sometimes even the application knows you should ignore a message:

And we’re surprised when users eventually ignore all messages?

Just Do It, Dammit

Too often messages are used to say something that the user really doesn’t need to know. This includes just about any use of a message box to indicate that everything is perfectly normal. Here’s one from a custom-built app I used to use:

Wow, you mean the program actually worked like it was supposed to? I never would’ve guessed. The bizarre part is that I hadn’t changed any preferences -users get this message every time they exit.

Then there are messages that give the user a choice when the right one is obvious. Here’s one from Firefox, only it has the bonus geekspeak to provide that little extra confusion (click for full size):

I’ve yet to ever not want the latest content when I view a page. I don’t see a reason Firefox shouldn’t refresh the page automatically without user authorization. If there is some edge case for a user seeing what used to be on a web page, then cache the old page before refreshing and provide a menu option for viewing it. It doesn’t make sense to divert the vast majority of users to try to capture a very rare issue.

Well, given the user is the one who stopped spell check, it’s a reasonable assumption that she or he would know that. This message seems aimed at a rare scenario that isn’t worth it. There’s no warning before sending if the user entirely skips spell check, which is the more likely error.

Not all such messages give the user a choice. Sometimes they’re just there to satisfy natural user curiosity. Like this one that popped in the middle of a lengthy installation:

Oh, I’m so glad you told me, because I was like watching every byte copied to my hard drive and was really expecting an installation of DirectX while at the same time I’m totally clueless on the fact that I already have DirectX, and this saved me so much time, unlike all those other lusers who walk away for 30 minutes during an installation only to return to find it stuck a fraction of the way through waiting for the user to click “OK, I understand you don’t need to install friggin’ DirectX.”

Look, do whatever you need to do. Users don’t need a play-by-play.

(Click for full size)

Unless you make a habit of including links to phishing sites, this is going to be apparent to the vast majority of users. But someone told the lawyers about the web, and now my surfing is interrupted to tell me the obvious. And, of course, I get this message. Every. Time. I. Select. A. Link. From the site. This provides more reason for users to learn to ignore unexpected messages.  If the lawyers really insist on this kind of “protection,” how about an asterisk or other symbol beside links that go off site? A linked page or legend for the symbol can provide this content. Actually, the web could use a standardized symbol to indicate off-site links.

Meanwhile, let links do their linking. Apps should do what they’re told to do the first time.

We’ll Fix it with a Message

You get this message in CorelPaint if you edit a text object’s characters after setting the color, size, or other formatting of the text. Well, I guess users need to know that they’re about to destroy their formatting work by making a little edit, but like so many such warnings, this occurs every time the user goes to edit text even though most of the time, they’ll have to edit it (and re-apply the formatting). It gets users in the habit of quickly choosing whatever moves them forward in warnings without reading the message.

“I was going to save my work, and I accidentally clicked Delete rather than Save,” user explains. Usually, a dialog box asks if you’re sure you want to do this, [a tech] points out. “Yes, one did,” says user, “and I clicked OK.” Why? “I always click OK,” user says. “I don’t have time to read them, so I just click OK.” (Shark Tank)

The ubiquitous delete confirmation message has the same problem. Since the vast majority of deletes are intentional, it gets users in the habit of smacking the “Yes” button so quick that when they are about the delete the wrong thing, oops, too quick. Even if users do read the confirmation message, it’s not telling them something they don’t already know most of the time (that they selected file X and then selected  Delete). The only thing such a confirmation can potentially protect against is accidentally hitting the delete key or menu item, like in the example above. Here’s a little usability heresy: if your app has an easy way to undo deletes, don’t have a confirmation message. If you don’t have an easy way to undo deletes, your app is broken. Any reasonably usable app should have undo, especially for dangerous actions. Using a confirmation message instead is a band aid to a sucking chest wound of a usability hole. And Search should also search the trash (especially if it can’t find the file in the selected place). That way, when the user realizes something is gone days later (due to an slip of the key), she or he can find it and recover it.

Which brings us back to the CorelPaint message. The answer is not to do away with the message; users are not going to expect editing text to obliterate their formatting work. The answer is not even to add a “Don’t show me this again” checkbox to the message. The answer is don’t destroy the formatting when re-editing text. I mean, that’s just a bad design. A message is no way to fix it.

Here’s another in the same category:

Yeah, yeah, you say. You and Alan Cooper have been arguing for implicit save for years. But this one has a twist: I hadn’t actually made any changes to the file. Excel sometimes shows this message whether I’ve made changes or not. I don’t know how to react to such a message. I don’t think I made any changes, but maybe I did but forgot, so I better say Yes. Or maybe I accidentally hit a Secret Accelerator Key of Doom, and totally hosed the file, so I better say No. Either way, such messages teach users that a message is not a place to get helpful information.

(Click for full size)

Oddly, there was no option button for, “I didn’t plug in any device, you moron.” RealTek was forgetting what was plugged in between boots, so I was getting this message every time I booted. I never did learn why checking “Enable auto detection when device plugged in” didn’t, you know, automatically detect a device it thinks I just plugged in, and instead threw up this message.

But I shouldn’t just blame the backend developers for trying to patch broken apps with messages. It’s us user interface designers too. We make apps that are intolerant of user mistakes, relying on messages rather than self-correcting designs.

(Click for full size)

False Security

Suddenly I hear a few “Boings” and the poor girl saying “I keep trying to open it but nothing happens.” I look over and see her “ignoring” the Norton security warnings and about a dozen windows minimized to the task bar. I get up and look and she kept trying to open one of the attachments that sobig [virus] uses, over and over again. (Network World)

Why do so many designers think you can achieve security if you just have enough messages? There’s Vista’s User Annoyance Control, of course, which has garnered heaps of praise. But it’s hardly unique. Take for example security certificate warnings:

It doesn’t work. The vast majority of the time there is no threat, and the few times there is a threat, there’s no way to tell. And users soon learn this, and so ignore the message and click on through. Even Bruce Schneier. The Host Operations System and Transaction Integrated Logic Environment that I’m required to use at work always shows this warning at login. You wouldn’t be able to use the web if you paid attention to these messages.

As another example, consider the Page has Expired message (click for full size):

I’ve never understood how this message increases security. I’ve already sent my information. How can sending it again make it any worse? If all someone has to do is click Refresh to resend the information, how does this protect me from someone who sits down before the browser after I’ve left? I guess there must be some circumstances when I shouldn’t Refresh, but this message doesn’t give a clue on what it is. This is an example of an app asking the user a question they cannot answer,  rather than just doing the sensible default.

Well, just to be extra secure, if the user does choose to click Refresh, IE shows another message that essentially says, “I’ve told you to click Refresh to resend your information. Now that you’ve clicked Refresh, do you want me to resend your information?”

Yes! Just send the bloody information! Whatever the risk, 99% of the time when these warnings are shown, the appropriate response is to refresh the page. So how are users going to respond on the 1%? They do what they’re in the habit of doing. Soon such messages become part of the background noise.

Here’s yet another:

Same story, different message box. Is it any wonder that users ignore security warnings?

One on-line payment system would give overdraft warning message for every transaction, whether it represented an overdraft or not. There is no value in a warning that occurs almost always for something innocuous.

The IT department at my work is a full subscriber to the security through messages philosophy. First there’s this at every login:

Important to know, sure, but it’s covered just fine by orientation. Dismiss that message and I get:

Geeze, why stop there? Why not have me page through the entire employee handbook every time I log on? Please don’t get the impression that I’m loose with sensitive information on the job. Some data gets an extra layer of protection through TrueCrypt. Except I guess TrueCrypt is a security risk if I try to run it from a shortcut on my network drive:

Craftily, I moved the shortcut to the Start Menu, and the message disappeared. Aren’t I the 1337 h@kr?

Well, I guess I should actually get to work, starting with opening an Access database.

Does the file contain code that was intended to harm my computer? It doesn’t say, but I happen to know it doesn’t have any code -no modules or macros -since I created it myself yesterday. But I feel more secure getting this message to protect me from my own non-code every time I open the file.

Hang on, I just got an email. It looks like I got some comments back regarding a statistics procedure I wrote up for someone. Let’s see what they have to say.

Well, since I sent them the file in the first place, I guess I trust them. Fortunately, once I save this attachment to my hard drive, I won’t get that useless warning anymore.

That’s right, I get to see an entirely different useless warning message.

While I’m saving attachments, I might as well rearrange my folders a bit. You know what makes using a GUI feel real natural and fluid? Drag and drop. Like take these pics over here, and put them in the folder over there.

I’m sorry, but in the name of all that is sacred, WHY? From dragging and dropping files, for Pete’s sake! And what is anyone supposed to do about an “unspecified potential security flaw” anyway? Do they seriously expect anyone to take a message like that seriously?

I’m sure there are other places with pointless security messages. Let me check Google.

Oh, yeah, I get this helpful message everytime I submit any kind of form online, including Google. Various other actions in a web app will trip it too. As you can see, thanks to the override power of the IT department, checking “Do not show this message” has no effect. The checkbox is just there to taunt me.

A child would understand the folly of such warning messages. When you cry wolf often enough, people are going to ignore you. More messages mean less security. They just train the user that they don’t matter.

User Education

Some designers appear to have an inflated ego, thinking that if they could just tell users about their most wonderful products, surely users will start using them. Some such advertisements are of course more to benefit the product maker than the user.

Others are attempts to educate the user on the availability of important features.

But maybe, just maybe the reason why users aren’t using your feature is because it really isn’t remotely important to them. Why would a user want to interrupt their work to upgrade just because you think it’s necessary to do it right now? Keep in mind that any upgrade typically means:

• Time for a lengthy installation.
• Effort necessary to learn something new.
• The not insignificant chance that it will actually make things worse.

One day Word threw this at me while I was deep in editing a document:

Helpful, except that I wasn’t typing anything French. All I did was delete a period after the word “Yes.” In other words, installing the feature wouldn’t have helped me and could have resulted in incorrect autocorrections. The only education users get out of such helpful messages is that messages are not helpful at all. If some one suggest you put a message like that in your app, say, “Non, non, non.”

Resistance is Futile

Useless messages are the antithesis of the usability principle of User in Control. It’s the computer taking control, forcing the users to deal with a message at a time when the users are trying to do something else. Sometimes, it seems messages are used to rub in who’s the real boss of the human-computer relationship.

As it happens, I don’t have any files on that particular volume, so there was nothing I could do about it, but I still got the message box popping up in my face every minute until it was resolve. Yeah, dance for me, user!

I swear, sometimes they just toy with me (click for full size).

Gee, a vulnerability. I better install this patch right away. Except the Install button is disabled -the patch is already being installed… slowly and painfully. My job is to choose how often this message should return to annoy me. That’s a creative definition of User in Control.

(Click for full size)

This old message from MS Internet Explorer appeared for a homepage of a particular site, which means I got it every time I return to it. Click a link. Back. Get the message. Click. Click a link. Back. Get the message. Click.  Click a link. Back. Get the message. Click…. I get the feeling that Microsoft is trying to torture me into permitting ActiveX. You shall comply.

When you paste some records from a query result into a table in Access, you get this message if Access can’t resolve the query and table structures (click for full size):

For. Every. Record. You. Pasted. Turns out I was pasting 5000 records when I got this. There’s no button to suppress future messages, and no button to cancel the pasting. It doesn’t say what field isn’t working, so you can’t decide if you should cancel the pasting or not, if you could. The only escape is to kill the process with the Task Manager, which could corrupt the database table. On the upside, clicking OK 5000 times has made me super-fast at dismissing message boxes.

Sometimes apps take to lying just to demonstrate their control over the users. Like this time when I was renaming a file in Windows Explorer:

‘

The truth was the folder given did in fact exist and was in fact the location of the file I was renaming. Clicking “No” reverted the file name. Clicking “Yes” changed the name with no new folder created. How amusing.

Or how about this one from copying some text in an Acrobat document?

Who knows what went wrong, but sometimes copying would work without error, and sometimes not, even for the same selection of text. At times, I’d have to retry copying several times before I didn’t get this error. The joke, of course, was that there was nothing wrong with the copying. The selected text was placed on the clipboard without any problem every time. I’m embarrassed to say how long it took me to figure that out.

And somewhere in some CPU, the Master Control Program is laughing maniacally at me.

0×575446

Not satisfied with futile button clicking, some apps also seek futile message reading, using language or code incomprehensible to the user. For a while, I’d get two of these at a time at login:

The buried reference to the Conficker malware made me wonder if I might be unprotected or even infected. I called IT, and they said to just ignore it. That’s easy. I’m getting good at ignoring messages.

One day, one app started saying this to me at execution:

No idea what PROMSGS is or why it needed opening. Maybe it contained more useless messages for my enjoyment.

I’ve already discussed how bad terminology makes lusers. The point here is that geekspeak in messages train users to not read them. Why bother if they’re not going to be understandable?

For additional messages gone bad, see the classic Interface Hall of Shame. The more things change….

What to Do About It?

Given the current state of things, when users get a message box:

• What are the odds the users can do anything about it?
• What are the odds users actually should do anything right then?
• Even if they can theoretically do something, what are the odds that users will understand the message enough to know what to do?
• Assuming the users can understand the message and can do something about it, what’re the odds that the correct response is the default response anyway?

The odds are pretty slim that any careful reading of a message will result in a meaningful difference in user behavior. So from the users’ standpoint of just wanting to get on with their task without getting delayed or sidetracked, getting rid of the messages as efficaciously as possible can be seen as optimal behavior.

If we are going to continue to rely on message boxes to communicate with our users, we’ve got to substantially improve the chance that any given message box is worth paying attention to. We’re going to have to all follow some strict rules to maximize the chances that they are relevant and helpful.

Rule 1. Don’t use message boxes. Users will be less likely to ignore them if they weren’t so common. Message boxes should only appear for exceptional circumstances. It should not be necessary to read a whole lot of documentation each time the user uses an app. If normal use of your app results in a message box, then your UI is wrong. Find another way.

• Instead of verification messages, show clearly in the main window what has happened and provide a clear way to undo it.
• Use auto-correction, pictured/masked fields, and disabling rather than error messages.
• Use good defaults and automation to avoid messages. For example, rather than showing an error message saying the user can’t upload because they’re not connected to the server, simply reconnect automatically.
• Break commands along options. Rather than a message box to ask if the user wants to paste with or without formatting, provide two different commands in the menu.
• Don’t have information messages spontaneously popping up telling the user everything worked fine (e.g., “Preferences Saved!”)
• Don’t have pop-ups providing helpful hints or documentation. Provide a tutorial or balloon help if you can’t make your UI self-documenting.
• Don’t have nagging “upgrade me” messages.
• Use other means to display feedback and status information, especially modeless ones including notifications and on-page messages.

Rule 2. If you have to use a message:

• Make the text as concise as possible to get the key information across. More text is not equivalent to more helpful.  If there are some users who will need more explanation than can be achieved in a brief message, provide a Help button or a “How do I…” link in the message box.
• Use clear plain language and no jargon in the message. That includes “innocent” words like “dialog,” “database,” and “toner.” Do not take raw exception text and throw it in a error message. Do not include any error numbers or dumps; log these instead. Purge your app of any debugging message boxes left by developers. Better to simply let the app disappear on a fatal error than to put up a message full of jargon and then the app disappears.
• Consider giving each message a unique icon or picture to represent the issue. This may help users distinguish one message box from another at a glance. It may cue the user to look at a message more carefully when it’s one they haven’t seen before.
• Label the buttons of a message box with what the action does, not “OK” or “Yes.” At the very least, the users have to focus on the buttons to dismiss a message box. If that button is labeled something like “Delete” or “Install,” it should give them pause. You should never have to explain in your message text what each button does. By the way, such labeling is a GUI standard on most platforms.
• Avoid algorithms that allow a message to occur repeatedly without providing more information.

Rule 3. Imprison those that make pop-up ads.

Summary Checklist

Problem: Users don’t read message boxes.

Potential Solutions:

• Don’t try to make up for design problems with messages.
• Don’t attempt security through messages.
• Don’t use message to try to educate users.
• Recognize that modal messages violate the principle of User in Control.
• Make the appearance of message boxes a rare event. Rely instead on:
  • Preventing errors.
  • Easy means to see and undo errors.
  • Defaults and automation.
  • Separate commands for different options for an action.
  • Modeless feedback.
• Make better message boxes
  • Clear and concise text.
  • Label buttons with action that will be committed.
  • Avoid repeating same message box.
  • Make sure each message provides meaningful options in all situations it appears.