Usability problem of the day (emergency exits in the interface)

In the courses I teach about human-computer interaction, I typically open each class with an example of a usability problem. I'm putting these online, in case others find them useful.

Jacob Nielsen offers this heuristic (one of ten) for designing a usable interface:

User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

I'm in the Macintosh Finder, looking through my file system. On the top right of the Finder window there's a text box with a standard search icon; I click in it (or press a shortcut key combination, Command-F) to search for a file somewhere within "Applications".

I start typing. Notice that if I decide to give up my search, I can click on the little x-in-a-circle cancellation icon that's appeared at the end of the text box. I could do the same with a keyboard shortcut, pressing the Escape key.

 But what if I give up by just deleting what I've typed? My emergency exits disappear. The cancellation icon goes away, and the Escape key stops working. I'm stuck here, unable to see my files, until I type something and then click to cancel or press the Escape key.

This is strange behavior. It's not quite the situation that Nielsen describes, but it's part of the same family of problems to avoid. I can use this example to illustrate a few lessons for my students.

The importance of finicky little details (yet again). How often do users find themselves in my situation? I imagine not very often. By analogy, though, how often do planes and buildings catch on fire? Again, not very often, but you don't hear airframe designers and architects talking about dispensing with emergency exits because of this. (The stakes are higher in those cases, of course, but in principle it's an argument about the tradeoffs between developer effort and end-user benefit. When in doubt, think about two things--resolving doubts in favor of users, and balancing the development team spending a couple of extra hours, perhaps, against the potential thousands or millions of customers who might save a few seconds. Time adds up.)

Undo is tricky. This may be surprising--undo seems like a simple matter of reversing some sequence of user actions, to put a system back in a previous state. Formal modeling research in human-computer interaction by Greg Abowd and Alan Dix has led to some unintuitive results. Under some reasonable assumptions, it turns out that a completely general undo function can be included in only the simplest systems--systems that only have two states. (You can carry out just one action, then undo it. Repeated undo's flip you between the two states.)

The value of interaction models. The graph (that is, the combinatorial graph) is a central concept in computer science, and it offers one useful way to think about a user interface. A graph can be used to represent each state of an interactive system along with the user actions that take the system from one state to another.

Dix et al., Human-Computer Interaction (Prentice Hall, 3rd ed., 2003)

We can use the structure of a graph to see how many actions or how much effort is involved in going between states--emergency exits should be easy to access, after all. Is an exit reachable with a single action in the all relevant states? There's a good deal of subtlety in deciding how to model interaction, but in many cases it's worthwhile.