Re: [Usability] moving or copying when drag'n'dropping

[Shaun McCance <shaunm gnome org>]

On Tue, 2007-02-27 at 11:09 -0600, Matthew Nuzum wrote:
> Hello, I'm paranoid about dragging files, because I never know what to
> expect. For example:

Others have replied, but I can provide a little
more information as well.

> I just drug files from an archive in whatever program Gnome uses onto
> a network place. The dialog said "moving files..." which worried me.
> Fortunately, it only copied them.

That's a very bad choice of wording, and it should
be fixed.  Could you please file a bug at

http://bugzilla.gnome.org/

against the product file-roller?

> Sometimes when I drag and drop files from the desktop it moves them.
> For example, dragging an item to the trash, which makes sense, but it
> seems like other times this happens too. I'm not sure what the pattern
> is.
> 
> Often times it copies them. For example, copying files from my desktop
> to network places.

It works like this:  If the source and destination
folders are on the same file systems, then the file
is moved.  Otherwise, it is copied.  Network servers
and such are treated as their own file system.

I was wary of this behavior long ago, because I don't
think users generally think in terms of file systems
(or necessarily know what they are).  But in common
practise, I find that the default drag action usually
ends up being exactly what I want.

> To further frustrate things, while it seems the common procedure for
> dragging is to copy, in Rhythmbox, it instead duplicates listings
> without duplicating files. This can be quite frustrating if you then
> try to delete the duplicate entries and instead completely trash your
> music files. The original entries are still present, but won't play
> because the music files are gone.

I think this is indicative of a larger issue that's
not entirely easy to solve.  Applications like music
managers and photo managers present your data to you
differently than file managers, even though that data
corresponds to files.  When you perform an action on
that data, it's not always clear what happens to the
actual files.

Deleting is probably the most obvious case.  When you
delete something from Rhythmbox, does it just delete
its knowledge of the file from its database, or does
it delete the file entirely?  F-Spot has menu items
for both "remove from catalog" and "delete the file",
but I have no idea which one happens if you just hit
your delete key.

> Things could be better if there is:
> a: standardization on what happens when you drag'n'drop

As Mariano pointed out, the HIG does have guidelines,
but they're perhaps not perfectly clear about what the
default action should be.  The HIG explicitly says that
dragging between applications should copy, but doesn't
provide clear guidelines for dragging within a single
application.

In most cases, the action will be copy.  Nautilus moves
files on the same file system because it usually makes
the most sense to do so (and reversing the operation is
quick and painless).

> b: communication or indication of what is going to happen when you
> drop (i.e. Windows shows an emblem indicating if the operation will
> copy, move or create a shortcut)

Your cursor should change to reflect the effect of
dropping at any given location.  There are stock
cursors for "move", "copy", "link", "ask", and
"not allowed". If you hover over any area of an
application during a drag and it doesn't display
the proper cursor, then that application needs to
be fixed.

> c: a standard and intuitive way to affect the default drag'n'drop action.
> 
> I'd also like to be able to control wither or not files get moved or
> copied. In XP you can drag with the right mouse button, and when
> dropping, get a choice to move, copy or create a shortcut. This suits
> me just fine, because the computer rarely knows what my intentions
> are. (i.e. duplicating an image file, moving files to a network share)

We don't do that on right drag, because it interferes
with the context menu.  In Nautilus, at least, you can
get the same effect with middle drag.

Don't have a middle mouse button?  That's OK.  We have
a standard, intuitive, and keyboard-accessible way to
affect the drop action.  Use your modifier keys.

Alt+drag creates a menu asking you what you want to do.
Ctrl+drag forces a copy.
Shift+drag forces a move.
Ctrl+Shift+drag forces a link.

To the extent that these actions make any sense within
a given application, that application should support
them.  If it doesn't, it needs to be fixed.

--
Shaun