Don't hide or disable menu items?

Question

In 2008, Joel Spolsky wrote:

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

That's an interesting idea, but I wish he'd elaborated on what he meant by "display a message telling the user why."

Has anyone actually followed this advice? Are there any examples of menus that display a message instead of disabling a menu item -- perhaps something you designed yourself, or something out of Fog Creek?

I'm curious about the mechanism by which the message would be displayed and whether anyone has experience (good or bad) with showing a message instead of disabling a menu item.

Answer 1

He's making multiple points of varying validity in that post:

Explain why an item is disabled: Great advice that almost no one follows! Google search "greyed out menu" and you'll find heaps of people wondering why their menu items are disabled, because the app doesn't tell them. Giving them info when they hover over a disabled item or try to click on it is a great way to reduce confusion and support calls. Google Docs does this well, this little guy pops up if you try to click the save "button" because it's not a button; it autosaves!

Hiding items: Generally this is a bad idea, especially in desktop applications. By hiding items just because a user can't use them now often helps them learn the item doesn't exist and if they do see it they might not know why it doesn't exist half the time. Imagine if half of MS Word's interface disappeared every time you switched from being in a table to a bullet point to a footer!

There are two related situations where hiding items can be good however though: when it's a web page/app or when the item is disabled for security reasons. In a security context a lower level user may never have access to those functions, and in some cases even displaying them is undesirable when you don't want users to know certain things are possible (like change my name ect).

If the user will never be able to use the item just hide it and keep it clean and simple. Items like this are common on web pages and are almost always hidden until a user is authenticated.

Android's UI Guidelines recommend dimming out menu items that can't be used and only hiding them when they're part of a context menu. Context menus change all the time, after all.

Disabling Items: For the reasons mentioned above, disabling menu items but not hiding them lets users see all the options. As Android's guidelines indicate, "dimming out" or more commonly graying out an item makes it clear that an item is not usable, so I can see at a glance I can't use any of the following options (in GIMP):

That's 14 options that I can see at a glance are disabled. His suggestion is to make it appear I can use impossible options? No way. Greying items out lets me see at a glance if I can or can't do things. I don't have to click every item to tell if it's working or not. That's why we gray them out.

Answer 2

Not quite - but I have taken a step further in the right direction having previously implemented a mechanism in several desktop applications, whereby in addition to any button or menu item being disabled, a tooltip shows the reason why it is disabled.

Thus we get something like the following (Disabled should be new-lined)

The additional follow through with the F1 highly context sensitive help is an added bonus.

Note that it is important that tooltips are provided everywhere for easier discovery and consistency.

I may well be biased here, but I think this is better than keeping the button enabled because the user is not fooled into thinking that functionality is available, but can still discover why the function is not available and what needs to be done to make it accessible. It helps the user learn about the system and it's requirements, and makes the system seem smarter.

---

For those with a technical interest, read on:

This mechanism relied on an internal framework called a state manager:

The state manager is a centralized mechanism by which all controls in the application are automatically enabled or disabled by setting and unsetting an internal system state.

Controls affected by the system states are registered with the state manager, along with the system states which affect that control.

System states can be disablers or prerequisites. Any one associated disabler can force a control to be disabled. Additionally, all associated prerequisite states must be satisfied in order for a control to stay enabled.

All system states are described by a message called a reason - i.e. the reason why the state is set or the reason why the state is unset.

When a system state changes, the state manager automatically updates the enabled state of the control, and either inserts or removes the reason from the tooltip (some basic tooltip builder logic required here).

Multiple reasons for disabled state can be combined into the tooltip if necessary.

Answer 3

So the "next track" button should be enabled even if the playlist is empty and nothing is playing? And the save button should be enabled even if the document isn't dirty so that users never really know if they have any unsaved work?

Seems like an overly general guideline. Sometimes it might be a good idea to fail gracefully and show some educational message to the user, but I think people are very used to disabled controls as an indication of the state of the application and never using them is just unreasonable.

Answer 4

"Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action." - Jakob Nielsen

http://www.useit.com/papers/heuristic/heuristic_list.html

I think it depends of the situation if it's a good idea to hide the element or make it disabled.

If it's a link to an admin interface and the user isn't an administrator, there is little need to show it. But if it's a disabled link to save a document and the user could save the document the last time he worked on it, an explanation of why it's not posible to save would be desirable.

Answer 5

Microsoft OneNote does not have a Save button because it automatically saves the file, which makes sense in one way, but can be a bit confusing because all of the other MS Office applications retain it. Regardless of whether it makes sense or not, consistency is certainly an important factor. If you disable it in some places and hide it in others, the user will have a pretty hard time figuring things out for themselves.

Answer 6

I think if the context is easily understood, disabling without hints of why, is fine.

Remember Balloon help in MacOS? Apple encouraged us to write balloon help for disabled items way back from 1991 and forward. Microsoft did not. But as said above, tool tips only work if you have the hover event, not for touch.

For more complex scenarios, explanation why an item is disabled, and what the user can do to enable it, is great for understanding how an application works.

Hover tool tips, alerts and [i] info icons can pretty much do the same thing: explain at the right place what the item is all about. I would preach: don't miss that opportunity to give the user more insight and your system to be more transparent. Does it require extra work? yes. Worth it? you decide.