The Directional Input Problem

In the Friday discussion thread, Dr. Azrael Tod said something that resonated with me:

Problem with vim and its “less work for your fingers” is that i think its the wrong way to solve this problem. As example: vim uses hjkl for coursor-movement, so you dont need to move your fingers away from the main part of the keyboard to the arrow-keys. This is because and could have been solved via the keyboard-layout. This way this would be solved for EVERY application. Instead nearly every developer uses vim, so they dont see this problem and it will never be solved for the average user.

This is a very intriguing point. I do agree that the inverted T block of arrow keys is somewhat counter-productive. It’s almost as bad as the mouse, in that it takes your right hand away from the home row and thus slows down your typing considerably and introduces unnecessary hand movement where there ought to be none. If we could come up with a better keyboard layout that would use HJKL for movement and train users to use it we could improve typing speed for all applications.

But, there is a problem here. Or rather, a whole set of problems that we would need to overcome. For one, HJKL keys are normally used for character input. They can be used for movement in Vim because it is a modal editor. It uses one set of shortcuts in normal mode, and whole other set in input mode. Unfortunately most people out there find modal editors endlessly confusing. It’s not that they are hard to use, it’s just that they are a bit counter intuitive. Let me give you an example. To edit a document in a non-modal editor you:

1. Use the main keyboard block to type
2. Use the arrow key block and the square above it for movement

With Vim/Vi this is a bit more complex. To edit a document:

1. If in normal mode, use HJKL and multiple other keys for movement
2. To enter insert mode, you press i, a or one of several other keys
3. If in insert mode, you use main keyboard block to type, but cannot move
4. Hit Esc to exit insert mode and go back to normal mode

The former example is intuitive, and can be learned by trial and error. The latter must be trained, or explained to the user. Even if you had a keyboard with Vim shortcuts printed on select keys, the differences between the two (or more) modes would have to be communicated to the end user.

Modal editing by itself is not that great. It works well in Vi because the editors other features complement it. The large set of commands, the fact that you can chain them, record them and then repeat them via macros gives you an incredible amount of power. If you introduce modes to other applications, you will merely make them awkward. You would need to replicate the whole Vi experience. Doing it in a system wide manner goes beyond creating custom keyboard layout. It becomes a very complex process that would have to redefine many established methods for moving around within and between applications.

We could possibly avoid going modal, by requiring the user to press and hold some modifier key while pressing HJKL keys for movement. This sort of thing however takes us away from the Vim philosophy and introduces a new problem. Which modifier key do we pick? How do we prevent it from conflicting with each applications internal shortcuts? How do we train people to use it?

Something tells me this is not the right way to go either. Let me ask you a question – does any of you have a laptop which had the numpad keys mapped onto the main keyboard block? A lot of manufacturers will do this, and then let you access these keys via special modifier button (usually labeled Fn or something like that). How many of you use this feature? I have never actually seen people use it. Most folks who like to use the numpad on a daily basis, buy an external one and plug int in via USB port. Hardly anyone bothers with the modified one.

You would think that people would be all over this. You get the whole thing replicated literally on the home row, and around it. It ought to make entering numbers easier and faster. But it doesn’t. Why?

I guess the whole point of creating the numpad is to have a dedicated keyboard block for numeric input. It is shaped like a traditional, rectangular calculator face making it easy to use and intuitive. If you lift it up, and map it onto the main keyboard block it loses it’s appeal almost completely. People don’t like their keys to have too many functions assigned to them.

I think it’s the same for the arrow key block. The point of inventing it was to have a dedicated, distinctive group of movement keys. One that is easy to identify and intuitive to use. That’s precisely what the inverted T is accomplishing. Lift it up, and map it onto the main keyboard and you instantly make it less useful.

Vi and it’s derivatives are the only text editor that uses HJKL keys for movement. They get away with it, because their rich feature set makes jumping around in a document extremely easy and efficient. An expert Vi user hardly ever uses HJKL anyway. There are more efficient ways of getting around such as jumping by word, sentence, paragraph, seeking to character, string, jumping to front, middle or end of a line. You only use these keys to move 2-3 characters in a given dimension. Vim makes you work faster, not because it puts directional keys on the home row. It’s because it puts a million of efficient movement and editing commands there. The main problem it solves, is the one where people use arrows way to much to move around the document. The position of HJKL keys doesn’t really matter that much in the long run.

Vim will even let you use the arrow keys in the insert mode if you wish to. This feature is there to accommodate new users, but also because taking your hand of the home row to move around once in a while is really not that bad. As long as you efficiently use Vim’s other features, falling back on the arrow keys when in a pinch probably won’t hurt your efficiency that much.

We have the inverted T block for a reason. It was put on the keyboard to solve a different problem where each application would define it’s own movement methods and keys. We needed a dedicated movement block that could be used system wide, and it had to be separate from the main keyboard block to avoid conflicting with all the existing shortcuts. So they are a good thing to have.

The problem Dr. Azrael Tod alluded to is not really that the arrow keys are located away from the home row. It’s that most of modern editors really suck when it comes to efficiently moving the cursor around in the text. With Vim you can probably get to any point visible on the screen using 3-4 key strokes. This is not possible in most other text editing tools. You are pretty much limited to start of the line (Home), end of the line (End), paging screenfulls of text with PgUp and PgDown and slowly moving the cursor with the arrow keys. Sometimes it is actually faster to take your hand off the keyboard and use the mouse. It’s simple and intuitive but not efficient.

Vi fixes the efficiency problem at the cost of intuitive and straightforward design. The speed comes at a cost of a rich feature set, and dozens of keyboard combinations that must be mastered by the user before he can see a a difference in his typing speed. It’s a fair trade off – and one few other people are willing to make. Most gladly trade this efficiency for intuitiveness.