Disabled Menus Are Usable
July 1st, 2008Joel 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!
July 1st, 2008 at 1:07 pm
Balloon Help would explain why a menu item is disabled. It at least felt like an elegant solution for that problem to me.
Unfortunately, developers yelled a little too loudly that they wanted plain HTML help systems that allowed them to reuse the content they’d prepared for Windows.
July 1st, 2008 at 1:10 pm
For years now the Mac has had an API (maybe it’s gone, I haven’t checked in a long time) that would send an event when a user chose a disabled menu item, to allow the program to explain why the item was disabled. I guess it’s counterintuitive for users to choose disabled items, but maybe people actually do — and if so that would be a great solution.
July 1st, 2008 at 1:19 pm
The function of balloon help is now performed by Tool Tips (aka Help Tags). You can specify help tags for your menu items on OS X. Just because few apps actually do that, doesn’t mean you can’t. Moreover, since help tags turn themselves on after a bit of hovering on a single spot, you can actually do this, while balloon help wasn’t used much because so few apps actually implemented them.
July 1st, 2008 at 1:32 pm
Great post Daniel – exactly right. You could probably get away with everything enabled for a small app with only a few menu items (still not a good idea though), but I shudder to think of something like Photoshop with every menu item enabled all the time.
July 1st, 2008 at 1:32 pm
I concur. You shouldn’t leave them enabled and display a message on why it doesn’t work. It doesn’t work, period. It should be disabled and use a tool tip, as mentioned. I think the original intent of the design (discoverability) still stands.
July 1st, 2008 at 1:40 pm
I agree one-hundred percent. Disabled menu items convey important information about application context. I was stunned by his advice and I am glad to see that I wasn’t alone.
July 1st, 2008 at 1:55 pm
A menu item could be grayed out to give the visual clue that it’s not useful right now, but still be selectable and give feedback when chosen…
July 1st, 2008 at 2:21 pm
I like the way the QuickTime player handles this, but until it’s part of the OS, well-documented and recommended I think it’s a lot of bother to go to for something that may be crushed by a future OS update. I’d prefer to see a message appear when the user hovers over a disabled menu item a la Balloon Help, though.
July 1st, 2008 at 3:01 pm
I find that although Batman and Robin ( Joel Spolsky and Jeff Attwood) have very popular blogs, their writings have become increasingly irrelevant. Occasionally one of them posts something worth reading but I no longer find that to be the norm. I would recommend them as good blogs for junior programmers but I don’t read them anymore.
It’s kinda like reality television, I don’t watch it regularly but sometimes I take a guilty peak at what’s going on.
July 1st, 2008 at 3:06 pm
That explains a lot! One of the things that frustrates me about Windows apps is when you click on something that appears to be active, only to get a message saying you can’t do that, or the action is unnecessary.
A specific example – you send an Outlook calendar request out to multiple people – you receive the same request with an ‘Accept’ button. Click on it, and it tells you that as the sender you can’t Accept, or have been automatically accepted – I can’t recall the wording, but what astounded me was that :
a) someone had thought of the situation
b) that rather than disabling the button / showing it as accepted / not sending the calendar appointment to the sender, they wrote a long explanation.
July 1st, 2008 at 4:15 pm
On the other hand, there’s the subject of using disabled menu items as messages to the user. Some people feel very strongly that this subverts the intent and “explorability” of menu items, whereas others find it a useful technique for conveying information.
Apple does this frequently in the menus under icons on the right-hand side of the menu bar – for example, the Airport status message (first item under the Airport menu icon), or the “Time Machine not configured” message in the Time Machine menu icon’s menu.
July 1st, 2008 at 4:32 pm
I”™m not familiar with the event Mark refers to, but it reflects the idea that immediately occurred to me: keep the disabled appearance but allow applications to present information when a disabled menu item is selected.
As for the caption menu items Erik refers to, Carbon introduced the
kMenuItemAttrSectionHeaderattribute to describe at least some of those cases. When I first saw it, back in the CarbonLib days, I assumed the intention was for “section headers” to be rendered distinctly from normal disabled items in OS X, but as far as I”™m aware that has never been the case.July 1st, 2008 at 4:51 pm
I couldn’t agree more.
If I were to encounter an application that acted as he suggests, I would quickly stop using it. My thoughts on his post:
http://anassina.com/blog/?p=21
July 1st, 2008 at 4:52 pm
I came to the same conclusion earlier today. http://zackola.com/blog/2008/07/01/disablehide-menu-items/
July 1st, 2008 at 5:28 pm
I guess I should link to my blog entry about this, too:
http://ignorethecode.net/blog/2008/07/01/disabling-inactive-menu-items/
Seems like this worked out just dandy for Spolsky’s inbound link rate :-)
July 1st, 2008 at 5:46 pm
Actually, it isn’t, but it would work for this purpose if you bother to dynamically set the tooltip. With Balloon Help you could specify different help text for different item states (enabled/disabled/checked) and the Help Manager would change the text automatically.
July 1st, 2008 at 5:49 pm
Ditto.
July 1st, 2008 at 6:07 pm
Joel’s new book is out – I wonder if his post is intended to garner attention for the book? Not directly – the post doesn’t mention it – but when you visit the site (instead of reading Joel’s post in your RSS reader) you see Joel’s unusually short article, as well as an ad for the new book.
Hmm…
July 1st, 2008 at 6:12 pm
Menu Items are unusable in general!
Context menus are better, but also not perfect.
We should associate and expose actions in proximity to the “noun” that they are operating on. Context menus do this, but use overlapping windows that hide potentially interesting information to expose the items.
A lot of programs these days use a mode where a set of options is exposed when something is selected/active. I believe this is a better form of context menu. This may change the layout and move things around, but makes better use of space.
Instead of a “menu” with lots of arbitrarily placed items, we get a set of “verbs” near the “noun” they operate on.
What about verbs that are not clearly associated with some specific noun? For these I would:
A) Try to spring a “noun” for them into existence. If its a configuration option, try to represent whatever is being configured by some visual item and offer that as the “noun”.
B) Use a toolbar. Since we cleaned up most of the menu, we need less scalability (so we can fit the remaining options into a small toolbar). Toolbars are also less clicks away, AND are useful at teaching the user the more effective way of using the keyboard – if there is an easy way to display the keyboard shortcuts associated with each toolbar button.
July 1st, 2008 at 6:33 pm
I would do both. Grey the item out, to signify that it’s disabled, but still allow it to be selected for info.
Interesting points all around.
July 1st, 2008 at 6:38 pm
On the subject of hidden menu items, I find OS X’s use of the Option key very disconcerting; various app’s menu items (both regular and context) change when you depress the Option key. While I understand the idea and the menu item changes are usually related (e.g. Safari goes from “Download linked file to Desktop” to “Download linked file to…” and lets your specify a location), the fact that this isn’t discoverable without pressing Option all the time is rather annoying.
I do agree that menu items should be disabled if they aren’t relevant; I can’t believe Joel would recommend this.
July 1st, 2008 at 6:44 pm
How about putting a little question mark on the far right of disabled menu items, and hovering on it gives a short snippet of help text like “Nothing to undo” or “Select something to copy”?
Useful, discoverable, unintrusive, everyone wins!
July 1st, 2008 at 6:57 pm
This brings up an important point: Windows apps (and increasingly Mac apps) rarely use the noun/verb relationship found in the original HIG.
Far too often on Windows I find myself right-clicking an item in a table, seeing the selection change, and then getting a context menu that relates only to the pane that the table is in. Part of this is to blame on MDI windows, but seeing the same behavior over and over in Mac applications indicates that noun/verb is dead.
July 1st, 2008 at 7:17 pm
Instead of having a disabled menu, it just could be a text there. Just show the menu, when the user can really interact with it. There are lot of UI Rich frameworks, which helps to build more intuitive interactions through the UI.
With AJAX and other tech you could just re-render the part of the page to change it to menu from plain text.
I think both the technology (AJAX) and user are ready for it. Most of the AJAX drawbacks are identified and fixed by alternate ways to do them.
July 1st, 2008 at 8:01 pm
Joel is usually pretty spot on with a lot of his stuff. This is one case where I read what he wrote and he has now lost a good deal of credibility. I have literally been looking for an excuse to use his help desk software, not so sure I am such a fan anymore.
This is not really a case of one agreeing or not, this is simply a case where he is flat out wrong, there is really no debate here. Say you have a menu called “burn” and 20 items are in it, and all 20 are not active, as you have not inserted a CD-R. If I have to hit up 20 items and get 20 alerts to figure that out, computing would suck.
July 1st, 2008 at 8:20 pm
I think Joel thinks he knows something.
Disabled menus probably go back to around 1980 and the Lisa project. the Somebody would be Apple. Human interfaces weren’t based on trends or fads or fashion, they were tested on humans and tweaked until they worked well, and then the guidelines were written into books.
“Fashionable” probably means “programmers started thinking the Mac way was useful and copied it.”
I find the fad of having constantly enabled menus to be annoying. I think it’s difficult to find a way to make this work that doesn’t insult the user. Most of the time, apps that work like this give an error alert. Consider if your car was that way. Reach over and push a radio station button and the horn honks and a voice says “The Radio Is Not On.” Lack of sound and lack of a displayed station could have told you that.
Menu item hiding…that really makes no sense. If I know the app well, I’m probably using shortcut keys. If not, I look at the menus. Of course, the commands I’m looking for are likely to be the ones hidden, because I rarely use them.
July 1st, 2008 at 9:27 pm
I think a compromise would be to show the menu item as disabled (to provide the visual clue that you can’t perform the action), but at the same time make the menu item actually clickable and show Joel’s proposed message box (to give the explanation). I’m not sure if either this or the tooltip suggestion is doable with standard menu controls. On the topic of usability and disabled buttons, I recently had to help my mom with one of those applications where the “Save” button is only enabled if you actually have any unsaved changes. You should know that my mother lost maybe 5 lines of text due to not understanding saving in 1997. She still doesn’t understand it, but since that day, she’s been saving ferociously. She saves about once every 30 seconds. She always presses save twice or three times, just to make sure. And as you can imagine, the disabled save button in this extra-smart application freaked her out completely. That was one of the hardest things to ever explain to her.
July 1st, 2008 at 9:33 pm
That’s what really irritates me about “modern” context menus – you can’t reliably learn by muscle-memory their position. Amigas had menus that that just ghosted the inapplicable menu items as appropriate. Much better, especially with a hack called MagicMenu that shifted the main menu to a right-click popup menu like a context menu in location but not behaviour. No jiggly vanishing menu items, no miles-away-menus like mac or unhacked amiga top-bar menus, just no-nonsense menus instantly accessible with clear feedback when a menu menu item didn’t apply to the object.
July 1st, 2008 at 10:01 pm
Dead on man, dead on. Menu items should never be enabled if they are not going to be usable. Any user with any sort of computer experience just glazes over them without a thought. Enabling all menus would create far more problems than it would ever solve.
July 1st, 2008 at 10:26 pm
I think that Eyal Lotem’s post comes closest to my thinking. Maybe we should rethink menu items that are only applicable for a limited number of things. Why don’t we have menu items (or whatever) that are always active and always relevant to what the user is doing?
I know it would be difficult (impossible?) but I think its worth considering. Going back to the Humane Interface (great book!), menus shouldn’t be tied to modes. They should always be active and relevant or they should be removed.
I know, easier said than done. :)
Later…
Richard
July 2nd, 2008 at 12:14 am
I’m thinking leave it grayed out, but if you click it regardless, *then* you tell the user why it’s disabled. (In a tooltip, so they don’t have to close another window that’s open) And not overlayed on the menu you have up..
I think this is the best of both worlds.
July 2nd, 2008 at 3:15 am
Mark’s right, there is a very old API that you could use to find out what the user selected when they let go of the mouse on a disabled menu item.
The API is MenuChoice. It’s still alive, too – I have no idea if it actually works these days, but it made it into Carbon! Here’s the original IM:TB documentation, and slightly newer Carbon documentation. There’s a little more detail under MenuSelect.
Nobody that I’m aware of ever used it, probably because there was no good UI guidance on what to do. I always thought it was a cool idea though.
July 2nd, 2008 at 4:42 am
Joel had obviously just installed Vista. Requesters are good! Cancel or Allow?
July 2nd, 2008 at 9:05 am
Disabled controls and menus when designed well with clear labels can guide a user during a task as well as provide clues to additional options that are available.
Also any kind of GUI design should be target built for the audience so there is no right or wrong answer, just guidelines you should follow. There are cases for example when hiding options can also help guide users.
Know your client and target audience.
July 2nd, 2008 at 2:04 pm
Well, here’s a specific example. My broadband connection at home stopped working– so I called tech help. The person on the phone decided to switch my connection from DHCP to PPPoE, which required going into (Leopard) system preferences. Problem was that the menu item needed to do the switch was dimmed. The reason, I eventually realized, was that I had to ‘unlock’ the network settings– once that was done, everything worked.
Presumably, there were two problems: the tech help person kept his preferences normally unlocked and there was a little ‘locked’ icon in the corner of my network preference pane that we both missed. What would have been the right interface?
July 2nd, 2008 at 2:08 pm
MattF: good example. It’s always easier to prescribe what would be “ideal” than to actually follow through on being a model of perfection. But in cases like you are describing, I think an ideal solution would be for the disabled items to also have visible next to them in the menu item a greyed-out lock icon. This would have immediately cued you to think about “unlocking,” right?
July 2nd, 2008 at 3:51 pm
That would probably have the desired effect, but… I wonder if adding more interface elements is the right approach. The ‘Spolskyan’ approach would, I guess, be to present an authentication dialog if the user chooses that menu item. That’s more typical of what OS X does in this sort of situation, but it’s not really right either– the -point- of locking the network parameters is to set a higher bar to the user than the usual ‘enter your password’ dialog box.
July 2nd, 2008 at 4:22 pm
It’s a very unusual situation where the application’s primary functionality is locked down. So I think it would make sense to use a somewhat heavy-handed technique to communicate this to users.
July 2nd, 2008 at 4:58 pm
At first, I was worried that you were just going to regurgitate Joel’s brief post — fortunately you had a little more rationality than that.
Perhaps Joel isn’t being clear on what he sees in his mind’s eye. Or maybe he has just spent way too long working on a novel in a remote Colorado hotel. All work and no play makes Joel…ah, forget it…
Still, it makes sense that if I open up a blank text document, I should be able to paste, but not cut or copy, since there would be nothing selected yet.
July 2nd, 2008 at 6:26 pm
Good article Daniel. I was pretty surprised by Joel’s comments.
Menu items are a teaching aid just when the user is starting out; disabled menu items show the user that a command exists but not available in the current context. Cooper et al say this in their great book About Face.
About Face.
July 5th, 2008 at 3:43 pm
It’s hard to disagree about the hidden menu issue that Joel Spolsky mentions; I’ve used products that would remove certain menu items based on context, especially when working on a very different type of data (e.g., spreadsheet vs. word processing document), and it can be annoying to try to find the menu item you thought was there but has moved.
When it comes to different levels of functionality supported by an application, such as QuickTime’s player application sporting the pro-based functionality in disabled menu items with a “PRO” icon beside them, I can see that as good (built-in marketing), but I can also see the logic in only showing those menu items that a particular user has permission to use, such as what happens in Mac OS X depending on what level of user is logged in (for-your-eyes-only).
There’s also some logic in only showing applicable menu items when invoking a contextual menu; after all, the user assumes it only holds those items applicable to the particular context, and to have to run over dozens of menu items applicable to files when you clearly are in a text field makes no sense.
However, when it comes to enabling all menu items, even if they cannot be used at the particular moment makes absolutely no sense at all. I like knowing that the content of the web page I’m looking at has finished loading, and if the “Stop” menu item were enabled, it would make me wonder what’s the problem with my browser, network connection, or the web server. If there is a valid reason for telling the user why a menu item is disabled (if an application is correctly designed, most cases should be fairly obvious), one popular way to do this is by using a help tag/tooltip as the user navigates over such an item; another popular way is to display text in a status bar strategically placed based on the particular application.
July 12th, 2008 at 2:42 pm
I have to agree with those who stated that Joel is incorrect on the concept of enabling for the sake of telling someone the feature isn’t available.
A tooltip can still lead someone in the right direction to enable it.
From a usability perspective, giving someone a dialog box or another page to go to which says “This feature isn’t available and why” only means yet another set of clicks and obstructions the user has to deal with to get from point a to point b.
To take it a step farther though –if the user were given the choice to enable the feature right there and then, I would still use a tooltip method where a choice didn’t have to be made, it would just disappear on “mouse-roll out”, since deliberately forcing users into choices or other screens they didn’t want to have to make in the first place is a no-no.
I’m not sure if Joel’s been thinking this one through, but after all — a blog is a brain dump half the time — and thinking out a concept is part of the worth. I wouldn’t stop reading Joel because he put out a premise and you happened to see it shot down.
July 13th, 2008 at 10:47 pm
I thought this and was surprised when I read it too. Thanks for replying to it.
July 31st, 2008 at 3:41 am
Good call Daniel