multi-touch-dev team mailing list archive

["Stephen M. Webb" <stephen.webb@xxxxxxxxxxxxx>]

On Thu, 2010-09-02 at 17:39 +0100, John Lea wrote:

>  I have just published version 0.2 of the Unity Gesture UI Guidelines; it
>  is available at http://docs.google.com/View?id=dfkkjjcj_1482g457bcc7 .

I looked through this with a view to identifying gesture-related work
that needs to be done.  This is not a design review so much as a list of
areas in uTouch or Unity that may need to be addressed to implement the
design, and a starting point for debate about how best to implement
these missing pieces.

(1) Gesture support for non-multitouch or limited-multitouch devices;
the uTouch stack in Maverick offers gesture recognition only for
multitouch devices.  The Unity spec section 2.2.7 requires full single
touch support, and I believe most users will expect that without having
to know the technical details of the silicon in their device.

(2) Support for "greedy" windows did not make it in to the Maverick
version of the uTouch stack.  It is a work item for Natty.  I'm not sure
if there's a bug for this, I suspect we need one.

(3) The grail recognizer does not recognize multiple taps atomically.
Traditionally, the toolkit does the multiple-click recognition and
receives only button-down and button-up events.  It makes sense to
continue with this tradition so that the timeouts can be configurable,
although the same argument can be made for moving it into grail to give
a system-wide consistent feel across toolkits.

(4) The grail recognizer reports a "hold" as a "drag" gesture with very
small movements (at least on my magicpad).  There is no separate "touch
and hold" gesture defined in grail.  Other gesture recognizers (eg.
Qt, .NET, not sure about Apple) treat this as an atomic gesture.  Again,
this can be done is either grail or the Unity side, same arguments as
above apply.

(5) Grail does not support a separate "flick" gesture.  This should
probably be implemented in Unity using drag gestures from grail and a
physics engine.  The physics engine will necessary in Unity to support
bounce-stop, touch-stall, and flick animation anyway.  Other toolkits
will also have to implements this.  See above.

(6) The "protected gestures" support may be problematic without moving
tap-and-hold recognition into grail or forcing applications to implement
possibly complex undo semantics.  This particular feature may need some
additional analysis.

The tap-and-hold gesture is also crucial to the touchpoint menus, which
I'm assuming will be used to implement the full single touch requirement
as well.  It is probably the issue that needs to be addressed first.

Note that issues (3), (4), and (5) above could be remedied by
implementing additional gesture processing at the geis
(application-side) layer of the uTouch stack to give consistency across
toolkits and other gesture consumers, rather than implementing in Unity
and again in each toolkit or application.  This would also tie in with
the "gesture expression language" that has been discussed, in which
grail would recognize and forward only gesture primitives and an
application-side library would recognize higher-level gestures built on
those primitives using extensible and customizable definitions.  Such a
recognizer represents a major development effort.


-- 
Stephen M. Webb <stephen.webb@xxxxxxxxxxxxx>
Canonical Ltd.