See also: IRC log
<Rich> chair: Don
<scribe> scribe: gregory
<scribe> scribenick: oedipus
<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
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: gregory Found ScribeNick: oedipus Present: Tim Boland Don_Evans RichS Becky_Gibson Tim_Boland Al_Gilman Gregory_J._Rosmaita Jon_Gunderson Chris Blouch Earl Johnson Got date from IRC log name: 7 Sep 2007 Guessing minutes URL: http://www.w3.org/2007/09/07-pf-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]