Re: Comment on IndieUI: Events 22 January 2013 (ACTION-39)

Hi Patrick, apologies for the tardy response. I didn't notice this email when it came through. Responses inline.

On Feb 13, 2013, at 9:01 AM, Janina Sajka <janina@rednote.net> wrote:

> Colleagues:
> 
> Forwarding the following comment received on our Events FPWD ...
> 
> Janina
> 
> Patrick Harms writes:
>> Hello everybody,
>> 
>> Thank your for the draft specification. I was seeking for a layer
>> like this for my own research work. Maybe my following comments can
>> help to extend and improve the specification.
>> 
>> To me the specification is a shift from the lexical layer of an
>> application to a more syntactical or even semantic layer of design.
>> Naming an event explicitly as an undo event is giving it a semantic
>> that is usually not connected to a lexical event like a key stroke.
>> I would include and describe this shift in the introduction of the
>> specification. The levels of design are e.g. named in Shneiderman
>> and Plaisant "Designing the User Interface - Strategies for
>> Effective Human-Computer Interaction" (2010).

Thanks for the suggestion. I've created ACTION-51 to look into the text you've referenced.

>> The specification strongly focusses on web applications (e.g. in
>> section 1.2 goal 3). But I propose to make it more independent of
>> the web and HTML. In general I think the list of events is also
>> applicable for any other application like apps on any kind of
>> operating system. Therefore, I would also start the specification
>> with naming and describing the events and then showing the
>> appropriate implementation in the context of HTML. This may in the
>> future be extended with a description of the implementation for any
>> other kind of platform.

This would be difficult, as the scope of the W3C is "The Web", the specification itself is defined in WebIDL, and the concepts rely heavily on a web-centric approach of event handlers as defined and handled via ECMAScript/JavaScript. Although the concepts are applicable outside this context, I'm not hopeful that we could write a single specification that would apply outside this context, and even if we could, it would likely take decades. 

I'll suggest that we keep IndieUI Events within the scope of the Web for the 1.0 release. Upon completion, this document could be used as a reference for any other implementors or specification developers that wish to take the concepts to other platforms.

>> In section 2.1.1 I would prefer the term receives/@receives.

Me too, but the main concern is the potential conflict with a host language attribute. Receives is a pretty common word and so snagging that attribute name in the null namespace is asking for trouble. Nevertheless, the weird casing/hyphenation of uiActions/@ui-actions bugged me too, so I've changed it to uiactions/@uiactions in the editor's draft. Hopefully that is a reasonable compromise that makes it easier to read and use but without as high a potential for name conflict.

Changeset:
https://dvcs.w3.org/hg/IndieUI/rev/9155914a1eda

>> I think the list of events needs to be extended. E.g. changing the
>> value of a text field is not included as far as I understood the
>> list.

Text editing is a giant issue too large for IndieUI 1.0. The PF group recently (last week) asked WebApps to consider a text editing API for custom views. For now the recommendation is only to use the native controls like input, textarea, and contenteditable.

>> But in my opinion the specification should cover all kinds of
>> events to really support user interface independence. Or is it
>> extending the list of events like "onclick" on elements? If this is
>> the case, than it must be clearly indicated in the specification.

None of these are meant to replace click as the primary activation event.

I have an editorial note in the document to remind me to clarify this in a future edit.
"There is purposefully no request event for activating the default action. Authors are encouraged to use a standard <code>click</code> event for default actions."

>> However, to me the specification is a new layer of events, i.e. a
>> more syntactical, even semantic one (see above). Therefore, it
>> should be a closed, complete, and detached set of events that can be
>> implemented on different platforms and to which existing event sets
>> can be mapped.
>> 
>> I hope these comments are helpful.

They are. Thanks Patrick.

Cheers,
James Craig

Received on Wednesday, 1 May 2013 02:37:11 UTC