See also: IRC log
<trackbot> Date: 20 February 2013
<janina> Meeting: IndieUI Task Force Teleconference
<MichaelC> scribe: jasonjgw
Participants introduce themselves.
<Ryladog> Sorry late
<Andy_> yep :-)
<richardschwerdtfeger> chuckle
<MichaelC> http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0001.html
<MichaelC> http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0002.html
Michael: there have been some substantive comments on the list.
<jcraig> ACTION: jcraig to address IDL feedback in http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0001.html [recorded in http://www.w3.org/2013/02/20-indie-ui-minutes.html#action01]
<trackbot> Created ACTION-38 - Address IDL feedback in http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0001.html [on James Craig - due 2013-02-27].
The links are to substantive comments that need discussion.
<jcraig> ACTION: jcraig to address comments or raise issues from http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0002.html [recorded in http://www.w3.org/2013/02/20-indie-ui-minutes.html#action02]
<trackbot> Created ACTION-39 - Address comments or raise issues from http://lists.w3.org/Archives/Public/public-indie-ui-comments/2013JanMar/0002.html [on James Craig - due 2013-02-27].
This discussion should be scheduled for a meeting.
Janina: raises the scope issues introduced in the last meeting.
<richardschwerdtfeger> q:
James: it is necessary to keep the user contexts spec narrowly focused. Some of the points raised in discussion are important and others remain outside the scope of the working group.
Rich: those who joined the working group do not wish to limit the contexts to operating system features. GPII is a source that should be supported. The user contexts has a much longer timeline than the events module.
James notes that the timeline will be long due to privacy questions. There are preferences that can be changed in operating systems today, and a Web application should have access to those existing preferences. There are additional preferences (e.g., captions) that can be provided by the Web application; this kind of preference
is not programmatically determinable, in which case a UI or other module is necessary to collect such preferences. This can extend the time-frame significantly.
Janina notes the requirements for two implementations at the CR stage.
Katie maintains that if we're not calling for implementation of a UI or other mechanism then it won't happen and thus suggests that these mechanisms are important.
<Zakim> MichaelC, you wanted to talk about v1 and v.next and triaging requirements
Rich maintains that asking for a simplified interface due to a user's cognitive disability should be within scope, for example, and a basic set of preferences should be included that a user can easily set. Needs/preferences should not be limited to waht is implemented in operating systems at the present moment.
Michael suggests that we should distinguish between the current and next versions of the spec, and that items can be moved between these versions as work progresses.
<Zakim> jcraig, you wanted to discuss the optional taxonomy parameter
James notes that there is a mechanism to request an optional taxonomy, and the basic list (need/preference taxonomy) can be extended by a browser, e.g., to list parameters from GPII, and a settings UI can be added as a browser extension.
This interface could even be provided by third-party tools.
This extension facility allows a larger vocabulary to be implemented without including it in the main spec.
Andy notes that the proposed vocabulary is a small subset of the full set of GPII terms. It won't be feasible to discover how implementable some of these are until more work is done.
Rich distinguishes the extensive support provided by GPII for learning contexts from the smaller need/preference set suitable for browsers and mobile devices. He argues that the IndieUI Events are not implemented in any browser either.
Janina urges the need to build consensus and hopes to avoid majority voting. She proposes to conduct an item-by-item analysis to consider which should be included.
<Zakim> jcraig, you wanted to use "simplifiedInterface" as an example; and respond to Andy's comment that it's easy to "throw stuff out of the spec" later
James notes the indeterminate meaning of a concept such as "simplified interface", and that such ill-defined terms shouldn't be included in the spec.
Andy maintains that how an author responds to such a request (for a simplified interface) shouldn't be specified. He agrees with Janina that a case-by-case analysis of preferences should be carried out.
Rich argues that a simplified version of the page (with fwer controls to allow the user to accomplish a task) is a well-defined notion that can be specified.
James gives the example of a "simplified interface" setting which is on because one site, e.g., shows 5 lines at a time, but anther makes very different changes taht the user doesn't desire; the user would have to toggle the setting when visiting different sites.
Katie suggests taht notions such as plain text can be well defined and specified and this is easier than that of a simplified interface.
Andy maintains that surely having one site which the user can't use is better than having two.
James is concerned with the generalization of preferences that apply to one Web site to preferences implemented differently by different sites. The spec should be written to avoid misinterpretation.
Rich reminds us that one reason why learning/cognitive issues haven't been addressed is that for each person, the needs are different for each person. We need to be able to require a page that has a limited nmber of controls so that a user can understand it; this is not a perfect fit [with any particular user's needs] but it can be well defined and specified.
Andy suggests that the normative/informative distinction could be used to address some of these concerns.
<Zakim> MichaelC, you wanted to suggest that we might want to review / edit requirements http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements to see what we think should be in
Michael reminds us that there are no rules as to whether best practices should be in the spec as informative material or whether they should be in an external document. He suggests going back to the requirements and seeking agreement on what they are and how they are prioritized.
<Ryladog> +1
James distinguishes the issue of dealing with preferences that don't exist in a mainstram interface from that of defining a set of preferences associated with simplification requirements that can be well defined and which are not amenable to inconsistent interpretations by implementors.
He suggests that browser extensions can provide a pathway for implementations to move into a browser proper once it has matured (when it becomes popular enough to justify native support). For 1.0 he recommends confining the spec to preferences that already exist.
<Zakim> MichaelC, you wanted to talk about coordination with other organizations, and which ones we instantiate in IndieUI: User Context
Michael notes that other efforts are underway in regard to preferences. He suggests enhancing our coordination efforts with organizations involved in such work to define exactly what the preferences are.
Andy argues that analyzing a "simplified interface" requirement into more specific requirements introduces dependencies on specific technologies (as has been seen in the development of other specs in this area) and that the way in which an application responds to the simplification request should be left to the application developers to determine.
<Zakim> jcraig, you wanted to discuss the political will
Michael notes the time and suggests planning next steps.
James argues that the less contact there is with what is implemented in current UAs and operating systems, the less interest there will be from potential implementors. He suggests addressing currently implemented preferences in 1.0 and then specifying other well defined preferences for the next version.
Michael notes that we could use the "at risk" designation to distinguish features that need to be examined by reviewers for feasibility of implementation.
Rich notes that the needs/preferences brought to the group are all easily implemented; they are not general or theoretical.
Michael notes that there are common goals but debate about how to get there. It isn't clear which requirements apply to Events and which to User Contexts; we should clarify this and engage in a discussion of requirements specific to user contexts.
He suggests a fresh examination of requirements before the next meeting.
He notes the desirability of coordinating with IMS and GPII.
James proposes to edit the spec to include those parts of the proposal from Rich and Andy which are not controversial.
In respose to a question from Rich, there is discussion of which sections of the spec should be reviewed now - James recommends reviewing section 1 now.
Andy notes the relevance of work takng place in a range of standardization efforts and suggests that cordinating with them would be premature currently.
Michael: James will perform edits that will help to clarify (when discussed) which proposed needs/preferences are controversial and which are not.
Rich agrees that editing should be carried out as proposed.
There is discussion of the issues list and how relevant items should be addressed.
Michael: he and Janina will propose next steps to carry forward this discussion. Discussion to be continued on list and at the next (regularly scheduled) meeting.
Meeting concludes.
rssagent, make minutes
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: jasonjgw Inferring ScribeNick: jasonjgw Default Present: Rich, Janina_Sajka, Jason_White, Rich_Simpson, Michael_Cooper, +1.919.604.aabb, jcraig, Andy_Heath, Stephen_Woodburn, +1.703.861.aacc, Katie_Haritos-Shea Present: Rich Janina_Sajka Jason_White Rich_Simpson Michael_Cooper +1.919.604.aabb jcraig Andy_Heath Stephen_Woodburn +1.703.861.aacc Katie_Haritos-Shea Found Date: 20 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/20-indie-ui-minutes.html People with action items: jcraig WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]