the keyboard/mouse and “bandwidth”

I want to clarify something of what I wrote in the last post about when the keyboard is more effective than the mouse and how it relates to bandwidth. If you haven’t already read the post on The Productive Programmer and vim, go do so, then come back.

I wish I could find the article about keyboard/mouse and bandwidth, but since I can’t, you’ll have to deal with my crappy summary of the articles summation.

First off, the article isn’t really discussing the keyboard and the mouse – it is a discussion of interaction with a console vs. interaction with a graphical interface. The key message is this:

The console primarily uses keyboard entry, which is high bandwidth, and textual output, which is low bandwidth
A GUI primarily uses mouse entry, which is low bandwidth, and graphical output, which is high bandwidth

So I did the article a disservice by saying that using the keyboard means that your output is low bandwidth. In vim, certainly, your output is (mostly) just text, and so why your input experience is very rich, the output experience is still a black box with some colorful text. Not to bash on simple boxes with colorful text, of course, as the simplicity of the interface ends up being one of the things I truly appreciate about vim (and the thing that people like Steve Ballmer will never understand about Google and how seriously they take simplicity).

As an aside, I heard a coworker the other day exclaim that, “The only reason anyone would ever use gmail [over windows live mail] is if they seriously hate Microsoft.” The reason (he later gave)? Because Windows Live Mail gives unlimited storage. Of course, my limited (7GB!) storage on gmail is getting pretty full these days (around 3% used), so I should probably consider upgrading. This relates to the topic at hand, however, since the reason I’ve switched to gmail entirely is that I find myself a metric shit-tonne faster navigating mail in gmail than any other mail application I use (especially Outlook, which I think was designed to make people frustrated).

Back to business.

The problem with my assertion about the mouse and keyboard (and relative benefits) is that it sidesteps a more important question – is there a way to get the best of both worlds?

Here’s what I think:

GUI widgets are often the most discoverable/obvious of interaction paradigms (the interaction here is the mouse)
Providing sensible shortcut keys is often the most efficient way of interacting with an application (the fewer times I have to move my hands around, the more efficient I will be)
GUI widgets often provide the most information for any given amount of visual space (bandwidth) – think of, for example, the ribbon in Office, which provides a large deal of information in a relatively minimal space.
A well designed set of shortcuts (i.e. keyboard interaction that feels purposeful instead of accidental, such as vim/emacs) allows shortcuts to be easily learned and thus makes the path from using the mouse (for discoverability) to using the keyboard (for efficiency) easier.

Take, for example, debuggers, comparing the Visual Studio debugger to, say, gdb. To a large extent, you can accomplish the same thing in both debuggers, but you’ll find that you’ll be much more efficient with the VS debugger than plain ol’ gdb (although something like DDD will bring you much closer).

The reason for this is that:

The VS debugger allows discoverable interaction through the mouse – menus, various windows that can be used/rearranged, and interaction with graphical widgets like breakpoints and the currently executing statement arrow
While the shortcuts aren’t necessarily “sensible” (lots of function keys, no clear rhyme/reason for the various shortcuts) or complete (you can’t do everything with them), there are keyboard shortcuts for doing almost anything with the debugger. Once you learn these, you have to go to the mouse much less.
The VS debugger, being plugged into a GUI, provides more information over the same amount of screen real-estate and the same amount of interaction than gdb does.

I’m going to cut this short. My mind keeps getting sidetracked on gmail/google reader, so I’m going to go pen a few words there before I lose them all.

This entry was posted on Friday, July 25th, 2008 at 10:14 am and is filed under general. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

John Floren

I agree that the worst part of it is moving your hands to the mouse and getting the cursor to the right place, moving back to the keyboard to type the command, and then switching back to the mouse again to select and execute the command, but I also find it convenient in its own way.
I use acme exclusively for editing on Plan 9 and emacs or vi for editing on UNIX. I don't work with Windows if I can help it but vim is the preferred option there too.

noah

So it sounds like you have to do the following:
1) You are typing along (hands on keyboard) and you want to replace something in a piece of text
2) You select the paragraph (hand on mouse) and move the mouse somewhere
3) You type in "edit s/foo/bar/g" (hands on keyboard)
4) You middle click it (hand on mouse)

The slowest part of using an editor is the movement back and forth between keyboard and mouse, I think, so this still feels suboptimal. In vim, for example, you could do the following:

1) You are typing along and want to change text in the paragraph
2) You select the current paragraph with "vip" or "vap": visual mode ("select") inner/"a" paragraph (the current paragraph) (more below).
3) You type ":s/foo/bar/g" and press enter

No movement of the hands, no movement off the keyboard.

For #2, you can replace the "p" in that with any of the following:
"w" - word
"s" - sentence
"[" or "]" - a "[]" block
"(" or ")" or "b"- a "()" block
"{" or "}" or "B" - a "{}" block
"<" or ">" - a "" block
" or ' or ` - a quoted string
"t" - a tag block, a la html (e.g.: "<foo>sometext</foo>")

You can also replace "v" (for selecting) with other commands like "d" (to delete) or "c" (to replace) or "y" (to copy). And the difference between the "a" and "i" version ("a" block vs. "inner" block) is that the "a" version includes the delimiters of the block.

The command remains, in a sense, for further use: pressing "." immediately runs the last command (so if you move the cursor to another paragraph and press ".", it will do it again). Pressing ":" and then the up arrow key will scroll through your history (if you've typed a part of something, like ":s/", it will only complete history items that match what you've typed so far). If you want to save it around, type "qa" (record macro into register 'a'), do steps 1-3, then hit "q" again to stop recording. "@a" runs the macro in register 'a'.

The paper is an interesting read, and I do believe that using the mouse for selecting text is faster for most people than would be the vim keyboard equivalents (my coworker uses gvim for this very reason, but I stick to just vim). However, I think that anything that requires some use of the mouse is still suboptimal to a solution that provides an optional mouse interface. Then again, to each their own :)

Here's a paper from the author of vim (Bram Moolenaar) about effective editing in vim: http://www.moolenaar.net/habits.html

John Floren

#ifdef ADVOCACY
Regarding the keyboard/mouse idea, I would say that a system must either provide keyboard shortcuts OR allow the user to accomplish almost any function in a small number of mouse-clicks. I personally enjoy a Plan 9 editor called "acme"; although there are very few keyboard shortcuts besides ^E for end of line, ^A for beginning, and left & right arrows to move one character at a time, it allows you to compose and run ed/sam-style editing commands on any selected text, easily pipe it through external programs, etc. Basically, my only desire would be for ^F and ^P to move forward and backward instead of the arrow keys; the interface allows me to work quickly enough without extensive shortcuts.
For example, to replace all instances of "foo" with "bar" in a paragraph, I just highlight the paragraph, move my mouse to the file tag-line, type "Edit s/foo/bar/g" and mid-click it. It may take a bit longer than vi, but the command remains for later editing/use, which helps reduce time spent later.

The paper is a bit old, but interesting: http://plan9.bell-labs.com/sys/doc/acme.html
#endif /*ADVOCACY*/