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

On Jan 8, 2013, at 8:42 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

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

So just the one word, "take" to "combine"?

Done.

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

I don't think that's appropriate. Mice and keyboards are not legacy device implementations. Neither are a lot of the physical events that IndieUI is intended to bypass. I'm not sure where you see a claim that IndieUI is the only type of non-physical event. The claim is just that IndieUI replaces physical events in certain cases.

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

The existing editorial note was the draft definition. I've move it out of it's "note" container and removed the TBD.

James

Received on Thursday, 10 January 2013 19:01:52 UTC