Virtual QWERTY Keyboards to be used with Fingers...

[Carsten Haitzler (The Rasterman)]

On Fri, 29 Feb 2008 18:50:14 +0100 "Marco Trevisan (Treviño)" <mail at 3v1n0.net>
babbled:

> > What you're talking about already exists - the qtopia guis have such a 
> > predictive qwerty keyboard that works - maybe it's possible for you to 
> > give it a try or find a video.
> 
> No it isn't the same thing... I meant reducing the size of each 
> key-button keeping it proportional to the possibility of being pressed 
> to complete a word (ie: It's hard to find a "r" after "hel", but it's 
> more probabile that next char will be a "l" for example, so why showing 
> "r" and "l" of the same size, on the keyboard?!)
> Predictive keyboard acts on words, I'd act on input (keys).
> Have I been more clear?

i would disagree that changing size is good - don't change the UI view. you
don't have time to see it and react anyway (do you really press the 'h' remove
your finger so u see the whole keyboard, then press the 'e', then remove again
and inspect the keyboard, then press 'l etc. etc.?). you likely have 0.2 to
0.5 or so seconds between presses. don't change size. simply have fuzzy
correction. your keyboard has a layout:

qwerty...
 asdfg...
  zxcv...

i WANT to type "waste".

i press w - but really my finger may easily hit q,e,a or s - maybe even r, d, z
or t. as such every key has a center point. my finger will try and press
somewhere close to this center, but may fail and be closer to something else.
distance from the center point of a key will be the probability that you wanted
that key. for practical computation u need to have a cutoff of X pixels away
and ignore any possibilities greater than that, so then u press another key.
now u are close to 1 key - but also to others. so as you type you get something
like (a key, then a closeness value from 1 to 9 lets say, where 9 is the
closest. closeness is just a measure of distance - inverted):

press 1: w7q3e4a2s3d1
press 2: a6s4d1q4w3e1z3x2
press 3  s4a5d2q3w4e2r1z3x1
press 4: t8r2y3d1f2g1
press 5: e7w4w1r5t2a3s4d2

every time a "space" is entered (could be a key - or ala qt kbd a stroke to the
right) the word buffer resets. so as you type, each press builds a list of
probable targets. you order each entry from closest to least. so the above raw
data will at pres 5 give the following list of "matches" (i'll shorten it for
this email):

wadte
waste
wawte
wsate
wsste
wswte
...

(you get the idea). and so on down to the least probable. yes - you need to
type the whole word, BUT as you type a word, it adjusts the probability of some
key presses being wrong/off based on matching it against a dictionary of
commonly used words (including a user dictionary so it will learn). in this
example the most probable input was #2 in the list. each combination of the
above letters can be assigned a probability value based on the closeness values
per letter in the combination (the higher, the better) and simply do a lookup
of the top N probable combinations and those that exist as a whole word in a
dictionary are the best matches, those that match the start of 1 or more words
are also next in line as being probable. in fact the dictionary would also have
a probability value for each word in it based on historical usage (input from
english test sources for example).

with this kind of scheme:

1. it's plain qwerty. nothing new to learn. simple.
2. it fixes your entries (yes - we can add unix commands in $PATH to the
dictionary etc. etc. so shell users get their commands predicted) based on
probable matches
3. the ui is static - so easy to get motor memory in your fingers working.
4. requires either a full XIM/SCIM/UIM etc. integration system where the vkbd
acts as the SCIM/UIM/XIM front-end so it is possible to enter whole words and
correct as you go, OR you need to fake it via the X Test extension and fake
fixups of words with backspaces, or buffer input until a space then output a
series of key fakes. the 2nd method is simpler and universal so apps/toolkits
that don't do XIM/UIM/SCIM integration work, but it is more limiting. it is
also much less work.
5. the keyboard is a simple set of buttons. it'll be trivial for having
multiple layouts (one for text messaging, one for using the shell/terminal with
more symbol characters, etc. etc.( as it can just be a config file. the vkbd
just provides a little switcher button to switch between layouts.

i'm definitely leaning this way. of course i wouldn't and don't preclude the
idea of any other keyboard styles/types as everyone is discussing here. one
size does NOT fit all. i just want to do something a little more conservative to
start with as it's tried and tested, familiar and known to work well at least
with a stylus. correction based on dictionary lookups is an added finesse to
work around fat fingers :)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>