- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 21 Feb 2013 09:46:45 -0500
- To: public-indie-ui@w3.org
- Message-ID: <51263355.10501@w3.org>
Minutes of the 20 February 2013 IndieUI meeting are posted to
http://www.w3.org/2013/02/20-indie-ui-minutes.html and copied below.
Independent User Interface Task Force Teleconference
20 Feb 2013
See also: IRC log <http://www.w3.org/2013/02/20-indie-ui-irc>
Attendees
Present
Rich, Janina_Sajka, Jason_White, Rich_Simpson, Michael_Cooper,
jcraig, Andy_Heath, Stephen_Woodburn, Katie_Haritos-Shea
Regrets
Chair
Janina_Sajka
Scribe
jasonjgw
Contents
* Topics <http://www.w3.org/2013/02/20-indie-ui-minutes.html#agenda>
1. Events Issues & Actions
https://www.w3.org/WAI/IndieUI/track/products/2
<http://www.w3.org/2013/02/20-indie-ui-minutes.html#item01>
2. User Context Issues & Actions
https://www.w3.org/WAI/IndieUI/track/products/3
<http://www.w3.org/2013/02/20-indie-ui-minutes.html#item02>
* Summary of Action Items
<http://www.w3.org/2013/02/20-indie-ui-minutes.html#ActionSummary>
------------------------------------------------------------------------
Participants introduce themselves.
Events Issues & Actions
https://www.w3.org/WAI/IndieUI/track/products/2
<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.
User Context Issues & Actions
https://www.w3.org/WAI/IndieUI/track/products/3
Janina: raises the scope issues introduced in the last meeting.
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.
Summary of Action Items
*[NEW]* *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]
*[NEW]* *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]
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.137 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-02-20 23:12:42 $
--
Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>
Received on Thursday, 21 February 2013 14:49:24 UTC