Re: [pointerevents] pointerType: 'dial'

PointerEvents can be tweaked to represent a "dial" (Windows Wheel) for
 sure. But before we commit to changes in this direction, we should 
discuss the pros & cons of other comparable alternatives. Here are my 
thoughts on one such alternative: WheelEvents could also be tweaked to
 represent the device too---is it really bad compared to 
PointerEvents?

Both PointerEvent and WheelEvent (each of them is a direct subclasses 
of MouseEvent) seem to have some unique winning points. I looked at 
three properties of a "dial", as follows. I found WheelEvents to be a 
better choice for two of them, YMMV.

#### Dial rotation
Dial rotation comes first because it is the most prominent aspect of 
the new hardware. The dial is symmetric around its axis, so the exact 
_physical_ angle of the dial position seems immaterial to users, e.g. 
there is no left/right/up/down position. This is like a mouse-wheel, 
and unlike stylus devices (possibly with a "calligraphic" tip) for 
which PointerEvent.twist was added.

The 
[website](https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/windows-wheel-interactions)
 shows some nice widgets to mark dial position but the physical dial 
has no mark, to allow defining the "position" arbitrarily through 
software (which is a great thing IMO). Even if a software widget 
exactly simulates a physical marker position on the dial, the 
connection between the widget and the device breaks completely when 
the device goes off-screen. Consider this experiment: mark the dial 
(with a marker) at the widget-marked rotation angle, detach the device
 from the screen, bring it back at a different angle.

Clearly an absolute rotation angle ("twist") from the device would 
make no sense to the software. Only the rotation offset matters here. 
This is like WheelEvent.deltaZ as @shepazu mentioned above, and unlike
 PointerEvent.twist.

So dial rotation is more like turning a mouse wheel than twisting a 
pen, both physically & for the software interface.

#### Device diameter
WheelEvent doesn't have anything to offer here. PointerEvent wins, 
with width & height.

#### Pointer location
The use-cases shown in Microsoft website seem to suggest that the 
location of the dial has only a weak association to the content below 
it. If a dial is off the screen, it's location is irrelevant, unlike 
any other pointing device. When the dial is about to touch the screen,
 it doesn't seem to affect the content below it but instead "pops up" 
a new UI widget, and then controls the part of the widget _around_ it.
 "Center of of the Widget upon contact" seems to be the only use of 
its location. Does it have any use case as a _pointing device_? I 
didn't find any.

A mouse wheel is not used as a pointing tool (even though it "resides"
 on a pointing device). We don't move the mouse when turning the 
wheel---either for the physical awkwardness of simultaneous movements,
 or to avoid scrolling wrong things accidentally. Dial seems exactly 
like this: meant to be used by our "non-dominant" hand which is not an
 expert for precise movement, at least for me.

Thoughts?

-- 
GitHub Notification of comment by mustaqahmed
Please view or discuss this issue at 
https://github.com/w3c/pointerevents/issues/152#issuecomment-258553526
 using your GitHub account

Received on Friday, 4 November 2016 21:35:29 UTC