BlindType — the Amazing Keyboard of the Future 125
kkleiner writes "BlindType has created a new touchscreen keyboard program of the same name that changes size, orientation, and position to match your wandering fingers as they type. BlindType also features some of the most impressive typing correction software I've ever seen. The result is a practical touchscreen interface that knows what you meant to type, even if you make mistakes. Lots of them. In fact, you can type without looking at the screen at all."
Can't believe it hasn't been done (Score:3, Interesting)
Re:Can't believe it hasn't been done (Score:4, Interesting)
Re:Can't believe it hasn't been done (Score:3, Interesting)
Swype is better (Score:3, Interesting)
Re:Gee, that's SURELY new... (Score:3, Interesting)
From what they've said, it appears to be language-independent. It's more to do about interpreting why you touched the screen in a certain place, so what language you're trying to type... it's just a different dictionary to match against.
Re:Can't believe it hasn't been done (Score:3, Interesting)
Same here. I actually prefered T9 over my smartphone keyboard, but I definately prefer the physical thing over any touch interface I've encountered.
Re:How is that novel? (Score:5, Interesting)
I wonder what it looks like if you try to code with it.
for (i=0; i4; ) {lease(r3,i); go( &i);}
becomes:
For I pop Ike. O Pleasure I'll goo You.\n
maybe?
The iPhone kind of does... (Score:2, Interesting)
I figured that the Android/iPhone keyboard would look at finger movements on each key to try to see if you pressed in the center like you wanted that letter or far to the side like you didn't and adjust accordingly much like this
The iPhone keyboard does actually take a lot of slop into account - if you type and shift to accidentally press other keys, the final word will correct based on keys that were almost where you hit, so that you don't have to be totally precise - the correction is pretty good on the iPhone and lets you type pretty fast as long as you trust the corrections.
BlindType is more impressive though, since it's all dynamic and doesn't rely on keys to be in a fixed position - yet seemingly works just as well. The only downside to BlindType for actual blind typing is, I'm not sure how many people touch-type well enough already to use it without a visual reference. But you can simply leave up the keyboard in that case.
Re:Swype is better (Score:3, Interesting)
Swype is great, and comes pre-loaded on many phones [Droid X, Galaxy S series of phones]. Only problem is that it adds to your dictionary anything that you tap out. That includes garbage from URLs like the end of a bit.ly link. Without manually deleting garbage like that, it starts to become unusable.
They should allow you to see and edit your dictionary like you can with T9.
How I would code it (Score:3, Interesting)
Let's think of how they might have designed the algorithm for this. In the videos, it looks like it is treating one word at a time, so let's consider that scenario here as well. I would define the problem as assigning to every possible word the probability that it is the word the user intended. I would use Bayes' theorem [wikipedia.org] to achieve this.
First, assume a prior probability distribution over all words. Words not in our dictionary, and words of the wrong length, we give probability zero. The remaining words can be assigned equal probability or, better, a probability proportional to their frequency in the language. If you want to be fancy, you could have more sophisticated models that knows which words are likely to come after others and such things.
Second, for each candidate word, what is the probability that the user would tap the screen as they just did? A model for this could be that the location of each tap is drawn from a Gaussian probability distribution centred at the intended letter with a known standard deviation and that each tap's deviation from its target is independent of the others'.
Finally, Bayes' theorem states that the posterior probability (the one we want to calculate) of each word is the word's prior probability (from step one) times its likelihood (the probability of step two).
To implement the arbitrary position, orientation and size of the keyboard, we redefine the problem from finding the probability of each candidate word to finding the probability of each tuple (intended word, keyboard position, keyboard orientation, keyboard size). Make it simple; have each element of this tuple to be independent of the other and use flat distributions for all keyboard parameters. To choose the most likely word, you could either pick the word of the most likely tuple or, more correctly, for each candidate word, integrate over all possible keyboard parameters (weighted with their prior probabilities) to get the probability of that word. Likewise, you could introduce the standard deviation of the taps as another element of the tuple, with its own prior distribution.
I suspect this method is a bit to heavy on computation cost and power consumption, so if you cannot find a clever way to do it fast, you might have to cut corners in the rigor (or do something completely different).
(Can I come work for them now?) :-)