Monday, February 15, 2010

Adaptive keyboard layout

This idea came up as a result of a lot of ruminations on data compression, and more specifically on huffman encoding.

Now, I'm a QWERTY touch typist. I can get by just fine on a blank Das Keyboard, if you give me a QWERTY layout. I realize, of course, that a lot of folks prefer DVORAK; having your more-frequently-used keys on home-row has to be great.

Even as a QWERTY touch-typist, I think there may be room for improvement. Consider the advantage Dvorak offers, with the most-frequently-used keys on home row. That only works under an assumed use case, which may or may not be accurate depending on anything from your locale to how you normally use a computer.

Let's say your keyboard kept a running record of your last twenty-thousand keystrokes. Every time you pressed a non-modifier key, it would push that key on to the queue, pop the twenty-thousand-and-first key off, and then run the entire buffer through huffman encoding.

The keyboard now has an internal representation of which characters you use most frequently, in the form of a huffman tree. Because it knows its own physical form factor, it can estimate the cost of each key on the board based on how much travel there is from home row to that key.

Simply sort the key cost in ascending order, and then walk through the huffman tree, assigning each character encountered to the least-cost key remaining.

You now have a possible keyboard layout optimized specifically for you and your use case.

For me, what I'd like the keyboard to do (at that point) would be to sit tight unless it discerns that a cost reduction threshold would be crossed; say, 10% cost reduction compared to my current activity and use case. At that point, it should beep at me, or flash a little light. Once I acknowledge, the keyboard layout would change.

Of course, something like this would depend on a visual feedback mechanism; I would have to be able to quickly see what the keys were remapped to. Under normal circumstances, the rearrangements shouldn't be much, and most of the layout would remain the same. I should only need to note that two or three keys (not key pairs, mind you) changed places.

I'd want to switch away from typing my password in, though; someone could get a lot closer to guessing it by noticing one or two strange characters that are closer to my home row than for most.

There's also the round-robin key buffer, which I think may be necessary for preventing old keystrokes from polluting the huffman tree. Perhaps simply randomizing which key in the buffer is replaced would be sufficiently optimal for the purpose, rather than storing keystrokes in order.

I think I could get used to a keyboard like that.

No comments:

Post a Comment