Joel Spolsky thinks that we should not disable inactive menu items because it’s confusing users who may not know why a menu item is disabled. In reality, disabling menu items is rarely a problem because it’s usually obvious why menu items are disabled (for example, if there’s no selection, you obviously can’t copy anything). 1
He is right though that there are some cases where disabling menu items can be confusing (and Gruber’s solution to just let the user figure it out isn’t an acceptable solution at all). It’s not only menu items, by the way; all UI elements which can be disabled can confuse users.
Mac OS 7 had a solution to this problem: Balloon Help allowed users to mouse over disabled UI elements, getting information explaining why they were disabled (If I remember correctly, I used this feature in Interarchy - née Anarchie - more than once). Wikipedia writes:
Developers were encouraged to include help text with a certain grammar, and not only name the object being looked at, but also explain to the user any state it might have
What a great idea! Apple already thought of this issue in 1991! 2
In its infinite wisdom, Microsoft does not display tooltips on disabled interface elements (or at least did not show them the last time I wrote Windows software, two or three years ago).3 People, this is the only time users actually want to see these damned yellow thingies! What were you thinking?
Fortunately, Mac OS X does allow tooltips on disabled menu items. So just do the right thing and show an explanation telling the user why a menu item (or any other UI widget) is disabled.
Here’s a disabled menu with a tooltip:
And here’s a disabled checkbox with a tooltip:
Take some time to think of a good explanation telling the user why these items are disabled and how they can enable them, too.
Please don’t just assume that people will figure it out, and don’t confuse people by enabling menu items which should be disabled. Use tooltips instead.
Addendum: Daniel Jalkut has an additional solution to this issue: «If the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration.»
While documentation should not replace usable interfaces, documenting such things is a great idea because some people will consult the documentation if they can’t figure out why something is disabled.
Addendum 2: A Big Contrarian post on this very topic.
If you need an explanation why keeping menus active is bad: Not disabling inactive menu items is a terrible idea because it crowds the menu bar with useless commands, making it harder to find the useful commands. It also takes away context information which informs users about the application’s state (for example, a disabled «Close Window» command tells the user that the application has no open windows). Disabling inactive commands makes it easier for the user to form a mental model of the different states of your application. Furthermore, preventing user errors - such as selecting menu items which don’t actually do anything - is generally better than allowing errors and then telling users that an error has occurred. Finally, not disabling inactive menu items means users have to guess what actions are actually available.
Tog suggested a different solution: «Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.» I think this used to be possible in Mac OS. I’m not sure Mac OS X still supports selecting disabled menu items, but it’s a strange solution anyways since it involves teaching people to counterintuitively click on disabled UI elements. What you can’t do is add «help» buttons to disabled menu items. At least as long as this patent is still valid.
If you require a short url to link to this article, please use http://ignco.de/31