[SHR] illume predictive keyboard is too slow

[Carsten Haitzler (The Rasterman)]

On Tue, 03 Feb 2009 18:28:49 +0100 Helge Hafting <helge.hafting at hist.no> said:

> Carsten Haitzler (The Rasterman) wrote:
> [...]
> > yeah. this is one reason i want toi understand how it works without ø, æ
> > etc. - one day there will be a phone with a kbd.. and it wont have a
> > version per language because the # of users in norway are too small to
> > warrant a special production run for them - same for germany, france etc.
> > etc. - until you have the sales numbers to justify that.. you need a way to
> > either work around it by ignoring them - or have software correct it. so
> > software that works eventually with a hw kbd and inserts the right ø, æ
> > etc. based off normal a-z typing... would be useful.
> 
> If we someday get an open phone with a keyboard, then I hope they are 
> smart enough to make enough keys. (In my case, both the q row and the a 
> row needs 11 keys) No problem if the keytops are painted with an english
> layout - I can paint. As long as they don't let the top row end in "p"...
> 
> Surely, when there is a kayboard anyway, a couple of extra keys won't
> cost much. Not if they are on all phones, instead of only "adapted" 
> ones. The americans can use the extras as application hotkeys.

oh its not the extra keys - its the variations in production. the moment you
have a variation (with different # of keys, different layout of them) you have
a change in plastic mould - thats costly (if doing things via molds a new mold
costs upward of $US 60,000-100,000 or more). so if all you have is 500
customers in that country - that'd be an up-front cost of maybe 100k to just
supply that market, and then for 500 people - IF you sell that many, it'd be
$12-$20 extra per unit in costs. to cover the risk of not selling all your
production you may have to raise retail prices by $50-$100 more over the "mass
produced" item. now imagine its only 100 customers in that region, or 50.

just a change in printing whats on the keys is not free. software keyboards are
by far the cheaper option :) but if a hardware keyboard is there - changes of
lots of variations per locale being around, unless you sell the kind of volume
nokia do, is slim to none. :(

> Another approach - let the "keyboard" be an extra touchscreen that is 
> wide - in the shape of a keyboard. Then we can program the kayboard like 
> we can today. Of course this keyboard-screen can be cheaper - 
> monochrome, low resolution, maybe no backlight.

of course! i've actually mulled this idea with a clear plastic overlay that
contains the mechanical contacts (done in a way that they dont obscure the
middle of the key) and just have a normal lcd under it... have an extra lcd or
just a bigger single lcd shared with the main one... :) thus a
soft-hard-keyboard happens. as long as the # of buttons are ok (you can cover
most use cases with the buttons there) then software can vary the "painting"
and "layout" runtime. this might be the best middleground solution for a
hardware keyboard for when low volume productions limit the ability to have
custom molds/paint runs due to the small customer bases per locale.

it sucks. but "english" is the lowest common denominator and thus most things
tend to be built to support it - as   it tends to keep more people happier
than  some other setup. if there was enough volume to make enough units for a
particular language/locale/country - it'd be different. :)

> > i just want to understand the constraints of the languages i don't know -
> > and how they are used. it gives me insight into how to solve the problem on
> > a wider picture. thanks for the info.
> > 
> Glad to be of help.
> 
> Helge Hafting
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com