Re: Review of IndiueUI: Events 1.0 Draft 7 January 2013

Sent from my iPad

On Jan 8, 2013, at 8:16 PM, "James Craig" <jcraig@apple.com> wrote:

> Address each inline.
>
> On Jan 7, 2013, at 6:11 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
>
> > Suggested Changes and Comments:
> >
> > Abstract:
> >
> > <change>
> > This specification, in conjunction with the User Context Module, is
intended address the problem of device-, OS-, and localization-independent
control of web content, including custom widgets. See the introduction for
background and usage examples.
> > </change>
> >
> > <to>
> > This specification, in conjunction with the User Context Module, is
intended address the problem of device-independent, OS-neutral, and
localization-independent control of web content, including custom widgets.
See the introduction for background and usage examples.
> > </to>
>
> Michael had a lot more feedback on the Abstract which supersedes this
change. Please review the new one.
>
>
https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#abstract

>

Ok. Reading Michaels:
<change>
Implementing platforms will take modality-specific user input, user
idiosyncratic heuristics to determine the specific corresponding Indie UI
event, and send that to the web application in addition to the
modality-specific input such as mouse or keyboard events, should
applications wish to process it.
</change>
<to>
Implementing platforms will combine modality-specific user input with user
idiosyncratic heuristics to determine the specific corresponding Indie UI
event, and send that event to the web application in addition to the
modality-specific input such as mouse or keyboard events, should
applications wish to process it.
</to>

> > 1.1 Background:
> >
> > Paragraph 1:
> >
> > <change>
> > alternate assistive technologies including
> > </change>
> > <to>
> > assistive technologies that use alternate forms of input such as
> > </to>
>
> Done.
>
> > 1.2 Goals:
> >
> > Bullet 1: <change< agnostic</change> <to> input agnostic </to>
> >
> > Bullet 3: A comment: Just wanted to point out that another group is
doing Pointer events which are more agnostic. We might want to limit this
to command and control functions.
>
> I'm not sure how this comment relates to bullet 3. Could you clarify? To
make sure we're talking about the same text, the full bullet 3 follows:
>
> "Provide a clear path for web developers to smoothly transition from
currently existing physical events to IndieUI events, during the period
when implementations of IndieUI are incomplete."
>
Well, the new pointer event working group may not consider our work the
only non-physical device event work as it has abstracted things to a
degree. Our statement seems to be center of the universe-ish. You might say
legacy input device implementations.

> > General change:
> >
> > Both sections 2 and 3 should say "This section is normative."  as the
preceding sections say they are non-normative. ... or you should separate
these sections into  a normative part of the spec. Either way would be
fine.
>
> The "non-normative" ones are generated by ReSpec. My understanding is
that anything not explicitly listed as non-normative is considered
normative, so adding these in would be redundant.
>
The ARIA spec. states what sections are normative.

> > 3. UI Request Events
> >
> > Are there going to be incidents where the request event is NOT sent to
the element with the Point of Regard. IOW should the Point of Regard always
be moved to make all requests? We should look into this.
>
> I don't understand your question. I'd expect that a UA or AT could "move"
the POR prior to sending an event, or not move it. If not, the event would
initiate from the current POR. If so, the event would initiate from the new
POR. If I'm understanding you correctly, this is out of scope for the spec,
as it's in the realm of specific implementations and user tools to figure
out where the user's POR is.
>
We don't have implementations. It is simply a question that where we are
not talking about UI input commands and we are talking about requests there
may be a need to not have to be the POR. We did not ask if there was a use
case for this. It is simply something that the group did not discuss. We
should ask ATs if any have such a use case. I tend to agree with you but we
should ask. That's all.

> > 3.1.3 UIRequestEventType
> >
> > Each of these are separated by a black and red color. I am not sure why
we are differentiating by color. e.g.:
> > Undo Request undorequest
> >
> > If we are differentiating by color that is an accessibility issue.
>
> The monospace <code> blocks differentiate in ways other than by color
alone so AFAIK, there is no accessibility problem with this format. The
color is just the default W3C style for inline <code> elements, in addition
to the monospace font.
>
> > Why don't we just get rid of the first part and have undorequest? You
have the definition following it.
>
> Explanation from the discussion here:
> http://lists.w3.org/Archives/Public/public-indie-ui/2012Nov/0010.html
>
> I just added in the originally proposed parentheses, to improve
readability a little bit.
>
ok

> > 3.2.1 UIManipulationRequest
> >
> > We need to prototype this to know whether we have this right.
>
> I agree.
>
> > Glossary:
> >
> > Point-of-Regard:
> >
> > The definition should start out as the point of user focus within which
UI actions are directed.
>
> "where actions are directed" is somewhat vague. Do you mean "where events
are initiated"? I left this as a noted TBD because I'm not sure the best
way to define this yet either.

I am ok with where Indie UI events are initiated. I would like to see a
draft definition here before we put out a draft.
>
> > ...  and then follow with the rest of it.
> >
> > This is the extent of my comments for this first working draft. It is a
good first draft. We need to dig into these deeper and provide greater
specificity such as scrolling increments. We are all aware of that.
>
> Thanks for your help Rich. I'm glad to hear you both are recuperating.
>

Thank you.

> James
>
>