GNOME.org
 

Re: [Usability]Dealing with files in Gnome

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]