The Problem of Menus
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 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.
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.
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.
The Problem of Menus -- But perhaps it's the wrong problem!Amen (Many times) to Lorin Ricker Nov 20, 2012.
To me, this comment hit it right on the head. The 'old-fashioned' menu system is very intuitive, easy to use and needs little a priori knowledge since it provides clues (a list of possibilities). Unfortunately this list must be too long and needs user trimming and reordering. Systems which are 'optimised' are bound to be unsatisfactory since different people have differing likes and needs. Unfortunately it is the more competent users who will gain most benefit from new selection systems while being most likely to be annoyed by them. Give users some credit (and some clear advice about what to do - not nerd-speak with a reference to BASH commands!).
The Problem of Menus -- But perhaps it's the wrong problem!Good article, taking a run at the root problem(s) of menu systems. But the analysis likely does not go far... or deep... enough, thus begging the same-ol', same-ol' question.
Seems to me that the (possibly false) problem that menu systems keep trying to solve is that of "Displaying all available choices, all of the time." In other words, menu systems keep evolving as a means for each installed application (utilities, component, etc.) to contribute its icon to start the corresponding app (utility, whatever, etc.). Thus, a menu system contributes or accretes to a solution-perspective which is partly developer-centric and partly total-system-centric (i.e., the aggregate of the installed components on a particular desktop, laptop, mobile or server). These perspectives both ignore, or at best under-represent, the _users's_ true perspective and needs... The only use-case that most menu systems address is the question of exploration: "What are all the apps currently installed on my system?"... but certainly they do _not_ address the issue of access to "What do I need right now?"
More than anything else, what does the user *really* want? Certainly _not_ access to "everything, all of the time." A user develops specific work patterns, and has specific needs, based on her/his tasks and focus of the day, or moment. She wants "the app she wants, when she wants or needs it." This does not mean a naively "adapting" menu which just "shows the most-frequently &/or most-recently-used" items... Simple "most-*" algorithms are partial and unsophisticated approaches to true adaptability; they lock us into use-modes that are as bad as searching through a whole-pile-everything classical, contained or full-screen menu. Furthermore, most users' needs evolve, develop and change over the long(er) haul -- our focus of attention can: a) simply grow and expand; b) shift about somewhat cyclically; or c) just change from one thing to another.
Rather than "everything available but easy to use", or even "adaptable", I think that what users _really_ want is simple: True customization and personalization on a do-it-yourself basis. This is what GUI/desktop developers *should* be focusing on, from the outset: Providing clean, easy/intuitive-to-use, simple-to-manage, mutable, robust and reliable means to take a basic/bare-bones desktop (regardless of whether or not this includes a "menu system" and evolve it into pretty much whatever the user wants or likes... within some basic design constraints, of course. Whether this involves menus, panels, spinners, desktop icons, or other wonderful widgets is in the purview of the GUI developer/designers... Just make it *customizable* by the end-user, out of the box -- and as a primary design goal, not an afterthought or accident!
Need proof of the need? Just look around your local Starbucks at all the laptops that are open... See all the icon-cluttered desktops, regardless of Windows, Mac or Linux? Yup, cluttered full of app- and doc-access icons, perhaps >60% of which are "broken links" or obsolete and abandoned. But just try to "intervene" and clean up a user's personal desktop -- you'll pull back a bloody stump for your efforts!
Developers! Instead of trying over and over to sell us *your* latest magical menu/GUI desktop, concentrate instead on providing a functional, reliable, usable and *customizable* environment -- one with how-to-customize-and-use-it tutorials (documentation), the means to add-in new application widgets on *our* terms, plus the tools to back-up and restore the environment should your (or another team's) next upgrades corrupt the whole thing -- give us reliability, usability, extensibility and -- mostly -- give us customizability!
But you can still be a non-voting “individual supporter” if you pay the money
Several current systems could fall victim to the attack
Latest Linux engine comes with better graphics and support for Intel's new power-saving chips.
Hackers send a message of beauty and liberation to server logs
Citrix gets excited about new Pi-Powered XenDesktop client system
Linux on Azure cert heralds a new era for Redmond.
Proposals for presentations at the CeBIT Open Source Forum will be accepted through 24 January 2016.
Adobe looks for a new start; renames its embattled Flash tool.
The Pi's popular Raspbian OS pursues secrecy without entropy.
VMware bids for a stake in the container industry with a bold effort to integrate containers with its classic virtualization system.