W3C home > Mailing lists > Public > public-indie-ui@w3.org > November 2012

Minutes; 14 Nov 2012 Indie UI Teleconference

From: Joseph Scheuhammer <clown@alum.mit.edu>
Date: Wed, 14 Nov 2012 14:00:44 -0500
Message-ID: <50A3EA5C.1090303@alum.mit.edu>
To: Independent User Interface Task Force <public-indie-ui@w3.org>
Please find the minutes from the Nov 14 2012 PFWG telecon at the 
following location and also in text below:


[1] http://www.w3.org/


Independent User Interface Task Force Teleconference

14 Nov 2012

See also: [2]IRC log

[2] http://www.w3.org/2012/11/14-indie-ui-irc


Janina, Joseph_Scheuhammer, jcraig, Rich, andy, Caroline




* [3]Topics
1. [4]Telecon Time Scheduling
2. [5]time of meeting
3. [6]Editor's Draft
4. [7]User Needs Capture
* [8]Summary of Action Items

<trackbot> Date: 14 November 2012

<janina> Meeting: IndieUI Task Force telecon

Zakim: I am Joseph_Scheuhammer

Telecon Time Scheduling

<andy> is this me?

<scribe> scribenick: clown

time of meeting

JS: at f2f in lyons discussed changing meeting time to be
... europeans liked this.

JS 23:00 CET, 22:00UTC 5:00pm EST

JS: can no longer commit to that time as I have another
commitment to travel to.
... wonder is 4pm EST would work.

JC: San-wang should be in on this discussioin (in Tokyo).
... let's put a proposed time in the list.

JS: no objections to 4pm? That gets back when we get to
daylight saving time
... 5am in Tokyo in daylight time.
... or, stay with 5pm EDT but on another day.
... we're taking about 9 or 10pm in London.

CJ: that's ok.

JC: every other time?

JS: not clear.
... I think it would be acceptable.

JC: if it is every other time, then let's get a time that works
for US+Tokyo and another time that works for US+Europe

JS: I will explore tokyo plus US
... will take this to email
... other days of the week that are possible?

AH: there are for me.

JS: let's take to email discussion.

Editor's Draft

JC: I'm not thru all the edits disucssed at the f2f
... I've posted some to the list, and we can discuss those.
... removed DOM changed request events
... that requires the AT to know a lot about how the web app
works, and that can't be expected.
... next big edit was adding the UIPanRequest event
... now a delta-x and y, and that makes more sense.
... added a Zoom event.
... sometimes they are discreet, and sometimes they are
continuous (e.g. scrioll wheel to zoom into a map).
... might want a zoom start and zoom end event.
... that's still in discussion.
... and, I made edits to respect the ReSpec rules.
... user context draft needs a lot of work still in this

JS: discussion?

JS; James, you suggested we go thru closed actions/issues?

JC: that was the update I just gave.
... but there are also a bugzilla products for indieui event
and one for indieui context
... joseph's notes from the group's proposal is now in there.


<trackbot> ACTION-29 -- Sangwhan Moon to send list of Opera use
cases and suggest requirements for mainstream events -- due
2012-12-01 -- OPEN

<trackbot> [9]http://www.w3.org/WAI/IndieUI/track/actions/29

[9] http://www.w3.org/WAI/IndieUI/track/actions/29

JC: Sangwhan says he is working on it.


<trackbot> ACTION-11 -- James Craig to incorporate Andy Heath's
and Rich's proposal into User Context spec -- due 2012-09-26 --

<trackbot> [10]http://www.w3.org/WAI/IndieUI/track/actions/11

[10] http://www.w3.org/WAI/IndieUI/track/actions/11

JC: we'll talk about that with andy

JS: questions?

User Needs Capture

JC: can I pull it back one?
... action for column sorting events for grids
... unless any objections, I was going to propose something in
an edit, and then send it to the list.

JS: hearing no objections.
... this is coming together nicely, thanks to James' work.
... the meeting in Lyons was really good.
... andy?

AH: My action is to go through the user needs out there and
produce a set that we would incorporate.

<jcraig> Sorry, ACTION-11 earlier was supposed to be ACTION-25

<jcraig> ACTION-25?

<trackbot> ACTION-25 -- James Craig to 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) --
due 2012-11-09 -- OPEN

<trackbot> [11]http://www.w3.org/WAI/IndieUI/track/actions/25

[11] http://www.w3.org/WAI/IndieUI/track/actions/25

<jcraig> heh. Not that one either

<jcraig> ACTION-18?

<trackbot> ACTION-18 -- Andy Heath to summarize important or
common preferences/keys list from AfA/APIP/GPII, etc. and send
to the IndieUI group for discussion and potential inclusion in
the User Context deliverable. -- due 2012-11-08 -- OPEN

<trackbot> [12]http://www.w3.org/WAI/IndieUI/track/actions/18

[12] http://www.w3.org/WAI/IndieUI/track/actions/18

<jcraig> There it is. ;-)

AH: what is the scope of this?
... I posted a discussion about this.
... there is a core of things that a device can do something
... that relates to preferences that exist for that device.
... several reasons to involve prefs to just pass to the webapp
... want to get people's views on this scope problem.
... it would be useful to write something into the draft fairly
... in order to make that clear.

<Zakim> jcraig, you wanted to ask for an example of what you
have in mind

AH: the scope currently is a lot narrower than I thought is
would be.

JC: what do you have in mind?
... what do you mean by prefs that are passed up to the web

AH: screen-enhanced content might be a case.

JC: what do you mean by enhance?

AH: colour transform for example.

JC: what does that mean? not being contentious, just want and

AH: audio transcripts — all sorts of things that <?>

JC: something like "prefers video descriptions" could be <?>

RS: the user prefs doesn't care who does the transformation.
... we are confusing people.

AH: there might be situations where…

JS: stick with the colour example. that might be simpler.
... might need a dark background with lighter fonts.
... and there might be problems with certain colour

<jcraig> a dark-on-light key versus light-on-dark key is
actionable. "color transform" is vague

AH: sometimes you can do that on the devcie, and other times
where one can't.
... there are a whole host of these.
... some of these can be handled by the device.
... but others where the device can't handle it, so pass it up
to the web app to deal with.
... and other where the device can handle it, but the webapp
does a better job.

RS: when developing these prefs, we should take into account
the capability of the device.

AH: can we do something to put these ideas into the draft?

JC: the plan is to constantly update the draft.
... but I'm still confused by the core of your idea.
... are you talking about GPII?

AH: no, simply talking about passing it on to the webapp.

JC: passing it from where?

RS: let's take high contrast.
... if preferred, and the platform has it, don't pass it on
because it's handled by the device.
... if we expose these things, we need to be more explicit.
... if the device currently has the setting on...
... it's already satisfied by the device.
... you would not want to pass the preference on.
... when we define these prefs, we should provide guidance to
the browser developers about passing it on.
... let's go thru the preferences, and vet them with the group.

AH: can we get something into the editor's draft now, and share
it with others?

JC: can you propose some text?
... the keys we need to state whether a natvie feature is on,
and a key to say that the native setting is not necessarly

AH: okay, it will a different preference.

JC: just a suggestion.

<janina> I'm wondering whether third party service should be
out of scope for us.

<Zakim> jcraig, you wanted to say I still don't know what you
mean by device can't respond a pref but the device "pass it up"
and I think what you're talking about is out of scope.

JS: we can decide if andy's proposals are in scope or not.
... Greg V has a "tried harder" notion.
... where you can access a third party way off in the cloud to
help you out.

<jcraig> I think we're in agreement now. Andy agreed to send
some suggested text to the list.

JS: I think this is out of scope for us.
... or, do we want a third party server to do this?

JC: don't think andy was asking for that.

AH: there might be.

JS: I think we should not consider those ones.

AH: there are prefs that the device cannot respond to, but you
still want those preferences stated.

JS: are we thinking that other servers that could provide the
transform, that this process is in scope.

JC: are you talking about http services as opposed to client

<andy> good phrasing of it james

JC: Janina was asking for something like QuickTime ref movie
requests, which might respond with a low rez version or one
with captions.
... I think that is out of scope.
... I think andy's ideas are in scope.

<andy> I will do

<andy> seems I'm not heard so I'll type it

JC: I think we need to expand. the list of keys.

<andy> fair enough - except in the longer run the differences

AH: in the longer run, the differences are a difference in
degree of complexity.

JS: we are looking for a baseline that will be adopted by the

AH: I will write some text.

JS: and, to keep ourselves from being ambitious for 1.0
... we need 1.0 to be a roaring success.
... that's the end of the agenda. Anything else?
... a scribe for next meeting, please. Nov 28th.

<jcraig> The list of defined prefs is short at the moment
(fontsize, captions, screenreader, etc) but we can and
certainly should add more for 1.0, as long as they are
generally useful.

JS: no volunteer. We will find a scribe at the next meeting.

RRSAgent: , draft minutes

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's [13]scribe.perl version
1.137 ([14]CVS log)
$Date: 2012/11/14 18:54:25 $

[13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[14] http://dev.w3.org/cvsweb/2002/scribe/


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -
Received on Wednesday, 14 November 2012 19:01:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:13:18 UTC