One of the first things people notice when they start using Vista is the absence of menu bars. Explorer, photo gallery, media player, and IE all don’t show menus by default and just use the so-called “command module.” What is up with that? Do we hate menu bars? And more importantly – what is the guidance that third-party developers are supposed to follow? Let me break it down for you.
First, let me be clear: we still like menus. Menus are known UI, they work OK, and are easy to make keyboard accessible. They are not perfect – they all look the same, they don’t provide good indications of their functionality if you don’t immediately grok the name, and users often have to hunt around to find the right one. We are watching carefully how the ribbon thing goes with office (it was designed to address those problems), but for now we are sticking with menus as the preferred UI for organizing a large set of commands.
However, menus can be used inappropriately - particularly when developers slavish follow the File/Edit/View/<my app>/help pattern. These standard menus are really designed for document-based applications, where there is a lot of saving, printing, cutting, pasting, and window management going on. So let me officially free everyone from that: If you don’t work with files, you don’t need a file menu. If your app does no editing, no need for Edit menu, etc. Here are some loose guidelines to consider:
- If your program’s functionality can be represented by six or fewer commands, you do not need to have a menu bar at all. Just use the command module. Putting the buttons out there makes it easier for the user to see all of their options instead of hiding them in the menus. And clicking a button is an easier action than using a mouse to select a menu item.
- If you expect that your user can accomplish 90% or more of their actions with six or fewer buttons, you can go ahead and have a menu bar that is hidden by default. For instance, that is why the explorer menu bar is hidden by default. You just don’t need it most of the time.
- It is OK to mix different types of controls in a command module. We have buttons, drop-down menus for selecting options, and split buttons for things like print that can typically be done with a click but sometimes require more settings, etc.
You can see the whole list of menu guidelines online in the UX Guide (http://msdn.microsoft.com/windowsvista/uxguide) :
Menu Guidelines & General Menu Concepts
So – now you are probably thinking: “That’s great! But what the heck does that have to do with what is going on in Media Player, IE, photo gallery, windows live apps, etc.?”
For a detailed analysis, let’s go app by app discussing menu bar guideline consistency so you can know what to do in your own apps.
Windows Photo Gallery
The Good: Windows Photo Gallery has no menu bar at all. It only has the command module. Based on the guidelines above, we would expect it to have only six or so commands. If we count, we find that it has 8. That is close enough (these are guidelines, not rules!) as long as we ignore that pesky “File” drop down.
The Bad: That pesky file button. File here is basically a dumping ground for the last dozen-or-so lesser used commands that would otherwise have been spread across a menu bar. Even so, I think it is a reasonable compromise. I would also have made print, burn, and open into split buttons, but that is something that reasonable people can disagree on.
The Ugly: Why are these things centered in the window instead of left-aligned? Why is the view menu next to the search box?
Bottom line: a pretty good example of an app that can live without a menu bar.
Windows Media Player
The Good: the black is the same color as the other media apps. 
The Bad: well, clearly WMP is doing something completely different here with their command module. WMP is an application that has five overall modes it can be in: Playing music, browsing the library, ripping a dvd, burning a DVD, and syncing to a device (6 if you count the online store). The splitter buttons in WMP have a top part that both switches modes and indicates the current mode and a bottom part that is a drop-down menu. Now, this is an acceptable pattern but not something that is appropriate for every app. The drop-down menus are small targets that are hard to hit and doubles the number of TABs needed to navigate with the keyboard. It is also not clear to people what happens if they select a menu item from a tab that is not active. This is all somewhat mitigated in WMP because the most common action is just pressing PLAY.
The Ugly: Standard help button is missing, but we have a specific help in the bottom of every menu. We have a breadcrumb bar of sorts, but it looks different and is in a different place than in the Explorers and IE.
Bottom Line: I recommend avoiding this pattern for most applications. Specific tasks that are fundamentally different can be done better in most cases with wizards.
Internet Explorer
Though I know that if you press Alt+F, menu in internet explorer will become visible..
The Good: IE is a good model for an app that can hide its menu bar. Most of the time, you are only using a few commands. Great use of split buttons for Home, RSS, and Print. Travel buttons / Address bar / search box in the standard location and using the standard look. Even the page and Tools drop-downs are not too bad in this context – no single command there is used that often, but you do want all of those options around. And the integration of the tabs into the command module is nice, where the new tab not only looks like a tab, it also is like a proper command button.
The bad: The “favorites center” and “add to favorites” buttons are both drop-down menus but they do not have the little black triangle to indicate it. If you show the menu bar, there is no obvious correlation between items in the Page and Tools drop-downs in the command module and the various menus in the menu bar. This is actually a common difficulty for apps that use command modules as well as menu bars.
The ugly: Help button in command module doesn’t need to be a drop-down – it should just go to help like every other help button. The progress bar is still at the bottom of the window instead of in the address bar (which would match Explorer). Although to be fair, the use of the address bar to indicate site trustworthiness is nice.
Bottom line: All in all pretty good. In your own apps, try to really be hardcore if each option you have really needs to be there. This can help eliminate extra menu items.
Conclusion
So – I hope this helps you figuring out how to design for command modules and menus in your own apps. And as always, if you have questions feel free to ask.