[Usability]Re: the Nautilus context menu

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Nov 13, 2002 at 11:48:35PM +0000, Andrew Sobala wrote:
> On Wed, 2002-11-13 at 23:01, Gregory Merchan wrote:
> > On Wed, Nov 13, 2002 at 07:32:21PM +0000, Andrew Sobala wrote:
> > 
> 
> <snip>
<snip>
> > MacOS, to my knowledge, does not provide Cut/Copy/Paste of files; I think
> > it only allow mouse-based DnD or tranfers by dialogs.
> 
> I just checked. It uses Cut/Copy/Paste.

I asked a Mac user I know and he says it does have Copy/Paste, but not Cut.
Whatever the case (I'll believe no one until I see it myself ;-) I'm pretty
sure it was added in version 10. (Though, again, I don't know the full
history of the Mac first-hand.)


> > Pick Up and Drop were present on OS/2 versions 2 through 4, at least.
> > 
> > 
> > > It doesn't seem worth alienating skilled computer users in an effort to
> > > make file management seem as simple as pie - which it isn't.
> > 
> > At this point, you've lost me. A series of questions:
> >   What do you think file management is?
> 
> OK, mine was a weak comment.

Still, I don't know what you're thinking. You say 'file management' again
in this last reply. I do not wish to engage in sophistry; I really didn't
understand what you were saying.


<snip>
> > Here is an important difference between Cut/Copy/Paste and Pick Up/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.
> 
> Not really. If you cut a file, it's still there. Cut/Copy/Paste is a
> 2-choice action. The Cut/Copy says what you want to do with the file,
> and Paste says where you want to do it. If you Copy a file, then realise
> you wanted to Cut it, you can choose Cut on that file before going and
> pasting it because the action only occurs on the paste step. You don't
> have to complete the action before changing your mind.

That's another example of how the operation on files is different from
the operation on other data. Text that has been cut must be pasted or
lost at the next cut or copy. (Assuming there is no clipboard history.)

Ok, so you can change your mind more easily than I thought, but now you've
lost consistency with other clipboard actions.


> > With Pick Up/Drop, you can defer the decision until you complete the
> > action.
> 
> So it's an inverted Cut/Copy/Paste. Instead of:

(well, I certainly would not put it that way)


> [Choose source file and what action to do] -> [Select location and
> action takes place]
> 
> which is [Cut/Copy] -> [Paste]
> 
> you want
> 
> [Choose source file] -> [Select location and what action to do and
> action takes place]
> 
> which is [Pick up] -> [Various drops]
> 
> Why is this arrangement advantageous? It means people have to relearn
> their file management, because the choice is made after rather than
> during source-selection, but I can't see what problems this solves.

(Again 'file management'. In this context is meant 'how to move, copy,
 or link to files.)

It solves the consistency problem. Cut/Copy/Paste always will mean one
thing and Pick Up/Drop always will mean another. I do not see this
consistency problem as one of being consistent with other platforms.
Sell me that being far more important than internal consistency, and
you'll have sold me Cut/Copy/Paste of files. Considering most of those
other platforms are not free (libre), it'll be a hard sell.

There is another point, but it's not so much a problem solved as it is
something afforded.  That is that Pick Up could be used discontinuously.
One may pick up any number of items over time and any number of times,
then finally drop them elsewhere. With Cut/Copy you are limited to what
you can select in one selection ring. Mistakes of recutting or recopying
are very slightly less forgiving.


> This is why cut/copy/paste is sort-of consistent at the moment; the
> action choice takes place during source-selection rather than during
> target-selection. And although the time of action is different to, say,
> editing text files (that's unavoidable since file management is a
> one-step action rather than two-step action), pick up/drop has the same
> delayed-action but compounds the issue by having action-choice at a
> different point.

"sort-of consistent" means inconsistent, and it's inconsistent with what
people are hopefully doing the most of: writing.  If you're moving
files around more than you're making them, something is really wrong.

Pick Up and Drop is different and differently named; there's no conflict
here.  I don't see what issue is being compounded and I don't see how.


> So as we said above, the problem cut/copy/paste and pick up/drop share
> is that a picked-up file or cut file doesn't go anywhere when it's cut
> or picked up. It stays on the file system. I think a proper resolution
> would be to show the user this.
>
> So something like when a file is cut, it "greys out" (like on Windows)
> and a greyed out icon of the file appears in the panel. This shows the
> weird limbo state that it's in before pasting/dropping. Then when it is
> pasted, the icon becomes solid in the paste location. This solution
> solves the cut problem; it doesn't discriminate against copy/paste where
> the limbo icon actually ends up in 2 places at once. Maybe cut would
> show the limbo icon in a greyed-out state to show that it's
> half-on-the-clipboard-and-half-on-the-file-system, and copy would show
> the limbo icon in a solid state to show that a full copy of the icon is
> on the file system.

I absolutely agree that the limbo state needs to be indicated. The
Windows-style desaturation seems a good way to do this. With Pick Up/Drop,
I think there should also be an indicator following the cursor. The indicator
can be done as the DnD indicator is done - with an override-redirect window.
To avoid conflicting PickUps between files and other pick-up-able things,
there can be a _GNOME_PREHENSILE_FOOT selection.


Cheers,
Greg Merchan

P.S. - Sorry if the tone of this is off. I'm upset about a flamewar over
       this erupting on desktop-devel-list.

P.P.S - _GNOME_PREHENSILE_FOOT is meant to be a joke. The rest isn't.