{ 2007 06 16 }

The misused mouse, part 1: The story of the mouse’s decline

Now, I am by no means hoping to abolish the mouse. Its price to performance ratio is unmatched, and the best alternative pointing device (the tablet) can’t be found for much less than an order of magnitude greater expense: hard to justify for the relatively small performance edge it offers. What I do wish to decry is the enormous reliance on the mouse to cover every possible user interface situation, failing to take advantage of other, better designs. Years of lazy design and low opinions of the user’s desire (even ability) to learn have left us with a constant testing of Fitts’ Law for such trivial tasks as saving, broken paradigms (what about a real-world button relates to replacing an old document irrevocably with the current one?), and a user experience that is more patronizing than productive.

Let’s start with a few key ideas about interface devices. The keyboard is quantized (that is, it consists of discrete units of input, like a piano’s notes), while the mouse is continuous (its input ranges without breaks across the entire screen, like the strings of a violin which cover every possible pitch in their range).

Now, think about the actions you perform on your computer in a given day. You type, save, open, close, select, resize, navigate, refresh, cancel, approve, and perform scores of other actions.

Now divide the tasks into groups. Which ones consist of discrete actions, and which require fine, continuous control? I’ll be generous (and rude to my fellow console text editors—I know vi/emacs can both comfortably rely on keyboard input only) and say text selection and input positioning, color selection, drawing, and most (spatial) navigation is most naturally, perhaps even most effectively, performed with a continuous input device such as a mouse.

Now, for the discrete actions: type, save, open, close, refresh, cancel, approve, and most of the other basic actions. In fact, I’d say many users could count scores of daily activities that are discrete, whereas breaking a dozen continuous actions would be a challenge. (Let’s put aside all window management like switching between windows, resizing them, moving them, and so on. These mostly seem continuous but I’ll explain in a later post why they’re usually not.)

Now, which of those actions are new users taught to do with the discrete input device? Typing.

Now, advanced users have memorized ways to do a large fraction of (or, if they’re fanatical, all) discrete actions with their discrete-input device. If you’re looking for evidence of the superiority of a keyboard over a mouse in most situations, look at these users. There is a strong correlation between how much time a person uses computers (especially professionally) and how much they switch away from the mouse whenever readily possible. I challenge you to find a hundredth as many IT professionals who prefer the mouse as who prefer the keyboard when either will perform a given action.

Further advantage of a keyboard over the mouse lies in “muscle memory.” (For those who might not be familiar with the term, it’s the re-enforced skill of repeated actions—and the reason we can speak, write, type, and a host of other skills, without having to consciously perform every muscle contraction in careful coordination.) This, however, isn’t because it’s quantized, but rather because our position on the keyboard is generally absolute, whereas whenever we grab the mouse the cursor could be anywhere. In fact, there are only five pixels we can hit with our eyes closed—the one we’re on plus the four corners. That’s less than 1/150,000th of the median computer screen’s real estate that can be associated with muscle memory. The keyboard, on the other hand, can be entirely memorized (or close to it) in the course of general computer use. With combinations of control, alt, and shift, and even the more modestly skilled typists have literally hundreds of key combinations they could hit rapidly, even with their eyes closed (and that’s ignoring key-chaining that programs like Emacs use).

Now, consider that without on-screen controls, the entire screen could be devoted to content. Certainly that’s a small gain in most programs (perhaps 10% on average, based on a wholly unscientific guess by me), but in more complex programs (like Photoshop) tools and controls can account for over a quarter of the screen. Save most of that space and you’ve upgraded your monitor by several inches diagonal. Furthermore, these same controls require the user to switch between their keyboard and mouse frequently. Perhaps it isn’t the most criminal of inefficiencies, but it’s still squeezing in more work to the same ends.

“Okay,” you’re thinking, “you may have me convinced that a keyboard is a better fit for most actions, but let’s see you convince the average computational neophyte that hiding everything behind obscure key combinations is somehow an improvement. The very euphemism for the user-unfriendly cruelty of engineers is the mystical incantation of button pressing on a VCR needed to banish the blinking 12:00 until the next power outage. How could transferring this blind manipulation to computer’s user interfaces possibly improve the world?”

The reason you say that is that you are still thinking in the framework of traditional GUIs. I never said “blind,” “hiding,” or “obscure.” Note also that I didn’t claim the transition would require no adaptation by existing users. Such a claim would be a lie for any changes.

What I am claiming is that, with a little thoughtful work, a keyboard-centric interface would be at least as usable a mouse-centric one. Xerox Alto’s revolutionary mouse (once filtered through Apple to the Macintosh), is rightly credited with bringing usable, accessible (in the social/intellectual, not physical, sense) computing to the mainstream, but we’ve strayed from good design, by forgetting about other input devices. In my next entry, I will explore one possible design for applications to largely eliminate the use of a mouse in favor of the more appropriate keyboard—without reducing usability.

Without further ado, I give you a proposal for a mouseless graphical user interface.

Update: It seems, as I peruse Jeff Atwood’s site, he has mentioned the efficiency of the keyboard over the mouse, which, according to Jeremy Miller is “the first step to coding faster.” I’m glad these gentlemen recognize the utility of the keyboard, and I’ll forgive Mr. Miller’s programming-centric view of the benefits. Perhaps a few more people will join the team.

Posted by Clay Barnes on Saturday, June 16th, 2007, at 4:28 am, and filed under hci, interface design, usability, user experience, user interface.

Follow any responses to this entry with the RSS 2.0 feed.

You can post a comment, or trackback from your site.