K e y b o a r d s v s M i c e Now and then a question pops up on the net, asking whether keyboard based interfaces are faster than mouse-centric interfaces[1], mostly citing an article from Bruce Tognazzi[2], or one of the many responses to said article[3]. This is usually followed by the comment section filling up with responses from die-hard emacs or vi users that vehemently point out the superior speed of keyboard input, interspersed by a few thoughtful people that recognize the subjectivity of such claims[4,5]. But, in the end, they all miss the point. The original claim sounds indeed questionable, and mentions an obscure study paid for by Apple, likely to be a marketing move to push mouse-based user interfaces. The case studies seem artificial, the counterexamples stupid and very few are actually able to judge the difference from own experience since one usually starts in one of the respective camps and stays there, continually optimizing their interfaces to the input method they prefer. What actually matters is for what kind of input method your user interface is optimized. Since typing-heavy activities like coding tend to favor optimizing for keys, programmer's interfaces accumulate more and more ways of doing as much as possible using keyboard shortcuts. The problem here is that there are very few programmer-centric interfaces that try to do the opposite and optimize for the mouse. The mouse-based interfaces that exist are mostly trying to serve the silly desktop/folder/trashbin metaphor, this terrible and pointless view of a computer that the average graphical user interface has been cursed with since the 80s, starting from harmless and well-meaning beginnings like the Smalltalk environment which later turned into usability horrors like the Windows and Mac OS desktops. Mobile devices gave a fresh impulse but only because of the constraints imposed by handsized bricks of plastic that are either too small for a keyboard or too big to be carried around in your pocket. And it doesn't help that most mice are of utterly bad quality. Interestingly, there is a programmer's environment based on the mouse, namely the rio[6]/acme[7] interface, by Rob Pike, itself influenced by Oberon[8]. Or, to put it differently, it is an environment that allows to be extended and optimized further, by adding functionality that can be accessed with the mouse instead of keyboard shortcuts. This goes surprisingly far, shown by an example from the documentation of Wily[9], which is an acme clone for UNIX: Susan has fetched the file frob.tar.Z. She clicks with B1 in the file name, and with B2 in the word untarz. The utility untarz uncompresses and untars the file, verbosely printing file names as it goes. She clicks with B3 on one of the file names, INSTALL, which opens the file. The INSTALL file suggests that she run configure then make. She clicks B2 in each of these words to run the suggested programs, but there's a problem. The make fails when gcc quits with the error message keyboard.c:4: strings.h: No such file or directory. She clicks with B3 in the first part of the error message, which opens the file and selects the line. On Susan's system there is a string.h but no strings.h. She removes the last s with a B1-B2 chord. When she modifies the file, Wily sets the ``file modified'' indicator, and adds the word ``Save'' to the tag for this window. Susan clicks B2 on the word Save to write the file, clicks B2 on make again, and she's done. This whole process uses about ten mouse clicks and no typing. What is important here to note is that what slows you down is the change from keyboard to mouse and back. The longer you can stay at one of the respective input devices, the more efficient you will be. As coding is only partially the job of a typist, it is also searching, browsing file systems, navigating through a file, copying and pasting of text that occupies our time to a large extent. Moreover, navigating seems to be something that ought to be easier with the mouse than by cognitively planning a course through the 2D-plane of your source code with more or less ingenious keystrokes. This is one of the arguments of the original study that stresses the cognitive load on navigating with keys and remembering keyboard-combinations. I leave it to you to judge this claim, but I do remember that after long exposure to emacs, I was unable to conciously recall many keyboard combinations I used all the time when one of those moments appeared when my hands had actually forgotten the moves that were sort of wired into them. Because, yes, I was a raving emacs user once. Lured by the conceptual simplicity of acme, I gave it a try, forcing myself to use the mouse and forcing myself to look for an improvement in usability, based on unrelated reasons like an aversion to bloat and overcomplexity. I'm using it for a while now, specfically a clone[10] and while I don't consider myself an expert, I nevertheless do not have the impression that it slows me down significantly. But what really decided this for me was the fact that I'm less stressed out: my usual mode of working with emacs was a frantic typing session - I was relatively fast, but paid for this with the preception of constant brain activity, while it feels to me that I'm nowadays calmly clicking through the virtual world of my computer. I may be less inside the "zone", even though I doubt that flow must be based on constant action. To demonstrate that it is possible for a mouse based environment to actually not suck, consider the following examples of effective mouse use: Scrollbars - the standard scrollbar is an epitome of bad user interface design. Scrolling through large bodies of text is a pain. In acme, it's the button that decides where to scroll: B1 (left) scrolls up, B3 (right) down, depending on the position where you click - the further up, the smaller the amount of scrolling, B3 near the bottom of the scrollbar scrolls a full page. Clicking and holding B2 (middle) in the "thumb" does what you expect and moves the visible area. Searching - B3 on a word moves the insertion point to the next occurence of the same word and it warps the mouse to that position, so you can just continue to click B3 to jump from one occurence to the next, wrapping once you reached the end. Selecting ("sweeping") with B3 over text extends the search string to that range. Note that in this and the previous case repetition of the action (continue scolling, search next occurrence) does not involve mouse movement. Cutting and pasting - this is done by mouse-chords: click B1 and hold, while moving to the end of the text to be cut, then click B2, with B1 still held. To paste is the opposite: click B1, hold, then click B3 to paste the text at the position where you clicked B1. It sounds more complicated than it is, and is be influenced by the quality of your mouse and, of course, practice. The acme-style interface tries to minimize retyping by allowing already written out commands and search texts to be executed and searched arbitrary times, provided it is visible somewhere. This trades in the time taken for a (visual) search of the required text for the cost of either typing it again or locating the commands in the input history, if there is one. Add that every piece of text is effectively hyperlinked, following a few rules (that can be extended), you can do a surprising amount of things by mouse clicking and sweeping, depending on context (location in the file system, type of window you are in, etc.) And these rules are more obvious compared to the keystrokes an advanced emacs user has to memorize. So, in conclusion: Apples remain apples, oranges will always be oranges and comparing differently executed variants of two input paradigms doesn't give any objective measure on how efficient they are and alternatives may be buried too deeply in history to be commonly known. You just may have to try it out for an extended period of time to know for sure. https://danluu.com/keyboard-v-mouse/ [1]
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html [2]
https://blog.codinghorror.com/revisiting-keyboard-vs-the-mouse-pt-1/ [3]
https://news.ycombinator.com/item?id=14544571&goto=news [4]
https://lobste.rs/s/jxtser/is_keyboard_faster_than_mouse [5]
Plan 9 rio(1) man page [6]
Plan 9 acme(1) man page [7]
Using Oberon [8]
Wily [9]
MA, an acme clone [10]