DHTML Style Guide Meeting
7 Sep 2007

See also: IRC log


Tim, Boland, Don_Evans, RichS, Becky_Gibson, Tim_Boland, Al_Gilman, Gregory_J._Rosmaita, Jon_Gunderson, Chris, Blouch, Earl, Johnson




<Rich> chair: Don

<scribe> scribe: gregory

<scribe> scribenick: oedipus

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 18:18:26 $

Scribe.perl diagnostic output

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