Sunday, April 3, 2011

Idea #5: Mobile Keyboards

So I recently got a notion ink adam. As gingerbread, the first tablet-friendly android OS is not out yet, I get to play with 2.2, a phone style one.

What I found is a terrible lack of good keyboards.

For my droid X, swype is amazing. Its among the best in just typing out words, and the feature it is named after, swype is great. A little memory/cpu intensive, but well worth it.

Apparently, swype is a very low level application. Probably to cut down on the cpu/memory intensiveness. So the "drivers" in the program don't work for my OS (it is a custom ROM-- the default that came with the Adam is pretty terrible). I'm pretty positive there are drivers out there that work, but they seem so afraid people will steal their software its not available.

Sadly, they are right. I would mod the hell out of any program they offered open source. Here's why:

  • A tablet is not a phone. Having 10 viewable inches is much different than having 3 (or at least that's what she said). I should have room for a number pad, punctuation, and the swype keyboard (if you're going traditional).

  • You shouldn't target specific hardware with your code. If it doesn't work on any android device, don't bother. The maintenance cost is incredible.

  • The keyboard user interface should depend on pixel resolution, page resolution, touch sensitivity, availability of another keyboard, availability of voice, and user overrides. I'm not suggesting the user should have to customize it in order to get it to work (the linux approach). I'm suggesting have smart defaults and allow the user to override them.

  • The technology for determining the word from a swype path shouldn't be coupled to the rest of the keyboard. I sat down and figured out how I would do it (bounding boxes around keys, parse your path weighing circles first, then turns, then straight throughs, parse your dictionary into path trees with 100% weights, add some path trees that skip various letters with less weights, take the user path and traverse your network. Probably also optimize based on the likelihood of straight throughs-- I've noticed skype puts a HUGE weight on circles.) Its complicated, complex, and shouldn't be bundled with the rest of your application! I only hope it separate on their source side! With this technology alone, I could have custom key layouts for games, programming ides, dynamically changing keyboards (with some performance loss), etc. Instead I have to get one complete package built around the piece that would be a pain in the ass to code-- I'd be more than willing to pay for that complex part and its API and forgo the existing!


Now onto the idea. I'd love to have a keyboard where everytime I type a letter, the only available letters are the ones that make a dictionary word (by default-- you can type one out instead and it gets automatically added to the dictionary). Once you get down to 3 or 4 choices, it just displays those. Common endings like "'s" could be listed on the right as well.

There's a few other ideas I had on this, like a circular keyboard layout based on proximity in your dictionary weighted with how often you use the word (optimal for swype). It'd be cool if the letters slowly moved over time to match your vocabulary. It'd have to be slow though, like a pixel a day.

But I have limited time and I likely won't finish this one. I have another post of touch screen user interfaces that I really want to do.

No comments:

Post a Comment