4 ms·
I haven't used Plan 9, so I'll have to take you at your word that the mouse in an effective preferred method of input in its UI. I would be very interested if y
by dkbrk 11y ago
I haven't used Plan 9, so I'll have to take you at your word that the mouse in an effective preferred method of input in its UI. I would be very interested if you had some specific examples of how it is used. That said, there are very real differences between methods of input that go far beyond "arbitrary UI convention" and that make one or the other substantially better suited for certain actions.
For example, the mouse is excellent at quickly moving to an arbitrary small area on a screen. Take as an example the operation of jumping to a particular character in a text file. To do this in emacs, I first move vertically either by looking at the line number of my target and jumping to it, or by moving in blocks (e.g paragraphs or code blocks) then by lines. Then I move the cursor to the correct horizontal position, first by blocks (e.g words, lexemes), then by characters. If my hand were already on the mouse, I think in a substantial proportion of cases using the mouse would be faster.
But there are other considerations. There is a noticable context switch moving my hand from my keyboard to my mouse and vice versa. Also, the mouse is only really good at moving to an area: moving to a single pixel is quite difficult; moving to a particular character is somewhat slower than moving to a word. This imprecision is related to the redundancies (i.e non-injectivity) in translating 2D analog movement to a 2D discrete position and mapping that to some action. In contrast, keyboard commands tend to be discrete, precise and minimal. While I could press the wrong key, that's a fairly substantial mistake; pressing a key off-centre or pressing it a bit harder than usual doesn't change the outcome of the command wheras a minute movement of my hand could easily make my mouse input skip over to something unintended.
One application the mouse excels at is clicking hyperlinks, or something hyperlink-like. Generally, these areas of input are large enough that a little bit of imprecision is acceptable and the 2D input can be very efficient. This comes up in emacs, for example when navigating info pages. You can either cycle through the hyperlinks in a document with TAB and Shift-TAB, or you can use the mouse. While it's a trade-off, generally I find the mouse to be far more comfortable.
The keyboard also offers an exponentially larger space of possible inputs for a given input length. The 2D input space of the mouse is quite large, but its imprecision considerably limits the space of useful inputs (i.e it would be a bad idea to assign a different command to each pixel of the screen). Like the keyboard, this can be expanded by successive commands, for example with a nested menu or compound actions such as click-and-drag. However, each element of the mouse input is slower -- wheras a keyboard command sequence can be entered as a whole from memory, each stage of the mouse input generally requires responding to new visual input (e.g a new submenu that has opened) and another distinct physical movement.
There is something to be said for combining keyboard chords on one hand with the mouse in the other, this allows much of the flexibility of the keyboard commands, but is still only really useful when the input is well suited to the somewhat idiosyncratic properties of the 2D cursor.
Finally, I think the most important factor for many people is the context-switch between touch-typing and keyboard-and-mouse. In this situation, even if the mouse is a better input method (e.g for clicking a hyperlink), then there may still be considerable advantages overall to just using the keyboard.
- michaelmrose 11y agoIn a text editor something like easymotion for vim or I think ace jump for emacs makes this very easy to do with the keyboard. Ex I press 1 key then the desired character I would like to jump to say y all ys on screen are replaced with 1-2 yellow characters typing those jumps to that location. There are actually several plugins for this and several different ways to set this up. Some variations include typing 2 target characters leading to fewer possible matches. On net though you can jump anywhere on the screen in 3-4 keystrokes. Another example hyperlinks plugins like pentadactyl and vimperator have a function wherein you hit f to highlight all the links which are marked with letters so basically you can click any link with 2-3 key presses. Obviously this doesn't work with anything involving hovering clever expanding menus but for a large portion of cases I find using pentadactyl keys better than a mouse.
- jodrellblank 11y agoOne other thing I don't think you've covered is that keypresses have a clear intent. CTRL-W means "close tab" in a browser, SHIFT-HOME means "select to beginning of line" in a text field. With a mouse, it's frustrating to try and resize a window and click one pixel off the edge, and bring a background window to the foreground instead - because there's no encoding of your intent to perform a resize operation so it's as likely that you were trying to reorder windows. It also means that to make up for this, GUIs are trying to guess your intent - just try selecting all the text except the first character, or including the first character, or to the end of line not including the newline, or to the end of the paragraph not including the beginning. Different programs, different environments, will jump both ends of your selection around and/or make it very hard to get down to the letter, as they override your movements while wrongly guessing your intent. It also means keyboard commands can be fired off in series, without waiting to see the results - especially with the awful trend of personalized menus - with a mouse + GUI you have to wait for the screen redraw between movements so you can respond to what's drawn. With a keyboard you can hammer ALT+F, X, N for File -> Exit -> No don't save, and know it will just work, no matter where the dialog appears, or where the 'exit' has moved to on the file menu, or where the cursor is on screen. Which is great for remote desktop sessions, but also it feels less annoying.