Long Live Menus!

(~2003?)

For a long time I've been of the opinion that the first law of user interface design is "put all functions on menus." This position was born out of years of coping with hidden keystroke functions, INI file settings, command line workarounds, and so on. But as user interfaces have become more sophisticated and graphical, and programs have become more multi-functional, it's no longer so simple a statement to make. I think, however, that the principle remains as true as ever. To this day, failure to put functions on menus is one of the most common mistakes, often forcing users to dig through some hidden resource to uncover needed features, whether they're buried treasure or land mines.

For instance, I was re-introduced to a feature of Microsoft Word just recently that inspired me to examine my First Law in the dawning light of the new millenium, as post-PC computing enters its 29th year. The feature at issue is called Spike. Do you think Spike is:

A) The dog on Rugrats.
B) A device used to end your pesky vampire infestation.
C) A variation on the Windows Clipboard used to accumulate multiple "cut" actions.

With apologies to Tommy and Chuckie, the answer is C. If you actually use Spike, you are either a real techno-explorer or a full-time cutter-and-paster because Spike is undiscoverable by ordinary means. Spike let's you repeatedly cut to the clipboard without replacing the contents of the Clipboard, so you can accumulate pieces of text and then paste them somewhere else as a group. Some years ago, I learned about Spike wandering through the online Help.

In some recent work, I finally found a use for Spike after about six years using Microsoft Word full-time. I was curious how many of my immediate co-workers would be aware of a feature that had no representation on the menus. Cutting to the chase, the answer was 2 out of 15, both the most technical of the group. Whether you believe that drop-down menus are God's greatest gift to computers or not, the point is that Spike is not put in front of users' eyes as they browse the repertoire of Word. Here's what a menu item for Spike might look like (without every UI convention such as hotkeys on the right):

Before continuing, a few remarks. First, I'm guessing that Microsoft Word might be the most used application program in the world. So it's not merely coincidence that I'm using it for a usability lesson. Second, I happen to think that Word is probably the leader for both the best and the worst usability. (It has some of the best "direct manipulation" features of any program. On the other hand, consider how many millions of hours have been lost untwisting its maze of template and style behavior alone.) Good ol' Spike combines a multitude of sins.

• First, there's its lack of menu support-invocation.
• Second, it uses a nickname instead of a descriptive, functional name.
• Third, it uses what I call special values: to view the text on Spike's clipboard, you have to use the AutoText function and look for the entry named Spike. It's a special value because it's an AutoText entry that you didn't create; the display function should be on a menu, not as a unique contrivance in an otherwise unrelated list.
• Finally, Spike didn't even accomplish what my two co-workers (the only ones who knew Spike) wanted-they wanted first-in-last-out processing. (Even I wanted something slightly different than Spike's standard fare… I wanted cumulative copy and paste, so I ended up doing an Undo after every cut.)

Back to our discussion of menus. First there's the issue of clutter; some critics would have us believe that this feature is too detailed and should be hidden if not removed altogether. I disagree. Despite arguments about being overwhelmed by complexity, the enemy is not complexity, but its presentation. I fondly remember an article that considered our current-day automobile. Aside from some confusion with windshield wiper controls when renting a car, cars are incredibly easy to use yet staggeringly complicated machines. Complexity is an easy scapegoat.

Then there's the issue of whether drop-down menus are a relic of the past, as we see more graphical substitutes. I've recently been working with a program from Asymetrix called Librarian, a wholly Java-based interface that makes me realize I have to reconsider my mandate for menus, or at least my choice of words. Librarian doesn't have conventional menus, instead opting for a multi-pronged attack: it combines tab pages, an outline control, context relevant icons, and a second set of tab pages. Here's what it looks like:

This isn't a menu, but it has the same effect as a menu structure several levels deep… and it has the same usability. If it isn't a menu, exactly what is the common denominator? It is this: all functions are available by browsing. Let's look at the criteria more carefully. First, the functions are visually presented… they are on the screen in the main navigation interface, unlike poor lost Spike or an INI file. Second, the order is functional, meaning you can quickly zero in on the task you want because of its proximity to associated tasks. Finally, the names of the functions appear within two or three seconds, quickly enough to encourage exploration. Call them whatever you want, they serve as menus.

In my recent meandering on the Web, I've noticed that, despite efforts to abandon them, menus are far from dead. My daytime company's Web site, for instance, has drop-down menus created with JavaScript, and Microsoft's site has succumbed to the supreme service rendered by the lowly menu:

Both do so because menus are the best solution for the problem. Yet somehow in the computer industry we have a prejudice against any technique more than a few years old. Perhaps it's my writer's background but I politely point out that tables of contents and indexes have been the best techniques for many hundreds of years. Only on the Web do we ignore the lessons learned and come up with new names like "map." This same modus operandi is why menus are apparently seen-by some but not me-as too pedestrian, too boring to suffice for modern interface purposes. I don't think so. I think that, just like tables of contents and indexes in paper documents, menus will survive for countless generations. Eight thousand years from now, when we software people are trying to solve the Y10K problem, and arrogantly saying as we said in 1980, "my code won't last that long," we'll use drop-down menus to facilitate our obfuscation.

I struggled recently to update my First Law to encompass more modern interfaces like Librarian, but the wording got bogged down by its own weight. Do you agree with my First Law? If so, can you suggest simple wording that will grow with the technology? Or, do you have a better one?