Are there any standards to follow in determining where to place menu items?

Question

In developing Windows forms based application, are there any standards that should be followed when designing your form's main menu system?

Most windows applications with menu systems will have your standard File | Edit | View | Tools | Help menus. How do you determine placement of any additional top level menu items?

In addition, how do you determine placement of sub-menu items? For example, what rules or principles would you follow to determine whether an items should be placed in the Edit, Tools, or maybe your own non-standard top-level menu?

I am looking for two things here:

1. Published resources (web or print) that detail this (especially if it is from Microsoft), or other material from UX or UI professionals.
2. Your own opinions.

Based on a response by Gamecat mentioning the Ribbon, I'll expand this to the Ribbon as well. How do you determine which tab buttons appear on? Looking for the same as above.

Related question: https://stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere

Answer 1

Microsoft's Vista User Experience Guidelines are at: http://msdn.microsoft.com/en-us/library/aa511258.aspx

Content specific to menus, including standard menus, is at: http://msdn.microsoft.com/en-us/library/aa511502.aspx

This includes standard order of menus and menu items, their names, and their accelerators.

Some general guidelines:

File is for commands that affect the entire content the user is working on (generally a file) or the entire application (eg, Exit). It's also a good place for users to select the form they want to work on.

Edit is for selecting pieces of content (eg, Find, Select All) and acting on such pieces (Copy, Delete). Do not use it as a general “change something” menu (eg, to “edit” preferences or a macro).

View changes the appearance or presentation of the content while not changing the underlying content itself (eg, what users entered into your forms). Consider not including in View menu items for controlling the presence of toolbars (toolbars are not content). That really should be with Options/Preferences.

Although it's listed as a standard, I would avoid the Tools menu. The name has no meaning and the contents are too often random junk. Consider the names and organization used by the Office Ribbon (eg, where Options are under the equivalent of File). See http://blogs.msdn.com/jensenh/archive/2006/01/31/520061.aspx .

Generally place application-specific menu items below standard menu items in a standard menu so the user's muscle memory is not disrupted for the standard menu items. However, if a app-specifc menu item is a variation of a standard menu item, then place it immediately below the standard menu item (eg, Find Next below Find or Paste Special below Paste)

Don't be afraid to create your own menus for items that do not fit in the above. Menubars often have insufficient breadth, creating a weak information scent especially for non-standard menu items. Eight to 10 menus is perfectly acceptable. A menu with only three menu items is perfectly acceptable; one with two menu items is not out of the question.

Cascade or sub-menus are awkward to use. Group menu items by separators instead. A menu may have ~15 items before it's necessary to consider cascade menus. If you have so many menu items, first consider breaking some off as a separate menu, rather than a cascade menu in a menu.

Place your app-specific menus after View but before Window or Help on the menu bar. I strongly recommend user research (eg, card sorting) for organizing and naming non-standard menus.

Look closely at the Ribbon, and you'll see it's organization is pretty much the same as menu bars, with equivalents for File (the logo menu), Edit (the “Home” tab, which includes formatting) and View, so from an organizational standpoint, it makes little difference whether you're using a Ribbon or menubar.

The menubar is still the best choice for most apps. The Ribbon does not mean less clicks than a traditional menubar/toolbar combination. Don't leap to the Ribbon just because MS is pushing it. I have details at http://www.zuschlogin.com/?p=36 .

Answer 2

The Microsoft menus documentation:

• The Windows User Experience Guidelines: Menus
• The Windows User Experience Guidelines: Menu Design Concepts

Answer 3

Yes... Logical grouping of menus help your users remember things easily. I too don't prefer have a "Tools" menu and dumping everything that doesn't belong elsewhere here... There should be an "Application Menu" like Mac or like the Office Button (Outspace UI in 2010) where you can have those "tools" or preferences.

Regarding button ordering, try following the platform conventions... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/

Answer 4

Not a standard, but you could use the office products as a guideline.

By the way, menu's are from the past, it is all Ribbon now. And at first I was sceptic about the ribbon, but now I think it's a very good idea. (Minimizing mouse clicks is always a good idea).

Nice link: http://blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx

Answer 5

There are several standards available:

• Microsoft's standards guide: http://www.amazon.com/review/product/1556156790?pageNumber=2
• http://msdn.microsoft.com/en-us/library/ms997532.aspx
• http://www.otal.umd.edu/guse/standards.html

Apple has a long guide just for this on their platform:

• Interface Guidelines

Answer 6

The Microsoft Ribbon documentation:

• The Windows User Experience Guidelines: Ribbons

Also, documentation on what type of interface (menu bars, ribbons, toolbars, direct command, etc) should be used for different types of applications:

• The Windows User Experience Guidelines: Program Command Patterns

Answer 7

Some things to keep in mind.

Both of the standardized methods were developed and implemented in desktop software before the web. This means that both of these models were not designed with the web context in mind. There is one big difference between the traditional desktop environment and a web-based environment – the browser's “Back” button.

o “Cancel” is also a way to “go back” and “OK” is a way to move “forward”. This “Forwards/Backwards” metaphor underlies most forms of “Cancel” and “OK” functions.

Here are some other extensions of this metaphor:

• We use visualization to communicate complex ideas. Graphical User Interfaces are one form of visualization. We have an strong history of visualization standards in Western (and more specifically US American culture)

o Time: in our standard visualizations ”Old” is usually depicted on the left, “New” is depicted on the right (most graphical depictions of time use this left-to-right metaphor)

o Process: We use the left-to-right metaphor when visualizing progressive steps: “First” is on the left, “Second” is usually displayed on the right.

o Writing and Reading: in writing and reading we “continue” or move “forward” from left to right (unless we're in Asia of course)

o In film: film is another form of visualization. In film a standard in movement is: if a person is “going somewhere” she moves from the left side of the screen to the right. If she's going “back” she travels from right to left

o The Cancel/OK model may help to improve conscious decision-making: This model assumes that you want to read the options before making a decision on which action you want to take (advisable on important interactions that require the user's full attention and have more than a couple of actions available to them.) The Cancel/OK model presents the “alternative” actions first (on the left)…so you can read them before deciding that “OK” is the action you really want to take. The OK/Cancel model may get the user in the habit of clicking the first option they encounter. At the same time, the users who are trained to use the Cancel/OK model may go directly for the “OK” button whenever they're fairly certain that's the choice they want to make.

o OS Adaptation: Mozilla's Firefox matches the OS being used when displaying the order of the OK and Cancel buttons. In other words, the display of the buttons adapts to fit what your OS has trained you to use.

This is an interesting survey that addresses this very specific question of which order this buttons should be in: http://measuringuserexperience.com/SubmitCancel/index.htm

• DM