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

[Jason Hoover <jasonhoover verizon net>]

On Sun, 2005-06-05 at 01:59 +0200, Matthew Thomas wrote: 

> 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".

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

Okay, since you seem to want a real-world example, here's one; I want to
move older pictures of my fiancee into a folder I've been saving new
ones in. She tends to give them similar names (like "ugly.png" [silly
modest Canadians]) when she sends them to me. I don't want to
accidentally loose any of the newer ones by doing so.

A sync operation is not appropriate, nor is replacing them. Really, I
just want to move only the ones which don't have a similar name, and
re-name the ones that do. Pruning the duplicates is a task for me later.
Hence, we need a skip/skip-all option.

In other words:

"Warning: Putting the smoke-bombs in the gopher holes will blow up your
tool shed because it contains TNT. 
[Hire professional] [Destroy shed] [Ignore gophers]"

But where is the "Skip the one next to the tool shed" option? 

> 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.

This is true, but I was assuming there was no sync command yet.

> 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.

Just because people ask to see something, doesn't mean they're actually
going to look at it. If it takes more than 2 seconds to figure out,
they'll just get frustrated and give up. As you pointed out.

http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

A sync command is an awful lot of trouble to go through for 3 to 10
individual files, and would really only be appropriate in the case of
someone attempting to replace a folder. 

Unless it involved maybe 2-4 button presses and almost no reading. A way
to know what was going to take place would be invaluable here as well,
via iSync, or a list perhaps.

Also, it should be careful and prompt in cases where there's too much (>
a month [unset clocks]) or too little (< 24 hours [timezone faux pas])
time difference, as relying on clocks to be near-synced is dangerous.
(If only files had revision counts in addition to date fields...)

So, the "synchronize" function you're proposing would need to be quick,
dirty and PERFECTLY reliable. I'm not saying it's impossible, or
wouldn't be the coolest thing ever, but I can't fathom a solution to
those problems myself.

If you can solve those problems, the world is your oyster.

> 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>

On an unrelated note, do you know if the permissions dialog will ever
contain an option to copy permissions to sub-items? 

>      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.

I can see lots of cases where that would happen and get annoying. And it
doesn't quite cover remote files well, unless 1.a would check for it. 

>      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.

Oy, drop boxes are evil, twisted things. 

> 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.

I suppose that would take care of some of my concerns about time/date
stamp testing, but, I'm not terribly confident that it would cover all
of them. 

>      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.

Having a skip-all option here would solve the scenario presented in my
example, and make me happy. 

> 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.

That sounds good, but could probably be better worded, or the buttons
"Empty Trash" and "Cancel" should probably be used instead, so the user
doesn't move the box aside and do it themselves. 

> 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?

To sum it up:

1) It needs a skip all option.
2) The sync command would have to be almost perfect.

Also, do you think Is there any way, like in the follow ups of: 
http://rentzsch.com/bugs/fileFolderOverwriteBug

That this could be done non-destructively? A move to trash default,
perhaps?

Hmm, this is getting quite lengthy, but it looks like real progress is
being made. Forgive me if I've overlooked something or fail to make
sense somewhere.

-Jason