Lightbox: Cut and Paste / Drag and Drop

[Paul Zablosky]

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.

Paul

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 
> 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 
>> <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>
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> 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
> 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/b41ca1b8/attachment.htm>