Lightbox: Cut and Paste / Drag and Drop

Wed Jun 6 21:40:59 UTC 2007

I would to point everyone to the latest ARIA working drafts. We have a new
section on drag and drop properties:
http://www.w3.org/TR/aria-state/#dragdrop

One of the big accessibility issues with drag and drop is identifying what
you can grab and where you can drop it. One of the reasons for introducing
these properties was to indicate this information through accessibility API
in the browser to a screen reader and optionally using style sheets to
"light up" the "grab" and "dropeffect" areas by applying CSS selectors to
the properties. The AT or user can navigate to the drop points as needed.

Rich

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

             Paul Zablosky                                                 
             <Paul.Zablosky at ub                                             
             c.ca>                                                      To 
             Sent by:                  fluid-work at fluidproject.org         
             fluid-work-bounce                                          cc 
             s at fluidproject.or                                             
             g                                                     Subject 
                                       Re: Lightbox: Cut and Paste / Drag  
                                       and Drop                            
             06/06/2007 03:31                                              
             PM                                                            

The power of the drag-and-drop metaphor lies in the fact that the state of
the transaction is continuously visible as the transaction progresses.
It's easy for the user to see how far it has gotten, and it's easy to see
how to back out (put it back where you found it).  While the name
"drag-and-drop" suggests a two-part event, the user can really be thinking
"move" -- a single atomic step.

With cut-and-paste, we really do have two parts: object selection, and
target selection.  It's harder to indicate the interim status while the
select object hovers between locations (perhaps it's in the Star Trek
transporter pattern buffer?).  But there are various things to be
considered:
      How do I back out, just using the keyboard?
      If I abandon the transaction after the cut, how does the object
      become unselected?
      Under what circumstances does a cut become a delete? (Other than
      pasting into the trash receptacle)
      If I forget what I was doing (e.g. the phone rang), how am I reminded
      that my cursor carries a payload to be pasted, and how do I find out
      what that payload is, and that it's a cut, not a copy?
      What happens if I attempt another cut while one is still pending?
Having all  these things apparent contributes to making the user's life
easier, but they must be expressed in an obvious and intuitive way.

One way around some of these concerns is to specify the paste target
location first.  There's less downside if you abandon or forget your paste
location. But this approach has it's own risks, and it's really
non-intuitive.  (It is how ATM's work -- you specify the target account
before you submit the envelope.)

Given all that, I agree that cut-and-paste (CtrlX/CtrlV) is the way to go.
We just have to do what we can to make it feel as safe as a "move" does.

Paul

Jonathan Hung wrote:

      On 06/06/07, Shaw-Han Liem <shawhan.liem at utoronto.ca> wrote:
        So the question was: If we do decide to implement the added
        'cut/paste' keyboard shortcuts, does it make sense to change the
        visual design and behaviour so that it more closely follows the
        'cut
        and paste' convention (for example, when you "cut" an image, it
        would
        disappear and be replaced by a 'cursor' until it is pasted again).,

      This raises some interesting issues. If you cut an image and it
      disappears from the UI, how do we indicate where to paste? Does this
      mean implementing a cursor?

      Also, the convention of having the item disappearing when cut is
      something I see mostly with text. For all other computer "objects"
      like file folders, images, etc., a greyed-out version is left behind
      until you paste it to your destination. Leaving a greyed-out version
      is useful as it gives you a visual cue. Also if they abort the
      cut-and-paste command, the greyed-out token implies that it isn't
      permanent, whereas cutting it completely from the UI may appear like
      a deletion.

      I like the idea of using the conventional CTRL+X / CTRL+V pattern...
      it will make adoption and learning a lot easier and quicker.

      - Jonathan.
      --
      Jonathan Hung / jonathan.hung at utoronto.ca
      University of Toronto - ATRC
      Tel: (416) 946-8312

      _______________________________________________
      fluid-work mailing list
      fluid-work at fluidproject.org
      http://fluidproject.org/mailman/listinfo/fluid-work

_______________________________________________
fluid-work mailing list
fluid-work at fluidproject.org
http://fluidproject.org/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070606/16c5f354/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070606/16c5f354/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic14074.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070606/16c5f354/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070606/16c5f354/attachment-0002.gif>