Joel Spolsky has a remarkable track record of speaking truth to programmers on his blog: Joel On Software. Occasionally he says something with which I disagree, but usually it’s on a subtle point, or it’s an issue where his passion for doing things one way is motivated by his preferred platforms: Windows and the web.
Today Joel shared a very short and dangerous pronouncement on the use of hidden and disabled menu items:
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.
He’s absolutely right about hidden menu items, but on the subject he emphasizes, disabled menu items, he’s absolutely wrong.
Joel argues that instead of disabling a menu item, applications should leave them enabled, and instead display an informative message when the user tries to use them. This solves one problem: that of the user who is perplexed as to why a menu item is disabled. I recognize and applaud the desire to fix this issue. But enabling every menu item creates more usability problems than it solves.
Disabled menu items convey valuable information. Users who are skimming menus in order to figure out what to do are trained by years of experience to skim past disabled items and look for enabled ones instead. The more complex the application is, the more valuable this dichotomy becomes. In essence, disabling menu items gives application designers a means of “funneling” user attention to the actions in an application that will actually work at this moment in time.
Sure, it’s frustrating when you can’t figure out why a menu item is disabled. But what would be unbelievably frustrating is drowning in a sea of enabled menu items, for which the application offers no immediate usability guidance. Instead of skimming past disabled items, a user could be forced to select several, each time receiving a valuable instruction (punishment) as to why it was a worthless move. In time the user would learn to avoid these irritatingly enabled menu items, but they would be offered no future assistance in actually avoiding them.
Joel is right that it’s a bad idea to outright hide menu items. Users become comfortable with an application by learning its topography: where each menu item is in relation to its menu and the other items in that menu. When you go about willy-nilly removing and adding items, it can cause confusion. If you’ve ever visited an old home town after years away, you know this problem. You’re sure your favorite restaurant is around here somewhere, but so many of the shops and landmarks have changed, it’s hard to find it as quickly as you once could.
Joel’s suggestion may increase the learnability of an application in one very specific way, but at the expense of long-term usability. Although it can be argued that an application needs to be learnable in order to attract long-term users, I think user loyalty will be greater when the usability of the application is maximized.
What would be a better solution? The idea is to answer the naive user’s question: why is the menu item disabled? For this purpose I can think of many solutions. The application might show tool tips as the mouse hovers over the disabled menu item. Or if the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration. The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.
It’s not often I get to say it, but hear me loud and clear today: don’t listen to what Joel says about menu items!
