This last week I’ve been getting familiar with Vim. I’ve dabbled a few times in the past, but this time I’m finally feeling comfortable enough to stick with it. I was quite annoyed with having to hit ESC all the time, but a neat tip is to set this in your config file:
imap jkl <esc> imap jlk <esc> imap kjl <esc> imap klj <esc> imap ljk <esc> imap lkj <esc> set timeoutlen=500 " cuts down the pause time you'll see after typing j, k, and l
…so now you can get out of insert mode by smashing ‘j’, ‘k’, and ‘l’ simultaneously. This will, of course, conflict if you ever need to type one of these sequences, but those are surely quite rare and work-around-able. I’m even going to experiment with reducing this just to ‘j’ and ‘k’, which is itself a really rare sequence in English. (Maybe ’s’, ‘d’, and ‘f’ or just ‘d’ and ‘f’ can be set to ESC as well.)
If you don’t like that solution, other good choices are:
imap <S-space> <esc> " shift-space to get out of insert mode
…and:
imap <S-enter> <esc> " shift-enter to get out of insert mode
I mention Vim because I recently played with the alpha of Archy, which is a project to implement the ideas of the late interface theorist Jeff Raskin, and its text editing mode feels much like Vi stripped down to the essentials for the common user. Here’s a quick summary of Archy’s interface:
- The primary part of the interface is one big text-editing window; there’s only one sequence of text, but the text is separated into ‘documents’ by special divider lines (which are inserted by the ` key).
- Navigation up and down the big glob of text is done primarily by holding down an alt key and typing a string of text to “leap” to. Using left-alt does a back search for that string while right-alt does a forward search. Releasing alt takes you back to typing mode at the location you just leapt to. To repeat your last search, hold capslock and tap alt (right-alt for forward searches, left-alt for back searches). Having to hold down alt while typing is pretty awkward and uncomfortable after a while.
- This ‘leaping’ feature with the alt-key searching is also how you select text: the selected text portion is always the section between the place you last leapt from and leapt to.
- The user issues commands by holding down the capslock key, then typing the command. E.g. [capslock]-C-O-P-Y to copy the highlighted text. Even with auto-completion, having to hold down capslock while typing is pretty awkward, especially if the command contains an ‘a’, ‘q’, or ‘z’.
- Text can be formated (coloring, fonts, style, size, alignment, etc.) by highlighting text and issuing a command.
- And for some reason, to get a key to autorepeat, you must triple-tap it before holding it down. (This is really annoying, especially with the navigation and backspace keys.)
Text-editing is the only part of the alpha, but Archy’s other key component will be what they call the Zooming User Interface (ZUI), which I take it is where non-textual elements will reside. How these components will fit together, I’m really not sure.
What to make of this? First, I’ll say there are some things I admire about this approach—mainly, Archy bravely recognizes average users can cope with a few non-discoverable elements: as long as the set of basic concepts to learn is small and worth the pay off, it’s OK—contra Steve Jobs—to expect users to learn something. Archy strikes me as an attempt to bring the Unix philosophy to the masses: rather than relying upon packaged solutions to problems, users are encouraged to build upon a base of simple yet powerful mechanisms; Archy simply starts from a clean slate, dispensing with the accumulated detritus of 40 years of terminals and programmer conventions, keeping things tidy, sacrificing power for approachability.
This said, there are glaring faults with Archy as currently available. First, having users hold down alt and capslock while typing is clearly not going to fly, as it’s difficult for even expert users, let alone the majority of users that have trouble touch typing. Yes, the purpose is to eliminate modality, but this is clearly not a realistic solution. (Maybe we need special keys below our space bar which we can hold while typing more naturally, or maybe the spacebar itself could be used.)
Really, modality is not as bad as UI orthodoxy claims. Keep the number of modes few and try to eliminate unnecessary ones, surely, but modality is extremely powerful, and to do it right, you really just have to give unmistakable visual, auditory, and feedback cues to the user conveying what state the interface is in. (A good test is to see what happens when users step away from the computer then come back later; if they mistake the mode they’re in, you have a problem.) Archy’s cues are just too damn subtle. For instance, I found myself confused when I started typing because sometimes Archy would move my cursor to some other document; turns out I was trying to type in a ‘locked’ document, but it took me a number of tries to figure this out as the message Archy briefly flashes is black text superimposed over very similar black text at the top of the screen; it’s great they didn’t annoy me with an ‘OK’ pop-up, but there’s unobtrusive and then there’s covert. In general, Archy has far too few elements of on-screen guidance, likely because the developers are too enamored of the idea of an interface-less interface. At the very least, Archy should have a training mode in which at least some screen real-estate is devoted to guiding new users.
Also problematic is how Archy messes with the user’s expectations about character keys, giving the keys surprising behavior in certain contexts such that they don’t always produce their usual characters. Now, there are obvious cases where average users quickly adapt to character keys not producing their respective characters on screen—games, for instance, often make use of the alphanumeric keys for non-text purposes—but such programs usually clearly delineate between typing mode and non-typing modes. In contrast, Vi, Emacs, and now Archy violate this barrier, messing with character keys in the context of typing text. In Archy, you find yourself in a few annoying moments like you do when first using Vi(m) where it’s not responding like you expect and you just can’t understand why.
Fortunately for Archy, both of these faults—inadequate cues and poor key assignments—can be fixed, but I wonder if the project will be willing to do so, as it requires compromising on its ideals of a totally modality-less and interface-less interface.