About a month ago Joel Spolsky wrote a very short post instructing people to not hide or disable menu items that are not available. This I’ve been working on one of my spare time projects this summer – a project that involves a web based user interface I’ve given this some thought. At a first glance Joel’s recommendation makes sense. At least to me since I’ve several times found my self in a situation where I see a disabled menu item or button in an application and I know I want to use that command but I have no idea what I needed to do to enable the option. Under such circumstances I would have loved the developers if they’d let me click the darn thing and then tell me what I need to do.
However, things are never black or white – they’re gray. And different situations call for different approaches I think. I also think you should include buttons in this discussion. The good thing is that buttons can be handled in the same way as menu items.
Hide vs Disable
A user menu should never change its content due to application state. If menu items are hidden and shown the user will have a harder time recognize the menus. It is easier for the user to navigate the menu if it is always the same (except that some things are disabled from time to time). Same applies to buttons since there sooner or later will be a manual with screen shots and if the user does not see all the buttons they will think they have the wrong view.
There is however one situation I think you should hide the menu item. That is when there is nothing the user can do to enable the item. This typically applies to security settings. If the user does not have access to a certain feature, and never will have unless somebody changes the security policy, it’s just annoying to see that option all the time. Personally I hate those web sites where you try to access some page and all you get is a “you do not have access to this feature“.
Disable vs Enable
If you disable an item you have to perform some kind of check when rendering the menu item (or button). You will also have to perform the same check when actually handling the click event in order to protect against programming errors and abuse by an evil user. Sometimes this check may be very expensive to perform. If the check is expensive to perform I tend to leave the item enabled (for a quick rendering routine) and then handle it once the item is clicked. But the error message must be descriptive and clearly point out what the user have to do in order to complete the action.
I would also leave the item enabled if there is a complex series of actions the user have to perform in order to enable the item. I think it is better to let the user get a descriptive error message telling him what to do rather than just disabling the item.
Another thing to consider is that many users are afraid of pop-up error messages and even offended since they think they did something wrong. And if you throw an error message in their face for something simple they think they’d understand if the item had been disabled instead they might get angry at your application (and you). You can’t please them all but you should consider this. For example if you have an edit view that is used for editing and creating items you might wanna disable the delete-button when in create mode rather than telling the user “they can’t delete an item that is not created” when they click it.
Tool-tips are the rescue. Adding a tool-tip for each disabled item telling the user why the item is disabled is an excellent solution.
So as usual in the wonderful world of software development, it depends. For items not available to the user at a given time, these are my recommendations:
- If the user will never have access to the feature – hide it.
- If the user may access the feature but it is cumbersome to determine if so is the case – enable it.
- If the user may access the feature only after a series of complex, non-obvious actions – enable it.
- Otherwise – disable it, preferably with a tool-tip explaining why the item is disabled.
If the item is enabled the error message when clicked (and the action fails) must be descriptive and tell the user exactly what went wrong and what he can do to complete the action.