See also: IRC log
<trackbot> Date: 30 April 2014
<janina> Meeting: IndieUI Task Force Teleconference
<scribe> scribe: jasonjgw
James: notes discussion in the TAG of event coordination between various groups (DOM, WebApps, IndieUI etc.).
We've requested Monday and Tuesday. Janina has coordinated with Charles regarding the possibility of common agenda items with WebApps, noting the need for flexibility in the timing of the joint discussions and deciding in advance what the issues needing coordination are.
<jcraig> https://dvcs.w3.org/hg/IndieUI/
Michael: Requirements title
changed to "Requirements for IndieUI Events 1.0 and User
Contexts 1.0".
... the concern was that in the Charter and other materials we
only refer to the specs, not to "IndieUI" as an entity, and the
title change reflects this.
The original proposed title was "Requirements for IndieUI", thus the names of the two specifications were added to the title of the requirements document. For consistency, in the Status section and elsewhere, this change was also made.
We can revisit the title later, if desired.
Michael notes that these are editorial changes.
James is working on the UIController/UITrigger proposal (discussed at an earlier meeting). He hopes to complete a draft of that work this week.
James proposes to omit MoveRequest from the 1.0 version, since it relies on MarkRequest, which is complex and not included in 1.0. Sometimes, MoveRequest stands alone, but this can create confusion, e.g., how an assistive technology distinguishes a move request from a directional focus reuest.
Responding to a question, James clarifies that the confusion lies in the fact that there's no clear distinction as to how to distinguish the directional focus from move request on items that can be manipulated using both.
<janina> 3~q?
Example: arow keys may be used to move an object or to dispatch directional focus events to change the focus, e.g., a grid. The same container may receive both types of requests, something that authors should take care to avoid.
The other difficulty is that move requests are often dependent on mark requests, but the latter feature is postponed until a later version of the spec, so an important aspect of MoveRequest can't be implemented in 1.0.
<jcraig> and markrequest, a prerequisite for some aspects of moverequest, has already been punted for 1.0
Andrew: the first confusion could be clarified in the spec by making it clear that move (contra focus) changes the state of the object.
His example: a list of programs (with associated priorities) to be recorded - there are focus changes as well as move requests to alter the priorities where items to be recorded are broadcast simultaneously.
James: either you distinguish the two events at the input level or require the user interface to change modes from editing to navigation.
Janina: an alternative to removing it is to mark it at risk.
James: we can always mark it risk
if nobody implements it.
... suggest leaving it in, as Andrew already has a scenario in
which it would be useful.
To substantiate the problem, we need to find a device-specific interface scenario in which there aren't enough distinct controls to be mapped to the distinct IndieUI abstract events (move and directional focus). In the absence of such a concrete example, there isn't a problem to be solved here.
James proposes to leave the feature in the spec, but mark it at risk later if necessary.
Current objective: publish a heartbeat draft of Events by 22 May.
James anticipates finishing the major edits this week.
Janina: we would need a call for
consensus during the week of the 14th in order to
publish.
... the call for consensus would thus end on 21 May.
... suggests making the call for consensus on 12 May.
This publication should attract interest from reviewers.
Responding to a question from Rich, James clarifies that we shouldn't add potentially complex work for implementors to 1.0, and mark request falls into this category for both implementors and authors.
James would prefer the basic aspects to be adopted first, then more complex events can be introduced later.
Mark request example (James): a list of mail messages in which multiple items can be selected and then an operation can be performed on them collectively. Selected items need not be contiguous. Meeting platform-specific behaviour requirements makes it a complicated abstract event to implement.
Janina notes we're looking for uptake initially and this is an important consideration.
Janina notes the timeline for Events - draft in May, Last Call potentially late October.
<jcraig> ACTION-80?
<trackbot> ACTION-80 -- James Craig to Link notes about screenreader privacy concerns, and try to address in the screenreader section, not just the security section. Add normative statements that implementors MUST NOT implement high security interfaces like screen reader until the user security model is in place. -- due 2014-03-12 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/80
Thus in a June/July timeframe we could publish a draft of User Contexts. Privacy is a major concern, suggesting that we invite participants in the privacy group to a call.
Before doing so, we should clarify the issues that need discussion.
James clarifies the User Contexts is our user preferences specification, giving examples of a Web application that can respond to a need for large fonts or captions, and altering its UI appropriately.
He notes privacy concerns and that the user should be able to decide what and whether to disclose preferences to a particular Web site/application.
At a minimum there would be a prompt presented to the user.
The prompt could include an explanation (supplied by the Web application) of why the specific preference type is being requested.
James clarifies, in answer to a question, that users of captions, for example, identify themselves to Web applications in ways that screen reader users currently don't, even though there are heuristics (not well known currently) that can be used to detect them.
Hence there is reason to be concerned about screen reader/assistive technology preferences with respect to privacy that don't apply to some of the other preferences supported by IndieUI User Contexts.
James agrees with a suggestion from Janina that we are enhancing privacy by providing a model for it and enabling the user to decide what and to whom to disclose.
Janina notes that the scope of User Contexts 1.0 will be limited, raising concerns, especially when people compare it with GPII and other work in the area.
Janina notes that we will discuss any concerns raised prior to publishing Events, then move into the privacy discussion surrounding User Contexts.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/this can be done if nobody implements it./we can always mark it risk if nobody implements it./ Found Scribe: jasonjgw Inferring ScribeNick: jasonjgw Default Present: +1.215.518.aaaa, janina, kurosawa, Michael_Cooper, jcraig, Rich_Schwerdtfeger, Preety_Kumar Present: +1.215.518.aaaa janina kurosawa Michael_Cooper jcraig Rich_Schwerdtfeger Preety_Kumar Found Date: 30 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/30-indie-ui-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]