Re: Drag and drop and copy/paste

Don,

The fluid project is really quite impressive. Would you consider inviting
Colin to the style guide meeting and let him vet some ideas on keystrokes
for drag/drop?

Thanks,
Rich

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

Colin Clark <colin.clark@utoronto.ca> wrote on 12/08/2008 03:14:20 PM:

> Colin Clark <colin.clark@utoronto.ca>
> 12/08/2008 03:14 PM
>
> To
>
> wai-xtech@w3.org
>
> cc
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, Joseph Scheuhammer
> <clown@utoronto.ca>, oliver.keim@sap.com, stefan.schnabel@sap.com
>
> Subject
>
> Drag and drop and copy/paste
>
> Hi all,
>
> I'm the technical lead for the Fluid Project, an open source community
> of interaction designers and UI developers who do a lot of DHTML
> accessibility work. I've been following the ongoing thread about
> keystrokes for doing drag and drop interactions with great interest.
>
> Over the past year or so, we've done a lot of user testing and
> research about drag and drop interactions. As we delved more deeply
> into the problem of keyboard navigation, one of the things that became
> clear was how much context matters when coming up with the appropriate
> keystrokes and interactions.
>
> Based on our testing experience, we found that it's risky to think
> about drag and drop as a homogenous use case. There are lots of
> different types of activities that are powered by drag and drop:
>
> * Sorting items in lists, grids, or layouts
> * Moving or copying items within a tree or folder hierarchy
> * Creating file shortcuts or aliases
> * Opening files within a specific application
> * Referencing external files, text, or other media within an application
> * And so on...
>
> Not all of these activities are appropriate for the familiar cut/copy/
> paste idiom. For example, prioritizing items in your "to do" list by
> sorting them in order of importance. You're not copying an element,
> you're simply moving its position relative to the others. Neither are
> you cutting an item from the list, since again, you're just changing
> position. Similarly, many of the other use cases listed above don't
> naturally correspond to the copy/paste metaphor.
>
Thanks Colin, the keyboard style guide group is still working on the key
strokes for this. You are not the
only one who has raised concerns over the copy/paste metaphor.

> Copy and paste are probably the two most familiar actions in all of
> computing. By overloading them with different actions and semantics,
> there's a real risk that you will detrimentally affect the consistency
> of your user interfaces and confuse users in the process.
>
> As far as I can tell, the goal of the Style Guide group is to come up
> with a "generic" set of keystrokes for all different flavours of drag
> and drop behaviour. Assuming this is the case, I'd recommend that you
> avoid overloading the copy/paste semantics by using Ctrl-C and Ctrl-V
> as keystrokes for drag and drop.
>
> On the other hand, a more fruitful approach might be to try to break
> up the problem into specific contexts, such as sorting, cut/copy/
> paste, shortcuts, and so on. Then it would be easier to come up with
> standards and best practices that are suited to the task at hand,
> along with shortcuts that match the user's expectations. In the end,
> this means you can design optimized keystrokes that will help the user
> accomplish their work faster.
>
> Our own Joseph Scheuhammer has articulated an excellent and in-depth
> rationale for this point. Aside from that, I'd be happy to lend a hand
> with exploring unique keystrokes for different use cases. I'm also
> happy to share advice and help from Fluid's interaction designers who
> have considered this issue in more depth than I have.
>
> I hope this helps,
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>