Searching for a more efficient onscreen keyboard
Because I run Boxee off a Mac Mini, my main interface with the software is the Apple Remote. As a result, whenever I want to search for a program, I’m relegated to keying in names letter-by-letter via the onscreen keyboard. This, we can all agree, is a pretty significant pain in the ass. I know Boxee and TiVo agree—that’s why they’re releasing new remotes with built-in keyboards. But at least for Boxee, not everyone who uses the software is going to have the new remote. So it’s worthwhile to explore how to make the annoyance of onscreen text input into less of an annoyance. Here’s my take.
Boxee’s current setup is an alphabetical keyboard laid out in a 6x5 grid. You key a letter, then move on to the next. This is the classical way to approach the problem. Sure, some use QWERTY and others play with different grid sizes, but all approaches are fundamentally linear, and that’s not ideal. Ideally, you’d develop a new keyboard layout optimized letter distances. But people have neither the time nor desire to learn a new keyboard layout (exhibit A: the Dvorak keyboard).
Current Layout

This is Boxee’s current layout. The * is where you enter into the field. ‘_’ is spacebar. Excel helps to quickly map distances between letters, measured by number of directional clicks required: A to B = 1; A to H = 2; P to S = 4. And so on. Now let’s assume that it’s usually enough to enter 5 letters to locate a show (i.e., after 5 letters are entered, the list of possible shows is down to one screen’s worth). Counting the clicks required to key in the first 5 letters of a few Boxee favorites—Lost, The Daily Show, How I Met Your Mother, Dollhouse, Caprica)—it takes an average of ~3.4 clicks per letter (stdev of 0.8). But that’s a small sample. We can get the global average from the distance map (spoiler: it’s 3.4). Seems pretty good.
So my two hypotheses for improvement: 1) separate the vowels; 2) recenter the cursor after each click.
Option 1: Separate the vowels
The Dvorak keyboard separates vowels from consonants; this makes intuitive sense—vowels and consonants represent two groups of characters that tend to alternate in words. At least one sufficient explanation for Dvorak’s failure to catch on was the hardware entrenchment of QWERTY. That dynamic still holds. Clearly, radical changes in key placement won’t fly—people know QWERTY and alphabetical, and that’s a state of nature. But if we drop the vowels to their own line and leave the consonants in alphabetical order, the result doesn’t offend our keyboard schemas all that much.:

Using the testing method described above, we get a sample average of 3.6 clicks per letter (stdev of 0.8). So, yeah, that’s worse. Well…it was a fun hypothesis.
Option 2: Recenter the cursor
When you play whack-a-mole, you keep the mallet centered; you don’t leave it on the last mole’s hole while you wait for the next one to pop up. Applying that logic here: what if we kept the alphabetical layout and set the cursor to recenter on ‘O’ after each letter input? With this new condition, average clicks per letter decreases from 3.4 to 2.3 for the sample (2.6 globally). Stdev decreases from 0.8 to 0.3. That’s a ~33% more efficient process with 1/4 the variability—by definition, a better process. So long as you believe the efficiency gains outweigh any confusion, then this represents a better process. If it takes 20 seconds to enter a title, and a user averages 5 title entries per day, the amount of time that user spends inputting titles in a month drops from 50 to ~33 minutes or about the same amount of time it takes to watch a TED talk. That’s real time.
Charts!
Here’s a probability distribution of the global key mappings:

More efficient = larger lumps further to the left. You can see that recentering yields the best distribution of direction key presses per letter. And I believe (though I could be wrong) that users would adapt almost immediately to cursor recentering. If that’s true, this tweak worth considering. Does it make a huge difference in UX? No. Will it make lovers out of haters? Nope. But it makes the UX more pleasant at minimal cost. To me, that’s always worthwhile.