tewha.net

A coworker posted on Firefox 3 and Mac addicts, and mentioned:

Other than background windows looking like foreground windows, all of his issues are either extreme power-user features (AppleScript support), things that are easily arguable (clicking on the URL bar selecting the URL), or things that Firefox could quickly steal from Safari and should make everyone happy (submenus with additional history items in the History menu.)

I started this as a comment there, but I wanted to expand it more. Now I know what he meant, but I don’t like the word “arguable” in that sentence. He suggested “subjective,” but I think that makes it worse.

Interfaces are thought out or not. Interfaces can be made simpler or more complicated, in one aspect or another. Often simplifying one aspect will make another more complicated. But interface design is neither arguable nor subjective. Instead, the effectiveness of an interface is something much simpler: measured or not.

In user interface design, the impact of an interface can be measured across your prospective user base. It may not be practical for you to do so¹, but it can be done. That means it’s not subjective. Don’t write something off as “arguable” — if it matters, determine the truth.

This is not to say you can determine the perfect interface by measuring, but you can determine the superior of two interface designs.

If it’s something your users will feel strongly about and there’s significant disagreement, make it an option, but that should be reserved for cases where it’s really important to the user. But that’s tangental: User preference for interface varying for a particular user doesn’t mean interface design is subjective. And I think a good first pass is to default to least astonishment — which in today’s world, will mean consistency with the spirit of the platform you’re targeting.

1. In fact, this is probably the rule rather than the exception. [↩]

In Where Keyboard Shortcuts Win, Gruber talks about Tog’s findings on mouse vs. keyboard. In a footnote, he adds:

Especially with most Cocoa apps, where the Find commands are in a sub-menu, and thus take even longer to target using the mouse.

To me, this is a real problem on Mac OS. It is not one that Apple has not only completely failed to address, but has actually made worse in Mac OS X. For technical users, items in hierarchical menus are slightly more difficult to activate. But for non-technical users, items in hierarchical menus are not just a little more difficult to activate, but awesomely so. And in Mac OS X, Apple has introduced more of them!

Hierarchical menus have become a little better now that you don’t have to hold down the mouse button¹, but watching a neophyte or novice try to access them is a real eye-opener. I’d really suggest to any developer thinking of using one that they ask a non-technical person to select one. Using the mouse at all is the first major task. Using the mouse to select menu items is almost as difficult. And using the mouse to select menu items in hierarchal menus will often be more difficult than the previous two combined. It’s not only conceptually screwy, but physically difficult.

After doing so with a product used by teachers (including the almost-ready-to-retire), I removed every hierarchical menu from our application. There weren’t many anyway. But one of the most difficult things for me when moving from Mac OS Classic to Mac OS X was how obvious it was that Apple hadn’t tested this.

Now I’m not altogether opposed to hierarchical menus. I think they’re a perfectly valid solution for Services, Open With and maybe even Arrange By². All of these options can be accessed some other way, except for Services which are rarely used by novices or neophytes. I also think they’re fine for contextual menus, since contextual menus only offer choices that are available elsewhere.³ But having Find commands in a hierarchical menu? That’s completely completely insane. Find is something users need to be able to access.

Apple even admits this problem in Apple Human Interface Guidelines:

Because submenus add complexity to the interface and are physically more difficult to use, you should use them only when you have more menus than fit in the menu bar…

So far, so good. But they go on:

…or for closely related commands.

This simply does not follow! Making something physically more difficult to use just because it’s closely related to something else is stupid. A good design puts commands in recognizable locations, and puts commands users need to access in locations that are easy to physically access. Closely related is not an excuse for a hierarchical menu. Closely related and infrequently used⁴ is a good reason, though. But what genius decided that spell checking and find qualified? If find qualifies as infrequently used, it’s almost certainly because it’s such as a pain in the ass to select!

I do think this is less of a problem now that the menu search has been added to the Help menu. I find myself using this frequently in applications with many infrequently-used menu entries.⁵

1. And, in fact, this suggests a simple fix Apple could do: Clicking an item with a hierarchical menu should lock that hierarchical menu open so the user can take as long as they want and use whatever motion they want to get into the hierarchical menu. [↩]
2. Arrange By is a valid place to use them only because novices and neophytes are probably looking to arrange by name most often, and that’s easily achieved by switching to list view. [↩]
3. Ahem. Or should. See Apple’s Human Interface Guidelines on Contextual Menus. [↩]
4. Or an option with an easier access method. [↩]
5. Another symptom of lack of zen in application design. A few unused commands are normal but when a menu bar consists almost entirely of unused commands there’s a problem. [↩]