Lightbox: Cut and Paste / Drag and Drop

[Paul Zablosky]

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 
> <mailto: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 
> <mailto: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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070606/c4447af7/attachment.htm>