
Apple R&D (1989): Mousing is faster than keyboarding, but users don't believe it - lars
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
======
asciilifeform
The mouse, when chosen as the primary user interface (for something other than
a fundamentally-spatial task, like CAD) is a _soul-destroyer._

This is because operating a mouse-based user interface is a _conscious_
process - one which cannot be fully relegated to "muscle memory." Unlike the
keyboard, the mouse scarcely rewards learning at all.

Erik Naggum, in a Usenet post (circa 1997) explains this far better than I
could:

 _"The clumsiness of people who have to engage their brain at every step is
unbearably painful to watch, at least to me, and that's what the novice-
friendly software makes people do, because there's no elegance in them, it's
just a mass of features to be learned by rote... it's sadly obvious that we
are moving into a way of working that is predominantly _conscious_, for which
I believe the human brain was never prepared. we no longer have the time to
let skills sink into the autonomous nervous system, as it were, and even if we
try, the criminal in Redmond, WA, has a new, incompatible version out by the
time we learned the last version... One of the joys of learning to ride a
bicycle is to stop thinking about it -- the feeling that I had successfully
programmed my body to master a bicycle at least thrilled me as a kid (except I
didn't know the verb "to program")... we need to communicate to users that
learning to use Emacs is like learning to ride a bicycle -- it does take some
time and effort, it's a worth-while skill to have, and then you never forget.
I firmly believe that the novice-friendly software is like giving people
several sets of supporting wheels so they won't tilt, but could get moving
right away, and then never taking them off, preferring that they keep using
them and moving so slowly that they always need them. of course, if you argue
that they should remove the supporting wheels to such users, they will,
admittedly correctly, argue that they will fall _splat_ on the ground and ruin
their three-piece suits. clearly a no-go."_

([http://groups.google.com/group/comp.emacs/msg/821a0f04bab918...](http://groups.google.com/group/comp.emacs/msg/821a0f04bab91864?dmode=source&output=gplain))

~~~
roelbondoc
I spend most of my computing hours using the keyboard 99% of the time. I can
completely agree keyboard interfaces are very rewarding.

However, I believe there is "muscle memory" that can be learned using the
mouse. For example, playing a lot of first person shooter games in my day, one
can learn and memorize the nuances of moving the mouse. Correlating the amount
and direction of movement of the mouse with the response of the screen is, I
believe, a skill that can be learned and is quite rewarding.

~~~
rapind
Unrelated, but one of the things with FPS's and such that annoy me the most is
that you are required to use the mouse to achieve top efficiency. It would be
great if someone made a game or extended the options to allow for better
keyboard navigation / aiming. Like key combinations to tweak the interval size
for a directional key (speed). I.e. shift+w, alt+w, ctrl/cmmd + w, maybe vim-
like w20, etc. Also for increasing turn intervals like 45, 90, 180, and custom
degree immediate turns.

~~~
jff
You used to use the keyboard for all actions in FPS's. The first Quake is an
example of this. And it was goddamn terrible, which is why everyone started
playing shooters with mice as soon as possible.

Wasn't it back around that same time period that some people also tried
playing FPS games with a joystick? Probably would have worked ok for Doom, but
I can't see it working as well with anything that allows vertical aiming.

~~~
rapind
The controls from the original Quake is not what I'm suggesting. Controlling
your movement and aim via keybaord right now IS terrible and I'm not disputing
that.

What I'd like to see as an experiment is having a much finer grained control
over your keyboard sensitivity.

As an example, let's say you have _"a"_ mapped as your left turn (not strafe)
key. So pressing and holding _"a"_ gives you the standard movement speed
you've come to expect. Pretty terrible.

Now let's say holding shift and pressing _"a"_ gives you a turn speed that's
twice as fast. Already this is a pretty significant improvement and offers you
some control over you turn speed using only the keyboard.

Now let's add a couple more modifiers; crtl/cmd for 3x speed, alt/opt for 4x
speed. Let's also add some new keys for turn 90 degrees, turn 180 degrees,
turn 270 degrees, and these are all instant, just like a fast mouse turn.

A mouse still allows for much more granular control when it comes to aiming
etc. but for someone who spends to time to really adapt these keys it would
close the gap significantly and may even make keyboard aiming / turning a
viable option.

I could be completely wrong though and it might just feel terrible, but I'd
love to test it out to see.

------
mechanical_fish
The first rule of interface testing: Test the actual interface, on the actual
problem, with the actual userbase.

This classic article is from 1989. You wouldn't believe what a state-of-the-
art interface looked like in 1989. My awesome shiny new Mac SE/30 -- an
excellent machine -- had a 512 by 342 black and white display (and I do mean
_black_ and _white_ , not greyscale) and a 16MHz processor, which was
considered fairly powerful.

My point is: We lived in a totally different universe back then. So, admire
the methodology, but don't waste time debating the relevance of the results.
Do some new measurements on _your_ interface with _your_ tasks. This is
especially important now that touch interfaces have finally escaped from the
lab: We are only starting to develop experience with such things, and
everything is up for debate again.

~~~
asciilifeform
_> You wouldn't believe what a state-of-the-art interface looked like in 1989.
My awesome shiny new Mac SE/30 -- an excellent machine -- had a 512 by 342
black and white display..._

You wouldn't believe what a state-of-the-art interface looked like... in 1981:

[http://www.digibarn.com/collections/screenshots/xerox-
star-8...](http://www.digibarn.com/collections/screenshots/xerox-
star-8010/index.html)

Crappy consumer hardware is never "the state of the art." Even now, when it's
all we've got. The art remains sadly frozen in time.

~~~
mechanical_fish
I meant the state of the _consumer_ art, of course.

------
Shenglong
If MMORPGs existed back then, this would not have been written. I don't know
if anyone here is/used to be a gamer, but ever tried using your mouse to click
skills/gear swaps? It takes forever, and completely distracts you from the
flow of the game.

I used to play RO, and in /bm mode, I had access to 24 hotkeys (qaz rows).
Enough? Hell naw. Even after they gave us access to another 8 keys (total 32),
I still had macros set up for playing. On 31ms average ping to the server, I
could dodge .3s casts - absolutely impossible by clicking.

While the mouse is more intuitive in the beginning, for anyone who actually
uses their computer a lot, the keyboard becomes increasingly faster. Having to
find the developer tab on excel and then hit export, save, and yes is much
slower than Alt->L->E->Enter->Left->Enter for example. The idea of hotkeys, is
just like ctrl+z, ctrl+c, and ctrl+v, they become intuitive.

A funny anecdote: I used to use ctrl+z (undo) hundreds of time a day when I
was designing Worms Armageddon maps in paint. There came a time, where when I
made a mistake in class on paper, my left hand would automatically go into the
ctrl+z position, and move down even when there was no keyboard.

~~~
KirinDave
I don't think that anyone argues that mousing to small, arbitrary targets is
more reliable or faster than keyboarding. Menus are a special case in this
study because they abut the top of the screen (at least, if your OS's UX is
reasonable), so you only have to care about x-axis accuracy.

Try mousing to the reply button on a HN page vs mousing to the Edit menu, it's
easy to see why one might be faster even if your pointer is closer to the
reply target.

------
ryanisinallofus
Every other year when this article hits the latest aggregator the same
conversation erupts.

People need to remember:

1.) This was the result of an actual user interface study. Responding with
anecdotal evidence makes you seem less than intelligent.

2.) This only applies to the specific type of software studied (perhaps even
within the time frame) and should not be taken out of context. Bringing up
Emacs or Vi is completely out of scope with the discussion and if I had the
power to; I'd down vote each comment that does.

~~~
robbles
Their whole argument seems to be about the use of simple hotkeys (cmd-p) vs
menu items (File->Print).

Text editors are a completely different application of the same input devices.
I also think that studying the efficiency and speed of typing complex text is
much harder than measuring the speed at which a user can activate a simple
command.

------
luu
I'd like to see a breakdown of exactly what's faster and what isn't.
Obviously, typing text by clicking on an onscreen qwerty keyboard (or better
yet, a menu) would not be faster than typing via a regular keyboard, so the
mouse isn't _always_ faster than the keyboard. Is typing text some magical
special case where the mouse becomes much slower? I find that hard to believe.

Tog's article makes it sound like mousing is always faster, but that's clearly
and incontrovertibly wrong. I know nuance doesn't make for an eye-catching
headline, but it would be nice to see somewhere in the essay.

~~~
chc
Using arrow keys to manipulate a virtual mouse to move an arrow cursor across
the screen is even more hopeless than typing with a mouse on a virtual
keyboard. Any device emulating another will probably not show its best face.

(Edited for clarity since people seemed to misunderstand my meaning.)

~~~
Tiomaidh
But using `(` in vim to move the cursor backwards by a sentence is probably
better than using a mouse--which involves locating the previous sentence,
locating the mouse, locating the mouse cursor, moving it to the spot, and
clicking.

~~~
jff
You're manipulating words to make the mouse operation sound more arduous than
it is. Similarly, I could say "when using the keyboard, you have to recognize
that you wish to move the cursor backwards by what vi arbitrarily calls a
sentence, then remember what the command you want is, then hold down the shift
key, then hit the '9' key, then locate where the cursor has jumped to".

The user knows where the mouse is, and as soon has he grabs the mouse and
starts to move it, the location of the cursor becomes evident. Moving to the
spot and clicking is then an exercise in the kind of hand-eye coordination
most people master by the age of 3.

~~~
javert
I really disagree. Getting around in text with a mouse is unbelievably tedious
once you learn the shortcuts in Vim.

~~~
jff
Getting around in text with a mouse _in Vim_ is probably unbelievably tedious,
because you're using an editor designed in the 70s to be used with the ADM-3
terminal, from which a mouse was definitely absent (I have one in the closet,
it's nice but doesn't even have a microprocessor, just TTL :)

~~~
javert
Right, that's why I use Vim.

I mean, sure, in Word, I can hit the "Home" key, if I want to make things
harder for myself than Vim but easier than mousing around. But that's about
all.

------
micheljansen
Regardless of the original claims on keyboard versus mouse (there is more
recent work on that subject), there are some really nice gems in the article
and comments, that are still relevant for current interfaces:

" Guideline: The keyboard interface must not dictate the design of the visual
interface.

Guideline: The work to design and build the keyboard interface should not sap
resources that are needed for the creation of the visual interface. "

Nolan Larsen from WordPerfect Corp. puts it nicely:

" ... When scrolling the text horizontally in a window we would refresh the
text by redisplaying each line starting at the top. This resulted in a wave of
text rippling down the screen, and many complaints that the screen refresh was
too slow. The remedy was to scroll the bits already on screen and then
redisplay each line from the top. The second implementation was actually
slower than the first because we incurred the overhead of scrolling the bits
before we even started to display the new text on the screen. However, the
perception was that there was an immense increase in speed. We stuck with the
second implementation because it increased the overall satisfaction of the
user even though it actually decreased the throughput of the product.

In my mind, perception is stronger than reality. A user’s perception of a
product is what causes him to purchase it and influences his satisfaction with
the product... "

~~~
joe_the_user
_The keyboard interface must not dictate the design of the visual interface._

I'm writing this on a borrowed Mac and hating the damn thing (damn mouse-base
dreck seriously slows me down).

I would say that because of its keyboard use, the Windows interface is far
more effective than the Macintosh interface but that the Mac interface is
designed to _seem_ usable. I would suppose something that _seems_ great is
exactly what companies should sell for their own benefit. I'm happy that Mac
is not yet universal...

~~~
StavrosK
You're conflating speed with usability. I'm insanely fast on Windows, to the
point where coworkers would make a sort of spectacle out of how fast I can
open windows and explore the filesystem and such, but it's just because I know
the shortcuts while they fumbled with a mouse.

Windows' keyboard accessibility combined with its responsiveness blows all
other OSes out of the water, Gnome is accessible but less responsive, OS X is
not accessible but responsive.

OS X is not keyboard-accessible at all, but it's more usable for novice users,
as it doesn't confuse them with many options, the UI is cleaner, everything is
laid out better, etc. I don't think anyone claims that using OS X is _faster_
per se...

~~~
mitchty
OSX is not keyboard accessible by default, its is not however "not keyboard-
accessible". Go into system preferences and turn on keyboard navigation and
adjust the keymaps to your hearts content. Heck add scripts to execute on
certain key combinations if you want. And if you like you can remap what its
defaults are to whatever you like.

OSX is setup to be transparent to novice users. That doesn't mean it cannot be
setup to be used with a keyboard. Just that the default, which for 99% of
users doesn't allow they keyboard to interfere with a novice user.

I can get OSX to do quite literally everything from the keyboard, I'm not sure
how one can argue it isn't keyboard accessible when it is trivial to turn on.
And being the 1% of the population that cares about it, power users shouldn't
be afraid of learning how to turn it on.

Hopefully this didn't come across as harsh, but I just get annoyed at people
that equate OSX = mouse only interface. When you can tell the whole idea
behind the interface is to make default things simple to use with a single
mouse button and make the rest possible. Despite what we think the actual idea
of more than one mouse button is about as foreign as trying to understand
Russian to an Englishman. Its more cognitive load than most care about.

~~~
mdaniel

      > I can get OSX to do quite literally everything from the keyboard,
    

I call foul on that one.

Perhaps if you said "I can get OSX to _eventually_ do everything from the
keyboard". I say that because of the 9 menu items showing for Chrome right now
(if one includes the Apple), I can get to exactly one of them using Ctrl-F2.
If I wanted to jump to the History menu, it is Ctrl-F2 followed by five right-
arrow presses. If I were on Windows, I bet a Euro it would be alt-H or some
such.

I just get annoyed at people who think that an _option_ to turn on tabbing
onto controls and to hotkey onto the Apple menu (or the dock) somehow equates
with the incredible keyboard-friendliness of some other OSes.

~~~
pdhborges
type Ctrl-F2 and then "hi". Problem solved.

~~~
StavrosK
Three keystrokes, the first of which is awkward and the rest of which are
menu-dependent. In other OSes it's just alt+accelerator, for anything you
want.

------
dexen
Reading comprehension, folks, seriously -_-' All your arguments is either `but
keyboard feels faster', or `there are some actions slow to do with mouse'. The
former is addressed in the article:

 _> While the keyboard users in this case feels as though they have gained two
seconds over the mouse users, the opposite is really the case. Because while
the keyboard users have been engaged in a process so fascinating that they
have experienced amnesia, the mouse users have been so disengaged that they
have been able to continue thinking about the task they are trying to
accomplish._

It's there, plain and simple: keyboarding around switches off (or busy-waits)
a part of our brain, while providing nice tactile and quantized visual (every
character stop) stimuli in regular interval. It _feels_ faster, because that's
how our brain is wired to measure time.

On the other hand, mousing around doesn't provide any cool stimuli until you
actually activate the target widget. It feels long-ish, because the brain has
to constantly work on adjusting cursor trajectory and nothing serious happens
till you actually activate the widget.

The later argument is the case of rarely used commands. _Of course_ ^S or ^P
is faster than hunting the `Save...' or `Print...' through _modern_ long
menus, but that's an exception; an action to be taken once every few minutes.
Manipulating text tokens and blocks (that's what we do most often, right?) is
inherently faster with mouse than with Vim-ish or EMACS-ish regexps. Same for
browsing hyper-text documentation or 'net forums.

Tell me you can select and move around a word, line or block of code faster
with regexps than with mouse, and I'll gladly do it faster with mouse. On the
average, anyway, which is what matters in the longer run.

~~~
jff
Addendum: When you watch somebody working with Vim, and he looks _so fast_...
consider that it's probably you hearing and seeing the massive stream of
^D^D^Djjjjjj3yykkkkkkkkp he has to type to find a chunk of text, yank it, and
move it a few lines up. And that was me being generous, assuming he needs to
cut 3 entire lines, not parts of a line. Working with the mouse looks slow
because it's just a few clicks and maybe a keystroke or two.

~~~
BasDirks
/foo<CR>

3yy

/bar<CR>

p

~~~
Someone
…with thinking pauses a) figuring out what to search for: /fo or /foo or even
/foo\\. and b) for checking that your idea about the search term was correct.
Repeat for the search for 'bar'

I am not claiming that this isn't faster for you or in general, but Tog
has/had data to defend his claims, and data that that introspection can be
unreliable in judging task duration. All you (and I) give are anecdotes.

~~~
BasDirks
no for the thinking pauses: _thinking in code_ is an advantage.

------
gacba
There's a nice post by Jeff Atwood from 2008 that says this is crap for modern
systems, but he does a nice job of putting it in historical context. There's
just no way going to the File menu, scrolling down to Print and then clicking
is faster than "Ctrl-P" (or Cmd-P) with your left hand.

Link: [http://www.codinghorror.com/blog/2008/03/revisiting-
keyboard...](http://www.codinghorror.com/blog/2008/03/revisiting-keyboard-vs-
the-mouse-pt-1.html)

~~~
CJefferson
Possibly for print, but then again I don't press print very often.

For scrolling down a couple of pages, copying 3 lines of code, moving back up,
pasting, and then changing a couple of characters, I actually believe I am
faster with a mouse than keyboard, after quite a bit of trying to master vim.

~~~
seabee
m'

"For scrolling down a couple of pages,"

CTRL-B and j several times (vs. scrollbar/scroll wheel)

"copying 3 lines of code,"

3yy (vs. select block, right-click -> 'Copy')

"moving back up,"

'' (vs. scrolling)

"pasting,"

p (vs. right-click > 'Paste')

"and then changing a couple of characters,"

(depends on the text)

"I actually believe I am faster with a mouse than keyboard, after quite a bit
of trying to master vim."

I would humbly suggest the sum of the parts is greater than the whole,
especially the use of marks and (unmentioned here) macros or the '.' repeat
command.

~~~
frelpen
"3yy (vs. select block, right-click -> 'Copy')"

Yeah, but then you're stuck counting lines. Whereas with a mouse, you just
click and drag exactly what you want.

"p (vs. right-click > 'Paste')"

This is more difficult if you've copied whole lines but want to paste inside a
line or replace text with your paste.

I love me some vim, but I do think it's easy to think we're faster than we
are. I wonder if I recorded myself and then watched it if I'd think I was as
fast as I feel that I am.

~~~
seabee
> _Yeah, but then you're stuck counting lines._

:set relativenumber

> _This is more difficult if you've copied whole lines but want to paste
> inside a line_

I agree, but the case where I want to copy multiple lines and have the first
line start in the middle of a line is very rare in the languages I use.

> _or replace text with your paste_

That's what Visual mode is for. Personally, I find pressing Shift-V then j a
few times is usually easier for line selection than acquiring the left line-
selection margin or finding the end of the text.

In these cases I wouldn't say it's faster as much as I would consistent and
easier. I do find myself having to clean up slight mistakes more often with
mousing than I do vim commands.

------
runjake
This is true, because they were testing in a mouse-based interface. Of course
mousing would be faster.

Now take an app that is keyboard-centric like Notational Velocity (or
gvim/macvim). All of a sudden keyboarding is more efficient.

Now, compare the speed and efficiency between the two paradigms. No surprise
who wins there.

Use the paradigm that fits the application. Use the applications that fit your
style. Nothing new here.

------
colincsl
Many of you have claimed that a keyboard is faster/'superior' but it really
depends on your form of mouse and the application at hand. I recently got a
new Macbook and have happily replaced some of my previous keyboard shortcuts
with multitouch gestures. With the aid of Jitouch and hotkeys I can easily
navigate web history (and go back and forth in folders and other programs),
switch spaces, maximize/minimize windows, show all applications, hide all
applications, show all spaces+applications, snap windows to the left or right
half of the screen, zoom in on pictures or web pages, and other less-used
actions.

I am not trying to say that multitouch+jitouch+hotcorners is the best solution
for all interactions. Surely for activities like coding it's probably not. But
over the past few weeks I've grown to prefer it for web browsing and general
navigating the OS.

<http://www.jitouch.com/index.php?page=jitouch>

------
andybak
This argument is flawed in several ways: 1\. Repetitive tasks get
progressively faster with the keyboard as the motion gets smoother as your
practise it. 2\. He allows two-handed using editing Ctrl+X/C/V as a special
case but there are other similar situations.

I'd like to see the exact methodology. 2 seconds to decide which key press to
use sounds fishy to me.

~~~
raganwald
Isn't your first point also true of mouse movements under certain
circumstances? I am specifically thinking of the Apple style of fixing the
menu at the top of the screen given the display resolutions at the time, and
of "pie menus" on today's hardware:

<http://en.wikipedia.org/wiki/Pie_menu>

A friend works on high-end image editing software (Maya). Their research is
that pie menus are faster than keyboard commands and both Apple and Windows
style menus because the user is learning write flicking gestures and their
hand is already on the mouse for drawing activities.

------
dkastner
I think context matters here. The article was discussing GUi word processor
usage.

When using an app like Pages or Word, the mouse will be faster because
keyboard navigation in those apps is terrible. You may be able to save some
mousing with command-p, but for general editing tasks like highlighting and
moving text, the mouse will always beat the keyboard.

In vim, however, editing via keyboard is well designed and always faster than
mousing.

The true test would be to compare editing LaTex with vim versus a rich text
document with TextEdit.

------
devmach
Ok, so what ? You can write faster with keyboard or move faster with mouse,
but do you really need to be so fast ?

I'm really curious ( and not trolling ) : Don't you guys need to think
"before" and "while" coding ? Or you just type as faster as you can ? I need
to design and "try" code on my mind and then write it, i can make some last
moment corrections while writing. Most of time, my code works as i designed
and i'm spending much of my time with designing not writing. So what's the
matter ?

~~~
glhaynes
Agree 100%. I've never gotten _really_ proficient at any single text editor,
but I've also never really felt like typing/editing was a significant part of
the time I spend programming. Hearing other people talk about their amazing
productivity gains from time to time makes me think I should master a
particular text editor, but I don't expect I ever will because it just doesn't
seem like a limiting factor to me. Could be wrong.

------
mirkules
(Warning: I am very opinionated on this matter)

I made a switch from PC to Apple 4 years ago. The lack of meaningful keyboard
shortcuts drives me mad. Consider a simple task of switching applications with
the Cmd-Tab key: Minimize the only window of your application. Switch to
another program, then cmd-tab back to your original program. Where did the
window go? Oh, it's still sitting in the dock. So, grab the mouse, go get your
window - and if you have 3 monitors (like I do), your mouse can be in a
different zip code and it takes a long time just to find the cursor.

In fact, I think if we did this study today, we would find that due to bigger
screen sizes, it's harder to spot the cursor, which would probably increase
"mousing" time. However, Apple has 6 modifier keys on a laptop: Shift, Fn,
Control, alt, option, and cmd, so trying to remember these keys can be a
challenge too (and drives me crazy as well). What is the full screenshot
shortcut? Control-Cmd-Shift-3 (aka finger-gymnastics)

~~~
super_mario
There's your problem right there. Don't minimize windows in OS X just because
that's what you are used to from decades of training on Windows. Hide the
window instead (CMD+h). This way when you get back to it with CMD+Tab it
magically appears again.

On the original topic. The whole idea makes me laugh. There is no way anyone
driving with a mouse is going to be faster than I am with a keyboard.
Navigating the filesystem, manipulating the filesystem, editing text esp. is
laughable (I love VIM and nothing can come close to the speed I can edit in
VIM, esp. not anything you have to drive with a mouse). Very few applications
are better done with a mouse/pad (like Photo editing in Photoshop, but even
there various keyboard shortcuts are faster than navigating submenus).

~~~
misuse-permit
> I love VIM and nothing can come close to the speed I can edit in VIM, esp.
> not anything you have to drive with a mouse

A contrived example, but I'd like to see someone edit a Java project faster in
VIM than I do in Eclipse.

Look, I know how to use VIM better than the next guy (you'll just have to
trust me on this), but when it comes to writing code for large projects I
can't stand using VIM. It makes me feel like I'm looking through this tiny
window to my code. Give me a mouse and a powerful IDE, and it's like I
suddenly have a 10,000ft view of the world.

~~~
super_mario
I prefer Eclipse with VI plugin. You get the best of both worlds. And if I'm
not happy with the vi plugin implementation, I can always continue editing in
actual VIM by typing :vi in Eclipse.

All, that being said, I have heavily customized VIM with ctags, cscope,
Command+T plugin and taglist.

Command+T alone is really worth it, you can open any file in the entire
project structure by just typing a few letters (just like Eclipse's
CTRL+SHIFT+t, but works on any file type).

With all these I can navigate code, and edit pretty much like I am in Eclipse,
but unlike Eclipse this combo works for C,C++, Ruby, Python, Perl, Javascript
etc. as well.

~~~
axylone
Ctrl+Shift+R opens files in eclipse.

------
Symmetry
I think a lot of the difference ends up being more a matter of expressiveness
than speed of simple operations. I'm pretty good in vim, but if I wanted to
highlight some arbitrary region of text I'm pretty sure I'd be faster at using
the mouse than I would with normal vim navigation.

However, I almost never want to highlight an arbitrary region, but instead a
sentence, a paragraph, a line, the text in some quotes, the text until the
next semi-colon, or something similar. And vi gives me easily expressed
intrinsics to do all of those very quickly.

On the other hand, I can use a mouse just fine with a soda or cup of tea in my
other hand, something I can't do with a keyboard. :)

------
wanderful
Many people here are creating a false dilemma out of mousing and keyboarding.
The argument isn't even necessarily about mousing vs. keyboarding, it could be
about GUI vs. command line/hotkey. GUIs provide a discoverable profile of all
actions (with the most common tasks optimized visually, hopefully). Hotkeys
package the common actions to save time.

In any interface, there is a learning curve. Some users never progress beyond
the most basic stages, and each time they interact with the software it's as
if they are starting over. Other users develop further along the learning
curve to the point that using a hotkey becomes cheaper. Many users bring
overlap from other interfaces (which is what makes an interface intuitive — it
fits the user's expectations). As more hotkeys are defined they will be for
less and less common actions, which fewer users will learn, remember, and use.
People will also move up and down the curve depending on their frequency of
use with the software.

A useful product should have both. The more complex a product gets, the more
the user skill stratifies (from newbs to pros), the more necessary both a GUI
and hotkey interface is. The GUI provides a scheme for organizing the myriad
features and functions as a fallback interaction layer, while hotkeys allow
the user to leap ahead.

HN users are overwhelmingly savvy, which is shown by the support of keyboard
interactions.

------
Someone
I am not saying that the title given here is true (certainly not in general,
with arbitrary small targets at arbitrary large distances. There also is quite
a bit of follow-up research on this), but I do find it sort-of
funny/interesting/sad (frankly, I do not know what to call this) to see many
reactions "I do not believe it" without evidence, while one of the claims of
this paper is that users do not believe the first result.

Oh, and IIRC, the original research was on a dual-monitor setup, moving the
pointer over two screens. And yet, Tog _measured_ that the mouse was faster. I
do assume he had a Macintosh mouse on a Mac, though. Compared to PC mice of
the era, those were good (especially software-wise. There were PC mice were it
was (as good as?) impossible to move the mouse by a single pixel.)

------
ojosilva
I've been a Vim user for 4 years now. I enjoy Vim and I'm definitely more
productive using all those household keystroke shortcuts without having to
move my fingers too much around. Really, everyone should try Vim once in their
lives.

But there's something weird that happens to me whenever I adventure myself
into a longer or smarter key combination that does a lot for little (ie. a
macro). My mind will actually figure out the correct sequence quickly (< 1s)
and fire it up... but then, after accomplishing my goal, I freeze during ~5s
with a strange, contemplative doze in my face. That's when all the
productivity it gave me goes down the drain.

So maybe too much keyboard shortcutting ends up overloading the brain at some
point or another, in an effort to learn, rinse, repeat or out of sheer
ecstasy.

------
Maci
Part 2: <http://www.asktog.com/TOI/toi22KeyboardVMouse2.html>

Part 3:
[http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.htm...](http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html)

~~~
jholman
Oh, this is awesome. Read Part 3.

It's not entirely clear if the test he relates (as "the test I did several
years ago") in Part 3 is the same test he is referencing in Part 1. Part 1
does mention $50M worth of testing, after all.

But the test in Part 3 is to replace all instances of '|' with instances of
'e', in a chunk of English text. Keyboard users take 99 seconds, mouse users
take 50 seconds.

He also implies that his experiment does not involve a cursor scheme that
allows word-wise or sentence-wise movement (something present in friggin'
Notepad, much less a real editor).

I'm not even gonna _start_ singing vim's praises at this point, because aside
from preaching to the choir, it's like shooting fish in a barrel.

------
StavrosK
I think this study is too old to be applicable. I'm sure "ctrl+w, ctrl+t,
ctrl+l" is much faster than "click the little X on the tab, click new tab,
click on the address bar".

I won't even try to compare vim/emacs to Word.

------
ww520
I have two words why i prefer keyboard over mouse: carpal tunnel. My wrist
tightens up quickly when using mouse excessively. Typing is so much more
relaxing.

------
skimbrel
_(USS Saratoga was our code name during development of the extended keyboard
because of its eerie resemblance to the popular aircraft carrier. Not so much
the shape as the size.)_

Nice bit of trivia there. I remember the Apple Extended Keyboard being big,
but not that big. IBM Model Ms are pretty much the biggest keyboard I can
think of.

------
scrrr
I feel very fast (faster than with any normal editor) with MacVim but what if
that also is just an illusion?

~~~
mhd
The equivalence of actions isn't the same, so this wreaks a bit havoc on the
argument. Yes, if you e.g. select text in visual mode and the "cursor" keys,
then you'd probably be faster switching to the mouse. If you use the semantic
movement commands, things are a bit different. Never mind keyboard macros...

It's pretty hard to generalize activity, and you really have to take notice of
the tasks and user groups selected for comparisons like this.

------
juiceandjuice
"If you are taking your hands off the keyboard, you are wasting time"

\- One of my Professors

------
daralthus
How about eye-tracking + keyboard?

------
thiagofm
1989 is the correct date.

~~~
mhewett
It makes me feel old that I remember reading the original article when it
first came out. When the first Mac came out in 1984, my roommate (an aerospace
engineering student) was down on it until he came rushing home one day and
excitedly informed me that, "I found out that I don't HAVE to use the mouse!
They have keyboard equivalents for everything!" He ended up buying the Mac,
but then went to work at IBM and was lost to the dark side.

------
boulderdash
bullshit

------
bxr
>It takes two seconds to decide upon which special-function key to press.
Deciding among abstract symbols is a high-level cognitive function. Not only
is this decision not boring, the user actually experiences amnesia! Real
amnesia! The time-slice spent making the decision simply ceases to exist.

I wonder if mussel memory ever catches up to make the time benefit break the
other way. I want something closed, hitting f3 is the same as typing any other
letter. I had to look down to see what F-button it actually is.

~~~
eropple
I think their claim is trivially disproven just by watching someone who's been
using computers long enough. I don't think about the overwhelming majority of
special-key presses, I just do them. Same with vim wizards and their tool of
choice.

But, then, this was written in Ye Olde Days, where people hadn't really grown
up with computers and may not have had that instinctual comfort with keyboard
commands.

------
neuroelectronic
Apple R&D: finding exactly what they're looking for since 1989

------
wunderfool
yes, the mouse may indeed be faster in a mouse-centric UI like that of osx/os9

but i use xmonad and/or dwm. i can tell you that keyboards are faster in
interfaces designed for keyboards

