5 ms·
With wireless mice you can move your hand nearer than they keyboard and even with tab completion navigation between files is hard compared to just a couple of c
by amriksohata 8y ago
With wireless mice you can move your hand nearer than they keyboard and even with tab completion navigation between files is hard compared to just a couple of clicks?
- jshevek 8y agoNo no, the problem isn't reaching across the desktop. The problem is literally taking your fingers off of home row. It's fine if you're in a phase of your activity where you're moving slowly, contemplatively. But if there's a series of tasks that we want to accomplish and we already know what they are, lifting your fingers off of home row will slow us down! Wireless vs wired mice have nothing to do with this. As far as what is considered to be hard, it depends on the individual. For many of us that spend a great deal of time on the command line, many multi-step activities, including those related to file manipulation, become like a single action. Consider the difference between touch typing and hunting and pecking. To an experienced secretary, the phrase "to whom it may concern" can become a single action, executed by the fingers without any thought whatsoever, while for an inexperienced typist that's 20 individual actions. Similarly, a whole series of file manipulations, git actions, SSH actions, become hardwired into our muscle memory and we don't even think about the steps. We just decide that we're going to do something, and let our fingers take care of it. This is much easier and faster then manipulating a GUI with a mouse.
- amriksohata 8y agoI would like to see data on this, any studies done?
- jshevek 8y agoA healthy skeptic doesn't demand data for claims like "touch typing is faster than hunt-and-peck".
- amriksohata 8y agoA healthy skeptic? Lol what? Anyone who feels they have a point should be able to back it up with sources or data
- jshevek 8y agoNo. Reality is not established by publication. You can, and should, observe some things for yourself. It is obvious that touch typing is faster than hunting and pecking for most people who: - have 10 fingers - have invested sufficient effort to learn touch typing To demand sources for this is disingenuous.
- amriksohata 8y agoI can observe the sun is hot, but doesn't mean I can tell what temperature it is. I think without data of timings across different applications and uses, it's hard to prove either side. I am open to both sides having the possibility of being quicker
- TeMPOraL 8y ago> and even with tab completion navigation between files is hard compared to just a couple of clicks? Since when? Editor speaking, I can navigate / open files / select faster with keyboard than it would take to move the hand to the mouse. Not move the mouse and click, just in time it takes to switch the right hand I can launch three of four keystrokes, and that's enough to complete arbitrary operation in vim or Emacs. By the time I'd complete that op by clicking, I could do a dozen more from keyboard. Mousing is that slow. Terminal speaking, sure, typing even portions of file names + arcane flags may seem a bit slower than pointing and clicking. But then I can type: | some-other-command --flags, and good luck doing that with mouse in reasonable time. And then, satisfied with my result, I can go back to the initial command and shove a "*" somewhere, and now I'm in batch mode, and with one Enter press repeating the same operation on a dozen or thousands of files. At this point, pure-GUI user would have to get on the web to find specialized software...
- amriksohata 8y agoI would like to see data on this, any studies done?
- TeMPOraL 8y agoYou need studies for something you can trivially test for yourself with a stopwatch?
- amriksohata 8y agoOne use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.
- TeMPOraL 8y agoLet me sketch you something of a theoretical proof here, then. 1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster. 2) The absolute upper bound on the simplest possible way of aiming at a single pixel of 4K UHD screen with just two keys is 23 key presses. 14 key presses if you're aiming at 16x16 squares (mouse rarely needs to aim better). 12 keypresses for arbitrary pixels with four keys (home row). 8 for 16x16 square with four keys. 5 presses with full set of English letters, for arbitrary pixels. That's an upper limit. It's slower than a mouse, but only by a little bit (within the same order of magnitude). 3) Generalizing this, the upper bound of keypresses you need to touch arbitrary element on the screen is given by log_n(number of elements), where n=how many keys you want to use. +1, if you need some sort of activation key before (to switch between typing and selecting). This quickly drops to 1-3 keys, and you can get even better if there's some structure to the expected workflow (see e.g. tab stops in any sane form in any UI that isn't suffering from acute JavaScriptitis yet). 4) 1-3 random keys are faster to press than clicking a random object on a screen. That you can time for yourself trivially. Basically, unless you're dragging arbitrary pixels around, for almost[0] any task one could easily design a keyboard-driven UI that's faster. Those kinds of UIs are not omnipresent (with the exception of Windows-style "accelerators" and tab stops, which the web is doing its best to get rid of), but they show up. In fact, properly configured Vim and Emacs are full of these kinds of UIs for programming tasks (see e.g. [1]). Which is exactly why you keep seeing people telling you Vim/Emacs are more efficient to work in. -- [0] - I'll make concession to visual arts here, but take a good look at Blender to see how far you can go with keyboard-driven efficiency improvements for 3D modeling. [1] - https://github.com/easymotion/vim-easymotion; https://github.com/easymotion/vim-easymotion; Emacs has stuff like this too, but this repo has better screenshots.