Draft drag and drop UI design pattern

Richard Schwerdtfeger schwer at us.ibm.com
Thu Jul 19 15:48:27 UTC 2007






Hi Colin,

>From a user experience we have the opportunity, with ARIA, to visually show
to the user what drag and drop targets are available. The current design,
unnecessarily, requires the user to make guesses on what UI objects meet
the criteria. This impacts productivity and usability for a broad range of
abilities. Putting aside the technical aspects we have the ability to show
identify this information, ... even if you are blind.

At the very least, since we are producing an personalized system, this
should be an option and one which we could support at the client rather
than the server.

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             Colin Clark                                                   
             <colin.clark at utor                                             
             onto.ca>                                                   To 
                                       Richard                             
             07/18/2007 05:53          Schwerdtfeger/Austin/IBM at IBMUS      
             PM                                                         cc 
                                       "fluid-work at fluidproject.org"       
                                       <fluid-work at fluidproject.org>       
                                                                   Subject 
                                       Re: Draft drag and drop UI design   
                                       pattern                             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Rich,

We chatted about your questions by IM, but I thought I'd follow up
on-list just to keep the thread alive.

As I mentioned, the purpose of a UI Design Pattern is to provide broad
information and advice about the *interaction*, rather than the
technical implementation. Shaw-Han's done a nice job of outlining the
various user-visible states or "moments" for drag and drop within his
pattern.

Your technical advice about ARIA is right on, and is exactly the kind of
behaviour we support in the Lightbox. I'm looking forward to having a
daily build ready shortly so everyone can play around with the Lightbox
and see the kinds of affordances that you mention in action, as well as
give us feedback.

You've provided a lot detail here, much of which is probably more
appropriately suited within the component implementation itself, rather
than a design pattern which describes in a general sense how to apply or
use the Lightbox and/or Reorderer. But it's great to have your feedback;
keep it coming!

Colin

Richard Schwerdtfeger wrote:
>
> Hi Colin,
>
> Once an object is selected for drag also knowns as a "grab?"  Doesn't
> the application already know what objects can receive the drag object?
>
> You need the ARIA states and properties for drag drop.
> http://www.w3.org/TR/aria-state/#dragdrop
>
> This informatio can be used to style designated drag and drop targets.
>
> Looking at this table: It seems like you are trying to figure out
> whether an dragover is invalid if in fact at the time you select an
> object for drag you already know the targets that can receive the drop.
> This, to me, is a usability problem. Using ARIA:
>
> select an object to drag using the keyboard ( this is all objects that
> have aaa:grab="supportered"
>
> upon a grab
>
> change the aaa:grab="true" on the objec to drag
> mark all objects with aaa:dropeffect=" copy | move | reference "
> depending on your drag operation.
> Optionally have CSS be triggered to highlight the targets which can
> receive the grabbed object for the operation.
> use keyboard to navigate to the drop targets or let the AT do it.
> If the user hits escape, cancel the drag operation and move the user
> back to the source and reset the grab and dropeffect properties
> (original state of the system).
> Upon completion of the drag set the source and target drag operations
> based on the state of the application.
>
>
> *Interesting Moment*         *Mouse*           *Keyboard*
> *Page Loaded*          Items shown as a list or grid. It is also a good
idea to
> provide textual description of the 'drag action' or graphic drag
> affordances that tell the user dragging is possible.             Same as
mouse
> *Mouse Hover*          Container border highlighted              N/a
> *Keyboard select*            N/a         User tabs to the draggable
section, and the
> first item is selected. This is equivalent to the mouse "hover" action.
> *Mouse Down*           Enter "drag" mode. Some visual indication that you
are in
> a new mode should happen here. Cursor changes to '4-way arrow'
N/a
> *Control-Key Down*           N/a         This is equivalent to the mouse
down. While the
> user is holding down ctrl, they are in drag mode. The same visual cue as
> mousedown should be visible.
> *Mouse Up*             If we are in drag mode, this completes a drag
action             N/a
> *Spacebar/Enter*             N/a
> *Drag Initiated*             The user drags the item using the mouse to
it's new
> desired location.            While holding ctrl, the user uses the arrow
keys to
> move the item to a new location.
> *Drag Over Valid*            Preview the new placement by showing a
half-alpha
> version of the currently dragged item in it's new position. The other
> images on the page will re-arrange to form the new order.
Same as mouse
> *Drag Over Invalid*          We will "snap" to the closest valid position

> (??).            there are no "invalid targets" for a keyboard user
> *Drag Over Original*         Same as 'drag over valid'           same as
mouse
> *Drop Accepted*              Half-alpha preview becomes full-alpha. New
order saved
> in database.           same as mouse
> *Drop Rejected*              Return to the original state (i.e. original
ordering)
> Return to the original state, additionally the original item is in hover
> mode.
> *Drop on Original*           Return to the original state
>
>
>
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> Chair, IBM Accessibility Architecture Review  Board
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
>
>
> *Colin Clark <colin.clark at utoronto.ca>*
> Sent by: fluid-work-bounces at fluidproject.org
>
> 07/17/2007 09:27 AM
>
>
> To
>            "fluid-work at fluidproject.org" <fluid-work at fluidproject.org>
> cc
>
> Subject
>            Draft drag and drop UI design pattern
>
>
>
>
>
>
>
>
> Hi everyone,
>
> Shaw-Han has been working on a UI design pattern for Sakai about drag
> and drop. It's a work in progress, but take a look and tell him what you
> think. Much of this material was inspired by our experience working on
> the Lightbox.
>
> http://issues.sakaiproject.org/confluence/display/DESPAT/Drag+and+Drop
>
> We'll do a version of this pattern for Moodle and uPortal, too.
>
> Colin
>
> --
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>

--
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070719/b71c7766/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070719/b71c7766/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic06474.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070719/b71c7766/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070719/b71c7766/attachment-0002.gif>


More information about the fluid-work mailing list