Re: [Events] UI Triggers for IndieUI Events 1.0

James Craig <jcraig@apple.com> wrote:
> Substantial edits made today/tonight covering the @uittrigger idea we've been discussing over the past few months. 
> 
> In addition to the rest of the edits, I'd appreciate a critical, technical review of this new section, entitled "UI Triggers."

Thank you, James, for your excellent work in specifying the new feature.
Consider the following comments "post-heartbeat" material - that is, they
needn't be addressed before publishing the heartbeat draft.

1. The text states explicitly that UIManipulationRequestEvent types are not
included in the set of tokens available as values of uitrigger, because
additional parameters not expressible as simple tokens are needed in these
cases.

It follows that the motivating example for the uitrigger feature, the slider
(operated by move events targeting the slider thumb) isn't covered. It needs
to be addressed, however, then reinstated as an example in the spec. As I
remember, the trigger element responds to move requests by dispatching value
change requests, and we need to define the relationship between deltas in the
move request and the the corresponding value change.

2. The text, as drafted, states that the trigger element need not be focusable
if, for example, there is an access key assigned to the operation. This makes
sense if focus means "keyboard focus", but I'm wondering whether there are any
other input methods that rely on focus (e.g., sequential navigation in a touch
interface) rather than merely on point-of-regard. On the systems that I have
used, sequentially navigating UI controls in a touch interface simply changes
point-of-regard, not focus, so the text as it stands may be fine - we're only
concerned about focus in relation to keyboard input, but I would still suggest
checking for possible counter-examples where this could be a problem. I don't
think speech input relies on focus either, for instance, thus perhaps all
non-keyboard inputs are covered without the element's having to be focusable.

3. There are minor errors worthy of cleaning up before publishing the new
section. This point probably should be addressed before the heartbeat draft.

4. I think informative text should be added that explains the differences
between uitrigger and uiactions, and gives the rationale for each. I expect
these attributes to be a source of confusion unless their respective purposes
are clearly delineated.

As mentioned, I don't want to stand in the way of publishing a heartbeat
draft in the agreed time-frame.

Received on Thursday, 15 May 2014 10:25:10 UTC