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

Hi Rick,

I don't speak for the entire group but given the fact that the pointer
group is not doing this and we want to do scrolling, pan, and zoom, for
graphics and this is important for mobile I think it is in scope of the
charter.

What you are stating makes sense sense.

Rich

Rich Schwerdtfeger



From:	Rick Byers <rbyers@chromium.org>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc:	public-indie-ui <public-indie-ui@w3.org>, Robert Kroeger
            <rjkroege@chromium.org>
Date:	11/05/2012 01:24 PM
Subject:	Re: Several event types are too discrete to be useful for
            touchscreen input
Sent by:	rbyers@google.com



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

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