Five Finger Keyboards (2)

So "chording keyboards" are what I "invented" in my blog entry on five finger keyboards. My thanks to all you folk who responded with so many excellent comments. I exposed my ignorance, you diluted it with great feedback. It looks like simple binary encoding is the norm for chording keyboards, giving only 31 combinations with 5 keys. Sequenced chords give 324, and Alex is already exploring that idea. Doubly sequenced chording (the order that you lift your fingers counts) and extended sequences didn't ring any bells, so maybe that small part of my idea was novel.

Encouraged by your response, I have decided to share some of the more trivial details that occurred to me on this topic. Hopefully someone will build one of these gizmos and try them out, it's the only way to tell how well they will work.

Balance

Commenters pointed out that it could be hard to keep the mobile phone steady if you need to press all the finger buttons on one side, but not the thumb button on the other side. One edge of the phone could rest against the base of the thumb, which would help. If any buttons got clicked by the thumb base, they would be ignored since they would not have been enrolled. The two buttons top on either side of the phone could be replaced by a rocker switch for the thumb tip to operate. Many phones already have a rocker switch to control volume. The rocker switch would allow the thumb to express three values (up, down, off) instead of just two (on, off), considerably increasing our code space of 324 combinations. If all 4 fingers are pressing on one edge, the thumb tip could press evenly on both halves of the rocker switch so that it doesn't rock up or down.

Similarly, the thumb might need to press its switch while all 4 fingers don't press their buttons, leading to an imbalance. The finger buttons could be recessed in small saucer-shaped depressions. When the finger tips are straight, they would exert pressure on the rear edges of these depressions rather than the buttons, and could thus counter-balance the pressure of the thumb. When users need to press the finger buttons, they would flex their fingertips inwards.

Repeating keys

There are some buttons, like space, tab, and the cursor movement keys, that we need often need to press repeatedly. If we had to go through a multi-finger sequence each time, we would lose patience very quickly. We could cheat our way round this limitation in the following ways:

• Suppose I must key 5 and 1 (thumb) to get to the cursor movement keys. Once I do, the soft labels next to fingers 2 through 5 all change to the familiar arrow up, down, left and right symbols. I keep key 1 pressed (that's why I assign it to the thumb, it's strong) and release finger 5, its selection job is done. I can then press and release any of keys 2 through 5 any number of times, keeping 1 down, and I get the corresponding cursor movement each time. If I press and hold any cursor key, I start to get automatic repeats, maybe 2 per second to start, speeding up to 8 per second if I persist. Once I release key 1, the soft labels next to keys 2 through 5 revert to their initial values.
  
  
• Keys 4 and 1 might give me the 4 tab keys (up, down, left, right). What, you didn't know about tab up and tab down? You must be using a keyboard with a small number of combinations!
  
  
• Similarly, any terminal key (i.e. one that finally selects a character) could give automatic repeats if held down long enough, maybe one second. This delay would have to be customisable by the user, since while we're learning how to use these things we'll be slow. Or maybe the phone could measure the speed with which we press key combos and adapt automatically. Why not, it has nothing better to do while waiting for keyboard input.
  

Remembering key sequences

We'll probably end up with learned committees meeting in Geneva to argue about which key sequences should lead to which characters. As qwerty as shown, first horse past the post gets the prize. We need to think about this problem before some arbitrary and clunky scheme gets adopted by default. Here are some rough ideas. I hope that they will provoke lots of thought and discussion, and get improved out of sight.

We need to group keys into related sets so that people find it easy to remember where they are in our code space. The alphabet and numerals are easy because they have a natural sequence. Accented alphas like à,á,â,ã,ä, and å could be located just a bit deeper in the code tree than their unaccented counterparts. Once you reach a, for example, the accented variations could appear on other keys. Since you could use up a few keys and fingers reaching the letter you want, we could adopt the same cheat that we did for the cursor keys; once you reach the bare letter, you only have to keep the last key that you clicked down, and the others keys all become available to select accented variations. If you release the last clicked key without clicking any other key after depressing it, you get the bare letter.

Here are some other possible logical groupings of special characters:

• Punctuation: . , ; : ? ! " '
• Arithmetic: + - * / ^ ( ) = != < > =< >= !
• Brackets: [ ] { } ( ) < >
  

Yes, some characters like ! and ( ) appear in more than one logical group. Why not? We have a nice big code space, unlike those clunky old qwerty keyboards

Modal spaces

I have suggested a couple of times that you may arrive at a place in the code tree where you can release all the keys that you pressed, except for the last one, and all the other keys get new functions and new soft labels. The cursor movement keys could fall in one such space, and the tab keys another. Paging the display up / down / left / right is another obvious candidate. This mode is different from usual, where you keep all keys that you have pressed down till you get to your final destination. Having different modes could lead to confusion. At the very least, we could use clues like different soft label background colours to indicate the mode that each key is currently in, e.g.

• a-i may denote a soft key that we have yet to click
  
• a-i may denote a soft key that we have already clicked
  
• á-å may denote a soft key that we have already clicked, but which now has a new function
  

Even today's mobile phones have input modes, so the users shouldn't find the concept too alarming. When you're capturing a new contact and you move the cursor to a phone number input field, the phone usually switches to numeric keyboard mode, while when you're entering a name, it's in alpha mode.

Happy imagineering, folks, we may be inventing some small part of the future. Which, as Alan Kay remarked, is a lot easier than trying to predict it.