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.

  • Thanks, Marjan Venema, for the link Commented Oct 14, 2011 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. Commented Oct 14, 2011 at 13:23
  • 11
    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
    Commented Oct 14, 2011 at 13:29
  • What I want to know is "what about hiding items that can't be used"
    – jcolebrand
    Commented Oct 14, 2011 at 13:33
  • 3
    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
    Commented Oct 14, 2011 at 13:38

6 Answers 6


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.

  • 27
    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. Commented Oct 14, 2011 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
    Commented Oct 14, 2011 at 14:30
  • 1
    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. Commented Oct 15, 2011 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
    Commented Sep 4, 2013 at 3:49
  • If word would hide items in special contexts so I only see the 30 options that matter instead of the 100 options that mostly do not matter I would call that an improvement.
    – nwp
    Commented Oct 7, 2014 at 14:05

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.

  • 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. Commented Oct 14, 2011 at 17:06
  • 1
    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é
    Commented Sep 4, 2013 at 8:17
  • I wish I could bookmark your answer!
    – sergiol
    Commented Oct 4, 2016 at 21:35
  • @André I can think of some solutions for communicating the reason on touch devices. On disabled widgets with an explanation, you could show an icon of a ‘?’ with a circle around it nearby to indicate that an explanation is available. Then tapping the disabled item would display the explanatory tooltip. For menu items, the icon would be placed on the right side of the menu item; for buttons, a tiny version of the icon could be shown in the corner, or the icon could be in the background of the button. Commented May 31, 2018 at 15:44
  • 1
    @RoryO'Kane sure, I guess there are ways to do it. But they will not be obvious or standard. I think your solution could result in UI noise that may not be acceptable. But perhaps one could have some "Help" action that you can tip and then tip whatever you want help on. For disabled items, it could then show the reason once again.
    – André
    Commented Jun 1, 2018 at 18:32

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.

  • I've never heard of a save button being disabled due to the document being unmodified.
    – Random832
    Commented Oct 14, 2011 at 14:36
  • 7
    @Random832: then you haven't been around long enough :-) Commented Oct 14, 2011 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. Commented Oct 15, 2011 at 19:58
  • 3
    having an enabled save button that doesn't nothing, not even become disabled once saved, can contribute to paranoia.. Commented Oct 16, 2011 at 6:50

"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


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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