Kevin Schofield brings up an important point: Menu bars work well up to a certain limit of menus, menu items and submenus, but what happens if your applications has so many features that you exceed this limit?

Says Schofield:

If you go back through the annals of those decades of UI research, you’ll find that the classic drop-down menu was designed and proven to be highly effective for 7 plus or minus two items per menu. And it was proven to only be effective for 2 levels of depth.

Emphasis mine. And indeed, those limits appear to be the general consensus amongst Usability experts.

You can easily check this for yourself: make a shopping list with 7 items, give or take two, and you will be able to “scan” over it with your eyes with a brief glimpse. Make a shopping list with 10 or more items, and this won’t be possible for the average human. Instead, you will be forced to go over the items one by one.

The limitation to two levels (i.e., the menu bar, a particular menu, and a submenu within) is there for a different reason. The deeper the level, the more difficult it becomes to navigate with the mouse, which is the primary input device for a menu bar. (A keyboard, on the other hand, doesn’t have increasing complexity for submenus, but is generally less convenient to use in this context.) For the average user, a submenu is already a difficult interface element to deal with; most notably, users tend to accidentally close submenus by moving the mouse cursor in the wrong direction.

In other words, these recommended constraints exist for a reason, and applications that ignore them are harder to use. Users will often refer to this as mere “clutter”, but their real problem is the inability to use overloaded menus efficiently.

When a software development team stumbles upon this issue, what can they do?

1. They can move off to dialogs.

   Safari 1.0, for instance, had a “View” menu with several items such as “Reload”. Using spaces as indentation, its menu items in fact appeared to have a hierarchy while avoiding submenus — this non-standard behaviour seems to become more common at Apple (cf., for instance, Mac OS X’s Apple menu’s “Recent Items” submenu, which uses disabled menu items as ‘categories’ and enabled but indented menu items for the actual ‘items’). The items’ purpose was to show or hide particular toolbar items. Yet OS X already has a perfectly fine toolbar customization sheet that is more flexible — it allows various display modes, lets you change the order using drag&drop and allows for adding separators — and, in this case, cleans up the “View” menu. For Safari 2.0, Apple has realized this (though Safari’s customization sheet, for some reason, lacks certain features), and the View menu, while still having 10 items, feels much ‘lighter’.

2. In certain cases, they can get rid of the function altogether and try and make it automatic (enabling / disabling where reasonable or applicable).
3. Finally, they can ponder whether the application might just have too many features, aka the “all-in-one” phenomenon.

All-in-one applications were popular in the 1990s — cf. ClarisWorks or Microsoft Works — because interaction between software wasn’t as appealing and multi-tasking didn’t work well. These days, however, they should be a thing of the past. ClarisWorks (now AppleWorks) is dying a slow but sure death, being replaced by stand-alone iWork applications. Similarly, Microsoft Works has been updated not by adding more features to the app itself, but by bundling several separate applications, such as Word.

This recent development of separating applications by their tasks, however, should in my personal opinion be taken further. Take iTunes: what used to be a playing and organizing application for songs with a streamlined “rip, mix, burn” process now stores PDFs (for album booklets), plays video clips (mostly for music videos) and syncs contacts and calendars for your iPod. And Apple continues to aggregate more and more features into this application. It has never been a lightweight audio player, but now, it is becoming even less of one. The “Advanced” menu is really a dumping place for “features that didn’t fit elsewhere”, and you find items like “Show Search Bar” and “View Options” in the “Edit” menu, even though they don’t edit anything. (A “View” menu, for no reason, doesn’t exist.)

As I have mentioned in my response to Schofield, FinalCut Pro gets this right. (I have never used it myself, though I have seen demos of it.) The main purpose of the application, importing and editing video, stays within the application; it can fully concentrate on that. Any other purpose is “moved outside the box”: converting is done by Compressor, creating crazy font effects is done by LiveType, Soundtrack Pro takes care of, well, adding soundtracks and finally, DVD Studio Pro handles outputting the movie to a DVD Video. And all the while, those satellite applications don’t lose functionality: Soundtrack Pro, for instance, interacts with FinalCut Pro enough as to show you a video preview, making it easy to sync your background audio with what’s seen. So you gain space in the user interface elements sense, and you don’t lose functionality — in fact, the gained space can be used for even more functionality you otherwise would have left out.

iTunes could have such ’satellite applications’. In fact, it used to: syncing contacts and calendars used to be done by iSync, though I suppose Apple’s problem with that was the non-availability of that on Windows (I don’t know how feasible it would have been to employ ActiveSync technology), so they integrated the feature into iTunes. An easy solution, to be sure, but a wrong one.

When you store movies inside iPhoto, it uses QuickTime Player to play them. Yet when you store movies inside iTunes, it plays them on its own.

“Every man to his job”.

Since Schofield and I were discussing Office 12, why not extract features such as WordArt into their own applications? Give them their own menu bar and their own ’space’.