Forgot your password?
typodupeerror
Input Devices Portables

BlindType — the Amazing Keyboard of the Future 125

Posted by kdawson
from the do-what-i-mean dept.
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."
This discussion has been archived. No new comments can be posted.

BlindType — the Amazing Keyboard of the Future

Comments Filter:
  • by Darkness404 (1287218) on Friday July 30, 2010 @11:15AM (#33084508)
    I really can't believe it took so long for them to make something like that, 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. But I guess not.
  • by Darkness404 (1287218) on Friday July 30, 2010 @11:27AM (#33084768)
    True, but the phones I've been buying and have really enjoyed are the ones with a retractable keyboard that I only use the software keyboard if I'm too lazy to open up the phone to use the physical keyboard.
  • by msauve (701917) on Friday July 30, 2010 @11:34AM (#33084898)
    You didn't watch the demo video, did you? Adaptation appears to be very fast and dynamic. They don't appear to be doing any per-user adaptation at all.
  • Swype is better (Score:3, Interesting)

    by Karganeth (1017580) on Friday July 30, 2010 @11:44AM (#33085062)
    I can type on swype without looking with ease.
  • by Guspaz (556486) on Friday July 30, 2010 @11:55AM (#33085256)

    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.

  • by Monkeedude1212 (1560403) on Friday July 30, 2010 @11:57AM (#33085284) Journal

    Same here. I actually prefered T9 over my smartphone keyboard, but I definately prefer the physical thing over any touch interface I've encountered.

  • by skids (119237) on Friday July 30, 2010 @11:58AM (#33085314) Homepage

    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?

  • by SuperKendall (25149) on Friday July 30, 2010 @12:04PM (#33085394)

    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)

    by teh31337one (1590023) on Friday July 30, 2010 @12:17PM (#33085596)

    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)

    by Bromskloss (750445) <auxiliary.addres ... l.com ['mai' in > on Friday July 30, 2010 @02:07PM (#33087136)

    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?) :-)

"If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234

Working...