Finger text input idea

Werner Almesberger werner at openmoko.org
Fri May 4 11:43:25 CEST 2007


While lamenting the lack of an all-finger environment in OpenMoko,
the following idea sparked in my mind (nothing of this is
implemented):

A wheel with seven segments and very simple gesture recognition
might do the trick. It would overlay most of the display area,
but with clever alpha-blending (or equivalent but computationally
cheaper effects), one may be able to see both the wheel and the
application information.

Here's a draft layout:
http://www.almesberger.net/misc/inw.ps

I call the central circle "O". Tapping it yields a space.
(And yes, the circle is probably a bit too big.)

Letters are entered by either tapping a segment in the ring, or
touching a segment in the ring and then moving to either an
adjacent segment or the center. E.g., tapping A yields A.
Touching A and moving to U yields B. A-O (center) is C. A-E is D.

Numbers (and Y and Z) are entered by starting in the center, then
moving to the ring and one segment to the side. E.g., O-E-A is 2,
O-E-I is 3, etc.

I don't use the O-segment sequences, mainly because I lack space
for labeling them. Something that would work without or with only
minimal labels would be cursor control, e.g., left = O-U,
up = O-A, page up or home = O-E, etc.

The diagonals are labeled on the inside of the center. E.g.,
Enter = U-O-I, Shift = E-O-Q, etc. Esc is an inside joke :-)

I don't use ring-center-ring moves that aren't diagonals, e.g.,
U-O-E, A-O-Q, etc. Perhaps someone could think of something nice
to do with them, too. Narrow turns, e.g., U-O-Q, may be difficult
to enter properly.

Fn changes to a different layout. Shift shifts upper/lower case
and also changes digits to special characters. I was thinking of
0 -> ., 1 -> ,, 2 -> :, 3 -> ;, 4 -> ?, 5 -> !, 6 -> +, 7 -> -,
8 -> ", and 9 -> '.

The layout is for quick learning but low efficiency. By arranging
letters by frequency, one could probably improve efficiency, but
it would be harder to get one's bearings. Not sure what's best.

This could be implemented as two parts: a layout manager and the
gesture recognition. The latter would ideally have a configuration
file describing all the actions, a bit similar to a keymap. Shift
states could even be scripted instead of expressing them through
qualifiers.

E.g.,

base_map = {
    E-O-Q -> {
	load_layout fn.wheel; /* or pre-compute layout images ? */
	A -> {
	    key "A";
	    base_map;
	}
    }
}

A gesture in progress could be cancelled by crossing any segment
boundary twice in the same sequence, e.g., to undo a "Delete", one
could Q-O-E-*oops*-O. Unmapped sequences do nothing.

Finally, just touching the wheel for, say, > 200 ms without crossing
a segment boundary could hide the wheel, giving a clear view of the
application, until the touch screen is released again.

Some layout issues: the labels in the center may be a bit confusing.
I'm also not quite sure whether it's better to place them next to
the first or the last segment. Since there are still a few unused
simple sequences, one could also consider just making them
bi-directional. Also, the "side" letters, B, D, F, H, etc., are
printed too close to the center, which makes one intuitively move
towards the center, not the side.

The layout could also be a hexagon instead of a circle. A circle
probably looks better, but hexagons may be easier to label. Note that,
in any case, the visible layout and the touch zones do not have to be
exactly identical. One may even go as far as changing them dynamically,
e.g., by growing the neighbours of the current zone, to make them
easier to reach.

I haven't implemented any of this, and I doubt I'd have time to do
so in the foreseeable future, but I kind of like the idea of being
able to do rapid text input without a stylus. So if anyone wants to
experiment with this idea, please feel free.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/



More information about the openmoko-devel mailing list