The Menu Must Die

By uliwitness

[A menu in Mac OS X]

When the original Macintosh user interface was created in the mid-1980ies, development happened under an amount of constraints that we can hardly wrap our minds around anymore today. Add to that the foresight and genius that went into its development, and consider how well the Mac UI has held up, and it is not surprising that some things have remained unchanged and unquestioned over decades.

One of these great, and undoubtedly very characteristic aspects is the Mac’s menu bar. Different from other operating systems, there is exactly one menu bar at the top edge of the screen, where it can be quickly reached by violently shoving the mouse upward, making it as easy to reach as a mile high button.

The menu bar is a very compact container for hundreds of commands that need to be accessed quickly and frequently, but do not fit into a more reachable location, like as buttons in the main window, because there are more important actions already taking up room there.

However, looking at an individual menu, the constraints of the time become apparent: It is a display that seems too simple for all the complex behavior it contains. Part of it is probably just an attempt at mimicking the appearance of an actual, physical menu, to comfort a less geeky audience. But you can still see that part of the design was also engineered to be so simple that it could be shown and hidden quickly: Lines of text, the occasional separator.

[A menu with checkmarks in System 6]

But is this really a good, contemporary user interface?┬áThink of checkmarks: There is no way for a user to discern by looking at a menu item whether it will actually function as an action (pushbutton), toggle (check box), or mutually-excusive selection (radio button). Back when the only way to show a menu quickly enough was to save the pixels underneath it so they could be restored after drawing the menu directly into the back buffer — instead of going to all the effort of creating and tearing down a window, that was a clever optimization.

But why are we still doing that today? Our menus are actual windows, menu items can be actual views, and we spend cycles like mad to composite our menus with transparency. Most of the differences between menus and windows have gone: We have multi-tasking now, so the OS needn’t stand still while a menu is open. It has been found that holding down the mouse to keep a menu open and then releasing is too complex and error-prone an interaction (though it was originally intended to make every menu command reachable with “only one click”), so we can now click once to open a menu, and a second time to select something.

[A Popover window on the iPad]

And the iPad (where you don’t have a mouse pointer, and thus things at the edge of the screen are no easier to reach than those closer to the center by shoving a mouse towards them) actually has pop-overs, menu-like constructs that pop up from buttons and contain regular user interface elements. This is what should be brought “back to the Mac” with Mac OS X “Lion”.

We no longer need spartan text lists, we need pop-up windows containing recognizable user interface elements for quick access. Be it pushbuttons, checkboxes and radio buttons (like we have them already in menus, by function if not appearance), search fields (like Spotlight), or sliders.

Maybe we should even take the time and bring back tear-off menus (available in HyperCard on System 6 and before, on NeXTstep, and planned as a major UI element for the aborted “Copland” version of Mac OS 8), which can serve as both quickly accessed menus or floating palettes, whatever the user prefers … ?

[A tear-off tools menu in HyperCard]

7 Comments Leave a comment

  1. Windows is already moving away from “traditional” menus. Looking at the applications that ship with Windows 7, you’ll rarely find a menu bar visible by default (they’re still an option for those who want them), and the menus gotten by clicking controls and right-clicking are often filled with rich, interactive controls.

  2. @Daniel, what are you, a Windows user? ;)

  3. I wholeheartedly agree. Maybe we can rethink toolbars at the same time. I like the way menus use a text label, which usually give a fairly good idea of what the menu contains. And I like the way toolbars are customizable. But do we really need both (especially when toolbar controls generally duplicate something available in the menus)? Maybe one UI concept for contextual and another for non-contextual operations?

  4. I had an idea here on getting rid of the menus. I guesture should bring up a modal type lay over with menus large displayed in the middle of the screen.

    http://idea.wirus.com/article/The_Paper_GUI_User_Interfaces_in_the_Age_of_the_Trackpad__Put_It_Under_My_Pointer_Not_On_The_Edges_Of_The_Screen_125

  5. For a minute I thought you were proposing to get rid of the menu bar altogether, which would immediately send me into convulsions.

    Adding richer UI elements to the menus is an interesting idea. The issue I see is that richer UI elements show information that shouldn’t be hidden down in a menu hierarchy. Text menus are great at organizing commands but any widget that provides feedback is probably better in a toolbar or window.

    Microsoft is making a huge mistake in replacing all menus with the huge ribbon toolbar. What a waste of screen space and disaster of usability. I’ve never been able to quickly discern the meaning of all those cut/copy/paste icon buttons, and now they’re multiplying the visual clutter while continuing to avoid any benefit from Fitts law.

  6. How often do you pull down a menu and think, “this just doesn’t cut it!”?

    My guess, rarely, if ever.

    Mind you, I certainly wouldn’t mind seeing the kind of changes you’re referring to, but my guess is that such changes aren’t really needed, and therefore probably won’t happen anytime soon.

  7. Eric C, by that rationale, we could leave away color, because it isn’t needed either. We could leave away graphical user interfaces…

    Is this a suggestion for a fairly incremental change? Yes. Does it help the UI get out of the user’s way, fade into the background? That, too.

    Usability is the art of making your program get the fuck out of the users’ way and letting them concentrate on their work.

    Every small bit helps.

Share your thoughts