Draft drag and drop UI design pattern
Colin Clark
colin.clark at utoronto.ca
Thu Jul 19 17:53:29 UTC 2007
Hi Rich,
Yes, this is a really good point. Shaw-Han and Daphne have been looking
at various types of visual affordances to convey a sense of
"draggability" to the user of the Lightbox. We're still playing with
design concepts, but I think there are some mockups in the wiki that
show this. Any suggestions from other designers about how to best
accomplish this?
Daphne often raises the point that such affordances are even more
critical in a Web-based environment where users aren't necessarily as
accustomed to being able to pick up and move items around on screen.
Combine this with the correct ARIA attributes to identify draggability
to non-visual agents and we should be in good shape.
Colin
Richard Schwerdtfeger wrote:
> 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
> Inactive hide details for Colin Clark <colin.clark at utoronto.ca>Colin
> Clark <colin.clark at utoronto.ca>
>
>
> *Colin Clark <colin.clark at utoronto.ca>*
>
> 07/18/2007 05:53 PM
>
>
>
> To
>
> Richard Schwerdtfeger/Austin/IBM at IBMUS
>
> 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
>
--
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
More information about the fluid-work
mailing list