Comments on: Disabled Menus Are Usable http://www.red-sweater.com/blog/515/disabled-menus-are-usable Mac & Technology Writings by Daniel Jalkut Sat, 11 Oct 2014 01:25:38 +0000 hourly 1 http://wordpress.org/?v=4.0 By: Donald http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-145786 Thu, 31 Jul 2008 07:41:48 +0000 http://www.red-sweater.com/blog/?p=515#comment-145786 Good call Daniel

]]>
By: Mathieu Tozer http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-145323 Mon, 14 Jul 2008 02:47:58 +0000 http://www.red-sweater.com/blog/?p=515#comment-145323 I thought this and was surprised when I read it too. Thanks for replying to it.

]]>
By: Jonathan Firestone http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-145287 Sat, 12 Jul 2008 18:42:09 +0000 http://www.red-sweater.com/blog/?p=515#comment-145287 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.

]]>
By: Gary L. Wade http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144688 Sat, 05 Jul 2008 19:43:35 +0000 http://www.red-sweater.com/blog/?p=515#comment-144688 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.

]]>
By: Matt West http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144359 Wed, 02 Jul 2008 22:26:02 +0000 http://www.red-sweater.com/blog/?p=515#comment-144359 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.

]]>
By: Chad http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144357 Wed, 02 Jul 2008 20:58:24 +0000 http://www.red-sweater.com/blog/?p=515#comment-144357 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.

]]>
By: Daniel Jalkut http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144353 Wed, 02 Jul 2008 20:22:24 +0000 http://www.red-sweater.com/blog/?p=515#comment-144353 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.

]]>
By: MattF http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144352 Wed, 02 Jul 2008 19:51:41 +0000 http://www.red-sweater.com/blog/?p=515#comment-144352 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.

]]>
By: Daniel Jalkut http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144350 Wed, 02 Jul 2008 18:08:08 +0000 http://www.red-sweater.com/blog/?p=515#comment-144350 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?

]]>
By: MattF http://www.red-sweater.com/blog/515/disabled-menus-are-usable/comment-page-1#comment-144349 Wed, 02 Jul 2008 18:04:25 +0000 http://www.red-sweater.com/blog/?p=515#comment-144349 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?

]]>