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

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

From: James Craig <jcraig@apple.com>
Date: Fri, 08 Aug 2014 14:49:50 -0700
Cc: "public-editing-tf@w3.org" <public-editing-tf@w3.org>, Indie UI <public-indie-ui@w3.org>, public-webapps <public-webapps@w3.org>
Message-id: <E48A3525-5E02-4FBB-9480-17C47D40922A@apple.com>
To: Ben Peters <Ben.Peters@microsoft.com>, Julie Parent <jparent@gmail.com>, Ryosuke Niwa <rniwa@apple.com>
From: Julie Parent <jparent@google.com>
>  
>> This is a great list, and I agree it is the right starting point.
>> 
>> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:
>>> * Activate / Invoke 
>>> 
>>>  * Expand
>>>  * Collapse
>>>  * Dismiss
>>>  * Media next/previous/start/stop/pause
>>>  * Rotate
>>>  * Zoom
>>>  * Value change
>> 
>> Is this the set from indie-ui?  I think we should make a decision if we are trying to cover these cases or not, as they do not make sense in the context of rich text editing and might be out of scope.

Sorry Julie, I didn't see your original email. Perhaps you removed the cross-posted lists? I'm on both IndieUI and WebApps, but didn't see it come through.

With the possible exception of the media events, all of the above events make sense in the context of editing. For example, in Word or Pages:

1. You can "expand" or "collapse" sections of a document.
2. You can "zoom" in on the document view. 
3. You can "rotate" an embedded photo or chart. 
4. You can "scale" a variety of elements by focusing on a corner handle (e.g. drag handle) and nudging it with arrow keys, or a mouse, or by touch. These can be modified in some apps. For example, option+arrow moves this handle by a smaller amount than unmodified arrow keys. This is a use case for either "scale" on the main object, or "value change" on the corner control.


>> It would help to have a list of arguments for/against merging with indie-ui?

I don't know if the arguments need to be about merging working groups. I don't care where the work happens, as long as it happens. I'd be fine with disbanding IndieUI if WebApps is ready to take up the work, but text editing is only one piece of it. IMO, it doesn't make sense to design one API for text editing, and another API for graphic manipulation, and another for form manipulation. 

One of the use cases that was deferred from the 1.0 version of IndieUI was to "mark" for some later action. For example, in a text editor, click in one spot, then shift+click in another to select a range of text. The next action (such as Delete) applies to the selection. On most desktop platforms, this works with text selection, but also on collections like table views: click then shift+click to select multiple songs in a music player, or multiple messages in an email inbox. 

INDIEUI-ACTION-25: Add markRequest with variant properties indicating "fromLast" (like Shift+click or select range from last mark) and "retainMarks" (like Mac Cmd+click or Win Ctrl+click meaning select in addition to)

https://www.w3.org/WAI/IndieUI/track/actions/25

Hopefully these examples demonstrate how overlapping the work is. It'd be tempting to limit the scope to text editing, but I feel that'd ultimately be short-sighted.

James


-- 
Indifference towards people and the reality in 
which they live is actually the one and only 
cardinal sin in design.  Dieter Rams
Received on Friday, 8 August 2014 21:50:53 UTC

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