1

My application shows a small menu bar if no window is shown. Of course, when a window is shown, its menu bar is visible. When now showing a modal dialog on top of this window, what menu bar should be shown - the "application" menu bar or the parent window menu bar?

More information to Roger Attrills comment: If no window is shown, we show a basic ("application") menu bar offering just a few commands (to open new windows). Unfortunately, when showing a parent modal dialog, SWT is showing this basic ("application") menu bar instead of the menu bar of the top-level window which is the parent of the shown modal dialog ("window menu bar").

Improve this question
3
  • 2
    I think the reason this question has not received enough attention is because you've not really given enough clarity in your explanation as to what the elements of your question relate to. If I read it right, you have a basic manu bar when no main window is present; a more detailed menubar when the main window is present, and you're wondering what to show if a modal dialog (aka sheet) is brought up from the main window; in which case I don't understand why you need to show anything different in the menubar - hence why your questions seems short on either detail or understanding or both
    – Roger Attrill
    Oct 20 '11 at 8:15
  • Let me guess, your programmers use java/swing? On Mac OS, the menu bar is not associated to the window, in contradiction to the swing implementation.
    – Kris Van Bael
    Oct 21 '11 at 5:49
  • No, I'm using SWT and for SWT you have to define different menus for the application and for the windows (shells).
    – Mike L.
    Oct 21 '11 at 7:20
3
+50

If I understand your question correctly, you are talking about changing the contents of the menu bar, not placing menu bars inside windows (which is also incorrect on Mac OS X).

You should avoid changing the menu bar at all. Only disable menus and menu items; do not remove them. This allows users to learn menu item locations and also gives a useful overview of the functions present in the application even when the right context for them has not been reached.

If you must, then have it change as infrequently as possible; leave the same menu bar up until there's a reason to change.

I looked for support for this in the Mac OS X HIG, but I did not find any. Still, note that very few (if any?) Mac OS X applications, outside of ports from other platforms, change the menu bar.

Improve this answer
1
  • Regarding avoid changing the menu bar at all: our application can show multiple top-level window for significantly different objects. I'm not sure it would be a good approach to merge everything into one stable menu bar (see also ux.stackexchange.com/questions/10251/…).
    – Mike L.
    Oct 21 '11 at 7:28
4

You may want to refer to the Apple Human Interface Guidelines, which have explicit instructions about the content and appearance of document modal dialogs (also known as sheets).

On page 234 of the HIG, "A sheet is a modal dialog attached to a particular document or window, ensuring that the user never loses track of which window the dialog applies to. Because a sheet is attached to the window from which it emerges, a sheet does not have its own title."

I interpret the HIG and the associated screenshots to indicate NO menu bars should be included in modal windows.

Of course, the HIG is a guideline and not a set of absolute rules, so also ask yourself if there is any reason your users would absolutely need to use menu bar controls within the modal window in question.

Improve this answer
6
  • Why not being able to open a new (main) window if a parent modal dialog (AKA sheet) is shown?
    – Mike L.
    Aug 24 '11 at 17:42
  • Hi Mike, I am very sorry, but I don't understand your question.
    – Nadine Schaeffer
    Aug 26 '11 at 17:09
  • Sorry, I don't understand what could not be understandable in my comment.
    – Mike L.
    Sep 2 '11 at 5:40
  • I don't understand why you don't understand what could not be understandable in your comment. You're talking about a new main (top-level) window in reference to a parent modal dialog and that relationship doesn't seem to make sense given the minimal information provided about your set-up. A new main window is just another standalone (unrelated) instance of the application, no?
    – Roger Attrill
    Oct 20 '11 at 8:00
  • 1
    Does Mac OS X lack a user interface to launch another instance of a running app? (i.e. leaving to the application to launch new windows of itself) If yes, and if one of the commenters does not know this fact, the confusion is explained.
    – marcus
    May 5 '12 at 23:41
0

You should avoid the use of application-global modal dialogs.

In the case of a sheet (a window-specific modal) then you should dim all of the menu options that have no meaning while the modal is displayed. Don't hide the menus, just dim their entries to show that they will return when the modal dialog is finished.

If a user switches to another window that doesn't have a sheet visible, the menu items should be restored.

Improve this answer
1
  • Do I understand you correctly, that the parent menu bar should remain visible when a parent-modal dialog is shown (e.g. sheet - sometimes it makes sense to not use a sheet), but its menu items be disabled which are not applicable in the context of the dialog (e.g. keep those enabled which allow to open another top-level window)?
    – Mike L.
    Sep 2 '11 at 5:39
0

The simple answer is that you don't show a menu bar in a modal dialogue.

A modal dialogue is a simple "page" that pops up on top of another page. It isn't for performing advanced tasks, and hence has no need for a menu bar in the first place.

Improve this answer
1
  • Please take a look at the Calculator (/Applications/Calculator.app) and select an item from the Convert menu. Of course, the menu bar remains visible and can be accessed.
    – Mike L.
    Oct 24 '11 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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