Please Don’t Disable My Menu Options!

Well, I am back from a wonderful vacation in Tuscany. Just a week in a small apartment in the countryside there, I highly recommend it. But back to work: I started this post before leaving, and it is time to finish it up……

One problem has bugged me for many years. It is another one of these things where the “conventional wisdom” is misguided. There must be other people hold my position, but because all of the terms are so generic, it seems to be impossible to google for other pages on this topic. So please, if you know of other discussions on this topic please make a comment with a link.


Early 1980’s saw the first modern graphical user interfaces. The Macintosh sported menus that drop down from the top of the screen. One UI guideline was ingrained into the common GUI consciousness:

If a menu option is not immediately available for use, disable the option, and indicate this by changing the color to grey.

Is this good? Is this bad? The visual indication is clearly good. By why do you have to disable the menu? Menu options that are disable can not be selected; they can not be acted upon; they can not tell you why you don’t need that option. Disabled menu items are completely dead and silent about why they are disabled.  It can take minutes or hours to figure out why an option is disabled.   I hate this.

User Protection

Why do we disable menu items? The response is usually along the line of “protecting” the user. People (users) are afraid of computers and applications; people can accidentally do the wrong thing and cause problems, so in order to make a more friendly and comfortable environment, we should only offer them operations that make sense at the time. Thereby preventing people from accidentally using the wrong option. In summary, we need to protect people from doing the wrong thing.
Protecting the user makes sense, but it ignores a critical aspect: users need to learn the system they are using. No, Virginia, people don’t read the manual. The point of a friendly user interface is that you can use the product without attending a training course. Just start using it and learn by experimentation. If you want to (graphically) re-size the object you are working on, look around for a menu option that looks appropriate, and try it. Oops, it was not what you wanted, no problem there is the “undo” command. A well designed application can be learned by trial and error.

If I do something completely ridiculous, it is not because I am a “bad” person who needs to be restrained or punished, but it is because I don’t understand the model/metaphor that the program is presenting to me. Therefor, the appropriate response that a friendly program should make is to explain: (1) what the operation does, (2) what it requires to operate correctly, and (3) why I have not met this condition. Through my exploration of the program, this kind of response will actually help me have a better understanding of the program, and it will help me use it better. I was still prevented from doing the ridiculous operation, but instead of a simple dead menu item, I got a pop-up error message that explained why I can’t use that operation. Once I learn that a particular path of action does not make sense, I will not use it, not because I was prevented, but because I will understand the program.

Simply disabling the menu option does not help me in this way. Due to my misunderstanding of the system, I THINK I need to use a particular command, but it is disabled, so I now believe that program is wrong (not me). A disabled menu gives me no information to teach me what I should be doing instead. I am forced to go outside of the system, maybe even look something up in the manual, or most likely bug a coworker who knows the program, and find out externally why the system does not work for me. In the end, my misunderstanding of the system will be corrected, and I will come back to use the system.

An Example

Some simple examples. I use a photo-graphical program that allows you to increase and reduce the color depth of the image. For example, a JPG is 16 million colors, and you have an option to reduce the image to 256 colors. Once you reduce the image to 256 colors, the option to reduce becomes disabled. This makes sense to anyone who understands what is going on, but what about who does not understand? The user wants to do something, and thinks it is called “reduce colors” but the menu is disabled. The user is left on his own to discover why the menu is disabled. Maybe the user (1) thinks the command does something other than it does, or (2) does not know that the image is already in 256 colors. Imagine how much nicer the program would be if when he chooses this option, it pops up an explanation about how the picture is already 256 colors, and this operation only works when the image has more colors than this. It is nice to have the menu gray as an indication, but disabling prevents me from learning how the program works.

The same program has filters (smoothing, etc) that work only when you have a 16 million color image. With a 256 color image, when you try to use a filter is it not disabled. Instead, a window pops up telling you that the filter options only work with images with 16 million colors. This is so much more helpful than simply disabling the menu.

Preventing Error Messages

It gets worse. Many software QA people believe that “preventing users for making mistakes” is extended “preventing users from ever experiencing a pop up error message”. I don’t know how many times I have heard someone say: “If the user is only going to get a pop-up error message, then the button should be disabled.” This is actually a codified rule in the Fujitsu software quality standards.

What is the matter with users getting harmless pop up error messages? The answer is simply: usually these error messages are completely useless. They do not explain anything about the program, and often end up blaming the user for being “bad”. They often use techno-jargon, or worse, simply contain an “error code” which is meaningless to the user.

So in summary, our programs are so poor at teaching users how to use them, that we go and prevent the most important way that people learn: trial and error. Please note: trial and error does not work without the error part. When my dad took me skiing when I was young, he always said “if you don’t fall down at least once every day, you are not trying hard enough.” It is impossible to design a program where everything that can be tried will be successful. It is those error messages that are the learning experience.

Common Lore, Fighting the Good Fight

Most intelligent people can understand the above reasoning, and will agree that good, well designed error messages are helpful for people to learn the program. But the rule to disable menu items still exists.

Try searching google for “disable menu” and you will find thousands of messages from people seeking to find ways to disable menus, and to find code support for disabling menus. Here are some examples:

  • “As user security may not permit a user access to a specific menu option(s) we need to disable them so if the user clicks on the option nothing happens.”
  • “I am working with the BasicMenu sample and would like to disable my menu entry, when no document is open.”
  • “You can use system policies to disable menu commands and their corresponding toolbar buttons. When you disable a menu command and toolbar button through a policy, users cannot use that command or button.”
  • “Does anybody knows how to disable the menu when you click the right button on your mouse? This is to control the desktop display for PCs meant for the public. Do we need special software?”
  • “if there’s nothing in the clipboard (state), then the Paste command should be disabled (menu).”
  • “if your program is in read-only mode, then commands that edit should be disabled…”
  • “Obviously, if there is no selected object at all, you’ll want to disable the menu item, thus reinforcing the connection between the item and its object.”
  • “visually disable menu item(s) which the user not allow to activate.”
  • KDE UI Guidelines: “If an action should not be executed (e. g. Cut when nothing is selected) then you should disable the entry in the menu.”
  • Eclipse GUI guidelines: “A command should only be enabled if it can be completed successfully. If this is not the case, the command should be disabled.”
  • GNOME UI: “Sometimes it does not make sense to allow the user to interact with a control in the current context, for example, to press a Paste button when the clipboard is empty. At these times, make the control insensitive to minimize the risk of user error.”
  • NASA UI Guidelines: “Dim (or gray out) unavailable or invalid options.”
  • Apple UI Guidelines: “When a menu item is unavailable—because it doesn’t apply to the selected object or to the selected object in its current state, or because nothing is selected, for example—the item should appear dimmed (gray) in the menu and is not highlighted when the user moves the pointer over it.”
  • SGI UI Guidelines: “In general, disabling entries when selecting them would give the user an error message. For example, if a menu entry works on a selection (such as “Cut” and “Copy”), disable it if there’s no current selection. “
  • Sun GUI Guidelines: “Disabled commands have dark gray text (instead of the usual black) on the usual light gray background. They are completely inoperative and are not highlighted in response to user actions.”
  • Java Look and Feel Design Guidelines: “If an application feature is not currently applicable, make the corresponding menu item unavailable and dim its text. When menu items do not apply to the current context, they are dimmed and cannot be activated. Keyboard navigation skips over them.”
  • Microsoft Official Guidelines for User Interface Developers and Designers: “If a menu item is not appropriate or applicable in a particular context, then disable or remove it. Leaving the menu item enabled and presenting a message box when the user selects the menu item is a poor method for providing feedback.”
  • Smith and Mosier HCI Guidelines: “When function keys and other devices are not needed for current control entry, and especially when they may have destructive effects, disable them temporarily under software control so that they cannot be activated by a user.”
  • “On the other hand, if the option is not available for a reason the user has no control over, then remove it. Otherwise the user will go nuts looking for the magic way to enable it.”

Everyone is looking for ways to disable menus, and disable means to make it non-functional or “dead”. I would claim that in everyone of these cases, the program would be far more helpful to people learning it if a pop-up message would tell them why the command is not useful at the moment, but the code libraries to support menus do not work this way!

How do we change this? Disabling menu items seems to be one thing that the common programmer pick up, but misapplies. It seems to be a simple thing for Quality Assurance people to check for and insist be changed.  How can this be corrected?

There may be guidelines existing that concur with my position, but I can’t find them! Searching the web only yields millions of cases of people trying to figure out how to disable menu items. I am looking for something telling people to NOT disable them.

I did find some things:

  • Bruce Tognazzini calls this the “Mysteriously Dimmed Menu Items” problem: “Bug: Designers offer no way for users to discover why a given menu or option has been dimmed (grayed out), nor how to turn it back on.    Proposed Fix: Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.”
  • GNOME UI guidelines: “Do not disable menu titles. Allow the user to explore the menu, even though there might be no available items on it at that time.”
  • Palm OS Guidelines: “Never dim or gray out a button to show that it does not apply to the current situation. If the button depends on a certain user context, display an alert dialog that explains why the button does not apply. For example, To Do List has buttons at the bottom of the main form that apply to the currently selected task. If the user has not selected an item, tapping one of the buttons results in an alert dialog explaining how to select an item”
  • Sun UI Guidelines: “When an application is in use, it is not uncommon for commands to have no valid function. For example, when a text editor does not have any documents open, its Save and Close commands have no function. In situations like this, a menu command that has no current function should either be disabled or it should open a panel explaining the function is not currently available.”
  • Apple Guidelines suggest a help balloon to explain why a menu item is dimmed: “Remember that the help balloon you provide for a dimmed menu item should explain why it isn’t currently available or, if more appropriate, how to make it available.”
  • Mark Levinson agreed: “we gray out menu items when they’re not available but don’t do anything to tell the user why they were greyed out.  So the user is expected to use their innate genius and grok why the item is greyed out.  What we really need is for industry behemoth (is MS listening) to help solve this problem.  We need both a standard UI guideline and BCL classes that implement it. “

Call to Action

I can’t be the only one with this opinion. Please use the comments on this message as a way to collect links to UI guidelines that concur with this position. If you know of a good UI article stating when it is bad to disable menus, PLEASE enter a comment with a link to that article. If you know of a discussion of this topic anywhere, PLEASE make a link to that discussion in a comment. I would greatly appreciate it.

7 thoughts on “Please Don’t Disable My Menu Options!

  1. I whole heartedly agree. It seems to me that there should only be two approaches to menus options. First, if there is absolutely nothing a user can do to change a particular situation (security restrictions, missing hardware, etc…) then menu options should not be greyed out, they should simply be hidden. In my opinion there is no use to having you application littered with menues that pop up a dialog that say “you do not have sufficient permissions” or “your video card does not support operation xyz”. In the case where the user cannot immediately remedy the situation, a warning ballon (not a dialog) at application startup should inform the user of the problem (and possibly a link to a solution) and tell him/her that certain features have be removed as a result (with a link to which features in specific).

    The second scenario is described in the article above. If the user can do something to fix his/her situation then a menu should be greyed out but still be active. The problem is the industry has used the grey menu to symbolize an ‘inactive menu’ for so long it would take some time to retrain everyone to the idea that grey does not mean “I’m a dead menu item”, it means “Click me for feedback on what I do and what I need before I can get it done”.

  2. Hi,
    Although I do respect your respect of users right to learn by error which must be taken care of by software designers (this is what is called a falt-tolerant system) but I think the reason to disable menu commands or even Hide them is not cuz we don’t trust users. It’s kinda customziation or tailoring of user experience based on what he is supposed to do not what is the software is capable to do. So if I am a user who is supposed to print as part of my job function, then I will see the print button and can press it too. If I am not why bother displaying the button for me and when I click it I will be told by the software that I am not supposed to print!! this is disappointing. And I can take that further: If that user has some power in my company he might get upset why he can’t print that document while others can ;-).
    I think what you are trying to say can be applied on productivity tools and software that can be used by a single person who’s the one who puts the rules for himself. But with business solutions where rules are defined by company’s policies and politics we can’t give the user these rights.
    Thanks for your thoughts.

  3. Keith, might want to raise this issue with
    davevr who (paraphrased) works for Microsoft, where he is a Research Manager for Windows User Experience Compliance team. see:

    brhoom, rtfa! Keith is saying: when a menu item is disabled, because it is inappropriate to perform the action in the current context, *give me a way to find out* what prerequisites it has to satisfy to enable that action that I want to do.

    NOT: go off and attempt to do the action anyway, possibly erroneously.

    so even in your example of an item being disabled, because the user doesn’t have authority in a corporate setting, give him an intuitive way to find out the reason – maybe even a hyperlink to the access request form on the intranet – rather than having to work out why the print button is ‘broken’.

    i wouldn’t think of trying to click on a greyed out menu item to discover this though, so we need a new intuitive/obvious but non-distracting way to make the info available –
    tooltip on mouseover? can only show so much, and
    what about keyboard users? disabled items are, for convenience, skipped by keyboard navigation

    wish i knew…

  4. Thanks Peter for the comment. Let me respond to a few things.

    Menu Bar: interesting trend away from traditional menu forms. My thesis of this post would still apply to “Command Center” or “Tool bars”. All of these are ways to present to the user the list of commands that can be performed at this time. Sometimes such commands become unavailable, and while this is usually indicated by a “greying” of the presentation, this also traditionally “deadens” the menu control.

    I don’t mean to imply that a greyed out command should go an erroneously operate the same command at the model layer. I am saying at the view and controller layer these greyed out entries should not be “dead”, but instead be active enough to tell you WHY it does not perform the normal function. This might mean that the greyed out control infact becomes a hyperlink to the correct, context sensitive information.

    Of course clicking on the greyed out menu option is not intuitive, because your intuition is informed by years of use with greyed out menu options that were completely dead. I realize that I am suggesting a change to the status quo, and such a change is never intuitive.

    The suggestion to use a tooltip on mouseover to display the reason is a very nice solution! The reason that you can not execute a function is meta-data about that function. Tool tips are for communicating meta-data about functions.

    I don’t know what to do about keyboard navigators.

    Good points!

  5. Pingback: Go Flow

  6. The author makes good points, but having to dispose of the pop-up dialog is a pain. Perhaps an alternative is if the user hovers over a dimmed menu item, a pop-up box appears that shows why the item is dimmed. Move the mouse & it goes away, and optionally have a help button in it which brings up the relevant page in the help system. This last approach may have the additional benefit of being easier to back engineer into existing programs.

  7. Pingback: Errors & Learning Opportunities « Thoughts on Collaborative Planning

Leave a Reply


You are commenting using your account. Log Out /  Change )

Google photo


Twitter picture


Facebook photo


Connecting to %s