Lightbox: Cut and Paste / Drag and Drop

[Daphne Ogle]

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 of:
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...

-Daphne

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.
>
> Jens
>
>
> On 6/6/07 11:12 AM, "Jonathan Hung" <jonathan.hung at utoronto.ca> 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.
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



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