On the menubar
February 20, 2010
KDE developers are currently discussing whether Rekonq could replace Konqi as KDE’s default web browser. I’m glad that this discussion has not (yet) turned into a flamewar like we saw in the days when Dolphin replaced Konqi as the default file manager. Instead, people are mostly discussing whether Rekonq is up to the task it is supposed to fulfil, and many people are arguing against that (including the Rekonq developers themselves!).
As you might already have concluded from the title, this blog post is only going to deal with a tiny detail of the whole discussion. Let’s start by quoting a mail by Eike Hein on the kde-core-devel mailing list:
[Rekonq’s] user interface also strays far from the path established by our other standard applications and the HIG. You’re going to have to make a good case for why our interface standards are not supposed to apply to our default web browser.
For those who do not know that yet, “HIG” stands for “Human Interface Guidelines”, a set of guidelines provided by desktop creators such as KDE, Microsoft and Apple, which allow third-party developers to create applications which fit into this desktop just like apps created by the original manufacturer.
In one of the following mails, Eike expands on his point:
I think our HIG is really important to the KDE SC’s identity as an app platform – we’re not just a set of libs, we’re a user experience with its own set of conventions – and we should really take care to manage that responsibly and not lose cohesion.
At the same time we also shouldn’t be afraid to evolve our interfaces, of course. It’s a fine line to walk.
I totally agree. Actually, we observe divergences from the classical menubar-toolbar-statusbar concept in many applications these days. Examples include Google Chrome, Firefox and Bangarang. What do we observe?
- Web browsers tend to replace the menubar by one or two drop-down menus (see Rekonq screenshot above, or Internet Explorer 7/8, for instance). Many also move the toolbar below the tabbar, because the state of most toolbar controls (adressbar, Back and Forward buttons) strongly depends on the state of the tab.
- Media center applications abandon the menubar/toolbar/statusbar concept completely and build their interface around the video viewport and the player controls. This trend is actually not new, it dates back to the 1990s.
The central question is: Could applications from other genres could also benefit from this trends? (Now, before we continue, the disclaimer: I am in no way a usability expert or educated interface designer. I’m just an application developer with some practical experience on interface design.) From my point of view, the menubar has three key conceptual advantages:
- A menubar can organise very many actions. While a growing number of actions may be an indicator for featuritis, it is also inevitable for a large number of applications, mostly professional ones (see e. g. KDevelop, SciDAVis).
- Compared to other interfaces that may accommodate a large number of actions and tasks, the menubar saves screen estate. For example, MS Office’s Ribbon consumes more vertical space then a menubar plus a toolbar. This is bad especially for small netbook screens or other compact form factors.
- The menubar has good accessibility. It contains very much text, which makes it a good target for screenreader software, and it has a coherent keyboard access scheme across all applications (Alt key + a series of letters highlighted in the action labels, or the shortcuts presented at the right of each action).
The main problems of the menubar are the discoverability of single actions (carefully crafted context menus usually perform better), and that most of its contents are duplicates of actions that are already available elsewhere.
With the menubar having many important advantages, but also quite some disadvantages, it might be time to rephrase the central question I’ve asked earlier: Is there a way in which we can evolve the current menubar into something that addresses these problems while retaining the conceptual advantages of the menubar?
The second part is the one that I’m missing from most current concepts. Most available concepts are crafted for single applications with a relatively small number of actions and a workflow that does not heavily rely on the keyboard (at least for most users). What I’m looking for, is a HIG-compatible approach: a design that also works for applications with a big number of actions or a keyboard-centric interface.
Instead of philosophizing any further, I’m going to present a possible solution. It may not be the perfect one-size-fits-all solution, but I hope that I can at least get a discussion going, or get some code written.
If you’re regularly following this blog, you know my jigsaw puzzle game Palapeli, which has just been released as part of KDE SC 4.4. Palapeli also diverges from the classical menubar, or better: it extends the classical menubar concept. When building the interface, I noticed that Palapeli consists of two disjunct parts: the puzzle collection (basically a list of all puzzles on your computer) and the puzzle table (where you play the puzzles). I organised both areas into tabs, and just like Google Chrome moved its toolbar inside the tabs (because, as I mentioned above, the toolbar state heavily depends on the tab content), I placed the toolbuttons for both views directly inside the tabs. Now I was left with a tabbar with only two tabs, and a menubar with only two menus (“Settings” and “Help”, as provided by default for all KDE applications).
The original reason for merging tabbar and menubar was to save some space. However, I think to have found a concept which can be generalised much further:
- Apps with a tabbar merge that with the menubar. If the app has a variable number of tabs (e. g. webbrowsers), the menus are concentrated at the left, to have their position fixed at all time. Dynamic tabs pile up left-to-right just as usual. There may also be static tabs (like Welcome pages, or like the two areas we saw in Palapeli), which can be mixed into the menus at the left.
- If the number of dynamic tabs is greater than what the menubar can display, only the dynamic tabs can be scrolled, the menus and static tabs are always visible (at least unless the menubar is shrunk too much).
- Even apps that do not have a tabbar currently could consider to add tabs to their menubar. Complex interfaces could offer multiple tabs with interfaces that are optimized towards one task or towards one group of tasks.
- The tabs could also have drop-down menus, just like the classical menus inside the bar. When you click on the tab for the first time, the tab will be opened. Click a second time, and the drop-down menu is displayed. Alternatively, one can click and hold the mouse button for a short moment to get to the menu directly.
- The thing that I like most about this concept is the backwards compatibility: If the tabs do totally not fit into an app’s workflow, the developer may just use the menubar as he did before.
I’ll conclude this very long post with a simple mockup of my “SuperMenubar”…
…and an example: How would Rekonq look like with a SuperMenubar? The tabbar would be moved to the top, and the “Tools” and “Bookmarks” buttons in the toolbar would become menus again. These menus would be inserted in the tabbar at the very left to form the SuperMenubar.