Re: [Usability] Nautilus: Overwrite Existing File/Folder Dialog Buttons

[Matthew Thomas <mpt myrealbox com>]

On 4 Jun, 2005, at 9:35 AM, Jason Hoover wrote:
> On Fri, 2005-06-03 at 23:35 +1200, Matthew Thomas wrote:
> ...
> > > Replace All, Skip All, Skip, Cancel, Replace
> ...
> > I think that's too many. In what case is "Skip" or "Skip All" ever
> > useful? I can't think of one -- except where you've added files to one
> > version of a folder, and then use that version to overwrite another
> > version.
>
> Not quite. I've come across a few instances where I've wanted to merge  
> a large collection of files together (such as digital camera images,
> filenames on a similar topic, etc) but not actually overwrite them.

I'm not sure what you mean by "filenames on a similar topic". But for  
merging a collection of digital photos (where the camera has used the  
same filenames for different photos), you don't want "Skip" anyway. You  
want to either mass-rename the incoming photos, or create a subfolder  
for them. And the first step to doing either of those things isn't  
"Skip", it's "Cancel".

> > But for that you should be using a proper Synchronize command,
> > not a Move or Copy, because you might have deleted stuff deliberately
> > from the local folder too, and you want that deletion repeated on the
> > other version.
>
> Has anyone ever seen someone use an MS briefcase? Ever? Anyone?

Ooh, Microsoft Briefcase! I remember that -- that was the desktop icon  
people either deleted or ignored after installing Windows 95 or 98. :-)  
By the time a significant number of people owned both desktops and  
portables, the Briefcase function had long since fallen victim to  
Microsoft's goal of "reducing desktop clutter" in Windows 2000 and  
later  
<http://www.microsoft.com/windows2000/professional/evaluation/business/ 
overview/manage/>.

Briefcase also had -- and, in Windows XP, still has -- the disadvantage  
that it has to be set up ahead of time, instead of catering for the  
"okay, I have two copies of this folder, what do I do now?" scenario.  
People would be much more likely to use a synchronization function if  
it was offered when they were about to lose data from trying to  
synchronize manually. For that, see step 5.b below.

> ...
> > Once pre-flighting is implemented, "Replace" and "Replace All" can  
> > also be merged into "Replace". For example: 'Items with all the same  
> > names already exist in "Bar". Do you want to replace them with the  
> > ones you're moving?" And: 'Some items with the same names (including  
> > "Foo") already exist in "Bar". Do you want to replace them with the  
> > ones you're moving?' And so on.
>
> As a rule of thumb, coercing the user into making blanket decisions can
> be as dangerous as making assumptions for them. Forgive me if I'm
> mis-reading this.

Not wanting to make a blanket decision is an edge case, for which you  
can click "Cancel", alter your selection, and try again.

> Imagine a user has three files, edits one on a floppy, and one at home.
> They goes to copy the files (as their bad habit teaches them) and
> overwrite the older with the new, but forgot which ones they edited on
> the floppy. So, now the user is forced to put both folders into list
> view, and manually select, one by one, the files they really want to
> replace.

In the absence of a Synchronize function, yes. But copying wouldn't  
produce the desired result here anyway! No matter which direction you  
copied in, even if you subjected yourself to the "Skip"/"Replace"  
extended interrogation, you'd still end up with one file out of date in  
the version you copied from.

> ...
> Hmm, perhaps a list box with summary info? A side-by-side comparison?
> This would be an awesome way to work with medium sized sets of  
> duplicate files. Though, there's potential here for it to spiral out  
> of control and take up WAY too much screen real-estate.

And because it's a confirmation alert, once you get past a couple of  
sentences (if that), humans just stop reading. So such a list wouldn't  
be useful for an alert. It would be ideal for a Synchronize command,  
though, because then you would have deliberately *asked* to see it.

> ...
> > Of your proposed buttons, the most useful one by far is "Cancel",  
> > which unfortunately doesn't even exist in the current alert. If I'm  
> > moving several items at once, and some of them won't go, chances are  
> > I don't want to move *any* of them there after all. I want to move  
> > them to the folder I really meant (a different one), or all together  
> > to a disk that has enough room (a different one). So if "Cancel" is  
> > implemented, make sure it really means Cancel, not just Stop.
>
> Hear hear! I'm guessing that this could be implemented a number of  
> ways, regardless of what the end-result box actually looks like, using
> pre-flighting?

Yes you could, but I'd recommend doing it this way in particular:

0.  Start an invisible timer. As soon as the timer hits 0.1 seconds,
    turn on a busy cursor. Whenever an alert comes up, pause the timer
    and go back to a normal cursor. Whenever an authentication or
    confirmation alert is dismissed, reset the timer. As soon as the
    timer hits two seconds (and for bonus points, also if it hasn't hit
    two seconds but you can tell it's going to), put up a progress
    window instead of the busy cursor (but which, unlike the busy
    cursor, doesn't go away when a confirmation alert appears). The
    progress window should feature a progress meter that's indeterminate
    up to the end of step 7 below, and determinate for step 8.

1.  Check the permissions of the destination.
    a.  If you can't write to the destination because it can never be
        writable (for example, it's a closed CD), retire with an error
        alert explaining the problem.
    b.  If you don't have write permission for the destination, and you
        own it, retire with an error alert that features an extra button
        for changing the permissions.  
<http://mail.gnome.org/archives/nautilus-list/2005-May/msg00071.html>
    c.  If you don't have write permission for the destination, and you
        don't own it, put up an authentication alert asking for an admin
        password.
    d.  If you have write access to the destination but not read access,
        and you don't own it, it's probably a drop box but maybe not.
        Put up an authentication alert as above, but include an extra
        button to "{Move, Copy} Without Password", and explain that
        {moving, copying} without a password will mean the {move, copy}
        is overwritable but not verifiable or undoable.

2.  Go through all the source items, calculating their total size, and
    compiling a list of permission problems and name clashes.

3.  If possible, check the space on the destination, and calculate
    whether there's enough (taking into account any moves/copies to the
    same volume currently taking place). If there isn't, calculate
    whether emptying the Trash would make enough space. If it would,
    remember that for step 6 below. If it wouldn't, retire with an error
    alert explaining how much more space is needed.

4.  If there are any permission problems with the source items, retire
    with an error alert that features an extra button for changing the
    permissions.

5.  If there are any name clashes:
    a.  If any of them involve files vs. folders, retire with an error
        alert naming the item (or the first example, if there's more
        than one). <http://rentzsch.com/bugs/fileFolderOverwriteBug>
    b.  If at least one of the destination items is newer, and at least
        one is older, it's dataloss city. Retire with an error alert
        that (eventually) has a "Synchronize..." button to the left of
        its "OK" button.
    c.  Otherwise, put up a confirmation alert naming the item (or
        the first example, if there's more than one), mentioning whether
        the clashing destination items are older or newer (if they all
        are), with "Cancel" and "Replace" buttons.

6.  If deleting some or all of the contents of the Trash would help
    (as calculated in step 3), put up a confirmation alert asking if you
    want to do that, using the words "delete some items from the Trash"
    or "empty the Trash" as appropriate, and buttons "Cancel" and
    "Continue". If "Continue" is chosen, delete just enough items from
    the Trash to make enough room, starting with the oldest items.

7.  Check whether there is any other move or copy currently taking place
    to the same destination volume. If there is, wait for it to finish
    (so as to prevent wasted time bouncing from one part of the disk
    to another).

8.  Do the moving/copying.

Explanations of subtleties:

*   Steps 3 and 6 are split so that you'll never be put through the
    ordeal of a confirmation alert only to be presented with a
    predictable error alert afterward. All the possibilities for
    quitting with a predictable error are placed first (steps 1 to 5b),
    followed by all the opportunities for a confirmation alert (steps 5c
    to 6).

*   Step 3 is before step 4 so that you won't spend valuable seconds
    messing around with permissions, only to discover that a floppy disk
    (or whatever) was never going to be big enough to hold all the stuff
    anyway. A similar waste of time could still happen with step 1b;
    that may be solvable using a split like the one between steps 3 and
    6, but I'm too tired to work it out right now.

This design probably isn't optimal: for example, in a pathological case  
it's possible to be presented with two successive confirmation alerts  
(5c and 6). But I think the design avoids mistakes made by other file  
managers. The Mac OS Classic Finder got at least steps 3 and 7 wrong.  
Mac OS X gets steps 3 and 7 right, but gets at least steps 4 and 5  
wrong. Windows Explorer, and other file managers I've tried, get step 1  
/partly/ right, but pretty much everything else wrong. So if Nautilus  
could follow this design, it would do moving and copying more reliably  
than any file manager I have ever used.

Thoughts?

--
Matthew Thomas
http://mpt.net.nz/