Openmoko on Design

[Al Johnson]

On Wednesday 30 July 2008, Marek Lindner wrote:
> On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote:
> > Something as simple as a keyboard button -- well, users were
> > complaining about its lack very quickly. If the design team were also
> > users, then they would have insisted that the error be fixed.
>
> They _are_ users and kept complaining all the time why we have to push the
> damn button. The software should know that we want to type something.
> Yes, they are no engineers but I try to see that as a plus not a burden.
> Their perception is to have software that gets invisible while enabling the
> user to get the real job done and not the other way round.

I agree with everything you say here. The keyboard should just appear when I 
want it and disappear when I don't. The absence of a manual override means 
that whenever it gets it wrong I can't correct it, the worst case being when 
I need to enter something but the keyboard doesn't appear. Conversely the 
presence of a manual override causes no problem even if it is never needed.

The keyboard failing to appear is not a hypothetical scenario. Without manual 
intervention minimo was unusable because the keyboard didn't appear when the 
cursor was placed for URL entry. This is likely to be an issue with other 
apps that don't have a specific openmoko port, and we shouldn't have to 
create such a port just to use an otherwise capable app on openmoko. Other 
issues include the keyboard appearing when an edit field has focus although I 
don't want to edit it, keyboard appearing and disappearing frequently if a 
form contains mixed input types, or appearing over the top of the field to be 
edited. The field having focus although editing is not required is probably 
impossible to detect because the answer depends on the opinion of the user at 
the time.