Is the keyboard faster than the mouse?
danluu.com
danluu.com
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
I'd say that is heavily dependent on personal workflow and taskset.
Like Starcraft, the best thing the mouse is for is box selection. Everything else is done with keys.
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.
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.
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.
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.
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...
Update with links:
https://github.com/guyht/vimari
https://addons.mozilla.org/sv-SE/firefox/addon/pentadactyl/?...
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?
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.
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, 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.
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...
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).
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.
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!).
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.
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.
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 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.
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).
My productivity is still crap even though I may look like a professional StarCraft player while coding.
Agree, besides you need your mouse to copy-paste code from StackOverflow anyway
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!
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 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.
(One of the developers of VsCodeVim here.)
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.
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'.
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.
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)
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; it's not a long-term limiting factor, of course, but when an idea crystallizes it's a short-term drag sometimes.
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.
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.
As a vim user, just thinking about doing this manually makes me tear up.
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.
:%s/e/|/g
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.
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
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.
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. :-)
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?
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.
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 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.
Hardware and Linux. Ugh.
I love my keyboard-heavy emacs workflow, but come on, at least pretend to read the article or seek some rigor in things.
Not that complicated.
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.
Investment bankers are famous for working without a mouse in Excel.
Ironically, this is especially true for things muce are faster at. Drag and drop is fast, but it kills your hand.
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;
}
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.
And on the new MacBooks, I'm pleasantly surprised how the Touch Bar saves me from even reaching for the trackpad, sometimes.
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.
For general UI purposes, mice are hopeless when you compare them to your fingers touching the screen directly.
There's a reason we don't write things using our bare fingers :)
is really not that inconvenient with the force-touch-on-keyboard on iPhones, and two-finger-swipe-on-keyboard on iPads.
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.
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 think we need both to be effective and this is false question in a way, but still good to explore from usability point.