Aaron Ballman left a comment on this blog last night, raising a good point about needing to pony up a solution to my “I hate menus” dilemma. Unfortunately, I’m not certain what the best solution would be, at least not universally.
I don’t think that menus are universally bad. Some are quite useful and cool, like the Action drop-down button in the Panther and Tiger Finder. Here, Apple is placing common, contextual commands where they are most needed.
As for the notion that menus provide an outlet for the exploratory catch-all approach, I think this is entirely reasonable for smaller applications that don’t suffer from an addiction to modes (although whether this mode-addiction is acknowledged or swept under the rug depends on the application).
My core issue with menus is that I think they are abused more often than not. Xcode is a prime example of this. I have Xcode 2.2 sitting open on my iBook G4 with the iRooster project running (yes, I need to upgrade Xcode). I currently see 14 separate top-level menus, with well over 100 menu items beneath that (plus many more items sitting on flyouts beneath that).
Xcode’s Debug menu is a particularly egregious offender. It barely fits on-screen at 1024×768px, with 34 items (not counting the contents of flyouts, again). 14 of these items are disabled, since I’m not debugging.
The Design menu is another offender, here. Since Xcode is in a code view, literally none of the items on this menu are enabled.
Windows Media Player for the Mac is another example of an application that makes poor use of menus. As near as I can tell, WMP:mac’s Edit menu contents are always disabled!
I have no issue with vertically stacked commands identified by labels and bitmaps. Instead, my problem stems from the everything-but-the-kitchen-sink dumping ground approach taken by many applications. I think it would make far more sense to move commands that will only be applicable in one place in the application into that component of the application.
Possibly Related Posts:
- Windows System Colors
- “We can’t spy…if we can’t buy!”
- Windows System Colors Chart Updated
- WgeTF: are Windows apps just lame?
- Making everyone happy does everything but that
6 Comments
FWIW, I do agree that too many menus is an atrocity. But you’re right, it’s a very difficult cat to skin. When you are supposed to have any functionality in a contextual menu also available in a “regular” menu, things can get very hairy when you deal with a lot of contextual concepts. I think that IDEs suffer from this more than most applications as they have so much varying functionality. You’ve got the code editor, design editor, and debugger being the major conceptual parts of most modern IDEs. Between those three things, you have a plethora of functionality trying to vie for UI space which generally means it gets stuck in a menu.
I really like the ribbon concept that Office has come out with as I think it solves a lot of UI problems. (Thinking out loud here) However, I think it could be used in tandem with a menu instead of in place of one. Imagine the ribbon being the place where the “major” functionality is exposed and the menu being the place for the “minor” stuff. This way you end up with a user friendly (but still “quick”) UI for the main functionality, and a place to put the secondary functionality which isn’t used as often — and neither place should suffer from information overload because you’ve split it into two areas. Good idea? Bad idea?
When you get down to the underlying UI elements, the Ribbon really consists of:
1. A series of tabs, each of which hosts:
2. A collection of groupboxes, menus, buttons, listboxes, combo boxes, and various other controls.
Don’t let the fancy UI make you think otherwise
My concern with having two totally independent sets of menus is that it’s not possible for a UI designer, developer, or (most importantly) a user to reliably determine what’s considered “major” functionality, and what’s considered “minor.”
Additionally, you’ll always end up with one camp that believes Feature X must be placed on the Ribbon, in direct contrast to another group that would never consider that functionality to be important.
Of course, there may still be a group of commands that simply don’t make sense in the context of a Ribbon tab (or are bits of functionality that you need to access everywhere), which is how you end up with something like the Office button, which contains items like your MRU list, save commands, a button to access the Options dialog, and the Exit command.
I’m not convinced that the Ribbon in its Office 2007 form would make sense for a developer tool suite. Perhaps in another incarnation it would, though.
Yeah, I can agree with your reasoning and conclusion. Unfortunately, it leaves things unresolved.
I think a large part of the menu snafu boils down to contextual items being on the main menu as well. But that begs the question: is it really necessary to do that for all applications? Such as with an IDE… you can expect a reasonable level of savviness from your users (perhaps), so you may be able to get away with not having every refactoring tool and widget doohicky on the main menu. Especially if you make the menus configurable. I know this goes against the conventions… but then again, IDEs are an entirely strange experience in themselves, so it may not be that bad of an idea. Or maybe it’s just late.
That’s not a bad idea, quite frankly. I’ve gone down that path many times, but it’s never worked out, for one reason or another. One place where this may break down is for blind users.
By the way, where do you live? Minneapolis? I grew up right near the U of M.
Ah, excellent point about the accessibility of it. That does throw a wrench into things, slightly. But once you make the menus configurable (probably via some sort of dialog), then even your blind users can still discover functionality in much the same way as your seeing customers will: via that dialog, right? It just takes a bit more adventure to discover the functionality.
I live up by St Cloud in a little town called St Augusta; about an hour away from the twin cities.
btw, the reason I’m keenly interested in this topic is because the company I work for makes an IDE (and programming language), and I’m responsible for keeping the UI design reasonable across the three platforms we deploy to (Windows, OS X and Linux). So any time I get the chance to have an in-depth discussion about a problem relating to IDE design, I get rather excited.
One Trackback
An auspicious number
Back in July, I decided to create a new weblog where I could share my thoughts on UI design and User Experience (especially the snarkier ones) with the world, and keep my writing skills (shabby though they may be) from…