Lightbox: Cut and Paste / Drag and Drop
Paul.Zablosky at ubc.ca
Wed Jun 6 21:33:07 UTC 2007
I think you've hit on a key point, Daphne. The mouse drag-and-drop and
the keyboard cut-and-paste are somewhat different metaphors. But the
high-level metaphor that reflects the user's intent in both cases is the
idea of /move./ If we can make both operations feel like "move", we'll
have succeeded. This is a challenge for the keyboard-only case.
Daphne Ogle wrote:
> I'd like to the stress the importance of the user's direct feedback
> about where they are moving the image, what it will look like in the
> new place, etc. as they make sense of the group of images they have
> collected. This is a very dynamic process. I believe the visual cues
> 1) where am I right now (where is the image? With my cursor as I move
> it along?),
> 2) where am I going (if I 'dropped' -pasted- my image right now where
> would it be and how would it look next the images around it), and
> 3) where was I (image shows in some form in original location until it
> is dropped)
> are especially important.
> We should keep the original metaphor in mind of directly picking up an
> image and rearranging it on a traditional lightbox... to create a
> lecture, for instance. Copy and paste just might be the best way to
> do this as a keyboard interaction. My concern is that we are in
> danger of halfway using an interaction convention...especially given
> the 'where I am' feedback that requires visually moving the image
> along with the cursor. Would this be confusing?
> Another general thought... these are new kinds of rich interactions
> and it's OK be innovative as long as it is very easy to learn and do.
> The lightbox component will include the ability to drag and drop
> which requires learning as a fairly new web interaction. But...once a
> user has done it once, they get it. I was just having a conversation
> yesterday about the ipod in this regard. A friend was complaining
> that when they first picked up the ipod hey had no idea what to do
> with it and so it was bad usability. After further discussion, he
> agreed that yes, after about 30 seconds he figured out the fly wheel
> and understood it from then on. It's a trade off. Is what we are
> doing with keyboard-only image rearrangement really a new metaphor?
> Just a few more thoughts for the mix...
> On Jun 6, 2007, at 11:27 AM, Jens Haeusser wrote:
>> I was going to suggest the same thing- Microsoft uses this visual
>> metaphor for cutting and pasting files and folders within Windows
>> Explorer; the image greys out when you Cut it (right click or
>> Control-X), and doesn’t actually move until you Paste it (again,
>> right click or Control-V). There is no visual cue for a Copied object.
>> On 6/6/07 11:12 AM, "Jonathan Hung" <jonathan.hung at utoronto.ca
>> <mailto:jonathan.hung at utoronto.ca>> 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.
>> fluid-work mailing list
>> fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
> cell (510)847-0308
> fluid-work mailing list
> fluid-work at fluidproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work