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 1024x768px, 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.