Re: Several event types are too discrete to be useful for touchscreen input

Thanks for your response Rich.  Inline.

On Mon, Nov 5, 2012 at 12:48 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> Rick,
>
> Can you tell us if the new Pointers working group will be addressing any
> scrolling?
>
The pointers WG will focus just on low-level events (down/move/up, etc.)
and so won't include scrolling or, I think, anything else covered by Indie
UI.  In fact, it's an explicit non-goal in the charter (
http://www.w3.org/2012/pointerevents/charter/charter-proposed.html).
>
>  These events have been targeted for discreet events but if you think we
> are deficient on scrolling then we should investigate the gaps and see if
> they can be addressed in 1.0.
>
It depends on the answer to my question about the intended scope.  Is the
'manipulate a map with a touch screen' scenario important, or something we
should cut as out-of-scope?  To support it I think we'd need at least:
 - deltaX / deltaY values (probably in CSS px) for scroll events
 - zoom events with a precise origin location and scale (again probably in
CSS px)
We'd probably also need some sort of start/end events so the app can tell
when the user is done panning/zooming.

If this is too far removed with the other goals of Indie UI events then
perhaps we should call that scenario out-of-scope.

> Rich
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Rick Byers ---11/05/2012 10:25:49
> AM---Hi, I know there was originally a desire that Indie UI events]Rick
> Byers ---11/05/2012 10:25:49 AM---Hi, I know there was originally a desire
> that Indie UI events would be rich
>
> From: Rick Byers <rbyers@chromium.org>
> To: public-indie-ui <public-indie-ui@w3.org>,
> Cc: Robert Kroeger <rjkroege@chromium.org>
> Date: 11/05/2012 10:25 AM
> Subject: Several event types are too discrete to be useful for
> touchscreen input
> Sent by: rbyers@google.com
> ------------------------------
>
>
>
> Hi,
> I know there was originally a desire that Indie UI events would be rich
> enough to be useful for common touch screen interactions (eg. see *
> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements#Scenario_1:_Manipulating_a_map
> *<http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements#Scenario_1:_Manipulating_a_map>).
>  To what extent is this still a goal?
>
> I took a quick look at the work-in-progress spec (*
> https://dvcs.w3.org/hg/IndieUI/raw-file/7f84811c9874/src/events.html*<https://dvcs.w3.org/hg/IndieUI/raw-file/7f84811c9874/src/events.html>)
> and see that a common theme is to make the events fairly discrete, eg. with
> an enum of possible values.  For example, the UIScrollRequestEvent takes an
> enum for one of 4 directions.  I'd love to be able to use UIScrollRequest
> to, eg., pan a map with a touch screen, but for that it would need
> _at_least_ some measure of distance connected to the screen (eg. scrolled
> 10 pixels up and 2 pixels to the right).  Even for the more common scenario
> of triggering these events from a track pad, you'd need a measure of
> distance.  Do you intend for UIScrollRequest to replace the use of
> mousewheel (*http://www.w3.org/TR/DOM-Level-3-Events/#events-WheelEvent*<http://www.w3.org/TR/DOM-Level-3-Events/#events-WheelEvent>)
> events, or would apps always need to listen to both?
>
> The overall impression I get is that these events are really designed to
> be triggered by discrete operations like pressing of buttons.  I think the
> approach would need to be modified (eg. to take arbitrary precision values
> in place of enums) to really ever get used for any sort of continuous input
> like a touch screen or track pad.  But perhaps that's no longer a goal?
>
> Thanks,
>    Rick
>
>
>