Is the keyboard faster than the mouse?(danluu.com)
danluu.com
Is the keyboard faster than the mouse?
https://danluu.com/keyboard-v-mouse/
143 comments
As a heavy keyboard user I have to agree. I've been using vim extensively and also use vim bindings for my browsers, without them navigation feels constrained. Obviously I still use the mouse for some tasks and certain types of text selection are much easier with a mouse then a keyboard for me.
I'd say that is heavily dependent on personal workflow and taskset.
I'd say that is heavily dependent on personal workflow and taskset.
> Obviously I still use the mouse for some tasks and certain types of text selection are much easier with a mouse then a keyboard for me.
Like Starcraft, the best thing the mouse is for is box selection. Everything else is done with keys.
Like Starcraft, the best thing the mouse is for is box selection. Everything else is done with keys.
And for actually pointing at things.
My brain doesn't "point" at something in Vi motions, not matter how much I try. Maybe some people manage to rewire their brains, I haven't. Despite using Vi/Vim for a long time.
My brain doesn't "point" at something in Vi motions, not matter how much I try. Maybe some people manage to rewire their brains, I haven't. Despite using Vi/Vim for a long time.
> My brain doesn't "point" at something in Vi motions...
In emacs there's a mode called ace jumping. Essentially, it lets you pinpoint exactly on screen where you want to move the cursor ~3 keypresses.
Similar to how the vimium extension to Chrome let's you jump to any link/button/control with two keypresses.
These aren't motion commands as you'd typically get in vim/emacs; instead it's a different interface to allow directly jumping to an arbitrary position (more of a warp than a movement).
http://emacsrocks.com/e10.html
Anyways, the point I wanted to make is that even some instances where the mouse is considered superior can be negated by a different UX.
So consider the idea that FPS games are more effective with a mouse. I believe this is a UX choice to reward developing mouse skills, not a fundamental limitation of the keyboard. As such, consider the following levels of keyboard FPS controls--
Option 1: Aim by directional arrows. Will be beat out by a mouse user for sure.
Option 2: Aim by movement commands (e.g. B skips and tracks the target on the left, F skips and tracks the target on the right, etc). Might be on par? Definitely has a different learning curve than using a mouse.
Option 3: Aim by label. Every target has a letter hovering over its head, and pressing the key will aim & track at that target. I suspect this would be much more _efficient_ control scheme than using a mouse.
Option 1, is akin to navigating text with arrows, Option 2 is akin to navigating with jump commands, and Option 3 is akin to navigating with an ace-jump type interface.
So although #3 would be considered unfair in a typical FPS context, as a programmer I just want to reduce effort as much as possible.
In emacs there's a mode called ace jumping. Essentially, it lets you pinpoint exactly on screen where you want to move the cursor ~3 keypresses.
Similar to how the vimium extension to Chrome let's you jump to any link/button/control with two keypresses.
These aren't motion commands as you'd typically get in vim/emacs; instead it's a different interface to allow directly jumping to an arbitrary position (more of a warp than a movement).
http://emacsrocks.com/e10.html
Anyways, the point I wanted to make is that even some instances where the mouse is considered superior can be negated by a different UX.
So consider the idea that FPS games are more effective with a mouse. I believe this is a UX choice to reward developing mouse skills, not a fundamental limitation of the keyboard. As such, consider the following levels of keyboard FPS controls--
Option 1: Aim by directional arrows. Will be beat out by a mouse user for sure.
Option 2: Aim by movement commands (e.g. B skips and tracks the target on the left, F skips and tracks the target on the right, etc). Might be on par? Definitely has a different learning curve than using a mouse.
Option 3: Aim by label. Every target has a letter hovering over its head, and pressing the key will aim & track at that target. I suspect this would be much more _efficient_ control scheme than using a mouse.
Option 1, is akin to navigating text with arrows, Option 2 is akin to navigating with jump commands, and Option 3 is akin to navigating with an ace-jump type interface.
So although #3 would be considered unfair in a typical FPS context, as a programmer I just want to reduce effort as much as possible.
#3 is basically how Typing of the Dead works, and when you reach high WPM it is indeed faster than using a mouse.
AHH TYPING OF THE DEAD! Best typing game ever (helps that it's just a rework of an actual rail gun shooter). From a gameplay simulation perspective though, mouse is the only method that I feel provides any relatable idea of aiming. Just being able to directly jump between targets would definitely be "more efficient", but so is an aimbot, both sort of defeat the general gameplay design.
> Just being able to directly jump between targets would definitely be "more efficient", but so is an aimbot, both sort of defeat the general gameplay design.
Of course - in the context of an FPS, where the basic expectation is for it to be "skill-based".
But this makes the notion a truly great metaphor, IMHO: The goal behind a text editor is for the user to get stuff done. "Fairness" is not a constraint; everything is allowed.
I'd even go to say that if you've developed some AI that allows me to quickly do what I want without getting in my way, I'm in! I don't think this will be the case any soon (at least in a usable manner), but having it would certainly be great.
In fact, I already pondered if it might be doable to use the new, cheap eye tracking hardware one can buy nowadays (e.g. Tobii devices) to develop something like Ace jumping with...
Of course - in the context of an FPS, where the basic expectation is for it to be "skill-based".
But this makes the notion a truly great metaphor, IMHO: The goal behind a text editor is for the user to get stuff done. "Fairness" is not a constraint; everything is allowed.
I'd even go to say that if you've developed some AI that allows me to quickly do what I want without getting in my way, I'm in! I don't think this will be the case any soon (at least in a usable manner), but having it would certainly be great.
In fact, I already pondered if it might be doable to use the new, cheap eye tracking hardware one can buy nowadays (e.g. Tobii devices) to develop something like Ace jumping with...
For vim there are plugins like EasyMotion[1], and for emacs there's Ace Jump Mode[2], which let you precisely get to any character on the screen with a couple of keystrokes. These plugins really revolutionized my vim and emacs usage.
Then there's also the ability of vim and emacs to quickly and precisely select text objects like words, paragraphs, functions, etc (even when they may span more than one screen). There's just no way a mouse can be anywhere near as fast as doing that for larger objects, and using the mouse is much more error-prone.
[1] - https://github.com/easymotion/vim-easymotion
[2] - https://github.com/winterTTr/ace-jump-mode
Then there's also the ability of vim and emacs to quickly and precisely select text objects like words, paragraphs, functions, etc (even when they may span more than one screen). There's just no way a mouse can be anywhere near as fast as doing that for larger objects, and using the mouse is much more error-prone.
[1] - https://github.com/easymotion/vim-easymotion
[2] - https://github.com/winterTTr/ace-jump-mode
For Intellij there's also AceJump, but I haven't tried it yet:
https://github.com/johnlindquist/AceJump
Speaking from the Emacs side of fence, my brain doesn't "point" in Emacs shortcuts either, but it sure does intuitively translate "I want to be there" / "I want to change that" to a series of keyboard presses, usually much faster than I could ever achieve with moving a mouse and clicking.
Generally I'm inclined to agree. However with textual hints pointing with vi-motions are a breeze.
In addition my joints click when I reach for the mouse putting an actually physical barrier between keyboard and mouse movements for me personally, hence I tend not to move between the two a lot. Laptop touchpads doesn't induce this strain so those are easier.
In addition my joints click when I reach for the mouse putting an actually physical barrier between keyboard and mouse movements for me personally, hence I tend not to move between the two a lot. Laptop touchpads doesn't induce this strain so those are easier.
For me it's not the mouse itself as much as it is moving my hands back and forth from the keyboard to the mouse. I've had RSI symptoms from that. Now I use a ThinkPad keyboard with a trackpoint and no separate mouse.
what browser do you use for vim bindings?
qutebrowser as default for opening links, then I run Chrome(ium) with Vimium and Safari with vimari and blank command prefix. I've previously also used Pentadactyl (think there's one named Vimperator as well) for Firefox. Once you're used to it you'll never want to go back.
Update with links:
https://www.qutebrowser.org/
https://vimium.github.io/
https://github.com/guyht/vimari
https://addons.mozilla.org/sv-SE/firefox/addon/pentadactyl/?...
https://addons.mozilla.org/sv-SE/firefox/addon/vimperator/
Update with links:
https://www.qutebrowser.org/
https://vimium.github.io/
https://github.com/guyht/vimari
https://addons.mozilla.org/sv-SE/firefox/addon/pentadactyl/?...
https://addons.mozilla.org/sv-SE/firefox/addon/vimperator/
Pentadactyl/Vimperator will soon stop working, I believe at FireFox 57. Firefox is removing the ability to run XUL extensions, which will effectively be the end of the awesome VIM plugins for FF :(
I've recently made the switch to VimFX as a result of this and I have to say I couldn't be happier - it may not have some of the more powerful features (that I'm unaware of) but it definitely gets the job done.
I also switched to VimFX from Vimperator, and it blew my mind how much faster Firefox suddenly became! I used to simpathixe with my friend who switched back to Chrome "for it's speed" but without Vimperator, Firefox is waaaaay snappier than Chrome (on my machine). It made browsing a fun tactile experience again!
Is VimFX going to continue to work when Pentadactyl breaks?
Only if it gets turned into a WebExtension:
https://github.com/akhodakivskiy/VimFx/issues/860
Mice for MOBAs and such have up to tweleve extra hotkeys...
Now you jogged my memory...
https://www.wired.com/2009/11/18-button-open-office-mouse-ma...
Also, didn't early mouse experiments involve rodents with many more buttons than the 2-3 that's common today?
https://www.wired.com/2009/11/18-button-open-office-mouse-ma...
Also, didn't early mouse experiments involve rodents with many more buttons than the 2-3 that's common today?
Yes, but you only have one thumb covering all those hotkeys. Pressing them in rapid succession will be much easier in parallel on a keyboard, simply because your four fingers aren't occupied on aiming the mouse and clicking the main two buttons.
The one Razer product I own is the Naga Hex, because having the keys 1-6 at thumb reach on the mouse is wildly helpful for RPG hotbars. Not that I think I'm that much faster a player, merely that my WARS movement hand gets a little less to do.
Reminds me that i loved playing the space part of Star Trek Online because i could use the "mouse hand" for hotkeys via the numpad and a couple of modifier keys.
I watched the video: that's incredible! Hopefully, I don't have to be that quick to be a professional dev, or I would be out of business ;-)
Starcraft is not a good example, because to play at any level above average, you need both keyboard and mouse.
Neither one is optional. Also the actions undertaken by keyboard/mouse in Starcraft are generally not equivalent, e.g. you cannot select a hotkey group of units with a mouse, unless you select the same units visually where they are, which will always be slower. Same way you won't be making a selection box with a keyboard. Although possible, it is far less precise than a mouse.
In other words, there are certain subsets of actions for which the keyboard OR mouse will always be faster.
This is contrary to operating in a text editor or doing configuration in shell vs gui, where some people have a legitimate preference for doing it with a mouse vs text.
Neither one is optional. Also the actions undertaken by keyboard/mouse in Starcraft are generally not equivalent, e.g. you cannot select a hotkey group of units with a mouse, unless you select the same units visually where they are, which will always be slower. Same way you won't be making a selection box with a keyboard. Although possible, it is far less precise than a mouse.
In other words, there are certain subsets of actions for which the keyboard OR mouse will always be faster.
This is contrary to operating in a text editor or doing configuration in shell vs gui, where some people have a legitimate preference for doing it with a mouse vs text.
Actually I'm fairly sure (at least in newer SC like HoTS and LoTV) you can select a hotkey group of units with the mouse since they are represented visually in an icon on the screen that can be clicked.
I think the main point was to say the aspects of the game that are faster with the keyboard is around 95+ percent and that top players reduce their use of the mouse to the bare minimum because of its inefficiency.
I think the main point was to say the aspects of the game that are faster with the keyboard is around 95+ percent and that top players reduce their use of the mouse to the bare minimum because of its inefficiency.
Ah, that makes sense, I stopped playing just before HoTS came out.
I think, however, if there are still micro mechanics (e.g. marine split vs banelings), then you will only be able to use the mouse to do that action - I have never heard of a professional player that uses the keyboard for microing units exclusively, but I do admit not having played in a while.
My larger point was that it's going to be hard to make proper comparisons because the result of the action has to be 100% equivalent. Otherwise, the comparison is pointless.
I think, however, if there are still micro mechanics (e.g. marine split vs banelings), then you will only be able to use the mouse to do that action - I have never heard of a professional player that uses the keyboard for microing units exclusively, but I do admit not having played in a while.
My larger point was that it's going to be hard to make proper comparisons because the result of the action has to be 100% equivalent. Otherwise, the comparison is pointless.
> I think software development also falls into this category.
Software development has absolutely nothing to do with code entry speed.
Requirements gathering, mockups, design, testing, and thought make up the vast majority of development time. Then even once you get down to coding, you're often maintaining existing code rather than writing code from a blank slate, which requires more time reading and thought than actual modifications. A one character code change might take an hour; but you spent that time testing, following workflows, and documenting.
So the supposed developers online who obsess over their mechanical keyboards and 1ms time saved hotkeys really confuse me. I genuinely think the day to day software development that I and my colleagues do has no relationship to this bizarre online fetish with code entry speed.
If I really want to improve my coding performance, I'll do a standing meeting instead of a sit down meeting, reduce the number of people in a meeting, or stop requirements slip by completely clamping down on change requests mid-work. Those are my performance tips, and they save hours, not milliseconds...
Software development has absolutely nothing to do with code entry speed.
Requirements gathering, mockups, design, testing, and thought make up the vast majority of development time. Then even once you get down to coding, you're often maintaining existing code rather than writing code from a blank slate, which requires more time reading and thought than actual modifications. A one character code change might take an hour; but you spent that time testing, following workflows, and documenting.
So the supposed developers online who obsess over their mechanical keyboards and 1ms time saved hotkeys really confuse me. I genuinely think the day to day software development that I and my colleagues do has no relationship to this bizarre online fetish with code entry speed.
If I really want to improve my coding performance, I'll do a standing meeting instead of a sit down meeting, reduce the number of people in a meeting, or stop requirements slip by completely clamping down on change requests mid-work. Those are my performance tips, and they save hours, not milliseconds...
As someone who obsesses online over my mechanical keyboard (cherry mx clear today, but I have a collection), system hotkeys and .vimrc, I actually generally agree with this. Code entry time has almost nothing to do with software development productivity. It's just stuff I enjoy, and the fact that people get obsessed by it shouldn't confuse you any more than the myriad of other things people obsess about online. Learning to save a keystroke in vim is really just my equivalent of learning to kill a certain monster in a video game.
On the other hand, I'm generally shocked when I meet programmers who don't know their tools at all, and in my experience that really does correspond to poor productivity. I'm not talking about people with average typing speed or people who use toolbar shortcuts rather than hotkeys, but programmers who don't know how to auto-format in their tool of choice or who stop typing every few keys to reach for the mouse, click file and then save. There's a mindset that goes with effective software development, and a natural curiosity and a constant desire to do things just a bit more efficiently are key factors in that mindset. People who are constantly getting out of the flow even in their editor of choice because they haven't learned to use the tool efficiently might not have the right mindset for software development.
But yeah, I recognize that the vim golf stuff is silly (but fun!).
On the other hand, I'm generally shocked when I meet programmers who don't know their tools at all, and in my experience that really does correspond to poor productivity. I'm not talking about people with average typing speed or people who use toolbar shortcuts rather than hotkeys, but programmers who don't know how to auto-format in their tool of choice or who stop typing every few keys to reach for the mouse, click file and then save. There's a mindset that goes with effective software development, and a natural curiosity and a constant desire to do things just a bit more efficiently are key factors in that mindset. People who are constantly getting out of the flow even in their editor of choice because they haven't learned to use the tool efficiently might not have the right mindset for software development.
But yeah, I recognize that the vim golf stuff is silly (but fun!).
> Software development has absolutely nothing to do with code entry speed.
I think this is false. I think, then I type. Then I think, then I type. The more time I spend entering code, the more I lose context on the problem. So while it's not as simple as "speed * time = total amount of code written", I'm fairly certain that code entry speed has a significant impact on my productivity.
Typing speed and use of shortcuts may not be the most important skills for a software developer, but I think it's borderline ludicrous to claim that they're irrelevant. For a trivial counterexample, try coding using an onscreen keyboard and mouse.
I think this is false. I think, then I type. Then I think, then I type. The more time I spend entering code, the more I lose context on the problem. So while it's not as simple as "speed * time = total amount of code written", I'm fairly certain that code entry speed has a significant impact on my productivity.
Typing speed and use of shortcuts may not be the most important skills for a software developer, but I think it's borderline ludicrous to claim that they're irrelevant. For a trivial counterexample, try coding using an onscreen keyboard and mouse.
What about the argument that less time spent typing (and more 'automatic' text editing) means shorter interruptions from thinking, and therefore more productive thought?
You spend a lot of time thinking, and interruptions negatively impact that. The concept that you only think while you type is non sequitur; if that's the case then even with all of the hotkeys you're still going to lose your train of thought every couple of minutes while you test, navigate, or dwell.
Again, the kind of software development people claim they do online, and what I see day to day have no connection to one another. If you're literally spending a whole day typing then you're extremely unusual. Even when writing fresh code with no front end, a lot of time is spent mapping data to structures, requirements building, diagramming, testing, or just considering the most maintainable way to solve the problem(s) presented.
These programming speed challenges that have popped up in the last few years are lies too. All these people do is pre-solve problems slowly and thoughtfully, then regurgitate those solutions within a very small timespan on the day. That's why many of them let the contestants create their own problem to solve, or give them very generic problems (e.g. twitter clone).
Again, the kind of software development people claim they do online, and what I see day to day have no connection to one another. If you're literally spending a whole day typing then you're extremely unusual. Even when writing fresh code with no front end, a lot of time is spent mapping data to structures, requirements building, diagramming, testing, or just considering the most maintainable way to solve the problem(s) presented.
These programming speed challenges that have popped up in the last few years are lies too. All these people do is pre-solve problems slowly and thoughtfully, then regurgitate those solutions within a very small timespan on the day. That's why many of them let the contestants create their own problem to solve, or give them very generic problems (e.g. twitter clone).
> The concept that you only think while you type is non sequitur
That's not the concept being argued for. The concept is that you aren't thinking while you type; you're dumping what you already thought of.
That's not the concept being argued for. The concept is that you aren't thinking while you type; you're dumping what you already thought of.
I completely agree that code writing speed is not the important metric.
However, keyboard shortcuts can still be very useful for the tasks of testing and debugging. Consider the problem of stepping through many lines of code, or copy-pasting data from one place to another in order to run a test.
Lastly, when you know what you want to write (or refactor) it helps if the input system just fast enough that you can keep your sensation of flow. This part is probably highly variable among individuals.
However, keyboard shortcuts can still be very useful for the tasks of testing and debugging. Consider the problem of stepping through many lines of code, or copy-pasting data from one place to another in order to run a test.
Lastly, when you know what you want to write (or refactor) it helps if the input system just fast enough that you can keep your sensation of flow. This part is probably highly variable among individuals.
For me a large part of the reason I use Vim and only Vim for writing code is it just makes the experience so much more enjoyable. I realise this is quite subjective, but my personal experience is that whenever I use a colleague's non-modal editor I find the experience frustrating even though I know how to use it. Years of using Vim has sensitised me to the constant annoyances that accompany using a conventional editor.
Has Vim sped up the rate at which I can edit text? Probably, but for me this is missing the point.
I'm not a physiotherapist but being able to rest my forearms/wrists on the table 99% of the time when using Vim significantly reduces the risk of RSI.
Has Vim sped up the rate at which I can edit text? Probably, but for me this is missing the point.
I'm not a physiotherapist but being able to rest my forearms/wrists on the table 99% of the time when using Vim significantly reduces the risk of RSI.
hotkeys aren't about code entry.
I bet when you're in visual studio you hit F5 to debug instead of moving your mouse up and trying to hit the small button.
You probably also use Ctrl+<space> when need to pop up autocomplete directly, or Ctrl+r+r when you want to rename something quickly.
It's an idea known as 'death by a thousand small cuts'. Perhaps each individual build isn't significantly quicker using keyboard over mouse, but do it all day and it becomes significant.
This doesn't even start to consider the mental attention required for mouse usage vs keyboard usage. Every context shift potentially slows you down even more due to non-physical issues.
Trying to frame this as a discussion bout typing speed is just not accurate.
I bet when you're in visual studio you hit F5 to debug instead of moving your mouse up and trying to hit the small button.
You probably also use Ctrl+<space> when need to pop up autocomplete directly, or Ctrl+r+r when you want to rename something quickly.
It's an idea known as 'death by a thousand small cuts'. Perhaps each individual build isn't significantly quicker using keyboard over mouse, but do it all day and it becomes significant.
This doesn't even start to consider the mental attention required for mouse usage vs keyboard usage. Every context shift potentially slows you down even more due to non-physical issues.
Trying to frame this as a discussion bout typing speed is just not accurate.
There are mice with an array of thumb buttons on them that can be assigned to keyboard macros these days, they are advertised as MMO mice.
The real question is, does it matter? I've been programming for nearly 15 years and I'm really struggling to think of a time that my productivity has been limited by the speed with which I can interact with the computer. I've never actually tried to keep track of how my time is spent, but these days I wouldn't be surprised if I average 5+ minutes of reading/thinking/planning/discussing/etc. for every minute spent editing code.
I use my keyboard plenty when just navigating and reading code. The mainline at work is some 100k+ source files
To be honest, I'd go even further - I think we rarely code more than 10% of our time. I know, there is an argument that implementation matters – you don't think about typing at all with good sense of the keyboard, but I personally think it is overrated; unless you are super slow typists, it does not really matter.
What matters, though, is the fact that it is some kind of an art – people master it, people enjoy when they are able to accomplish some tasks in an elegant way (coarse example is macro in vim).
What matters, though, is the fact that it is some kind of an art – people master it, people enjoy when they are able to accomplish some tasks in an elegant way (coarse example is macro in vim).
I experienced this recently. Crashed my bike, and broke my wrists. Had about a month where I could only type with one finger at a time, or gently use a touchpad.
I thought it would be fine, since I could take my time and think things through fully in my head before typing the code. Instead, I found it so difficult - as if I could only think as quickly as I could type.
I don't know. I went from "how do I exit vi" to "mice are for losers" to "who am I trying to impress anyway".
My productivity is still crap even though I may look like a professional StarCraft player while coding.
My productivity is still crap even though I may look like a professional StarCraft player while coding.
> "who am I trying to impress anyway"
Agree, besides you need your mouse to copy-paste code from StackOverflow anyway
Agree, besides you need your mouse to copy-paste code from StackOverflow anyway
Not with Vimium you don't.
How do you select a block of text with Vimium?
Almost the same way as in vim ;)
1. Search for the text you want to copy with '/my-search-term' 2. Switch to visual mode with 'v' 3. Select the text you want 4. Yank!
1. Search for the text you want to copy with '/my-search-term' 2. Switch to visual mode with 'v' 3. Select the text you want 4. Yank!
Visual Mode
https://github.com/philc/vimium/wiki/Visual-Mode
Note btw that Firefox support something called caret browsing (maybe other browsers as well, but i stick with Firefox if technically possible). Hit F7 and you can navigate around a page using a caret.
I’ve never heard of or used Vimium before. But based on the name, it stands to reason that some variant of the ‘v’ key should select text.
Not if you browse within emacs :-)
I never feel while programming that I'm bottlenecked by my input speed.
Very true. People talking about how vim is so much more efficient than me using VSCode with my "slow" mouse inputs and I'm just thinking about how my brain is the biggest bottleneck of all - it completely dwarfs keyboard and mouse bottlenecks.
I agree 100%. I also feel like vim helps me stay in flow by providing a frictionless input environment. The way vim edits text is pretty close to the way I think about text. "change these quotes", "delete until that >", etc.
The slowest and most time-consuming thing is not writing code, but reading code. And vim, for me, optimizes reading a code base distributed across large numbers of files. I can be anywhere I want in seconds.
I know other editors also have fuzzy file finders and text search, but damn does it just feel good surfing text objects at the speed of thought!
I know other editors also have fuzzy file finders and text search, but damn does it just feel good surfing text objects at the speed of thought!
VSCode has a great Vim plugin these days and even without it, a ton of good key shortcuts. Not that maybe you need them today, but options if you need them.
I think that's probably the best summary here: it's great having options.
Also, speed isn't the only bottleneck to worry about. It's easy to forget about things like ergonomics. Things like hand movements in mousing and back and forth between mouse and keyboard can slowly take their toll. Again, it's great to have options to control the overall amount of movement.
I think that's probably the best summary here: it's great having options.
Also, speed isn't the only bottleneck to worry about. It's easy to forget about things like ergonomics. Things like hand movements in mousing and back and forth between mouse and keyboard can slowly take their toll. Again, it's great to have options to control the overall amount of movement.
Awww, thanks.
(One of the developers of VsCodeVim here.)
(One of the developers of VsCodeVim here.)
This! I've been developing for over 20 years. In my experience, it's never been the case that typing speed or keyboard fu has been the bottle neck for that development.
I agree. I was asked in an interview how fast I type. I didn't know how many WPM, but said "Average - maybe even kinda slow". I followed up with a similar thought - I tend to spend more time thinking about the correct solution, finding the right spot in the code than I do typing. I got the job. I've had the reputation at every job as someone who can get things done quickly so it must not hurt too much. Knowing what to type is way more important than how fast you can lay it down. Of course, having both would be ideal.
It never should be. If it is you're probably churning out some really crap code, and you should stop and think about what you're doing.
If you're cleaning up some really crap code, input speed becomes an issue. But I do agree that well-factored code makes for less typing, though navigation speed can be very important.
My bottleneck is usually how many things I can hold in my head at once. Getting things out of my head before I forget them and have to start over is not entirely about input speed, but it does have a significant effect.
This is probably the best take I've seen on the issue. Well put.
My input speed definitely is my bottleneck when writing down the code I have constructed in my head. So why not optimize this part of programming?
My input speed definitely is my bottleneck when writing down the code I have constructed in my head
Same here. Never learned to type properly and this happens often enough. I can't count the numbers of times I thought 'man, if I'd just have a brain-machine interface which would tranlate my thinking into text this thing would have been done 10 minutes ago'.
Same here. Never learned to type properly and this happens often enough. I can't count the numbers of times I thought 'man, if I'd just have a brain-machine interface which would tranlate my thinking into text this thing would have been done 10 minutes ago'.
I think this often as well.
And I have actively practiced my typing to try to reduce this pain. I am stuck at a sustained speed of about 55 WPM, much slower than think. In bursts I can get it much higher, but not for a whole C++ class or lengthy function. I know it shouldn't annoy me but it does that my father, who is practically retired and has has never coded types at like 80 and this while in the military of all the unlikely places.
And I have actively practiced my typing to try to reduce this pain. I am stuck at a sustained speed of about 55 WPM, much slower than think. In bursts I can get it much higher, but not for a whole C++ class or lengthy function. I know it shouldn't annoy me but it does that my father, who is practically retired and has has never coded types at like 80 and this while in the military of all the unlikely places.
Learning to type at 90wpm or so should do the trick.
I type at least that fast, and the keyboard is still a bottleneck for me sometimes.
When using emacs/vim and primarily using the keyboard, there are extra gains to be had by typing faster, because you can use keyboard shortcuts to navigate, find text, etc.
Unless you're playing a videogame, it's unlikely that you'll practice or improve on your mouse coordination and make significant gains there.
When using emacs/vim and primarily using the keyboard, there are extra gains to be had by typing faster, because you can use keyboard shortcuts to navigate, find text, etc.
Unless you're playing a videogame, it's unlikely that you'll practice or improve on your mouse coordination and make significant gains there.
If you see the brain as a multi-stage somewhat parallel pattern matching engine, I wonder if the speed of reading is limited by the mechanical capabilities of the eyes or by brain speed itself.
If it's the brain that's the limit then a computer <-> brain interface will likely be equally slow (or it has to bypass the pattern recognition parts of the brain, which is to say.. most of it)
If it's the brain that's the limit then a computer <-> brain interface will likely be equally slow (or it has to bypass the pattern recognition parts of the brain, which is to say.. most of it)
Studies (that I don't know how to look up and probably am remembering wrong) show that the eye jumps forward and back while reading. It is easy to use eye tracking to figure out what word your eye is looking at. They used some scheme to figure out what word subjects were reading, and blurred the rest, and it slowed reading down when the next two and previous words were not readable.
Thus the limit is not mechanical as the eye is moving faster than the brain to feed both the current word and preprocessing of the next few.
Thus the limit is not mechanical as the eye is moving faster than the brain to feed both the current word and preprocessing of the next few.
I do sometimes because my only to the computer tends to happen very unevenly, in bursts. I ponder things for a long while, then when something clicks mentally, I want to get it typed in as fast as possible before I lose it.
In my experience, only a small fraction of the time editing a program is spent "inputting" as opposed to editing.
> I never feel while programming that I'm bottlenecked by my input speed.
I do; it's not a long-term limiting factor, of course, but when an idea crystallizes it's a short-term drag sometimes.
I do; it's not a long-term limiting factor, of course, but when an idea crystallizes it's a short-term drag sometimes.
Back when the Ask Tog piece came out, I wrote a Slashdot comment along the same lines as this article.
I had one additional point. Keeping in mind that this uses a WYSIWIG editor, use a very slightly different benchmark task: instead of replacing every ‘e’ with ‘|’, replace every ‘l’ with ‘|’ — and by the way, your text is in 6 point Helvetica. And you'd better not miss any, or replace any ‘I’s.
The key (badum tish) is that characters on a keyboard are semantically connected to characters in a document, in a direct and obvious way. By contrast, there is no such direct link between mouse (or touch) and the document, only a transient link via the document's current presentation. With a keyboard, you can operate on text; with a mouse, you can only operate on pictures of text.
I had one additional point. Keeping in mind that this uses a WYSIWIG editor, use a very slightly different benchmark task: instead of replacing every ‘e’ with ‘|’, replace every ‘l’ with ‘|’ — and by the way, your text is in 6 point Helvetica. And you'd better not miss any, or replace any ‘I’s.
The key (badum tish) is that characters on a keyboard are semantically connected to characters in a document, in a direct and obvious way. By contrast, there is no such direct link between mouse (or touch) and the document, only a transient link via the document's current presentation. With a keyboard, you can operate on text; with a mouse, you can only operate on pictures of text.
> By contrast, there is no such direct link between mouse (or touch) and the document, only a transient link via the document's current presentation.
It need not be this way. It's simply an utter lack of imagination on part of modern peripheral makers. I had a touchstream keyboard and after a bit of work I had emacs integration that was absolutely fantastic and involved semantic gestures.
There is nothing fundamentally flawed about suggesting that gestures could be semantically meaningful.
It need not be this way. It's simply an utter lack of imagination on part of modern peripheral makers. I had a touchstream keyboard and after a bit of work I had emacs integration that was absolutely fantastic and involved semantic gestures.
There is nothing fundamentally flawed about suggesting that gestures could be semantically meaningful.
| the author typed a paragraph and then had to replace every “e” with a “|”
As a vim user, just thinking about doing this manually makes me tear up.
As a vim user, just thinking about doing this manually makes me tear up.
Why do you have to do it manually? In every common IDE you can mark your paragraph press Ctrl + R, and enter your search and replace values.
I would write a C program to do it before I would go and manually select/replace every instance using a mouse.
But what if, in the midst of writing this program, you need to rename all occurrences of a variable?
[deleted]
Depends if I'm being paid by the hour or the job :)
I assume you would call it sed?
I was trying to illustrate how far down the list I would go before resorting to manually selecting each character with a mouse. Sed is much higher on the list.
That's a little unfair. If I was only changing one or two characters then the mouse is fine. If I'm changing more than about 10-20 there will be a hunt for an alternative.
That's a little unfair. If I was only changing one or two characters then the mouse is fine. If I'm changing more than about 10-20 there will be a hunt for an alternative.
[deleted]
Another point missed by anyone using the AskTog article to argue against the need for keyboard shortcuts is the fact that you have two hands.
My own Photoshop use often involves simultaneous or near-simultaneous use of both keyboard and mouse. Sometimes I start one action before the other is completed so my hand or cursor is already near the right place.
There is no conceivable keyboard-only or mouse-only control scheme that could better this for one important reason: assuming some use of the mouse is needed (true of Photoshop and many other applications although probably not true of text editors and IDEs) then the cost of moving my right hand from the mouse to the keyboard and back again is a very large cost.
My own Photoshop use often involves simultaneous or near-simultaneous use of both keyboard and mouse. Sometimes I start one action before the other is completed so my hand or cursor is already near the right place.
There is no conceivable keyboard-only or mouse-only control scheme that could better this for one important reason: assuming some use of the mouse is needed (true of Photoshop and many other applications although probably not true of text editors and IDEs) then the cost of moving my right hand from the mouse to the keyboard and back again is a very large cost.
https://i.imgur.com/IZf6hSx.jpg
An image i ran across a while back, apparently the work area of some manga artist.
Interesting all the square buttons are programmable keys, so each of them is likely mapped to a hotkey or similar.
An image i ran across a while back, apparently the work area of some manga artist.
Interesting all the square buttons are programmable keys, so each of them is likely mapped to a hotkey or similar.
> you have two hands.
⁰ https://youtu.be/yJDv-zdhzMY
¹ http://www.digibarn.com/friends/curbow/star/keyboard/
² https://youtu.be/_OwG_rQ_Hqw?t=54m25s
This "context switch" cost of moving from keyboard only to keyboard+mouse (or mouse only) is why I always have both VimFX for keyboard controls in FireFox, and FireGestures, for mouse-only tools for doing most things.
Whether I'm leaning back in my chair with a hand on the mouse, or sitting forward with both ands on the keyboard, I can have all or most functionality available without having to reposition.
Whether I'm leaning back in my chair with a hand on the mouse, or sitting forward with both ands on the keyboard, I can have all or most functionality available without having to reposition.
Another problematic point that perhaps should be raised about those studies:
Most of today's software is optimized for usage of mouse, with keyboard only as afterthought. But we should compare software optimally designed for the use of the mouse with software optimally designed for the use of the keyboard (e.g. Vim). Though I am not sure former really exists - which is perhaps a testament of how slow mouse actually is. :-)
Most of today's software is optimized for usage of mouse, with keyboard only as afterthought. But we should compare software optimally designed for the use of the mouse with software optimally designed for the use of the keyboard (e.g. Vim). Though I am not sure former really exists - which is perhaps a testament of how slow mouse actually is. :-)
>Most of today's software is optimized for usage of mouse, with keyboard only as afterthought.
And can I add my personal pet peeve: Keyboard COMMANDS are referred to as keyboard "shortcuts". As if using the keyboard for anything other than typing text is somehow an invalid usage, and the real way of doing it is with a mouse or something?
And can I add my personal pet peeve: Keyboard COMMANDS are referred to as keyboard "shortcuts". As if using the keyboard for anything other than typing text is somehow an invalid usage, and the real way of doing it is with a mouse or something?
Having spent a lot of time in emacs, vim and plan9's acme(1) editor (which uses the mouse heavily):
The speed is about the same for most work. The time spent thinking is the major task which happens, so the time it takes to edit your buffer is not that dominating.
When you have unique reordering which you only have to do once, the mouse in acme(1) tend to beat emacs/vi. One subtle trick is that the acme cursor sits "between" characters, not "on" a character, which makes selection of text much faster. Also, if you click on eg, { it marks to the }. You need a precise mouse and some acceleration to make mouse flicks possible, but then it absolutely rocks.
On the other hand, whenever you have a repeated task, you are better off programming a solution. Here macros or vi move-style comes in handy. In acme(1), you use the built-in command language (which is close to the sam(1) command language). It is a bit easier in emacs/vi I think, but only a bit.
disclaimer: I didn't really time myself, so there may be a perception mistake in these observations. But I don't find one method vastly faster than the other. In a typical editing session, the mix of tasks makes sure that on average the editing speed is about the same. OTOH, I have enough muscle memory for emacs-fluency, so a newcomer would probably be faster on the mouse than in a keyboard-binding-experienced vi/emacs programmer.
The speed is about the same for most work. The time spent thinking is the major task which happens, so the time it takes to edit your buffer is not that dominating.
When you have unique reordering which you only have to do once, the mouse in acme(1) tend to beat emacs/vi. One subtle trick is that the acme cursor sits "between" characters, not "on" a character, which makes selection of text much faster. Also, if you click on eg, { it marks to the }. You need a precise mouse and some acceleration to make mouse flicks possible, but then it absolutely rocks.
On the other hand, whenever you have a repeated task, you are better off programming a solution. Here macros or vi move-style comes in handy. In acme(1), you use the built-in command language (which is close to the sam(1) command language). It is a bit easier in emacs/vi I think, but only a bit.
disclaimer: I didn't really time myself, so there may be a perception mistake in these observations. But I don't find one method vastly faster than the other. In a typical editing session, the mix of tasks makes sure that on average the editing speed is about the same. OTOH, I have enough muscle memory for emacs-fluency, so a newcomer would probably be faster on the mouse than in a keyboard-binding-experienced vi/emacs programmer.
Anyone have RSI problems with mice?
I switched to a touchpad over 10 years ago, and my right hand RSI problems went away.
But with an Ubuntu 16.04 upgrade, the touchpad driver went to hell (don't get me started...) and I've been using a mouse again for the last several months. So far no problems, but I really wish I could go back to my once-trusty Logitech touchpad.
I switched to a touchpad over 10 years ago, and my right hand RSI problems went away.
But with an Ubuntu 16.04 upgrade, the touchpad driver went to hell (don't get me started...) and I've been using a mouse again for the last several months. So far no problems, but I really wish I could go back to my once-trusty Logitech touchpad.
Yes. I'm waiting for Apple magic track pad 2 support in Linux before I switch. It's by far the best track pad I've ever used. Unfortunately Linux track pad support is shit as you point out. I'm hopeful it won't be in a few years. And people still wonder why Linux on the desktop will never happen. This is why.
My experience was that my trackpads worked perfectly with 12.04 and 14.04, but in 16.04 they changed the driver to... something that uses 'synclient' to adjust parameters. And this was a disaster; there are some 60 params that affect operation, and many of them have completely non-working defaults (like you sweep your finger across the touchpad and it randomly selects stuff).
I tried for weeks to try and find some synclient settings that made my trackpad work as well as it did in 12.04, to no avail. I have another machine still running 14.04 (don't ask) and the trackpad still works perfectly.
I tried posting on StackExchange, but I am apparently the only person (besides you?) that cares about Linux support for trackpads, or has trouble with the support in the current driver.
So yes, I'll second your comment about Linux on the desktop.
I tried for weeks to try and find some synclient settings that made my trackpad work as well as it did in 12.04, to no avail. I have another machine still running 14.04 (don't ask) and the trackpad still works perfectly.
I tried posting on StackExchange, but I am apparently the only person (besides you?) that cares about Linux support for trackpads, or has trouble with the support in the current driver.
So yes, I'll second your comment about Linux on the desktop.
Which trackpad do you use? It seems anything more than point and click is almost hopeless, though I did get gestures working on the built in MBPro trackpad in Linux Mint.
And yes, I tried going back to the old driver used in 14.04 (psmouse!) on 16.04 to try and get it to work, and I can't seem to make that work either.
Hardware and Linux. Ugh.
Hardware and Linux. Ugh.
Its not about speed, its about ergonomics.
As someone diagnosed with RSI, I'm looking for ways to type and use my track pad slower and less of the time. I find that other than text chatting with my co workers, nothing really depends on me being able to type fast. I don't know what kind of programming work the author does, but I find I have to type/track pad very little even for large refactorings and slowing down from about 80wpm typing to probably half that hasn't really affected my working speed. I'd say I'm at least half to a quarter as slow both typing and tracking (used to use a trackball which was faster than any track pad or mouse) and it's affected my overall speed less than 10%. There are many ways to automate and avoid a lot of repetitive actions in programming which also help quite a bit.
An article is posted bemoaning the lack of rigor in mouse and keyboard speed measurements. Instead of posting anything of rigor, tons of posts are done about more anecdotal input experiences.
I love my keyboard-heavy emacs workflow, but come on, at least pretend to read the article or seek some rigor in things.
I love my keyboard-heavy emacs workflow, but come on, at least pretend to read the article or seek some rigor in things.
Keyboard is best for digital input (keypresses, either/or actions), and mouse is best for analog input (precision, sweeps, variable speed).
Not that complicated.
Not that complicated.
My mouse cursor is in a different place every time I reach for it. My keyboard is always in the same place. Sure, if I'm using a cursor with my keyboard, I'll have the same problem, but at least the cursor tends to be in the exact same spot I was already focusing my attention, ie where I was just typing.
If I'm executing an action with my mouse, the path between my cursor's current location and where I need to click is almost always different. I have to move my attention to the cursor, and I can't just rely on muscle memory to do the command.
If I'm executing an action with a hotkey, the path between the home row and the keys I need to hit are always the same. If it's something I do frequently, it's in my muscle memory, and I don't have to shift my attention away from the task at hand.
I don't care much about the speed at which I can accomplish a single action (as long as it's not unbearably slow), but I do care about having to shift my attention away from what I'm doing. If I'm doing something that requires a lot of typing (eg, programming), I'll try to do as much as possible with the keyboard. If I'm in a novel environment and have to rely on visual cues (eg, surfing the web), I'll do most things with the mouse.
If I'm executing an action with my mouse, the path between my cursor's current location and where I need to click is almost always different. I have to move my attention to the cursor, and I can't just rely on muscle memory to do the command.
If I'm executing an action with a hotkey, the path between the home row and the keys I need to hit are always the same. If it's something I do frequently, it's in my muscle memory, and I don't have to shift my attention away from the task at hand.
I don't care much about the speed at which I can accomplish a single action (as long as it's not unbearably slow), but I do care about having to shift my attention away from what I'm doing. If I'm doing something that requires a lot of typing (eg, programming), I'll try to do as much as possible with the keyboard. If I'm in a novel environment and have to rely on visual cues (eg, surfing the web), I'll do most things with the mouse.
Learning keyboard shortcuts in Excel yields massive returns on productivity. For an intro, Joel Spolsky has a great tutorial: https://www.youtube.com/watch?v=0nbkaYsR94c
Investment bankers are famous for working without a mouse in Excel.
Investment bankers are famous for working without a mouse in Excel.
There's a lot more potential for repetitive stress injury (e.g. carpal tunnel) with using mouse on one hand constantly. At least with a keyboard, you are distributing the stress among four fingers and a thumb. Although, admittedly I use my right thumb for space rather than alternating with my left thumb.
Never mind whether it's faster. Is it more comfortable and less likely to give you RSI? Grief yes.
Ironically, this is especially true for things muce are faster at. Drag and drop is fast, but it kills your hand.
Ironically, this is especially true for things muce are faster at. Drag and drop is fast, but it kills your hand.
Okay that was quite hard to read, any reason for no formatting at all?
Agreed.
Been using My Style [1] for readability on his site. Even this small tweak helped:
Been using My Style [1] for readability on his site. Even this small tweak helped:
body {
max-width: 768px;
margin: 32px auto;
font-family: Helvetica;
font-size: 20px;
}
Spent some time on this a while back, and even wrote a driver that let me use a game controller as a complete replacement for my keyboard and mouse. Interesting but not really successful.
One key takeaway: The input bitrate that a competent typist can get from a keyboard is quite high. As a guess, it might be 8x higher than with a gamepad or mouse.
And as an additional detail, I've had more RSI issues with mice than keyboards over the years, even though I use emacs.
One key takeaway: The input bitrate that a competent typist can get from a keyboard is quite high. As a guess, it might be 8x higher than with a gamepad or mouse.
And as an additional detail, I've had more RSI issues with mice than keyboards over the years, even though I use emacs.
I'm surprised nobody mentioned Keystroke Level Modeling (KLM) or CogTool (github.com/cogtool/cogtool), which divides up UI interactions into discrete actions with specific times. It gives a pretty reasonable estimate overall, and is great for comparing between multiple competing concepts/usage-models.
Regarding speed across overall, day-to-day usage, the trackpad is closer than a mouse – you can move the pointer a fair distance and click/etc. with just your thumb while keeping your hands on the keys.
And on the new MacBooks, I'm pleasantly surprised how the Touch Bar saves me from even reaching for the trackpad, sometimes.
And on the new MacBooks, I'm pleasantly surprised how the Touch Bar saves me from even reaching for the trackpad, sometimes.
About this Tog guy, I've never heard of him before, but for all his claims of doing UX research, he has 0 peer-reviewed papers, and the "experiment" about the 'e's and the pipes is so laughably bad, that I wonder what's the point in taking anything of what he says seriously.
Also worth mentioning, when it comes to picking or pointing from the keyboard, is keynav. It lets you do a binary search in screen-space, which can be pretty fast (though probably slower than the mouse if your hand is already on it).
One important area on where keyboard gets an unknown advantage is the muscle memory.
Using mouse will require attention from your hand and eye both at the same time. On keyboard, you can let your fingers work while resting your eyes.
Using mouse will require attention from your hand and eye both at the same time. On keyboard, you can let your fingers work while resting your eyes.
Keyboard can be a bit slower, but I find that moving to the mouse interrupts my train of thought. I'm not sure why but it seems to engage a different part of my brain that pauses what I'm thinking about.
If you want the fastest way in existence to copy/paste in terminal
https://github.com/morantron/tmux-fingers
https://github.com/morantron/tmux-fingers
If you really want to make the question more interesting, throw a touchscreen at it.
For general UI purposes, mice are hopeless when you compare them to your fingers touching the screen directly.
For general UI purposes, mice are hopeless when you compare them to your fingers touching the screen directly.
To be honest, if we could somehow make an effective pen technology, that would beat both hands down in many scenarios.
There's a reason we don't write things using our bare fingers :)
There's a reason we don't write things using our bare fingers :)
I use my Surface Book with touchpad (pointer/mouse), keyboard, touch and pen. Pen and touch can work quite nicely together, e.g. in Maps using touch to pan and zoom and pen to write, all in the one hand. But it certainly requires the software to have been designed with all of these possibilities in mind.
I'm not sure if that applies to a 32" 4k display that is positioned about 10" away from the user in a typical desktop setting. I can't only imagine the pain in my shoulders.
I guess that is why Microsoft added the hinge on their Surface Studio.
Selecting text with a touchscreen is the pits. My big fat fingers obscure what I'm trying to select and most of the UXes fit touchacreens make text selection a second class citizen.
I said “general UI purposes” rather than “everything” very deliberately; certainly touch is ghastly for some things.
> Selecting text with a touchscreen
is really not that inconvenient with the force-touch-on-keyboard on iPhones, and two-finger-swipe-on-keyboard on iPads.
is really not that inconvenient with the force-touch-on-keyboard on iPhones, and two-finger-swipe-on-keyboard on iPads.
I find it to be a big pain on my iPhone. You have to tap and hold for a long time, very carefully not moving the finger so it doesn't interpret the gesture as a scroll, then probably adjust its selection using those tiny fiddly little blue touch thingies, and if you mistap at any point it resets everything. Then you need to long tap again to bring up the options, but not medium long tap because that will reset everything, nor have any wiggle since that will scroll, nor super long tap since that does nothing...
The best I can say is that it's better than nothing. I use it from time to time, but only because I have to.
The best I can say is that it's better than nothing. I use it from time to time, but only because I have to.
> You have to tap and hold for a long time, very carefully not moving the finger so it doesn't interpret the gesture as a scroll, then probably adjust its selection using those tiny fiddly little blue touch thingies, and if you mistap at any point it resets everything.
That isn't what I was referring to. Force-pressing on the on-screen keyboard lets you move the caret around like a mouse pointer, by sliding your finger on the keyboard. Pressing again/harder begins a selection.
That isn't what I was referring to. Force-pressing on the on-screen keyboard lets you move the caret around like a mouse pointer, by sliding your finger on the keyboard. Pressing again/harder begins a selection.
I dunno. I keep screwing up when picking an entry from a list of them on my phone. Perhaps because there is no way for me to correct by dragging my finger elsewhere unlike with a mouse (outside of web links most mouse actions happen on button release, not button press).
It depends, if it is wired or wireless ;)
I think we need both to be effective and this is false question in a way, but still good to explore from usability point.
I think we need both to be effective and this is false question in a way, but still good to explore from usability point.
My big problem in productivity is multiple cut and paste buffers in vim; i would love to see a good way to use that.
Small typo: "hunt-and-pack" should be "hunt-and-peck."
[deleted]
For me isn't just the fact that using the keyboard is faster to carry out a specific task, it is also that in Vim (or most places using a good keyboard layout) I don't have to take my fingers out of the home row and then carrying out the next action is also faster.
The problem is the whole mouse physics.. if you could look at a point and then click.. that would be a dream.
eyetracking and AI should be able to replace the mouse.
Interesting post. Thanks!
depends, duh. are you typing code or are you documenting a graph?
[deleted]
I think software development also falls into this category. Some hotkeys are at least an order of magnitude faster. And 90% of the time hotkeys will be faster. But in some cases you absolutely need to use your mouse, it's just much faster.
Here's a YouTube video that discusses what it takes to be a competitive Starcraft player and shows them entering actions: https://youtu.be/zmYhX8fjmo8