See also: IRC log
<trackbot> Date: 14 November 2012
<janina> Meeting: IndieUI Task Force telecon
Zakim: I am Joseph_Scheuhammer
<andy> is this me?
<scribe> scribenick: clown
JS: at f2f in lyons discussed
changing meeting time to be later.
... 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.
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
regard.
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.
action-29?
<trackbot> ACTION-29 -- Sangwhan Moon to send list of Opera use cases and suggest requirements for mainstream events -- due 2012-12-01 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/29
JC: Sangwhan says he is working on it.
action-11?
<trackbot> ACTION-11 -- James Craig to incorporate Andy Heath's and Rich's proposal into User Context spec -- due 2012-09-26 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/11
JC: we'll talk about that with andy
JS: questions?
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> 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> 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
about.
... 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
quickly.
... 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
app.
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 explanation.
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
combinations
<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
preferred.
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 javascript.
<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 industry.
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
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) Succeeded: s/but on another call/but on another day/ Succeeded: s/get a time that works for Tokyo and for Europe/get a time that works for US+Tokyo and another time that works for US+Europe/ Succeeded: s/there is also/there are also/ Succeeded: s/is not in there/is now in there/ Succeeded: s/exapnd/expand./ Found ScribeNick: clown Inferring Scribes: clown Default Present: Janina, Joseph_Scheuhammer, jcraig, Rich, andy, Caroline Present: Janina Joseph_Scheuhammer jcraig Rich andy Caroline Found Date: 14 Nov 2012 Guessing minutes URL: http://www.w3.org/2012/11/14-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]