Thursday, July 03, 2008 7:48 AM
Menu item usability vs. learnability
I'm sure Joel Spolsky has forgotten more about UI design than I'll ever know, but I'll take a shot any way. A few days ago he wrote this about disabling menu items:
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.
I actually got to this post through this thoughtful reply from Daniel Jalkut about why disabling menu items is usable:
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.
And, he further goes on to make the distinction between usable and learnable interfaces. There are probably a lot of ways to think about it, but basically I reserve "usability" for productivity related issues that users who use a system a lot run into and "learnability" for first-time or occasional users. Daniel makes this point:
The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.
Generally, I agree. However, some applications never have experienced users (meaning users that use the application nearly every day for long periods of time). For me, the applications that need to have high user-productivity (usability) are Office, Visual Studio, my browsers, and a handful of websites. For others, I appreciate some help orienting me, and I wouldn't mind non-disabled menus that explain why they can't work. If your application is used only occasionally or mostly by first-timers, then concentrate on learnability and don't disable menu items.
It's not always that simple. For example, I have to use Photoshop and Gimp at my job, but not as a designer and only occasionally. Most people who use it for work probably keep it up all day and might find it to be very usable. For me, its steep learnability curve makes it hard to use. However, I think it's right for the authors of those applications to ignore me. They should disable menu items that cannot be used in the current context because they have a large number of users that use the application very frequently.
There is a third option though, one that I think gets both usability and learnability. Just do the operation of the menu. If the user is picking the menu item, then they think it makes sense -- figure out what they think the menu item should do and then do it, or as Joel once put it:
Thus, the cardinal axiom of all user interface design:
A user interface is well-designed when the program behaves exactly how the user thought it would.
While reading the blog articles cited above, I quickly checked the menu of my browser (IE 7.0) to see which items were disabled (image on the right). I don't know what "Security Report" and "International Website Address" do, and the status bar message for them gives no indication when these might be available. I even did a quick look in the help and Google, but I didn't find anything useful.
Of course, the help could be better, but really, I bet that you could generate a "Security Report" for any web page. Maybe the report would be simple or not give much information, but I would like to see what a report might have. This is not the same as just popping up an error, which would not generate a report. If you wanted to have some explanation of why the it was so sparse, that's easily integrated into the report.
Another option is to not put the items into the menu to begin with. If these items are so rarely available, then they probably shouldn't even be there. IE already uses the status bar for website/context specific actions, and these could probably be relagated to a less obvious place.
So, I don't think it's a clear as never/always disable menu items. Personally, I try to always make the menu enabled and just do the operation (undo is essential if you do this pervasively), but I would certainly disable a menu item that could not possibly make sense (e.g. "Save" when no document is open or "Copy" when nothing is selected). If I was writing an application that was only used occasionally, then I would opt for Joel's suggestion of leaving all menu items enabled and using them as a way to explain the usage of the application.