Menus

Traditional menu bars are being removed or replaced in some application designs, including single menu buttons of various descriptions. Let's use this page to discuss and develop design patterns for alternatives.

The design of menus for three GNOME applications feature here: Nautilus, Eye of GNOME, and Epiphany.

Menu bars

The traditional menu bar.

Advantages

• Provides a consistent set of disclosure points across windows.
• Are able to include a high proportion of the actions made available by an application.
  • Means that common operations like cut/copy/paste can be found in the GUI.
  • This means that a menu bar can provide an overview of the functionality provided, and that users can use them to learn an application. Question - does this actually happen?
• Make keyboard shortcuts discoverable.

Disadvantages

• Menus have a tendency to grow.

• They provide multiple disclosure points, meaning that it can be difficult for users to find the option that they are looking for.
• They take up vertical screen space.
• Menu headings and groupings often don't make sense.
• They look bad.
• They sit at the top of the window, distracting a user from content and instead emphasising actions/functionality.

Menu buttons

A single button that activates a menu.

Advantages

• Provide a single disclosure point.
• Don't take up vertical space.
• Can only accomodate a limited number of items.

Disadvantages

• Could be difficult to find a consistent location for these in windows.
• Unable to show keyboard shortcuts for all operations.
• Can only accomodate a limited number of items.

Open questions

What is the best place to position these? They would need to be consistent across applications.

What should the button look like? They probably need to be an icon with a disclosure triangle.

Variations, real and otherwise

Google Chrome

• Clever consolidation of cut/copy/paste, zoom and full screen < the problem is that you lose the keyboard shortcuts

• Spanner icon on the button...
• It is overpopulated
• Submenus!

Firefox

• Overpopulated. The two pane approach is an attempt to deal with this, but the logic of what item goes in which pane isn't entirely obvious.
• Dual pane does not work particularly cleanly with submenus.
• Use of disclosure arrow on the menu button is effective, but the string 'Firefox' confuses the distinction between window-orientated and application orientated actoins.
• Combination of buttons and sub-menus is difficult to decipher.

Firefox Concept

GNOME Menu Button Concepts

Eye of GNOME:

Some notes about the design of this one:

• It punts application-orientated actions to the app menu. Hence no About, Help, Preferences.
• It has lost some items which are probably quite useful:
  • The recent files list (really don't want to use a submenu here).

  • Open With >

• More or less any actions which are present in the GUI have been excluded (zooming, for example).

Nautilus:

Epiphany:

Analysis:

• The key question with regards to this model is whether it can successfully accommodate the full range of essential menu entries, without spawning nasty submenus.
• One thing about these menus that isn't so great is the lack of clarity over groups of menu items. Clearer groups with headings would make the menu more intelligible.

Mega Menus

See: http://www.useit.com/alertbox/mega-dropdown-menus.html

• This approach has some similarities with menu bars, and comes with the associated pros and cons:
  • There's room for overpopulation.
  • Forcing entries into groups risks (a) groups that don't make sense and (b) not leaving room for entries which don't have a place in the grouping schema.

  • But:

    • Headings do make entry groups easier to parse.
    • Similar approaches have performed well in usability tests.
    • It gives a bit more flexibility than the simple menu approach (see above).

See also: http://www.useit.com/alertbox/mega-menus-wrong.html

Problem spaces

Issues to be considered in relation to the design of menu bar alternatives.

Learning keyboard shortcuts

Menus provide a way to view the various keyboard shortcuts used by an application. It would be nice to replace this with something that is more effective.

Ideas:

• Cheat sheets - could we generate a document for each app? Could these be automagically generated?
• A visual overlay - would work well using the Alt key as a modifier, since this already displays menu mnemonics.

Contextual action discovery

Context menus are a heavily used way to access common actions made available by menu bars (such as cut/copy/paste). Making contextual menus/actions more discoverable could enable some actions to be removed from window level menus, such as cut/copy/paste.

Ideas:

• Provide a GUI when text and other content is selected. See Selections

• Adaptive contextual menus - see the Nautilus future designs for one such concept:

Discussion

Menus at the bottom of a window has a problem of habituation. The menus will open upwards if the window is too close to the screen edge and open downwards otherwise. Putting the menu on the top avoids this problem.

Comments

I think menus are a very important part of design for GNOME to look at. I really like the mockup with the gear icon just like Google Chrome, and would love to see Chrome-like menus as a standard part of GNOME apps. However, I don't like the cheat-sheet idea, as it is more natural to discover the keyboard shortcuts within the menu. Few users will want to read a whole list, and even fewer will actually remember the shortcuts.

The single icon menus do not work at all for me, I find it extremely difficult to figure out what the various icons mean. There is a reason I have the chosen both icons and text for the toolbar style. This new menu style is making it difficult and frustrating to use applications. Would it be possible to allow a user to set an option of using the older menu style or at least have both the icon and text for the menus?

The MegaMenu needs to be more explored because not only it removes the clutter within the applications, it also provides the bonus for being touchscreen friendly for the future. With the advent of popover, why not expanding the functionality. While the megamenu may only works for Gnome Shell, gracefully falling back to the traditional menu. I orginally posted on Fedora Desktop mailing list until I learned the existence of this wiki. - Luya Tshimbalanga

Another attempt at resolving the menu issue for Gnome Shell tentativelly called Hybrid Menu. It combines the best part of menus seen above. The concept is similar to fullscreen mode where menu will appears by clicking of application on top bar. The main menu will display either main elements from popover. - Luya Tshimbalanga

• hybrid-menu.jpg

About the apps that are using the traditional titlebar-menubar scheme, we can treat it as a title-subtitle pair where the menus are shown as clickable subtitles. As a further modification, we can shrink the entire menubar to a hamburger button when the width of the window is too less. - Ajinkya Dahale