20 ms·

Apple R&D (1989): Mousing is faster than keyboarding, but users don't believe it

119 points by lars 15y ago

scrrr 15y ago
I feel very fast (faster than with any normal editor) with MacVim but what if that also is just an illusion?
- sigzero 15y ago
  There is no spoon.
- mhd 15y ago
  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.
gacba 15y ago
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-vs-the-mouse-pt-1.html http://www.codinghorror.com/blog/2008/03/revisiting-keyboard...
- CJefferson 15y ago
  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 15y ago
    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 15y ago
      "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.
      - burgerbrain 15y ago
        V[movement]y
      - seabee 15y ago
        > 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.
    - 15y ago
- dexen 15y ago
  If executing `Print' command is your top priority, you're a Federal Reserve employee, not an enterpreneur/programmer/tech enthusiast.</sarcasm> Thinking, reading & browsing, writting -- those should take the most time in front of the computer, in that order. If you write more than think, you're either Don Knuth (hi there, Professor!) or using some VisualBasic 1.0 Verbose Edition. If you write more than read, you're working on a three-file project that only calls a few stdlib functions. My point? That's not where the money is. What you want is to make software for an pre-existing ecosystem of other software. Re-use code, build upon ready-made libraries and services. You get to think of how to interact with them, you get to browse the docs, jump around code a bit, pinpoint the right place and then type. Just a little, because you're using a high-level language. Thinking? No idea how that interacts with the mouse. Except that being able to hold a snack or mug in the other hand helps sometimes ;-) Browsing? Sure there is Vimperator [1], but most of the time you want mouse to browse docs and code efficiently. You want to use it profficiently, and you want an editor that treats your code (and possibly data, like Adminer [2] does for SQL DBs) as hypertext. Occasional ^F, sure, but that doesn't dominate. You can search with mouse, it's faster. Programming? You work on various chunks of code or data. A block, a line, a word, a tag (if you are an XML person). All that's fast to indicate, search, select, copy, move etc. with mouse and proper editor [3] that doesn't force you to go through menus or toolbars. You want to click on the right FILE:LINE in compiler's error output and see it in editor, not keyboard through the output or manually input FILE:LINE it into editor when it's right there on your screen. Of course keyboarding feels like it's doing that faster, but see the original article about why appearances are misleading here. And yes, I've seen folks still using the old right-click, pop-up-menu, going all the way to `Cut' and then right-click, pop-up-menu, all the way to `Paste'. That's kind of backward and bloody sad, but not by itself a counter-argument against fast work with mouse. ---- [1] http://en.wikipedia.org/wiki/Vimperator http://en.wikipedia.org/wiki/Vimperator [2] http://www.adminer.org/ http://www.adminer.org/ [3] http://en.wikipedia.org/wiki/Acme_(text_editor) http://en.wikipedia.org/wiki/Acme_(text_editor)
bxr 15y ago
>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 15y ago
  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.
- code_duck 15y ago
  Just a note, mussels don't have memories - they're very simple bivalves. I think you mean 'muscle'.
andybak 15y ago
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 15y ago
  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 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.
- eropple 15y ago
  > 2. He allows two-handed using editing Ctrl+X/C/V as a special case but there are other similar situations. Like "all of them." The only command shortcuts I actually use one hand for are Ctrl-(Z|X|C|V), Alt-Tab, and Ctrl-Tab - everything else, I hold Ctrl with one hand and press the key with the other hand. It feels more natural that way.
thiagofm 15y ago
1989 is the correct date.
- lars 15y ago
  Whoops. Fixed it, thanks!
- mhewett 15y ago
  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.
micheljansen 15y ago
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... "
- wunderfool 15y ago
  > "Guideline: The keyboard interface must not dictate the design of the > visual interface" that is only a "guideline" because it follows from their axiom that the UI must be driven by the mouse if you remove that axiom, this no longer makes sense
- lurker19 15y ago
  Translating to modern technology, Nolan would express surprise that his irrational users that preferred web pages that displayed text before downloading media, or displayed above-the-fold content before rendering the rest, or liked being able to see welcome message instead of a full-screen loading animation at game startup, because the less-user-friendly version has the optimal "reality" of taking less time to finish an return to idle. The lessons Nolan got tanalizingly close to discovering were that overall user experience matters more than whatever metric is easiest to measure mechanically, and that sometimes empirical data can disprove a theory. (Ironically, this second lesson was part of the message of Tog's article.).
Shenglong 15y ago
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 15y ago
  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.
- kstenerud 15y ago
  Actually, they did exist back then. All text based, of course, so we tended to use specialized telnet programs that supported macros and scripting.
asciilifeform 15y ago
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/821a0f04bab91864?dmode=source&output=gplain http://groups.google.com/group/comp.emacs/msg/821a0f04bab918...)
- EAMiller 15y ago
  This is a great point - when I was trying to articulate (to myself) why I prefer the keyboard it wasn't necessarily any speed advantage, it was more like the "flow" advantage. Your point speaks to that. I think there's also a big difference in the amount of physical effort needed when using the mouse. With the keyboard it's easier to keep most of my arms relaxed, and when I need to switch to the mouse everything from the shoulder down has to contract into action.
luu 15y ago
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 15y ago
  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.)
  - burgerbrain 15y ago
    But what happens when you throw in full Vi-movement commands?
  - Tiomaidh 15y ago
    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 15y ago
      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.
mirkules 15y ago
(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 15y ago
  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).
  - cturner 15y ago
    Your advice on hiding and switching applies to applications rather than windows. Consider this: you have four terminal windows open. You want to get toggle between two of them. Mac only has rotate (CMD+`), not toggle. There's no equivalent of the alt+tab combination in win32+gnome.
    - 15y ago
wunderfool 15y ago
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
dkastner 15y ago
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.
mechanical_fish 15y ago
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 15y ago
  > 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-8010/index.html http://www.digibarn.com/collections/screenshots/xerox-star-8... 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 15y ago
    I meant the state of the consumer art, of course.
skimbrel 15y ago
(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.
colincsl 15y ago
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 http://www.jitouch.com/index.php?page=jitouch
juiceandjuice 15y ago
"If you are taking your hands off the keyboard, you are wasting time" - One of my Professors
daralthus 15y ago
How about eye-tracking + keyboard?
dexen 15y ago
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 15y ago
  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 15y ago
    /foo<CR> 3yy /bar<CR> p
Someone 15y ago
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.)
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
ryanisinallofus 15y ago
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 15y ago
  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.
- vacri 15y ago
  How is it out of scope? The article isn't presented with such tight restrictions. In response to 1), how seriously do we take opinion that claims "finding a mouse is boring, finding a keystroke is fascinating"? Make no mistake, the main article is an opinion not a study, so you're engaging in double standards to berate others for holding an opinion.
devmach 15y ago
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 15y ago
  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.
StavrosK 15y ago
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.
Maci 15y ago
Part 2: http://www.asktog.com/TOI/toi22KeyboardVMouse2.html http://www.asktog.com/TOI/toi22KeyboardVMouse2.html Part 3: http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.htm...
- jholman 15y ago
  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.
neuroelectronic 15y ago
Apple R&D: finding exactly what they're looking for since 1989
ww520 15y ago
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.
runjake 15y ago
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.
Symmetry 15y ago
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. :)
boulderdash 15y ago
bullshit
wanderful 15y ago
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.
ojosilva 15y ago
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.

119 points by lars 15y ago

scrrr 15y ago

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

sigzero 15y ago
There is no spoon.
mhd 15y ago
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.

gacba 15y ago

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-vs-the-mouse-pt-1.html http://www.codinghorror.com/blog/2008/03/revisiting-keyboard...

CJefferson 15y ago
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 15y ago
  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 15y ago
    "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.
    - burgerbrain 15y ago
      V[movement]y
    - seabee 15y ago
      > 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.
  - 15y ago
dexen 15y ago
If executing `Print' command is your top priority, you're a Federal Reserve employee, not an enterpreneur/programmer/tech enthusiast.</sarcasm> Thinking, reading & browsing, writting -- those should take the most time in front of the computer, in that order. If you write more than think, you're either Don Knuth (hi there, Professor!) or using some VisualBasic 1.0 Verbose Edition. If you write more than read, you're working on a three-file project that only calls a few stdlib functions. My point? That's not where the money is. What you want is to make software for an pre-existing ecosystem of other software. Re-use code, build upon ready-made libraries and services. You get to think of how to interact with them, you get to browse the docs, jump around code a bit, pinpoint the right place and then type. Just a little, because you're using a high-level language. Thinking? No idea how that interacts with the mouse. Except that being able to hold a snack or mug in the other hand helps sometimes ;-) Browsing? Sure there is Vimperator [1], but most of the time you want mouse to browse docs and code efficiently. You want to use it profficiently, and you want an editor that treats your code (and possibly data, like Adminer [2] does for SQL DBs) as hypertext. Occasional ^F, sure, but that doesn't dominate. You can search with mouse, it's faster. Programming? You work on various chunks of code or data. A block, a line, a word, a tag (if you are an XML person). All that's fast to indicate, search, select, copy, move etc. with mouse and proper editor [3] that doesn't force you to go through menus or toolbars. You want to click on the right FILE:LINE in compiler's error output and see it in editor, not keyboard through the output or manually input FILE:LINE it into editor when it's right there on your screen. Of course keyboarding feels like it's doing that faster, but see the original article about why appearances are misleading here. And yes, I've seen folks still using the old right-click, pop-up-menu, going all the way to `Cut' and then right-click, pop-up-menu, all the way to `Paste'. That's kind of backward and bloody sad, but not by itself a counter-argument against fast work with mouse. ---- [1] http://en.wikipedia.org/wiki/Vimperator http://en.wikipedia.org/wiki/Vimperator [2] http://www.adminer.org/ http://www.adminer.org/ [3] http://en.wikipedia.org/wiki/Acme_(text_editor) http://en.wikipedia.org/wiki/Acme_(text_editor)

bxr 15y ago

>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 15y ago
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.
code_duck 15y ago
Just a note, mussels don't have memories - they're very simple bivalves. I think you mean 'muscle'.

andybak 15y ago

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 15y ago
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 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.
eropple 15y ago
> 2. He allows two-handed using editing Ctrl+X/C/V as a special case but there are other similar situations. Like "all of them." The only command shortcuts I actually use one hand for are Ctrl-(Z|X|C|V), Alt-Tab, and Ctrl-Tab - everything else, I hold Ctrl with one hand and press the key with the other hand. It feels more natural that way.

thiagofm 15y ago

1989 is the correct date.

lars 15y ago
Whoops. Fixed it, thanks!
mhewett 15y ago
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.

micheljansen 15y ago

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... "

wunderfool 15y ago
> "Guideline: The keyboard interface must not dictate the design of the > visual interface" that is only a "guideline" because it follows from their axiom that the UI must be driven by the mouse if you remove that axiom, this no longer makes sense
lurker19 15y ago
Translating to modern technology, Nolan would express surprise that his irrational users that preferred web pages that displayed text before downloading media, or displayed above-the-fold content before rendering the rest, or liked being able to see welcome message instead of a full-screen loading animation at game startup, because the less-user-friendly version has the optimal "reality" of taking less time to finish an return to idle. The lessons Nolan got tanalizingly close to discovering were that overall user experience matters more than whatever metric is easiest to measure mechanically, and that sometimes empirical data can disprove a theory. (Ironically, this second lesson was part of the message of Tog's article.).

Shenglong 15y ago

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 15y ago
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.
kstenerud 15y ago
Actually, they did exist back then. All text based, of course, so we tended to use specialized telnet programs that supported macros and scripting.

asciilifeform 15y ago

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/821a0f04bab91864?dmode=source&output=gplain http://groups.google.com/group/comp.emacs/msg/821a0f04bab918...)

EAMiller 15y ago
This is a great point - when I was trying to articulate (to myself) why I prefer the keyboard it wasn't necessarily any speed advantage, it was more like the "flow" advantage. Your point speaks to that. I think there's also a big difference in the amount of physical effort needed when using the mouse. With the keyboard it's easier to keep most of my arms relaxed, and when I need to switch to the mouse everything from the shoulder down has to contract into action.

luu 15y ago

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 15y ago
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.)
- burgerbrain 15y ago
  But what happens when you throw in full Vi-movement commands?
- Tiomaidh 15y ago
  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 15y ago
    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.

mirkules 15y ago

(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 15y ago
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).
- cturner 15y ago
  Your advice on hiding and switching applies to applications rather than windows. Consider this: you have four terminal windows open. You want to get toggle between two of them. Mac only has rotate (CMD+`), not toggle. There's no equivalent of the alt+tab combination in win32+gnome.
  - 15y ago

wunderfool 15y ago

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

dkastner 15y ago

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.

mechanical_fish 15y ago

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 15y ago
> 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-8010/index.html http://www.digibarn.com/collections/screenshots/xerox-star-8... 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 15y ago
  I meant the state of the consumer art, of course.

skimbrel 15y ago

(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.

colincsl 15y ago

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 http://www.jitouch.com/index.php?page=jitouch

juiceandjuice 15y ago

"If you are taking your hands off the keyboard, you are wasting time" - One of my Professors

daralthus 15y ago

How about eye-tracking + keyboard?

dexen 15y ago

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 15y ago
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 15y ago
  /foo<CR> 3yy /bar<CR> p

Someone 15y ago

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.)

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

ryanisinallofus 15y ago

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 15y ago
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.
vacri 15y ago
How is it out of scope? The article isn't presented with such tight restrictions. In response to 1), how seriously do we take opinion that claims "finding a mouse is boring, finding a keystroke is fascinating"? Make no mistake, the main article is an opinion not a study, so you're engaging in double standards to berate others for holding an opinion.

devmach 15y ago

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 15y ago
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.

StavrosK 15y ago

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.

Maci 15y ago

Part 2: http://www.asktog.com/TOI/toi22KeyboardVMouse2.html http://www.asktog.com/TOI/toi22KeyboardVMouse2.html Part 3: http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.htm...

jholman 15y ago
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.

neuroelectronic 15y ago

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

ww520 15y ago

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.

runjake 15y ago

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.

Symmetry 15y ago

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. :)

boulderdash 15y ago

bullshit

wanderful 15y ago

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.

ojosilva 15y ago

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.