Virtual QWERTY Keyboards to be used with Fingers...

[Ortwin Regel]

On 3/1/08, Ortwin Regel <ortwin at gmail.com> wrote:
> 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
>

Well, so I can't count. If you consider that valid 3 square motions
are also moving to another square and then moving back to the old one
(which I didn't above) you end up with 68 for 3*3 and 70 for 2*5.
However, it might make sense to leave these moves out as they might
make continuos motions more confusing. Or they might not, I can't
really tell without having tried it for a while.

In the past few minutes I also came up with a third layout which uses
hexagons. 7 hexagons would be 42 triples or 66 if moving back is
allowed. Sounds very useful, especially since motions would probably
be more natural with hexagons and more continuos motions should be
possible because less fields (7 instead of 9 or 10) are used.

I hope my counts are correct this time... -_-'

Ortwin