RE: User Intentions Explainer (was: List of Intentions)

I agree with this. We should have a single 'shape' for these events and shared terminology. 

I think trying to solve all of the problems in one complete spec would be too complex,  but if we use an Intentions Explainer to divide the problem into manageable pieces, we can continue on our trajectory of creating these events for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other user interactions. Are there objections to this approach? If not, I will begin to adapt the Commands Explainer into a more generic Intentions Explainer.

> -----Original Message-----
> From: Jason White []
> Sent: Saturday, August 9, 2014 4:56 PM
> To:
> Cc:;
> Subject: Re: User Intentions Explainer (was: List of Intentions)
> [Cross-posting the comments below per Janina's thoughtful request.]
> I concur with Janina's insightful remark [at the Indie-UI teleconference on
> Thursday] that the "explainer" could evolve into a (potentially cross-group)
> requirements document. This raises several issues.
> 1. Harmonization of terminology. We're already seeing differences between
> the terminology used by WEB Apps in connection with editing and our own
> terms for similar concepts, e.g., "abstract events" and "intentions". Naming
> conventions for events aren't harmonized either.
> 2. Whether there should ultimately be one spec or several, and where the
> division should lie, is obviously up for discussion. Given the progress we've
> made to date, it makes good sense that support for interactive editing could
> reside in its own spec, with its own development schedule. This, after all, is
> work that we anticipated in Indie-UI but postponed.
> 3. If there are two or more specs to be produced in this area, we should
> provide appropriate cross-references (perhaps a non-normative reference in
> each spec to the requirements would be sufficient), so that user agent and
> Web application implementors alike can readily appreciate the relationships
> between the technologies described in the respective documents.
> My main concern at this point is that the designs be consistent and that
> terminology be unified wherever possible.

Received on Tuesday, 12 August 2014 00:23:43 UTC