John Gruber rebuts Joel Splosky on whether a menu item should be disabled when the action is either irrelevant to the context or unable to be completed for some reason:

Spolsky’s suggestion is also predicated on the assumption that the user is stupid. Better is to assume that the user is clever and curious and will be able to figure out for themself why a certain command is currently disabled.

Except even a clever user won’t always be able to suss out just why the menu item is disabled. And if it’s something they assume they should be able to do, even if logically they shouldn’t, it’s just as frustrating. Users don’t always grasp the arcane logic behind the target/action paradigm. Hell, I’m a fairly intelligent guy and sometimes I can’t figure out why a given option is disabled.

Both men are wrong. Both men are right.

John is right that the visual appearance of the menu should reflect the state of the action. Any menu item that is unavailable should be dimmed. This allows an exploring user to quickly scan to see what actions he can take. The menu item should not respond to the mouse over event, and no action should be taken if the user single-clicks on the menu item.

To be a little tautological: if you can’t do something, you shouldn’t be able to do it.

However, Joel is right that there is benefit in explaining to the user just why the menu option was disabled. In many cases it’s something as simple as the current selection being of the wrong data type for the action or there being no selection at all. But in other cases it can be a complex set of criteria which may or may not involved variables the user can’t see and may not know exists. Simply disabling the menu and calling it a day is the lazy way out.

There are other ways to handle that though. In a perfect world, when I hover over a disabled menu item for a few seconds a tooltip could/should appear either telling me why the menu is disabled or pointing me to an explanation elsewhere in the system. On Mac OS X, it might look like this. Copy is shit, but you get the point.

I should also be able to reach this explanation or dialog prompt with a double-click on the disabled menu item.

This is the best of both worlds. What’s disabled is obvious, and why it’s disabled is something the user can easily find out without reading through your help files and user forums.

Update: Lukas Mathis had the same idea, as did Apple’s old Ballon Help.