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

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

> 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."

> 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. 

> 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.

> 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.

> 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.

> ...  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.

James

Received on Wednesday, 9 January 2013 02:16:20 UTC