Comment on IndieUI: Events 30 July 2013 - UIScrollRequestEvent

Dear IndieUI WG/TF members,

I am a researcher on web accessibility and have been keeping an eye on the
work of IndieUI. I would like to provide my comments regarding "IndieUI:
Events 1.0" Working Draft of July 30, specifically regarding the
UIScrollRequestEvent.

As background information, the current specification deals with scroll
events that allow users to:
a) Move viewport in any direction (i.e. up, down, left or right) by a
predefined amount.
b) Move viewport in any direction by another, larger predefined amount
(labelled as "page")
c) Move viewport in any direction to the limit (top, bottom, leftmost,
rightmost).
d) Move viewport in any direction (even obliquely) by a non-predefined
increment (delta).

(Always understanding 'viewport' in a modality-agnostic way, i.e., as the
part of the view that is currently rendered in any format).

However, scroll controls usually provide mechanisms to at least control
two other actions:

e) Jump to a specific point in the view.
In the UI frameworks that support this event, it is usually produced by a
point-and-click input modality. Users click on a point in the scrollbar
proportional to the desired final position.
It should be noted that in "infinite scroll views", the same gesture does
indeed map to a delta (relative) movement.

f) Start/change/stop continuous view scrolling, in any direction (even
obliquely) at some speed.
In some UI frameworks that support this event, it is produced by a
point-and-click input device or a haptic input. Users click on a
destination point in the desired direction (relative to the current
scrollbar position), and hold it until they wish to stop. The farther from
the current position, or the longer the user holds the pointer clicked,
the fastest the scrollview moves.
In other cases, users produce this event with dedicated hardware such as
clickable scrollwheels: the movement starts when the scrollwheel is
depressed, and the (vectorial) speed changes proportionally to the shift
of the device from its original position.

Some potential criticisms could come from:

- Regarding e), it could be argued that jumping to newX is equivalent to
scrolling by deltaX = newX - oldX. However, the semantics of the user
intent are different in both events (i.e. relative versus absolute
movement).

- Regarding both e) and f), there are not any keyboard-based input methods
that convey those meanings (at least, I am not aware of any
implementation). However, this matter of fact should not preclude us from
having the semantic events considered by IndieUI, so that they can be used
in a device-independent manner (and be open to eventual keyboard-based
implemenations). Note there are APIs (e.g. Android's View scrollTo) that
allow programatically generating these events. Moreover, please note there
are non-mouse-based implementations as well, e.g. Dragon Naturally
Speaking supports commands to "Start Scrolling Down/Up", "Speed Down/Up",
and "Stop Scrolling".

Some other, separate considerations, but still related to scrolling
events. I would regard them as of lesser relevance, since they reflect not
so widespread usage:

- I wonder whether it is enough with three scrolling levels (say: [line]
up / page up / [top] limit).  For instance, Office 2010 products [1]
distinguish up to 6 levels: line up, paragraph up (incidentally bound to
"PAGE UP" key), screen top (window top), screen up, page up, and document
top. It may be also the case that IndieUI considers some of these are
indeed UIFocusRequestEvent instances. In that case, I would suggest
clearly distinguishing between both event types. Otherwise, implementors
could wonder why (or whether) e.g. paragraph-up is a navigation event.

- What brings me to another point. In some programs, different UI actions
are mapped to "move the viewport while keeping the insertion cursor at the
original position" and "move the viewport and the insertion point". I
would suggest this semantic difference being documented in
UIScrollRequestEventInit.

I hope you find this input helpful, although I understand not all the
comments can always be addressed.

Regards,

Samuel Martín.
Universidad Politécnica de Madrid (UPM)

[1] Keyboard shortcuts for Microsoft Word. Expand section on "Move through
your document"
http://office2010.microsoft.com/en-us/word-help/keyboard-shortcuts-for-microsoft-word-HP010370109.aspx

Received on Thursday, 12 September 2013 15:50:31 UTC