Introduction
Introduction Statistics Contact Development Disclaimer Help
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]
You are viewing proxied material from schinkel.bevuta.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.