Virtual QWERTY Keyboards to be used with Fingers...

Ortwin Regel ortwin at gmail.com
Sat Mar 1 22:31:15 CET 2008


On 3/1/08, Sean Moss-Pultz <sean at openmoko.com> wrote:
> On 3/1/08 Carsten Haitzler (The Rasterman) wrote:
> > On Sat, 01 Mar 2008 08:47:31 +0100 Karsten Ensinger
> > <karsten.at.openmoko at onlinehome.de> babbled:
> >
> > > > Sorry to jump into the thread this late, but I am wondering
> > > > if you already examined the following Wiki-Link?
> > > > We had a very extensive discussion about text input running
> > > > on the community list several months ago.
> > > > Nearly all proposals were documented on the following Wiki:
> > > >
> > > > http://wiki.openmoko.org/wiki/Wishlist:Text_Input
> > > >
> > > > My personal favourites are the Quickwriting (there is even
> > > > a java demo available) and "another text input" (although
> > > > it seems to be another implementation of this more moko-like
> > > > implementation: http://www.micropp.se/openmoko/splash.html ).
> > > >
> > > > If I remember correctly, "all" participants of the discussion
> > > > came to the conclusion, that a regular qwerty keyboard is not
> > > > sufficient no matter how clever you "pimp" it, due to
> > > > restriction of precision of finger typing and lack of screen
> > > > space.
> >
> > i disagree. reality of the qtopia predictive keyboard and actual use
> > of it
> > disagrees. talk and theory is fine - actual code that works is
> > disagreeing.
> > users of that code are disagreeing.
>
> I have to agree with Raster here. Trolltech did an amazing job on their
> QWERTY (onscreen) keypad. I highly recommend you trying it out on the
> Neo if you haven't already. Personally, I think it's the best touchpanel
> keyboard on the market now. Bar none.
>
> Sean
>

Maybe it is. I still hate it and any other form of predictive text
input I have used so far. That doesn't mean I want to prevent anyone
else from having it. I can understand that some people are happy with
it and it would probably be a good idea to use it as the default input
method. What I want is an alternative I can very easily switch to.

We don't want the perfect input method because it probably doesn't
exist. Let's agree on disagreeing and try to figure out a base set of
alternative input mechanisms that should be included in Openmoko as
well as making it easy for the user to install more of them.

Some options I can think of that would find an audience:
-Predictive QWERTY, maybe with different prediction modes (dictionary,
closeness, combination, none)
-Multitap 3*4 standard phone layout (maybe with optional prediction if
patent issues can be avoided)
-Dasher
-A sliding method. My favorite, even though I never used one and don't
really know which of the ideas floating around will be the best one.

The next thing to consider is size. There are basically two options:
-Use about 1/3 of the screen so that the running program is still
visible. The problem with this is that the space is very small and
some of the methods above would not work at this size or only work
with a stylus.
-Use pretty much the whole screen while inputting something and close
the input method afterwards. This worked very well on my Palm device
for two thumb landscape QWERTY input but that screen was twice as big
as the Neo's. It is my prefered way of doing input because I don't
need to see the program while typing. I only need to see about two
lines of the text I last typed.
For all methods where this makes sense, both sizes should be available.


Last, let me describe my imaginary perfect input method:
The input area is divided in 3*3 squares. A letter is written by
starting on a defined square and moving over one square to end in a
3rd square. So every letter is a combination of 3 adjacent squares
drawn in the right direction.
Now here is what makes this fast and thus great: If the next letter
you want to draw starts on the square you just ended on, you simply
continue your slide and add two squares. This way, many letter
combinations and even whole words could be written in one continuos
sliding motion.
There are 44 possible combinations (if I counted right) which should
be plenty if we plan for a shift-combination and a numbers/special
characters-combination.
The character layout shouldn't follow any alphabet or QWERTY logic but
instead be entirely based on language. The reason is that it would
require learning from the ground up anyway so it should be as fast as
possible once you have learned it.
The small version for only taking up 1/3 of the screen would be
perfect in 2*5 which would also result in 44 combinations (again, if I
counted them right...).
Feedback and actual implementation of this would be very welcome! In
fact, I offer 30 Paypal €uros to the first person to make this work on
my Neo (meaning it has to come with simple installation instructions).

Ortwin




More information about the community mailing list