Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
    
Thanks, Marjan Venema, for the link –  Patrick McElhaney Oct 14 '11 at 13:21
1  
I was wondering the same thing when I read this this morning. All applications that I have installed, for example Microsoft and Adobe products - disable save if there have been no changes since the last save. This indicates to me that I currently have all my changes saved. –  Matt Rockwell Oct 14 '11 at 13:23
6  
I think the point of telling people why is far, far more important than not disabling things. It's very helpful to have an at-a-glance view of what I can't use instead of clicking every damn button and finding they're all disabled. On a side note, no, I've never seen this put into practice, for good reason. –  Ben Brocka Oct 14 '11 at 13:29
    
What I want to know is "what about hiding items that can't be used" –  jcolebrand Oct 14 '11 at 13:33
2  
Hiding things has never been a good idea, greying out things has always been done to leave all options there but give you context as to which are usable and which aren't. The only exception is if they can't use them for security/permissions reason, in which case they'll never be able to use them in a large timeframe usually, so in that case hiding them just reduces clutter. I really don't want random users to see the Delete Database button even if they can't use it. –  Ben Brocka Oct 14 '11 at 13:38

5 Answers 5

up vote 38 down vote accepted

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!

enter image description here

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):

enter image description here

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.

share|improve this answer
13  
When I wrote the original blog post I was thinking of typical desktop programming environments (Windows, Macintosh) which did not, by default, provide any mechanism for the user to learn why a menu item was disabled; they just left the user to scratch their heads and caused a usability problem. If you are 100% confident that your users will understand WHY something is disabled, or if you can provide a tooltip explanation that will be easily found, disabling is fine. –  Joel Spolsky Oct 14 '11 at 14:19
2  
It unfortunately certainly wasn't common, but since you're talking about desktop programs there's always a way to include such a method. Giving them a notification only after they attempt to click may solve the "furious clicking" issue of disabled items, but doesn't help convey which items are disabled. I can understand that with no ability to convey why a grayed out item is unusable it might be better to notify them after a click, but notifying and graying out seems much better and certainly practically possible. In web apps it's pretty easy JS, too. –  Ben Brocka Oct 14 '11 at 14:30
    
Maybe it would make sense to gray the items out, but still allow them to be clickable (so you can pop up a message saying "You can't do that because ..."). Not sure how many GUI toolkits support that though. –  Brendan Long Oct 15 '11 at 19:56
    
If you disable the menu item but don't provide a clear context of how they can be enabled, the user is going to be rather frustrated trying to figure it out by clicking through the rest of the interface. –  Michael Lai Sep 4 '13 at 3:49

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.

share|improve this answer
    
I've never heard of a save button being disabled due to the document being unmodified. –  Random832 Oct 14 '11 at 14:36
6  
@Random832: then you haven't been around long enough :-) –  Marjan Venema Oct 14 '11 at 17:06
    
@Assaf Lavie - yes, the save button should always be enabled. Users are paranoid. Let them have their button, even if it doesn't do anything. –  Brendan Long Oct 15 '11 at 19:58
1  
having an enabled save button that doesn't nothing, not even become disabled once saved, can contribute to paranoia.. –  Assaf Lavie Oct 16 '11 at 6:50

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)

enter image description here

enter image description here

enter image description here

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.

share|improve this answer
1  
Yep, this is the approach I am now aiming for as well, but only if there really is no logical action for the app to take given its state. –  Marjan Venema Oct 14 '11 at 17:06
    
I really like this approach, and have deviced a similar system as you have (just not implemented yet). There is however one big spoiler here: it works nicely for systems using a mouse where there is a hover event, and where users understand that they can get information by hovering. However, we're more and more moving to touch, and hovering doesn't work there. Nor can you rely on users understanding the whole idea of hovering and tooltips for all target groups. –  André Sep 4 '13 at 8:17

"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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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