W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 04 Aug 2014 19:55:12 -0700
Cc: "public-editing-tf@w3.org" <public-editing-tf@w3.org>, Julie Parent <jparent@gmail.com>, "public-indie-ui@w3.org" <public-indie-ui@w3.org>, public-webapps <public-webapps@w3.org>
Message-id: <2E226975-DC0E-4CC7-9956-C5B1D660BFFC@apple.com>
To: Ben Peters <Ben.Peters@microsoft.com>
On Aug 4, 2014, at 7:28 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:

> Cross-posted​: Editing TF, IndieUI TF, WebApps WG
> 
> In order to solve the broad issue of User Intentions, we have compiled below a list of User Intentions derived from all of the sources of intention-style events that I am aware of. I agree with Julie that some of the events below are not in scope for Editing at this time. However, they are in scope for IndieUI, and I think that we have an important opportunity here to bring all concepts of "Intentions" together in a single explainer document so that 1) web developers can have a coherent picture of how to understand User Intentions and 2) the specs that concern User Intentions do not overlap. To that end, I propose that we create a new User Intentions Explainer document, borrowing from the work of the Editing Explainer and IndieUI to give an overview of how all of the following Intention Events work together in a high-level non-normative form:

Looking at the broader perspective is a great idea since many user actions such as copying and pasting are not specific text editable regions.

> Clipboard API
> HTML5 Drag and Drop
> Selection API (beforeSelectionChange)
> DOM Events (beforeInput)
> IndieUI
> 
> Each of these specs solves some aspect of User Intentions, and they should be coherent. For instance, we need to solve how beforeInput does not overlap Clipboard and DnD, and consider moving some parts of IndieUI that apply to input (undo/redo) to beforeInput.

Indeed.

> Further, I propose that we fine-tune the Editing Explainer, making it clear that there are two problems we're trying to solve in that space- Editing Intentions and Extensible Web Editing. From there we can begin to create normative specs for solving these two Editing problems.

I don’t think we need to necessarily scope specifically for editing per se.  There is a broader set of user actions that need to manually detected by the web apps at the moment, and it would be nice to create event-based API that could be extended for other applications such as drawing apps and various UI components such as a color palette, etc…

> The end result of this would be a high-level explainer for all known User Intention specs, and a high-level explainer for Editing. Then we can solve each individual problem more granularly while maintaining coherence. Thoughts?

Perhaps we even want to look at the list of use case in http://www.w3.org/TR/indie-ui-requirements/ and come up with a single coherent API.  It would be really nice if we added the “intention” events as the foundation for all UI interactions and built extensible editing API on top of it.

- R. Niwa


Received on Tuesday, 5 August 2014 02:56:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC