« How Would You Like Your Three Panes? | Main | SWT: I Still Don't Get It »

Interface Modes, Fitt's Law, and the Menu Bar

I've been reading Jef Raskin's book The Humane Interface and he has a big section about how modeless interfaces are a goal yet a few chapters later he discusses Fitt's Law and is ravings and how wonderful the Macintosh menu bar is WRT ease of use with a mouse. The problem is that while being an glowing example of Fitt's law the menu bar violates modelessness.

First let's address Fitt's law. Fitt's law says that the expected time to perform a gesture is directly proportional to the distance traveled by the cursor and inversley proportional to the size of the target area. A big button close is quicker to click then a small button far away. The arguement goes that since the menu is at the edge of the screen the vertical dimensions of the menu items are essentially infinite and thus easier to move the cursor to the menu from a greater distance. Once you become familiar with the interface you don't look at the menu as much as you just remeber how to move the mouse to get there quickly.

The issue of modality however is can be technically argued away in Jef's two part definition of modes. The second part essentially requires that the same gesture does two different thing at two different times for the interface to be modal. In this case clicking at 100, 0 (or thereabouts) bringing up the Foo menu. Where the entire Macintosh UI creates one huge mode shift is in the treatment of the menu bar. Depending on the application whose window you have focused (or just closed) the menu bar is the menu bar for that application. So the menu at 100, 0 could be wildly different between applcation. A team Jef was on was once so obsessed with removing a mode from a computer that they even designed a computer without a power button! (Engineering was convinced it was an error in the spewcification and put a power switch on anyway.)

But then there is the second part of the modality definition that starts to break down this paradox: "the current state of the interface is not the user's locus of attention." If you are selecting a menu clearly the locus of attention should be the menu. Also the window you are looking at should be a locus of attention just before the menu item is selected.

But let's go back to how you interact with th system once yoar familiar with it. It's the ability to go to a menu item from "memory" that indicates the fact the locus of attention is not the menu bar. It's this interaction that makes the menu bar modal. It's not a non-recoverable error either, because no commands are really supposed to be invoked from a single click of the menu bar the user will have to focus attention on the drop down menu. So before any command occurs the user will realize that the menu bar was in a different mode.

It seems then that the bashing other windowing systems get for attaching the menu to the window is only half deserved, since by being less efficent with Fitt's law they are less likely to be subject to accidental user mode-based mis-gestures. Fitt's law may allow the menu to be brought up faster, but that is at the risk of modal user-errors.

About

This page contains a single entry from the blog posted on July 8, 2003 11:51 AM.

The previous post in this blog was How Would You Like Your Three Panes?.

The next post in this blog is SWT: I Still Don't Get It.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33