Re: [Usability]Dealing with files in Gnome

[Wesley Leggette <wleggette gate net>]

About the NEXT suggestion below, I think it brings up two points: It
would be great to have some sort of visual representation of what is in
the user's "hand". Another thing is that it allows the user to select
and item, then select another, and then drop both items. We could do
that if we wanted to, otherwise we could just have a new pick-up replace
the last one. If we opt for the later, the last term in the current drop
context menu model ("Cancel Drag") could conceivably be eliminated.

-Wesley




On Wed, 2003-04-02 at 16:42, Manuel Amador (Rudd-O) wrote:
> MArk Finlay wrote:
> 
> >On Tue, 2003-04-01 at 01:25, Wesley Leggette wrote:
> >  
> >
> >>Regarding Pick up and drop, I think the semantics are no better. What
> >>happens if you "pick up" one object, then another, and then drop? It
> >>would defy all expectations to "drop" both of them at the new location
> >>if this is simply a change in cut, copy, paste. So assuming that that it
> >>would work this same way, the change in terminology is pointless. We all
> >>know what cut, copy, and paste mean and it's more than logical to assume
> >>our users do to.
> >>    
> >>
> >
> >I think that if you can dig through bug 77293 you will see that they are
> >not the same. As well as that, copy and paste in a file manager is not
> >something that the majority 
> >
> >"Remove Cut/Copy/Paste from the file operations.
> >Add a Pick Up operation.
> >  Using this on a file, selected files, or either in sequence
> >  adds the file(s) to a list (or whatever data type)
> >Add three Drop commands.
> >  Drop Here.
> >    The picked up file(s) is(are) moved to the drop location.
> >    The list is emptied.
> >  Drop Copies.
> >    They are copied, and the lisfile:///home/sisob/.gnome2/panel2.d/default/launchers/blah-001a326f8b.desktopt is emptied.
> >  Drop Links.
> >    Links (hard, symbolic, or .desktop) are created at the
> >    drop location. The list is emptied.
> >Add a Cancel command.
> >  The list is emptied. Nothing is done to the files.
> >
> 
> A different, perhaps better, perhaps worse, suggestion (from the NEXT 
> implementation):
> 
> Edit... Put selected files in shelf:
>    *selected files go to the shelf (a special folder, shown in the Go 
> menu).  Actually they don't go there, just a representation of the files 
> goes there.
> Edit... Move files in shelf here
>    *files in shelf get moved here
> Edit... Copy files in shelf here
>    *files in shelf get copied here
> Edit... Place links to files in shelf here
> 
> The "shelf" could be a "folder" window that shows icons for each file in 
> the "shelf" (think shelf://).  Icons could also be dragged from/to the 
> shelf.
> The shelf could also open automatically when files get put there.  *In a 
> new window, please*
> (the "here" word is necessary to avoid the confusion stemming from the 
> "what's this operation's subject? the folder or the selected icon?" problem)
> We could have a panel applet à là GTM panel applet, to quickly place 
> files in the shelf.  This makes drag-and-drop between a window which is 
> open and another which has to be closed easier.  It also provides a 
> workaround to the spring-loaded folders: place the files in the shelf, 
> locate your folder, then drag the files in the shelf to the folder.  Presto.
> 
> This achieves several good things:
> * the menu entries are explicit and clear (copy/cut/paste don't reveal 
> what exactly happens to files upon activating those commands on them).  
> They just make sense
> * the shelf could serve as middle-man in drag/drop operation
> * the shelf can contain several files, not just the ones from the last 
> copy/cut operation.  This is having your multi-copy cake and eating it too.
> * special operations could be added to the shelf which would let you 
> save the list of files to a TXT file.  Think graphical 'find'.  Think 
> creating a file list without opening a terminal
> 
> >
> >For the UI: the Cut/Copy/Paste items are replaced with:
> >
> >...       |
> >Pick Up   |+-------------+
> >Drop     >|| Drop Here   |
> >...       || Drop Copies |
> >...       || Drop Links  |
> >...       ||-------------|
> >...       || Cancel Drag |
> >...       |+-------------+
> >
> >
> >Preferably, the drop item is a conditional cascading menu as
> >described in bug #82162. This way the user can move or copy
> >files (whichever is the default) without opening the submenu.
> >
> >An advantage of this is that it may also be used for keyboard
> >accessible drag-and-drop. (Perhaps the accessibility keyword
> >should be added.)"
> >
> >  
> >
> >>>another point from the bug:
> >>>      
> >>>
> >
> >"Here is an important differnce between the two models which has not
> >been mentioned, afaik. I think it may actually be the most important
> >difference and the clincher for moving to Pick Up and Drop.
> >
> >With Cut/Copy/Paste, you are committed to a particular action well
> >before completing it. If you have Cut and when going to paste you
> >realize you actually wanted to Copy, you have to either go back
> >and Paste where you Cut or you complete the action and Copy back
> >to the original location.
> >
> >With Pick Up/Drop, you can defer the decision until you complete
> >the action.
> >
> >There is also the matter of accessibility which Bill Haneman
> >expresses well in:
> >http://mail.gnome.org/archives/desktop-devel-list/2002-November/msg00248.html";
> >
> >  
> >
> >>>end of bug comments
> >>>      
> >>>
> >
> >Personally I don't think that this implementation is perfect, but it's a
> >lot better than copy and paste and I hope that we can improve these
> >ideas in the future.
> >
> >  
> >
> >>But of course there is a utility for remembering multiple cuts and
> >>placing them all in the new paste spot. But users would have to be able
> >>to easily remember what they have currently cut (some sort of cursor
> >>tag-a-long that shows the icon's they are carrying and allows them to
> >>drop all or some of them unchanged?). If this sort of behavior were
> >>implemented, "pick up" and "drop" would make a lot of sense, and since
> >>it's different that traditional cut and paste, the name change would be
> >>appropriate.
> >>    
> >>
> >
> >you see - now you're thinking properly - we don't have to copy OsX or
> >Windows or KDE or anyone - let's make gnome really Useful and inovative
> >;) I agree that knowing what is currently picked up is left out from the
> >current proposal and that would need to be delt with.
> >
> >  
> >
> >> And hey, we could always have a preferences toggle between
> >>the two modes of operation.
> >>    
> >>
> >
> >Good no! /me points to havocs paper
> >
> >
> >  
> >
-- 
Wesley Leggette <wleggette gate net>