Telecon Time Scheduling

time of meeting

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.

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
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> 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

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

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.

Scribe.perl diagnostic output

[Delete this section
before finalizing the 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.