Lightbox: Cut and Paste / Drag and Drop
Paul.Zablosky at ubc.ca
Wed Jun 6 20:31:34 UTC 2007
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
* How do I back out, just using the keyboard?
* If I abandon the transaction after the cut, how does the object
* 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
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work