Nautilus Drag & Drop Behaviour

[Sebastian Rittau]

[Followup-To the Usability list]

Hi!

In reference to Nautilus bug #143746 [1], I would like to discuss the
current drag & drop behaviour of files in Nautilus. Currently Nautilus's
behaviour changes, depending on whether the file is dragged onto a
directory on the same file system or a directory on another file system.
I will try to list the pros of this solution and why I think a
consistent action (e.g. "always move") is a better solution.

Pros for the current behaviour
------------------------------

* It was claimed that when dragging a file onto a different file system,
  most users want to copy the file anyway. I think this is certainly not
  the case for local file systems (like moving a file from /home to
  /var) and often not true for remote or removable file systems. Some
  remote file systems work much like a local one. For example, NFS
  mounts are often treated like a local file system. Especially in
  larger organizations it's quite common to mount home directories from
  a central file server. Also, when moving files to removable device (or
  a remote location that is often used the same way), I often encounter
  two different situations: Either I want to give a file to someone
  else. In this case, copying is indeed the correct action. Or I want to
  work on a file on a different computer. In this case, I don't want a
  local copy to stick around, since this will become confusing (see
  below).

* It was also claimed that moving a file across file systems is not
  "safe". This is true in the sense that if there is a crash between the
  point the move has finished and the file has been deleted on the
  source side and the next sync on the target side, the file will be
  lost. For local file systems, a sync after the move, but before the
  file is deleted, helps. Another solution is to put the file in the
  Trash folder on the source side after moving it, so it won't be lost.

* It was also pointed out that "data loss" may occur, if someone
  intended to just copy the file (for example onto an USB stick for
  another person) and it is moved. I think with a consistent drag & drop
  behaviour this risk is minimized. Also the Trash solution mentioned
  above could help.

* Other operating systems (I remember Windows XP) also use the same
  inconsistent approach as we do. I don't think this is a good reason to
  keep bad usability around, though.

Pros for the "always move" behaviour
------------------------------------

* The current behaviour is unexpected. Users need to distinguish between
  "partitions" or "remotely mounted file systems". While most users will
  probably grasp the difference between a local move and a move onto an
  USB stick, it's hard to see why a drag inside my (NFS mounted) home
  directory is different from a drag between my home directory and the
  /tmp directory.

* The current behaviour can be confusing, since "old" versions of files
  are left lying around. If move a file onto an USB stick to work on it
  on a different computer, I suddenly have two versions of the same file
  and have to find out, which version is newer. In the worst case I have
  edited both versions (having forgotten about a copy) and have to merge
  them or accidently delete the changes from one of the files.

* When dragging I currently always have to check whether a move or a
  copy will be performed. I have several mounts and partitions that I
  work with regularily. I now press the shift key by default when moving
  files around. (A feature for advanced users.) I should not need to
  care on what file system or file server a certain directory is mounted
  on. This is what my system administrator is for. I just want a plain,
  consistent view on all the files, directories, and devices I work
  with.

* The action of "dragging means moving" is more natural that "dragging
  means copying". Drag & drop is a real world metaphor. In reality I
  usually don't copy stuff just by taking it and moving it around. That
  stuff is suddenly copied is unexpected, especially if you've used drag
  & drop on the same file system before.

There are ways to enforce moving files or getting asked about your
preferred action. But these are all power user features. The most simple
and forward action (just moving stuff around) should be the most easily
understood.

 - Sebastian

[1] http://bugzilla.gnome.org/show_bug.cgi?id=143746

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Matthew Paul Thomas-2]

Sebastian Rittau wrote on 23/05/08 11:24:

>...
> In reference to Nautilus bug #143746 [1], I would like to discuss the
> current drag & drop behaviour of files in Nautilus. Currently Nautilus's
> behaviour changes, depending on whether the file is dragged onto a
> directory on the same file system or a directory on another file system.
>...
> * It was claimed that when dragging a file onto a different file system,
>   most users want to copy the file anyway. I think this is certainly not
>   the case for local file systems (like moving a file from /home to
>   /var)
>...
> * The current behaviour is unexpected. Users need to distinguish between
>   "partitions" or "remotely mounted file systems". While most users will
>   probably grasp the difference between a local move and a move onto an
>   USB stick, it's hard to see why a drag inside my (NFS mounted) home
>   directory is different from a drag between my home directory and the
>   /tmp directory.

I agree that your specific examples show incorrect behavior from
Nautilus. If /home and /var are presented as being part of the same disk
(which is how Nautilus presents /home for me, though it's really a
separate partition), then dragging from /home to /var should indeed move
rather than copy. The same applies to an NFS home; that it's actually on
a separate device is an implementation detail, which (I assume) Nautilus
usually hides, and it should hide it when dragging too.

However, I don't think that means the "move on the same device, copy
between different devices" drag-and-drop model is broken in general.
It's not wonderfully consistent, but it Does The Right Thing in the
majority of cases. One obvious counterexample to your proposed "always
move" model is a CD-R: that you want to burn a file to CD rarely means
that you don't want the original any more. (Especially since you might
never get around to actually clicking "Write to Disc"!) Another example
is music players, both in hardware (e.g. an iPod) and in software (e.g.
Rhythmbox): that you drag music into the player doesn't mean you want it
moved from where it was before, it just means you want it imported.

> * The current behaviour can be confusing, since "old" versions of files
>   are left lying around. If move a file onto an USB stick to work on it
>   on a different computer, I suddenly have two versions of the same file
>   and have to find out, which version is newer. In the worst case I have
>   edited both versions (having forgotten about a copy) and have to merge
>   them or accidently delete the changes from one of the files.

I think that would be handled better by a merge and sync command, not by
a move *or* a copy.

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[ritz-2]

Hello

On Fri, 2008-05-23 at 12:24 +0200, Sebastian Rittau wrote:
> [Followup-To the Usability list]
>
> Hi!
<snip/>
>
> * When dragging I currently always have to check whether a move or a
>   copy will be performed. I have several mounts and partitions that I
>   work with regularily. I now press the shift key by default when moving
>   files around. (A feature for advanced users.) I should not need to
>   care on what file system or file server a certain directory is mounted
>   on. This is what my system administrator is for. I just want a plain,
>   consistent view on all the files, directories, and devices I work
>   with.
checking if the files to be moved are on the same fs is broken in
nautilus. nautilus uses check_same_fs[1], which checks for fs type[2]
and if they match moves them.

  This bug manifest itself when user is moving from say, one nfs share
to another. file would be moved, rather than copied.

>
> * The action of "dragging means moving" is more natural that "dragging
>   means copying". Drag & drop is a real world metaphor. In reality I
>   usually don't copy stuff just by taking it and moving it around. That
>   stuff is suddenly copied is unexpected, especially if you've used drag
>   & drop on the same file system before.
>
> There are ways to enforce moving files or getting asked about your
> preferred action. But these are all power user features. The most simple
> and forward action (just moving stuff around) should be the most easily
> understood.
>
>  - Sebastian
>
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=143746
>

[1]
http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-dnd.c?view=markup
[2]
http://library.gnome.org/devel/gio/unstable/GFileInfo.html#G-FILE-ATTRIBUTE-ID-FILESYSTEM:CAPS

--
Ritesh Khadgaray
Ph: [phone]
Desktop LinuX N Stuff, RHCE
Software Maintenance Engineer, Pune, Red Hat
ॐ मणि पद्मे हूँ
Eat Right, Exercise, Die Anyway.


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Matthew Paul Thomas-2]

ritz wrote on 28/05/08 06:42:
>...
> checking if the files to be moved are on the same fs is broken in
> nautilus. nautilus uses check_same_fs[1], which checks for fs type[2]
> and if they match moves them.
>
>   This bug manifest itself when user is moving from say, one nfs share
> to another. file would be moved, rather than copied.
>...

Is that bug reported in Bugzilla? I don't find it with a search for
"check_same_fs".

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[ritz-2]

Hello

On Mon, 2008-06-02 at 22:38 +0100, Matthew Paul Thomas wrote:

> ritz wrote on 28/05/08 06:42:
> >...
> > checking if the files to be moved are on the same fs is broken in
> > nautilus. nautilus uses check_same_fs[1], which checks for fs type[2]
> > and if they match moves them.
> >
> >   This bug manifest itself when user is moving from say, one nfs share
> > to another. file would be moved, rather than copied.
> >...
>
> Is that bug reported in Bugzilla? I don't find it with a search for
> "check_same_fs".

I hit upon this, when investigating a different bug
http://bugzilla.gnome.org/show_bug.cgi?id=505690

>
> Cheers
> --
> Matthew Paul Thomas
> http://mpt.net.nz/
--
Ritesh Khadgaray
Ph: [phone]
Desktop LinuX N Stuff, RHCE
Software Maintenance Engineer, Pune, Red Hat
ॐ मणि पद्मे हूँ
Eat Right, Exercise, Die Anyway.


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability