Clarification for UI Request events (why no "activate"?)

Hello,

*** Sorry if this was posted already, I sent it earlier from the wrong
address and it bounced ***

In section 3 there is an editorial note that reads "There is
purposefully no request event for activating the default action. Authors
are encouraged to use a standard |click| event for default actions."

I failed to find the origin of that note in public forums, so excuse me
if I am re-igniting an old debate. I would very much like to see an
"activate" UI request. Using the "click" event is not always a good
solution.

For one, it is centered around a mouse metaphor and is not input-agnostic.

Second, because of the proliferation of pointer types and events a web
app might choose to discover a user pressing a button by other means
besides "click". For example, with touch (or soon, pointer) events it
might be touchstart and touchend with the same finger within radius r
from the widget without travelling more than distance "d" and was lifted
well after duration x but not before duration y. Why would they do this?
Because they might need enough nuance to distinguish between a tap, a
swipe and a dwell. Each of which would do something else in the UI. They
might also choose not to add an event listener to the widget directly,
but to its container, so that they can determine with some fuzz which of
the child widgets the user meant to activate.

I think it would fit under Indie-UI's goals to separate the nuanced and
fragile input interpretation from the actual activation of a widget.
This is good for automated testing where the developers could have unit
tests for the gesture detection, and readable automated UI tests with UI
request events. This is obviously good for accessibility too!

Cheers,
  Eitan.

Received on Thursday, 2 May 2013 16:33:33 UTC