Re: Touch Events version 2 - Requesting evaluation of feasibility to exploit touch pressure values to enable equivalent of mouse hover events on mobile touch devices

Since no-one has replied to this yet I'll take a crack at it with my
personal opinion.  There are three questions here:

1) Should the standard be more precise in requiring full and even use of
the range [0, 1].
Personally I think this is a good idea.  It's hard to use pressure for
anything today without this - the app has to dynamically adapt itself to
the 'normal' range it sees in practice.

Of course making the language a little stronger in the standard is just a
small piece.  Eg., Chrome on Android today can return values >1 (
https://bugs.webkit.org/show_bug.cgi?id=91799) which is already clearly
illegal.  The challenge is that Android runs on such a variety of hardware,
and Android itself provides no absolute calibration, so Chrome would just
have to do the same sort of dynamic tuning/adjustment (but better Chrome
than every app).  Frankly I think it'll be pretty difficult to get really
consistent behavior out of the variety of different hardware and OSes, but
that doesn't mean we shouldn't try.

2) If pressure was consistent in practice, could it be used as an analog
for hover.
Sure, it could.  But the user experience would vary so much depending on
the hardware (and the user), and it would be so unusual and unexpected that
I doubt it would make for good UX in practice.

Rick

On Fri, Jul 20, 2012 at 11:17 PM, Richard Creamer <2to32minus1@gmail.com>wrote:

> Dear Editors:
>
> The Touch Events version 2 document is, to me, unclear as to whether the
> equivalent of mouse over/move/hover events are intended to be
> included/supported.
>
>  I would very much like to see touch screen devices support the
> equivalent of a mouse over/move/hover event. This feature enables much more
> dynamic UIs, and would go a long way towards eliminating one of the few
> remaining advantages that mouse-equipped desktops and touch pad-equipped
> laptops have over touch devices.  (I would like to point out that touch
> pads on laptops support these events.)
>
>  I had hoped that the touch event pressure value range [0, 1] was being
> fully utilized so that I could emulate this type of event in my own
> applications, but upon writing a simple Android test app for my phone,
> discovered that all pressure values were primarily compressed into the
> range of approximately [0.15 - 0.30] representing the lightest to the
> strongest touch events I could create. (I should mention that I have a
> high-end aftermarket screen protector on my phone which conceivably might
> be compressing the pressure values.)
>
>  If the pressure value's dynamic range were more fully utilized, it may
> be feasible to reserve a standardized touch event pressure range to
> represent the equivalent of a mouse over/move/hover event, while
> higher-pressure touch events could initiate the already-implemented touch
> events.
>
>  My purpose in submitting this is to suggest that this possibility be
> considered. Perhaps hardware or platform vendors could calibrate their
> pressure readout values to be more evenly distributed throughout the [0, 1]
> range such that my suggestion can be adopted.
>
> Thank you for your consideration.
>
>  Richard Creamer
> Individual
>