See also: IRC log
<trackbot> Date: 03 October 2012
<janina> Meeting: IndieUI Task Force telecon
<janina> Below]
<scribe> ScribeNick: hober
janina: fyi, we've surveyed about different/rotating telcon schedule
<clown> https://www.w3.org/2002/09/wbs/54997/2012_meetings/results
janina: the current schedule is
late in the day for europe and middle of night for asia
... survey is open through tomorrow
... we'll talk it over on the list and on the call
richardschwerdtfe: what sort of conflicts do we have?
janina: [describes global interest]
MichaelC: each of the two times
in the survey would gain us one person who is not currently
attending this time
... gain of one person might not be worth it; need more people
to vote
janina: the education and outreach wai wg maintains overview pages for each wai activity
<janina> http://lists.w3.org/Archives/Public/public-indie-ui/2012Oct/0002.html
janina: they've drafted an
overview page for the wai indie-ui wg
... please take a look, check for accuracy, etc.
... audience is non-technical
... should be readily understandable, accurate, and
comprehensive
<janina> http://lists.w3.org/Archives/Public/public-indie-ui/2012Oct/0002.html
janina: any questions about this page?
<clown> actual page is here: http://www.w3.org/WAI/EO/wiki/IndieUI_Overview
<shepazu> http://www.w3.org/WAI/EO/wiki/IndieUI_Overview
shepazu: could we take a minute now to skim?
janina: yes
richardschwerdtfe: the
introduction only talks about device independent events and not
the user context
... could also mention scroll wheel in scrolling example
janina: [introduces Shawn]
<Ryladog> +1 to include AT in Intro
Shawn: we're trying to cover what
this is for in the introduction, and then we talk about each
document in the documents section
... the intro captures the idea, why we're doing this
richardschwerdtfe: in the first
sentence, not just a wide range of devices, but also a wide
range of users and the contexts in which they operate
... could use more of a "command" example like "open", instead
of a device-tied example like "scroll"
... you might have an "open" event, top open a folder, to open
a new row in your document
... or other high-level examples like zoom in, zoom out
shepazu: scroll seems less compelling, it usually has a lot of existing affordances
Shawn: for either zoom or open, what would the sentence be like?
<andy> hoper - sorry - just saw this - I suggested "wide range of user needs and devices"
richardschwerdtfe: "a user
operating a web application may wish to open a folder using a
broad range of device commands such as a gesture, a voice
command, etc. Indie-UI allows the device to send a simple
'open' event to the application regardless of how the user
signaled..."
... in both the intro and the documents section
Shawn: would this be an additional example or replacing the existing one?
shepazu: combine the two
... [expands on that]
<Zakim> jcraig, you wanted to suggest escape/dismiss example and to say "open" will be too easily confused with "click"
<Ryladog> Better to use the word 'Context' (as Rich suggests) with (use needs, preferences, access device) in parans after it. Example: 'Context' (as Rich suggests) with (use needs, preferences, access device)
jcraig: wordsmithing is probably not the best use of telcon time
<Ryladog> Soory, somehow I muted myself
jcraig: rich's example of open could also be confused by users, like scroll
<Ryladog> Zakim unmute me
jcraig: we could use an escape or
dismiss gesture
... lots of people capture ESC key
Ryladog: the word 'context' as
rich suggested is key
... important to make this broader, and 'context' does that
Shawn: scroll seems so much
stronger for novices
... could you say the same sort of thing for escape or
dismiss?
janina: we're not sure what to
call it, so it might not be a good example
... zoom is also common, like scroll
Shawn: do you want me to draft
wording for zoom?
... is it ok to put out a draft of this with scroll?
shepazu: that's fine
janina: you can send it to the mailing list
clown: if we want to replace the
scroll event example, we could use a checkbox
... [describes various ways of toggling a checkbox]
jcraig: checkbox is already
covered by click events
... scroll is fine for now, zoom too
<Zakim> Joseph_Scheuhammer, you wanted to suggest a checkbox as a very concrete case.
jcraig: some examples of escape or dismiss: kbd ESC, voice over has a gesture, android has a back button
andy: re: the "indie ui: user context" paragraph, user settings is too narrow, maybe 'preferences' would be better?
Shawn: we could swap them around, would decouple it from AT
andy: the word 'settings' doesn't say what sort of settings
shepazu: can we wordsmith over email?
janina: i think we should
Shawn: will try to get an email out today
janina: those of you who are in
the wai wg, we have a brief telcon next week
... for administrative topics
... re: TPAC, our agenda is on our wiki page
<MichaelC> IndieUI TPAC 2012 meeting page
janina: we've had a submission; ac is considering it
ArtB: web events wg welcomes the
submission
... if we assume the wg gets created, it affects some web
events work
... and our participation in indi-ui tf
... web events will continue working on the touch events
v1
... to CR
... we will stop work on touch events v2
... instead we'll work with pointer events wg
... once touch events v1 rec is published, web events wg will
close
... so how do web events participants continue participating in
this tf?
... most straightforward way would be to ask web events folks
to join the wai wg
shepazu: [talks about the pointer
events model; prefers it to the touch events model]
... if web events shuts down, don't know what that will mean
wrt my involvement in this tf
MichaelC: if that happens, should this tf become joint with pointer events wg?
shepazu: no
... they want to be very focused, don't want to veer off on
high-level events
janina: how does the pointer events model handle multiple finger events?
shepazu: it doesn't do gestures, it does multiple fingers
<Zakim> janina, you wanted to ask how pointer events will handle multip-finger touch events
ArtB: we should keep pointer events really narrowly scoped
MichaelC: web events wg participants in this tf are invited to join the wai indie-ui tf
janina: AC voting goes on through
the 25th
... not a done deal yet
MichaelC: 4 or 5 people would be affected
janina: jcraig, let's have a regular check-in; any updates on the draft?
jcraig: working through the open issues as i have time
<jcraig> action-5?
<trackbot> ACTION-5 -- Joseph Scheuhammer to author draft spec. change for james craig to include place holders for agreed upon events today in -- due 2012-08-29 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/5
jcraig: there's one action item on joseph
clown: can close it or assign it to jcraig:
janina: any questions?
janina: we should focus a significant amount of time at tpac on use cases
richardschwerdtfe: pick back up at use case 6
<richardschwerdtfe> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements#S6:_Command_move_the_focus_point_within_a_UI_component_down_to_the_next_focusable_item_within_a_UI_component
richardschwerdtfe: if you're in a widget and want to move down in the widget, could have a command for that
jcraig: do we already have
something like this?
... it says "move down to the next *focusable* item" instead of
just "the next item"
... basically the equivalent of TAB or Shift-TAB
richardschwerdtfe: what terminology would be better?
jcraig: we could just remove the word "focusable"
richardschwerdtfe: if you have a list box, going to each of the items
jcraig: following para might need some wordsmithing, or a note that says this isn't the same as TAB/Shift-TAB
richardschwerdtfe: maybe "within a ui component"?
janina: isn't this about local navigation? "local next"/"local previous"
<Ryladog> FYI........Many User cases in this doc have the typo "supports supports" in the first sentence
jcraig: let's start by taking the word "focusable" out and go from there
<Ryladog> +1 remove word Focus
richardschwerdtfe: do we need an action item to get this into the spec?
jcraig: i think the use cases are
clear; we should keep working on them in the wiki
... some of them are already covered, some aren't
... i will do a comparison with the spec
... use case 7 also needs that same change
clown: it shouldn't be down/up,
it should be next/previous
... set of items, there's a next/prev relative to where you
are
richardschwerdtfe: left & right v. up & down, we need this separate for two-dimensional widgets
Ryladog: also 3D
janina: we decided to put 3D off
clown: in grid, next/prev in row, next/prev in col
richardschwerdtfe: what about a flow diagram?
clown: suppose you have a tree
like OS X's Finder
... could be rendered on an iPhone as swiping left/right
... still a tree
... shouldn't be tied to the rendering
<Zakim> Joseph_Scheuhammer, you wanted to suggest next/previous instead of up/down
janina: agree with clown
Ryladog: for the moment, yes
richardschwerdtfe: how about "in a horizontal direction, next and previous"?
Caroline_Jay: i think this
important for grid widgets like date pickers
... i tend to agree with clown
jcraig: use case 6 through 9 are
all in this "linear directional navigation" context
... clown had the right idea, this is a general
next/previous
... visual left/right is locale dependent
<Ryladog> what about vertical languages?
jcraig: "general next" and
"general previous", which might be left/right in ltr
languages
... grids might need special directional navigation
events
... once you're in a managed focus widget like a grid or a
tree, then the next/prev is like "change selected value"
... need to indicate that there's a multi-dimensional value
change
<Zakim> jcraig, you wanted to mention s8 and s9. I like Joseph's idea of vertical vs linear
richardschwerdtfe: you might be moving in increments?
jcraig: something like a slider,
next notch in slider is incrementing the value of the
slider
... but tree widgets have a selection state; current use case
for incrementing slider may also apply for these sorts of
cases
... we should focus on the primary next/previous instead of
left/right
... would be good to have special-cased "vertical
next/previous"
... vertical v. linear
andy: isn't this just like tab order anyway?
<clown> "it's"
andy: the case for general
next/previous within some order
... what does next/previous mean in a tree with unordered
subnodes
... next/prev gets parameter that varies depending on the kind
of object
Ryladog: definitely don't use right/left due to vertical and rtl languages
richardschwerdtfe: we've agreed on a next and previous; should i separate out vertical and horizontal?
jcraig: i'll send an email to the list
janina: yes, let's do this on the list
jcraig: it's possible that this
is just covered by focus events
... we can have a separate at focus (point of regard focus)
different from the kbd focus
... then we don't need next/prev, we just alert the app "this
is the item i'm on"
Ryladog: richardschwerdtfe, there's diagonal too
richardschwerdtfe: they had directional work in SVG 1.2 tiny, could look at that
janina: let's try to figure out
how to group these for better tpac time
... next meeting in 2 weeks, wai wg in 1 week
RRSAgent: make logs public
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/example of open is also confused/example of open could also be confused by users/ Succeeded: s/topisc/topics/ Found ScribeNick: hober Inferring Scribes: hober Default Present: Janina_Sajka, shepazu, hober, Michael_Cooper, Joseph_Scheuhammer, Andi_Heath, Art_Barstow, Andy_Heath, Rich, +1.626.841.aaaa, Katie_Haritos-Shea, Shawn, jcraig, Caroline_Jay Present: Janina_Sajka shepazu hober Michael_Cooper Joseph_Scheuhammer Andi_Heath Art_Barstow Andy_Heath Rich +1.626.841.aaaa Katie_Haritos-Shea Shawn jcraig Caroline_Jay Found Date: 03 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/03-indie-ui-minutes.html People with action items:[End of scribe.perl diagnostic output]