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

[Alan Horkan <horkana maths tcd ie>]

On Thu, 2 Jun 2005, Christian Neumair wrote:

> Date: Thu, 02 Jun 2005 22:32:05 +0200
> From: Christian Neumair <chris gnome-de org>
> To: usability gnome org
> Subject: [Usability] Nautilus: Overwrite Existing File/Folder Dialog
>     Buttons
>
> Hello usability geeks! :)

Remember back when geek was still an insult?!

Anyhoo

> We've got Nautilus users who complain that when they copy multiple files
> and there is a conflict (moving foo to bar, where bar/foo existed
> beforehead, that is), they want that we offer the following 5
> possibilities:
> Skip, Skip All, Replace, Replace All, Cancel

GQView has been doing that for years [1].  ;)

My preferred workaround in this kind of situation is to bang an extra
suffix on the files and then figure out which files are redundant and can
safely be removed.  By sorting and compare the files based on date/size
etc you can tell which files are duplicates reasonably efficiently.  When
working with Images GQView provides some fancy tools for checking (like
compare by checksum) if you really need them.

> They should all be presented in one dialog. I fear they might look very
> scary. Is there anything "creative" we could do about them? We had a
> little discussion in #nautilus on IRC on that:

Are you looking to just fix this problem or are you willing to try and
address the bigger more nebulous problem of file management?

I think with more information this process could be improved.  For
example, you are not likely to want to replace older files with newer ones
or waste time transferring copies of exactly the same file.  Better
feedback would really help the user decide if they want to use
Skip/Replace.  The user doesn't usually have enough information to
decide if they can safely Replace All, and if they make a mistake they
cannot go back.  I dont know what the right answer is exactly but I think
there is a bigger problem that could be solved here.

> gedit resolves this obviously in a very creative way, and we can
> investigate moving to that system, which would require some backend
> bending. But for now, I think it is better to just polish the conflict
> dialog. Do you think that it is reasonable to put 5 response buttons
> into 1 dialog? If yes, what would be the preferred order? I've come to
> the conclusion that
>
> Replace All, Skip All, Skip, Cancel, Replace

Can anyone recall the underlying logic that is supposed to be used to
determine button order in a dialog?

I would have thought it would be:
Cancel, Replace All, Skip All, Replace, Skip
(seems like Cancel/Close should be at the end, and it is probably better
to default to Skip which is the safer option)

Having Five buttons in a dialog like that doesn't exactly feel right but
using a checkbox instead doesn't feel any better.

Tough problem to get exactly right, people have been trying for years.

Sincerely

Alan Horkan


[1] http://www.maths.tcd.ie/~horkana/gqview-overwrite.png