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 <[email protected]> Canonical Ltd. _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp
