The Second Edition is out!
Visit designinginterfaces.com to read excerpts and learn more.

Command History

MATLAB's command history, shown in the lower left
What:	As the user performs actions, keep a visible record of what was done, to what, and when.
Use when:	Users perform long and complex sequences of actions, either with a GUI or a command line. Most users are fairly experienced, or if not, they at least want an efficient interface that's supportive of long-term or recurring work. Graphical editors and programming environments are usually good candidates for this pattern.
Why:	Sometimes a user needs to remember or review what he did in the course of working with the software. For instance, he may want to do any of these things: Repeat an action or command done earlier, one he doesn't remember well Recall the order in which some actions were done Repeat a sequence of operations, originally done to one object, on a different object Keep a log of his actions, for legal or security actions Convert an interactive series of commands into a script or macro (see the Macros pattern in this chapter) Computers are good at keeping an accurate record of steps taken; people aren't. Take advantage of that.
How:	Keep a running list of the actions taken by the user. If the interface is driven from a command line, then you have it easy -- just record everything typed there. See the example above. If you can, keep track of the history across sessions, so the user can see what was done even a week ago or longer. If it's a graphic interface, or a combination of graphic and command-line interfaces, then things get a little more complicated. Find a way to express each action in one consistent, concise way, usually with words (though there's no reason why it can't be done visually). Make sure you define these with the right granularity -- if one action is done en masse to seventeen objects, record it as one action, not seventeen. What commands should you record, and which ones shouldn't you? See the Multi-Level Undo pattern for a thorough discussion of what commands should "count." If a command is undoable, it should be recorded in the history. Finally, display the history to the user. That display should be optional in most software, since it will almost certainly play a supporting role in the user's work, not a starring role. Lists of commands -- oldest to newest -- tend to work well. If you'd like, you could timestamp the history display somehow. MATLAB, shown in the example above, puts a date and time into the history whenever the program restarts.
Examples:
A typical tcsh history UNIX and its many variants use shell programs, such as tcsh and bash, that keep track of their own command histories in files. The user can call it up with the "history" command, as shown here. The history is also accessible through various command-line constructs, like "!!" (reuse the last command), "!3" (reuse the command issued three commands ago), and Control-P, which you can issue repeatedly to show the previous commands one at a time.