Off the Beat: Bruce Byfield's Blog

Interfaces for traditional computers and mobile devices have become increasingly inventive in the last few years. So far, however, none have solved a basic design challenge: designing an efficient menu.

The challenge rarely exists within applications. An application usually has half a dozen or more top level menus, each with less than a dozen items, so a drop-down system is usually good enough.

But on the desktop environment, the norm has always been to have a single menu that lists all applications, and often shut-down commands, a list of favorites, and a few other items. 

To function well, each variation needs to make items quick to find and to distract minimally from whatever else the user is doing. Unfortunately, while a solution may do one of these things, none of the available alternatives manages to do both at the same time.

The main solutions to this dilemma are:

The Classic or Traditional Menu

Probably, every computer user has seen this type of menu. It lists every available item in a drop-down list, with each sub-menu opening in its own list, spilling across the page. The ultimate example is the Debian menu, which is four or five menus deep in some areas.

The classic menu was the first to reach the desktop. In the days of limited hard drive space, it allowed users to find items quickly -- so quickly that, although its accordion-like folds of drop-down lists took focus, users could return to an already open application with a minimum of delay.
However, with larger hard drives allowing more applications, the classic menu became increasingly unwieldy. Stopgap measures, such as lists of recently used applications, user editing, and increased organization of top-level categories could only delay the inevitable melt-down. Microsoft Windows even tried menus that by default displayed only the most commonly used items, but the confusion created by ever-changing menus pleased no one.

For a while, some distributions tried listing only some applications in the name of not overwhelming users. The GNOME 2 release series tried to lighten the load by dividing the main menu into Applications, Places, and System.  Despite these efforts, by five years into the current century, the average classic menu contained so many items that it was no longer efficient. The classic menu's familiarity means that it continues to be popular, but developers began searching for alternatives.

The Contained Menu

Contained menus are similar to classic menus, but are kept confined to a single dialog window. In some cases, the window can be dragged to a larger size, although I suspect that most users are unaware of the fact.

This solution keeps the menu from obscuring other windows, but at the expense of navigation. Opening a sub-menu means either that one sliding panel replaces the other or else another row of items is created that is smaller and harder to read. Sub-menus may also scroll, concealing some or all items.
The extent of the difficulties that the contained menu creates is the number of additional features that its implementations require. Almost all of them include a search field, and many include extra filters and icons. These features are not difficult to learn, but they are a sign that contained menus are not as easy to navigate as classic menus.

All the same, contained menus remain popular with developers. However, given the popularity of GNOME 2 recreations, as well as the fact that, four years after introducing contained menus, KDE continues to offer classic menus as an option, they are probably less popular with users.

Full-Screen Menus

Full-screen menus are an obvious choice on mobile devices. In the last few years, they have been added to interfaces intended for workstations and laptops as well, such as Ubuntu's Unity or GNOME 3 with its overview mode. Typically, they overlay the entire workspace, presenting an icon view of available items.

Full-screen menus often include filters and scrolling, but on the whole they allow users to find items more quickly than classic or contained menus. The difficulty lies in reaching the needed display. Full-screen menus always seem to require far more clicks than classic or contained menus, which is slow or confusing for users who have more than one app open at the same time. Often, users are reduced to frantically clicking the back button to return to their starting point.

The most functional full-screen menu I have seen is in KDE's Plasma Active, in which the menu is pulled down from the top edge of the screen, then retracts when no longer needed. This setup improves navigation immensely. Still, the distraction from the tasks at hand remain.

Other alternatives

Plasma Active also uses a pull-out spinner for choosing Activities. Occupying only a small part of the work space, this solution balances ease of use and minimizing disruption. However, I suspect that, like the classic menu, this solution works best with no more than about a dozen options. More options or more spinners, and the solution would probably become far less elegant.

Another alternative to menus is the Head Up Display (HUD) introduced in early 2012 in Unity. HUD replaces menus by typing with auto-completion. This solution is ingenious, and might be useful for experts or those who need to minimize repetitive stress, but it is hard to imagine it becoming a major solution. As Ubuntu's Mark Shuttleworth admits, its main problem is that, unlike classic menus, it fails to offer a complete map of available options. In addition, it is as disruptive as a full-screen menu.

Other alternatives exist, like KRunner, which offers a field for entering commands. However, like HUD, it seems more of a solution for experts than anything that is about to become widely used. 

In the end, the same is true of all the minor alternatives.
Getting creative

What the major alternatives have in common is that they all assume a single, centralized method for picking applications. However, since none of them is completely successful, I think some creative thinking is overdue.
For example, what about a menu panel that contains top-level menus? Especially on wide screens, there would be plenty of room, and all the advantages of the classic menu -- which, in its early days, was probably the most successful of the major alternatives -- would be restored on workstations and laptops, although not on mobile devices.
And while we're rethinking, what about persistent filters that are resumed with each log-in? For that matter, why should a modern desktop be confined to a single menu? The KDE 4 release series introduced swappable icon sets. Why not have swappable menus, each one customized by the user for different purposes, or, in KDE, associated with a particular Activity? 
These are only the first ideas that occur to me. How practical or acceptable they are might be another matter. However, the point is that we can do better than any of the existing menu alternatives. 
The effort is long overdue.

Comments