OpenMoko - SoC--- is there a mentor?

Karsten Ensinger at
Sat Mar 24 19:52:09 CET 2007

Hi Guy,

following your explanation, I will get "c", "z", "g" and "q" as
characters when tapping on "1", dragging to "3" and dragging back
to "1". When I want to have "c", "g" and "q", I have to tap on
"1", drag to "2", lift the finger, tap on "3" and drag to "1".
If I want to have "c", "g" and "c", I have to tap on "1", drag to
"2", lift the finger, tap on "3", drag to "2", lift the finger,
tap on "1" and drag to "2".
Depending on the needed character sequence, your "new" concept
can result in the same amount of taps and drags as the original
"finger splash" concept.
So everthing depends on the intelligent placement of the characters
on the keyboard layout.
Let's come to the usability aspects.
If I look at the "finger splash", the tapping on "1" will result
in a button overlay which will hide the complete "2" at least
(maybe also some parts of "3", depending on size). So there is no
way for the user to see what is on the right side of the "2"
button. This leads to a drag into the blind to get the "z".
This seems to me as not user friendly enough to get accepted
widely. One has to remember the whole keyboard layout in mind
while typing.
This would lead to the idea to NOT enlarge the buttons when one
taps them. The user would be able to see what he gets, when
dragging to the next button.
Unfortunately the size of the buttons can't get big enough to
hold characters with an easy readable fontsize due to limited
physical screen size. This seems to be a dilemma. Making the
buttons bigger means less buttons per row and column, means
less benefit from the "dragging feature".
Maybe the KISS pattern matches here (KISS = Keep It Small and
Simple). Although the ability to type more than one letter with
a single stroke has charming aspects, the learning curve of the
keyboard usage should be as steep as possible and to me, the
current concept seems to be to much in need of an explanation.
What I have only shortly mentioned before, is the fact that you
have to analyse the inherent syllables of the language the user
will use. You have to place the characters in a way, that one can
type as much words with one or two strokes as possible. So the
keyboard layout will vary from language to language.
What about users using two different languages at the same time?
They will have to pay the price for this. One language will
fit perfectly to the keyboard while the other will not (most
of the times).
I myself will definitely use german and english at the same
time every day, and I think most of the non-english natives
will do the same. German and english do not have a lot of
syllables in common when counting the frequency with which
they appear in day to day communications vocabulary.

But whatever I comment here, it's my personal and therefore
biased opinion. I do NOT want to discourage you to start your
own implementation, because an old man think he found a fly
in the ointment.
Take my comments as food for thoughts and nothing else.


--- gsilva.85 wrote:
> Karsten,
> you are right except for one thing on my idea: you are considering only 
> a row and only a drag from left to right (or right to left..) in this 
> case only 2 characters will be draw. But think if you press the '1' drag 
> to '3' and drag again to '1' we got one press with four characters at 
> output but on finger splash to produce 4 characters (in the better case) 
> we have to press 4 times. And you can drag not only to left or right but 
> up, down...
> did you understood?
> I thought to adapt this to fingers splash: when the 'splash' appear if  
> you continue dragging over the buttons of the splash it possible 
> continues  writing that chars (like the speed script concept) but even 
> with this we stay limited to only 7 different chars in a drag...
> please fell free to comment...
> thanks
> Guy
 > [...]

More information about the community mailing list