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

Rick,

Thank you for your reply.  I knew this request would not be a simple or
even necessarily a practical thing on many fronts...

I guess the issue-behind-the-issue is the fact that, without support for
this UX gesture set, touch-based devices will always take a back seat to
mouse- or laptop/touchpad-equipped devices when it comes to
highly-interactive, fast-paced UXs.  That is, there is a definite
productivity differential, at least for several UI types.

Sadly, a well-thought-out union of touch + traditional mouse-driven UI
gestures would have greater potential efficacy than either by itself.
 Consider http://www.perceptivepixel.com/ for example, not to mention the
advanced UXs we have seen in several movies from the past decade or so.

For my current project, I can work around this issue simply by creating a
non-standard UI which I'm sure the children which use my under-development
Education KB app can pick up pretty easily/naturally.  For example, a tap
could trigger a popup event (in lieu of a hover or right-click) with an
optional 2,000 ms delayed fade-away, or alternatively, a second tap could
hide the popup.  This would then require the introduction of either a
double-tap or long press gesture  to represent an "action" event which is
currently a single tap event in Android.  But non-standard is not a good
thing...  I would really prefer my apps' UXs to be "standard."

And, let me mention that, to a certain extent, some of your issues could
perhaps be mitigated with Android platform variables similar to the
"uses-feature" declarations in the manifest XML file.  Applications could
adapt based on the current device's capabilities.

Finally, I guess I'll mention a possible near-term "future" application of
tablets and surfaces for collaboration: geographically distributed, or when
multiple meeting attendees jointly collaborate.  For these use cases, users
will want the ability to affect a large, group-shared view/surface which
they can interact with from their own personal touch devices.  This might
then introduce further gesture categorization: 1) local device only, or 2)
shared view only, or 3) both.  My point is that sometimes it is a good
thing to think ahead.

Thank you again.

Regards,

Rick


On Tue, Jul 31, 2012 at 6:21 PM, Rick Byers <rbyers@chromium.org> wrote:

> 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
>>
>
>