Re: [Usability] New Nautilus File Exists Dialog

First, thanx for the opinions.
The main reason why i designed this mockup was.
Everytime i use the copy command in nautilus getting the trubble with
duplicated files i do not know which file the on is i need.
And if there are more directorys in which dir. the file is.
So i designed a dialog, which i thougt solve the most problems.
This should only be a design, with your help i try to design it,
as easy as posible, by not hidding needed features.

There are some questions open i would discus.
1) Detecting if a file is the same.
   It's right only check the filename is not enought, we should check
the content of the file too, to decide if a file is different. And only
if we know that the file is different we should show the dialog

2) There was the hint that a file could be the same with different type.
Is there someone who can explain me this ?? 

3) I have the same view like Alan Horkan for the file content view
stuff. We should not show the content of the file. Only the icon,
nautilus regulary shows. Or no icon, for the eyecandy i would like to
see the icon. I do not know if it deflect the user from make the

Next i try to make a new mockup with your opinion.
+ a Label which describes which side the target and wich the source is
+ rename open to show file or so
+ the modification time. Dan Zlotnikov had the opinion to only show
which file is older an wich is newer. Personaly i like the plain date,
for the simplicity i change it to the older / newer style.
+ a dialog title, i hope this one is better

You can see it at

Am Die, 2003-07-08 um 18.09 schrieb Alan Horkan:
> On Tue, 8 Jul 2003, Dan Zlotnikov wrote:
> > 1) Displaying the changes in a thumbnail. This is not just for graphics,
> > incidentally. Don't you just love the "file has been changed" error
> > dialogue? What the devil have you changed in it again? Do you really want
> > to keep those changes?
> > A review window of these changes as compared to the existing file would be
> > a Very Good Thing (tm).
> > I realize that this is going to be non-trivial, since the computer would
> > have to distinguish between significant changes (extra paragraph in the
> > middle) and insignificant ones (the remaining text in the file is shifted
> > lower due to the new paragraph being inserted). I've no suggestions at
> > this time as to how to handle that.
> [i can make suggestions but i dont think this is the best way to handle
> it]
> > 2) I object to the idea of automatic decision on whether the file should
> I would not suggested anything like that, I hope you did not get that
> impression from my earlier message.  I tried to keep my reply short, and
> to deal with his question first before the problem he was trying to solve.
> I definately dont want a duplicate interrupting the rest of the copy
> operation, dont copy it at all or send it the end of the queue and ask me
> when the others are done!
> Keep in mind that the real speed bottleneck is usually waiting while
> asking the user silly questions.  I do think there is an efficient
> solution here.
> Suggesting that a file is a duplicate purely based on its name is very
> crude, the size really should be checked too and if they both match then
> perhaps you could see if they both produce the same hash/checksum.
> I expect a well choosen checksum would be far faster than any other
> comparison method.
> Adding an extra size/date check or something could be a relatively simple
> improvement that could be made in the short term and leave more complex
> changes until later.
> Generally I would be happy to have a number -001 -002 appended to avoid
> the name clash and in the case of images at least I would use GQView later
> on to sort out which ones are duplicates (sweet feature, that Gthumb
> doesnt have).
> > Also, with the larger size of the dialogue window, a title inside the
> > dialogue itself (instead of the title bar) would be more visible.
> Many themes use the title bar, please avoid repeating the exact same thing
> just for the sake of those that dont.  In any case the contents of message
> box should be clear and meaningful one its own but that is a differnt
> thing.
> Sincerely
> Alan Horkan
> _______________________________________________
> Usability mailing list
> Usability gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]