Draft: Minutes DHTML StyleGuide Call 2007-09-07

IRC logged minutes of today's DHTML Style Guide Meting are available 
online, at:

http://www.w3.org/2007/09/07-pf-minutes

and below as text -- i think i captured everyone in attendance, if not,
please reply to this message on list to indicate that you, too,  were in
attendance...

--------------------------------------------------------------------------

                                   - DRAFT -

                           DHTML Style Guide Meeting
                                  7 Sep 2007

   See also: IRC log (http://www.w3.org/2007/09/07-pf-irc)

Attendees

   Present
          Tim_Boland, Don_Evans, RichS, Becky_Gibson, Tim_Boland,
          Al_Gilman, Gregory_J._Rosmaita, Jon_Gunderson, Chris_Blouch,
          Earl_Johnson

   Regrets
          none logged
   Chair
          don
   Scribe
          gregory

Contents

     * Topics
         1. drag and drop
     * Summary of Action Items
     _________________________________________________________________

   <Rich> chair: Don

   <scribe> scribe: gregory

   <scribe> scribenick: oedipus

Topic 1: drag and drop

   <Rich> http://esw.w3.org/topic/PF/ARIA/BestPractices/DragDrop

   RS: (for reference consult above URI)
   ... working on drag drop example: want to create something in BP guide
   how to do draganddrop -- LisaP asked me to pass this by the DHTML
   style guide team

   <Rich> http://www.w3.org/TR/aria-state/#dragdrop

   RS: (refers to link) drag and drop features challange for PWDs -
   manipulating mouse, finding targets, dropping in correct place, etc.
   -- use may not be aware of drop operation; result: frustration; ARIA
   introduces 2 draganddrop
   ... grab and dropeffect; aaa:grab what is being "grabbed and dragged"
   aaa:dropeffect communicates result of drop; step 1 id indifiable
   objects - objects capable of being dragged MUST have a determined role
   -- no DIV!; repurpose target to apply -- marks element that can be
   dragged and dropped; aaa:grab grabs supporting object -- authors can
   use CSS to highlight elements that are draggable; all draggable
   objects must be accessible from keyboard; no keyboard mapping
   ... step 2: allow user to activate the drag operation (reviews
   technical details contained in
   http://www.w3.org/TR/aria-state/#dragdrop)
   ... suggested control-shift-10 on control object; add to list of menu
   items; escape should close popup window and restore previous focus;
   ... feedback needed -- should we have a hotkey? once drag selection
   made, should do close and move focus to grabbable object and receive
   aaa:grab

   BG: didn't talk about drag option, but supporting drag
   ... grab equals supported grabbed equals true?

   RS: if in menu and select, in grab mode; third part: app knows what is
   dragged, identifies potential targets -- marke by setting markeffect
   to copy to reference space on menu or hotkey; drop objects must have a
   defineable mode; any object without drop effect will have assumed
   value of none; should be excluded from dragdrop operation
   ... next step: configure script to handle mouse operations (selected,
   go into mousemode, move mouse around desktop) at will move mouse to
   accepting drop partners -- app will move map or adjust menu; user
   hitting defined key will execute drop; can always cancel -- resets
   drop to none
   ... step 5: cleanup
   ... other considerations: right now, drop effect can support more than
   one value -- should that be the case?
   ... once user navigates target, user needs to be able to execute drop;
   determined upon previous selection; must then perform cleanup --
   thoughts? more than 1 way of doing this? if only 1 way, simplifies
   things; keyboard operation implications?

   CB: pick mark and action sequence -- pick what want moved, mark for
   movement, and action (moveto and drop); chance to change action?

   RS: hit escape to go back to where you began

   CB: pick destinations, then execute actions -- makes more logical
   sense

   RS: user doing picking?

   CB: yes, id target, decide what to do, and then do it

   RS: only author or app knows drop targets -- here are all that match
   accept patterns, choose one

   CB: pick, then mark, then execute user demand

   RS: make informed decision based on what is supported by app

   CB: six of one - half dozen of others; what about pick and replace?

   RS: hadn't considered that -- wasn't a use case i considered

   CB: copy, move replace file operations

   RS: if valid use case can bring to group

   AG: always a challange to perform dragdrop -- could be by-product of
   follow-up dialog -- either move or copy;
   ... choice of rename or replace on target to drop

   CB: text editor, picked destination, want to replace selected text

   AG: in editor, that is cued by selection of destination -- you choose
   between characters want to replace

   CB: destination selection will determine, then?

   AG: yes -- aspect of it we hadn't considered

   BG: hard to mark every range possible -- have to tell what are
   acceptable drop targets

   CB: if selected mark before command, might be easier?

   BG: place in tree -- can copy, move or replace this item; editor, user
   selecting what want as replace - no mechanism for user to specify
   where target is -- seems that is app's job

   AG: in a text editor, everything is a possible replace target
   ... mark block/mark range -- move block in range;

   CB: tree example - nodes and leaves - want to replace nodes elsewhere
   in tree with nodes i've selected

   EJ: how do multiple targets get marked?

   AG: multiselection drag selection -- that's EJ's use case, i think

   EJ: different keystrokes for each
   ... in directory, want to either pick a bunch discontiguous before i
   choose contiguous; have to mark both with same action?

   RS: want to be able to set multiple drag sources?
   ... if mark all want to manipulate

   GJR: control+space for noncontiguous shift+space for contiguous
   (windows)

   RS: control click mark each thing you want selected; what have to do
   is once selected, indicate why selected -- if have control "click"
   when bring up menu to select drag menu to start operation, all marked
   go to true, escape cancels all; when get to location, context menu
   will alow range of actions

   EJ: if select popup menu option going to initiate drag operation?

   RS: yes, all those elements are marked for grabbing after selection --
   app doesn't know what user's intent is (copy to clipboard, delete,
   move, etc.)
   ... marked then pick droptargets -- not supporting dropping in
   multiple locations

   EJ: select multiple objects for drag; asked for something different

   RS: my key sequence is: launch menue, popup menu, how to escape out of
   it; halt entire operation
   ... define hotkey sequence for doing a move is a menu adequate?

   EJ: identified hole, how do will fill it? is that what your requesting
   of style guide group
   ... marking multiple selections for a dragto - copy these and drop on
   acceptable target

   RS: multiple options - 2 seperate operations

   EJ: marking it?

   RS: one question -- do we want to leave last operation open for user
   to not drop until context menu pops up? decision decides in DTD for
   drop effect if select one or multiple in drop effect

   AG: if the user chooses drop effect when grab source, don't have to
   support multiple on target, but may have some drop events that are
   legal on some targets and illegal in others; example that spawned
   multiple drop effects -- changes from move to copy -- don't know that
   when grab source -- that's what got us to put in multiple effects as
   possibility on target

   RS: user picking which operation when starts?

   AG: no, just grabbing and dragging
   ... want reverse operation - when get to target decide what i want to
   do
   ... narrow choices of what system knows to the max; if multiple, ask
   user

   BG: people are used to picking what to do when grab not when drop

   CB: right

   BG: problem as implementor, don't have to calculate what drop is until
   i get a mouseover -- now, have to precalculate for what is on screen
   -- potentially daunting

   RS: doing additional work to assist user

   BG: going to get pushback on it

   AG: have option to follow what AT does with mouse, what user does with
   navigation, and simulate mouseover when reach acceptable target; user
   navigates blind and gets an alert when can drop something --
   functional, don't know if

   BG: how is someone blind going to navigate to other items

   RS: AT keeps track of visible area and can navigate to those using
   JAWS cursor

   BG: JAWS would say "now i'm doing a drag, need to visit all acceptable
   targets and let user decide when to take action

   AG: opera supports a wide variety of tab-cycles -- future opera, when
   grab something, get navigation cycle that visits potential drop
   targets -- select expression - navigatet amongst those expressions

   BG: have no idea user using screen reader; if mixed navigation,
   keyboard tab navigation to point-and-click

   RS: once target identified, move mouse cursor to it

   AG: same scripts that accept the mouse and the keyboard actions; have
   to describe state machine with mouse and keyboard synonyms at each
   point

   BG: can work, needs to be thought throug

   AG: very difficult use case

   RS: i need to deal with EJ's case about mulitple selectable sources
   and how execute grab -- what else needed?
   ... trying to take ARIA to last call for target date of mid-october;
   trying to create a graph of best practices which would include
   dragdrop -- can tweak later on if developers identify problems/holes
   -- can address specific use cases

   AG: best practices doesn't have to be perfect -- need to test markup
   COMPLETELY before issuing BP document

   RS: let's have follow-up and discuss it

   CB: control-shift-f10 -- already defined in IE and FF

   RS: going to redefine -- if group doesn't like it, can be changed

   BG: doesn't matter -- do the same thing, right?

   CB: right

   BG: some things may already have a context menu, so we allow you to
   put context menu on tree

   RS: add or remove specific menu items at same time

   BG: append your stuff to existing menu? person created DOM with their
   menu, have to modify on fly?

   TB: alternative is have second menu

   BG: browser wrote original menu -- it is doing modification

   AG: change menu worth looking at -- take most immediate candidates
   (dragdrop, grab, dragchoices with menu item that says "other options"
   or "more" and go to author's menu as sub-menu;

   BG: talking about computing that takes time;

   AG: currently been done in script which takes even longer

   BG: if menu can't be static, has to be generated for specific item --
   don't know if copyable, moveable, etc. -- doable, but worry about
   performance issues

   DE: had no idea how could be done at outset -- you've convinced me
   there is a implementable way

   RS: traveling next week

   AG: next call in 2 weeks anyway (21 september 2007)

   BG: posted to list menu punch list to list; LisaP put on wiki

   DE: ok, can review

   EJ: use cases defining keyboard sequences -- use cases going to drive
   choice of final key sequences -- RichS have you done that --
   operations for each key gesture -- popup menu, know its there, what it
   can do -- what happens

   RS: haven't run through all use cases -- working on example; keep
   suggestions coming -- didn't think about multiple select before call

   meeting adjourned 1704 UTC -- next meeting 21 September 2007 at 1600
   UTC

Summary of Action Items

   [End of minutes]
     _________________________________________________________________

    Minutes formatted by David Booth's scribe.perl version 1.128 (CVS
    log)
    $Date: 2007/09/07 17:06:17 $
     _________________________________________________________________

Received on Friday, 7 September 2007 17:16:37 UTC