Our application has different major windows which don't share a noticeable common menu item set. Hence the menu bar changes when switching between those windows. Unfortunately, I have not found any other Mac application with same behavior. Even if no window is shown, their application menu bar remains the same.

What do you suggest - try to "merge" our different menu bars into one common or use independent ones for the different windows?

Additional question: there is also a menu bar ("application menu bar"?) which should occur when no window is shown at all. Usually, it allows to open files or create new ones. What should this menu bar contain in the context of different major windows?

7 Answers 7


Having a stable menu bar is a pretty strong convention on the Mac. If you didn't find any application that does what you want to do, you should seriously ask yourself if breaking the user's expectations about the platform is really a good idea.

If you look at native Mac OS applications, you will see that the contents of the menu bar are not changing but there is often one or two menus that are only active in some contexts. For example, in Mail, the “Format” menu is visible at all times but most of its items are disabled unless an editing window is activated. Conversely, most choices in the “View” menu are not available when writing an email. Same thing with “Select”, “Filter”, etc. in Adobe CS (Photoshope, Fireworks…) One major exception is Adobe Flash CS, which does have a number of menus hidden until you open a file.

Some menus might also simply provide functions operating on another level in the background. For example, in Mail you can synchronize your mailboxes at all time, even from an editing window. I don't really understand why an “Application” menu with options to open or create a new file shouldn't be available when other files are opened (incidentally, on the Mac, those two options should in fact be in the “File” menu, not the “Application” menu). Even if you can't have two files opened at the same time, having to close a window to be able to see the menu you're looking for can be annoying.

Going for a fixed menu therefore seems the best solution to match Mac OS users' expectations. If needed, there a couple of ways complex Mac applications reduce the number of menus: Move functions to toolbars, group them in sub-menus or secondary windows accessible from the menu.

Some applications do break this convention but those are often cross-platform applications and they do not really feel like real Mac applications. In the case of OpenOffice, the issue is that OO packs, at least conceptually, several applications into one. By contrast, Keynote or Excel look like separate applications, can be closed and opened independently, live in separate windows, with a specific icon in the dock, etc. If your application can be split up that way, that might also be an interesting approach.

You can even find some Mac applications with a menu directly in the window (often those are open-source projects or java applications), which might be a solution if you really don't care about the platform's convention and need to follow the MS Windows interface model closely. I suspect most Mac users would find them awkward and that could reflect negatively on the image they have of your company but such applications do exist (Matlab is an example of a large commercial application designed that way, presumably because the Mac OS platform is not its primary target).

  • We are developing a cross-platform application. If we design a all-in-one menu bar, we should split it for the other OS, right?
    – Mike L.
    Aug 29, 2011 at 18:45
  • Yes, I think so. It might depend on the other OS but Windows users would for example have other expectations (or a different mental model if you will). You do need to take these expectations into account so that changing the interface towards a more Mac-oriented structure is unlikely to work well on another platform.
    – Gala
    Aug 29, 2011 at 19:34

According to the Apple Human Interface Guidelines, most applications should have the following menus if applicable: <App>, File, Edit, View, <App-Specific...>, Windows, Help.

In your case, at least File, Windows and Help should be applicable for both windows. It seems OK to add or remove menus when switching top-level windows. IIRC, OpenOffice for Mac does this when switching between Documents and Spreadsheets, for example.

  • Regarding File: one window can operate on files, another window can operate on projects, a third one on directory structures or something else. See also stackoverflow.com/questions/7121094/…
    – Mike L.
    Aug 19, 2011 at 11:50
  • Then just use different menu bars for each window. Having too many menus (and useless ones!) is very distracting. I wonder what kind of application you are developing that combines such a number of different workflows.
    – Ferdinand Beyer
    Aug 19, 2011 at 12:40

Since we do not know the details it is hard to tell, but it seems to me that having need for such enormous number of commands in menus might be a symptom of your UI model being troubled. Extra modes are usually another symptom that there is something wrong with the UI model itself.


The idea of a menu bar in OS X, it seems to me, is to be application global - similar to a dictionary you go to when you want to verify if something exists in the first place. If you have an application menu bar that is supposed to be active when no windows are active, it seems to me that this is what should always show when your application is active.

So if you are breaking the Mac OS menu element anyway, and are absolutely sure that the additional menus are required, it seems adding the additional menu bars to the actual windows (instead of to the menu bar at top of screen) to which they are related, would at least make the application less moded.

If possible though, I would try to reduce complexity, and try to make the extra menus unnecessary by carefully considering each menu item and

  • adding just some of the items to the global menu and/or
  • having toolbars in the windows where window-specific commands are required, instead of menus (Like Davide suggests above).

Without knowing the application, I would suspect some of the commands you have in the menus are probably even more context specific than just either of the windows, i.e. the commands could be placed closer to the actual elements (inside the windows) that they affect instead of in a menu bar. Some of the elements could perhaps also be hidden by means of progressive disclosure. http://en.wikipedia.org/wiki/Progressive_disclosure

  • Regarding your toolbar suggestion: shouldn't each toolbar item have a menu item pendant?
    – Mike L.
    Aug 29, 2011 at 18:47
  • Not sure what you mean with 'pendant' - this may be my lack of knowledge of the OS X guidelines though. If a menu bar is fixed and can not be hidden or moved out of its window, it should require no special item in the menu bar, if that is what you mean. Sep 1, 2011 at 14:30
  • I meant, that for each toolbar action there also should be a menu item which does the same action.
    – Mike L.
    Sep 2, 2011 at 5:42
  • Ah, I see. Yes, it would make sense to have a single place in the application where all functionality - including that of the toolbars - is available globally. So this is tricky. However, if the other option is to have a separate menu for each window, then you are not going to have that global safe-place-to-go-to for users that way either. Toolbars are just a more visual and a more quickly accessible alternative, provided that the number of buttons you would have there is not huge. Sep 5, 2011 at 19:33
  • Of course, the MS office ribbon is something of a combination of both the menu and the toolbar. Haven't seen it on Mac though. Sep 5, 2011 at 19:33

Because there will be some overlap, and because you have not found anything that does it differently, I would suggest trying to merge the two menu sets, disabling the irrelevant ones. The reason is that there is a sense of continuity across the two different windows, there is a visual feeling that the two types are connected.

If the menu changes completely there is a danger that the two types will appear to be too disconnected. Providing this small piece of linkage may be significant.

  • +1. With no other clear marker to differentiate the contexts in which the different menus apply, the best approach seems to be merging them with items irrelevant to the immediate context disabled. If you can provide tooltips on the disabled items to indicate where/when they can be used, even better. Aug 23, 2011 at 21:50

Either use a menu bar with everything visible and lots of things simply just not enabled, or use a mechanism separate from menu bars in other windows and resign yourself to simply not representing every command in the menus. On Mac OS X, menus just don't appear in windows.

You should probably also ask this question in the UX Stack Exchange.


Perhaps the menus are not the issue.

Instead of different windows with different menu structures, could you think of the different windows as different modes (like when one edits a master slide in PowerPoint). As long as the user is aware he or she is in a different mode, a change in menus may not be so striking.

I think Microsoft Access works like this, but its been a while since I've used it.

  • Hm, (I don't know your mentioned MS products) but modes usually are considered to be bad. Finally, the application has different windows and not one operating in different modes.
    – Mike L.
    Aug 24, 2011 at 9:56

Your question needs a bit more details probably.

From a generic point of view you might have toolbars, and a common menu bar from where you can access everything.

Or simply you need a bit better navigation design, trying to squeeze all in!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.