AskTog: Interaction Design Solutions for the Real World
 
Interaction Design Section   Living Section   About Bruce Tognazzini
Ask Tog

Keyboard vs. The Mouse, pt 2

Originally published in the AppleDirect, October, 1989
Republished as Chapter 22, in Tog on Interface

People were not about to let the whole command-key thing drop:

Tog,

Consider a typical MS-DOS word processor. It sits there and waits for the user to tell it to do something, and then it gets its next action from a big list something like this<p>If the user pressed a number or letter key, then insert the corresponding character into memory and advance the cursor<p

Now consider a typical Mac word processor, with all of its wonderful new concepts. It sits there and waits for the user to tell it to do something, and then it gets its next action from a big list something like this:

—and so forth, unless the user wants to use the command key equivalents, in which case she has to remember whether she is in the MPW editor (where command-S means Save) or the AppleLink editor (where command-S means Send) or in some other editor, where command-S means something else. If she wants to use the same editor for C source, Pascal source, letters to Mom, and AppleLink memos, or to redefine the command keys, that's too bad.

It should be obvious that this is orders of magnitude better than the simple-minded MS-DOS interface, and justifies perfectly the choice of an expensive computer with no second source.

Unfortunately, it isn't obvious. Could you explain the difference? Could you explain it in reasonable terms, without sounding like Jimmy Swaggart denouncing Buddhism?

Thanks,

—David Winfrey, Silver Spring, MD

Oh, sure, David, open up on me with an AK-47 assault rifle and then ask me to fight back with one mouth tied behind my back.

You paint a most rose-colored picture of what I had always thought of as a blue world. Perhaps we have all been misled these years. Perhaps the independent studies that show over and over again that Macintosh users are more productive, can learn quicker, buy more software packages, etc., etc., etc., are somehow all flawed. Perhaps....

Let us first examine your ponderous exposition of the tribulations of discovering and using the mouse:

If the user left the keyboard, found the mouse, watched the screen while she moved the cursor to the File menu, pressed the mouse button, watched the screen while she dragged the cursor to the Save item, and released the mouse button....

Now, that does sound like a lot of work. Particularly since, like most responsible mouse and AK 47 owners, you probably keep your mouse locked up in your bedside chest, with the ball secreted elsewhere, least the children find it and roll each other to death. I, myself, casting danger to the wind, keep my mouse in the same room as the keyboard! Often actually connected (gasp) to the computer!

Command Keys Aren’t Faster. As you know from my August column, it takes just as long to decide upon a command key as it does to access the mouse. The difference is that the command-key decision is a high-level cognitive function of which there is no long-term memory generated. Therefore, subjectively, keys seem faster when in fact they usually take just as long to use.

Since mouse acquisition is a low-level cognitive function, the user need not abandon cognitive process on the primary task during the acquisition period. Therefore, the mouse acquirer achieves greater productivity. And just to balance the record, here is how you might have phrased the process used by your MS DOS victim:

If the user stopped all cognitive processing on the primary task, entered a 2.5 second decision-making process shrouded by amnesia, laterally rotated the forearm at the olecranon joint while simultaneously flexing the fifth metacarpophalangeal joint for purposes of accessing the ALT key, while simultaneously extending the second metacarpophalangeal joint in an effort to reach the W, then you should write the stuff in memory to a disk file while the user tries desperately to do a cognitive re-acquirement of her original task.

Let us now move on to the more general questions of a visual vs. abstract interface:

There are some really good abstract interfaces. The HASCI system, a text-based interface that preceeded and far outshowed DOS, was one. Jef Raskin’s Cannon Cat interface is another. At the risk of seeming immodest, I think the Apple II File card interface, as embodied in AppleWorks, is a third. The system you describe might well be a fourth. These systems promote many of the behavioral attributes that are strengths of the Macintosh interface: consistency, freedom from modes and sequences, user-control, feedback and dialog, metaphors from the real world, forgiveness. At the same time, there are bad graphical interfaces, where behaviors are not bound to visual appearance, where consistency is often in short supply.

Still, studies on individual differences indicate that the overwhelming majority of people will never be comfortable with abstract interfaces. For example, a remarkable number of people cannot remember 250 different commands.

We programmers are not normal people. We tend to have superior memories, we actually grasp boolean logic, we have formed priesthoods around the most egregious interfaces, and we have a firm belief that the average citizen is in search of an editor for his daily C and Pascal coding tasks.

We are not firmly rooted in the real world.

I submit that the greatest difference, Brother Winfrey, between the interface you describe and the Macintosh interface, is that the "lights are on" on the Macintosh. The Macintosh is a visible interface, and people thrive on that visibility.

That is indeed a profound difference.

The Macintosh is sweeping away the dying carcasses of the ‘black cave" interfaces of old. Join with us, Brother Winfrey, in celebrating the dawning of a new, glorious, single-source day.


Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top

---
 
Contact Us:  Bruce Tognazzini
 
Copyright Bruce Tognazzini.  All Rights Reserved