Virtual QWERTY Keyboards to be used with Fingers...

[Kevin Dean]

Having fussed myself about the change from QWERTY to T9, what raster
is planning solves the issue. I actually prefer non-qwerty as long as
there's some kind of predictive input that reduced the number of key
presses.

I'm quite excited to see what comes of this. Any idea where on this
list of things to do this falls?

On Sun, Feb 24, 2008 at 4:14 AM, The Rasterman Carsten Haitzler
<raster at openmoko.org> wrote:
> On Sun, 24 Feb 2008 04:53:34 -0300 "Gustavo Sverzut Barbieri"
>  <barbieri at profusion.mobi> babbled:
>
>  i intend to first give a predictive qwerty keyboard a go - why? well qwerty is
>  familiar and requires only 1 press per letter. it seems the qtopia predictive
>  kbd works pretty well on the gta01 and gta02 - so now it's a cvhance to improve
>  on it wiht configurable layout, keys etc. etc.
>
>
>
>  > On Sat, Feb 23, 2008 at 10:43 PM, "Marco Trevisan (Treviño)"
>  > <mail at 3v1n0.net> wrote:
>  > > Gustavo Sverzut Barbieri ha scritto:
>  > >
>  > > > On Sat, Feb 23, 2008 at 6:49 PM, "Marco Trevisan (Treviño)"
>  > >  > <mail at 3v1n0.net> wrote:
>  > >  >> I'm really excited waiting for the Freerunner to be available to the
>  > >  >>  public, so I'm looking around searching the resources I'll need more.
>  > >  >>
>  > >  >>  I think that one of the most important thing when it comes to the daily
>  > >  >>  phone use, is the virtual input device that imho it should be
>  > >  >> completely usable with *fingers* (the stilus isn't portable!) giving
>  > >  >> the users the same confort that the key-based devices give.
>  > >  >>
>  > >  >>  To get the best usability and speed while writing I do think that is
>  > >  >>  needed a QWERTY style keyboard (If you've ever tried a blackberry you'd
>  > >  >>  know what I mean).
>  > >  >>  Actually there are two alternatives: the QTopia predictive keyboard [1]
>  > >  >>  that works quite well if used with a good dictionary (also if it should
>  > >  >>  be improved for writing new words), and the iphone-like virtual
>  > >  >> keyboard [2] that is already available for N800 and that should be
>  > >  >> easily portable to Openmoko too.
>  > >  >>
>  > >  >>  Any other? If there are some others I don't know them, but the
>  > >  >> solutions I've tried using the Openmoko GUI with qemu aren't so good
>  > >  >> imho. I think that some virtual qwerty keyboards should be developed
>  > >  >> also considering that Openmoko supports the landscape view (not using
>  > >  >>  accelerometers yet, but it does it!) and that mode could/should be used
>  > >  >>  for writing, so we could use more space to put keys in!
>  > >  >
>  > >  > Hi Marco,
>  > >
>  > >  Hi Gustavo!
>  > >
>  > >
>  > >  > I disagree on this, QWERTY keyboard is a no-go for OpenMoko. I'm using
>  > >  > iPhone for about 2 months and I wrote the one you cited, so I think I
>  > >  > have some knowledge about it :-)
>  > >  >
>  > >  > Reasons:
>  > >  >   - iPhone vkbd is not so great, even on iPhone hardware. The
>  > >  > landscape version is almost usable, but the vertical is bad - but
>  > >  > acceptable, see below.
>  > >
>  > >  Well, I've tried the iPhone virtual keybard (not only on the iPhone but
>  > >  also in the iPod touch, that it's the same) and it's not so bad imho...
>  > >  Of course the vertical view is really better than the landscape one but
>  > >  considering how I use the T9 based phones, I'm really a much faster
>  >
>  > I guess you mean the other way around, using keyboard in landscape
>  > mode (like iPhone browser)
>  >
>  >
>  > >  writer using this kind of keyboard, also if sometimes I do mistakes.
>  > >  That's why I think that the pressure should be compared char-by-char
>  > >  with a dictionary!
>  > >
>  > >  >   - iPhone has no sunken screen, with borders that make you loose many
>  > >  > physical space. This happens on Maemo devices as N800 and it's painful
>  > >  > in Canola and that vkbd mockup I wrote. I do not have a OpenMoko
>  > >  > hardware yet, but I suspect it will be even worse, as the screen is
>  > >  > more high dpi and smaller in physical size.
>  > >
>  > >  Yes, that's could be true, but in landscape view I think it could be
>  > >  usable in Freerunner too...
>  >
>  > I dare to say it's not even without trying. Our experience with Canola
>  > is that you waste more than 30px in each edge due the border, in
>  > OpenMoko it should be even more. Given that each click area must be
>  > around 100x100 to have good hit rate, then you guess you'd not have
>  > much space to fit around 10 keys on 1 row.
>  >
>  >
>  > >  >   - iPhone has a capacitive (not pressure based), VERY sensitive touch
>  > >  > screen.
>  > >  >   - Running my prototype on N800 was not so bad because the screen is
>  > >  > huge and you have plenty of space, but you often miss some clicks due
>  > >  > the pressure based touch screen.
>  > >
>  > >  I don't know how it is in Freerunner, but there's no software control on
>  > > it?
>  >
>  > it's a physical limitation: the screen need pressure to emit hardware
>  > signals, while the capacitive just needs contact, you barely need to
>  > touch in order to produce hardware signals.
>  >
>  >
>  > >  > That's why I think it's not a good option. We better keep with some
>  > >  > kind variation of T9. I already talked to rasterman about that and he
>  > >  > have a great idea of a key matrix (3x3 or 4x3) that would behave like
>  > >  > number keypad, but the labels would weight the key with greatest
>  > >  > probability of being used (based on dicts, T9 like).
>  > >
>  > >  As I've said, I don't love T9 neither 9x9 keyboards as they're commonly
>  > >   meant (the ones used for years by key-based phones) maybe Lars
>  > >  Hallberg keyboards [1] are a little more usable...
>  >
>  > I think it's not much diferent from T9, just a implementation that
>  > utilizes software capabilities better.
>  >
>  >
>  > >  > The major problem with T9 is it takes time to train and have it behave
>  > >  > fine for you. One option would be to provide a service (pc, web or on
>  > >  > the device itself) to feed with personal texts (mails, docs, ... text
>  > >  > you wrote) so it will optimize for it.  Other improvements could be
>  > >  > abbreviations and maybe mode selection to use even more optimized
>  > >  > dicts (language based and terms based, like "polite", "3733t speech",
>  > >  > "development"...).
>  > >
>  > >  This is a good idea...
>  > >
>  > >
>  > >  > What we need to do is implement something fast, with good feedback and
>  > >  > users will get used... people already got used to write "graffiti",
>  > >  > T9, ... and even QWERTY... they will learn yet another, just make the
>  > >  > behavior predictable and help the user whenever possible.
>  > >
>  > >  Of course, but the one I feel better with (and with I'm more productive)
>  > >  is the QWERTY way :P, maybe because I'm using it for too many years! :P
>  >
>  > yeah, mee too, but physical space is an important issue we have to deal
>  > with :-/
>  >
>  > --
>  > Gustavo Sverzut Barbieri
>  > http://profusion.mobi - Embedded and Mobile Software Development
>  > --------------------------------------
>  > MSN: barbieri at gmail.com
>  > Skype: gsbarbieri
>  > Mobile: +55 (81) 9927 0010
>
>
>  --
>  Carsten Haitzler (The Rasterman) <raster at openmoko.org>
>
>