Draft drag and drop UI design pattern
Colin Clark
colin.clark at utoronto.ca
Wed Jul 18 22:53:40 UTC 2007
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
More information about the fluid-work
mailing list