Calum Benson wrote: > However, I'm not sure I necessarily agree. Most of the time, when I'm > copying or moving files, my intention is to replace any conflicting > files. I'd never look at the thumbnails in those cases. I can't even > remember the last time I started a move/copy operation without > realising there was going to be a conflict, and then had to make a per- > file decision once the operation was in progress.
For me, unexpected conflicts are most likely with images :) I wouldn't mind the dialog remembering collapsed/expanded state. > (But this is one of the details that makes it hard to design this type > of dialog without some user testing... right now we're really just > guessing what the most common use cases are, based on our own > experiences.) I rather have a better dialog soon, based on our limited experience, than a well researched one never ;) Now, if someone here is in a position to do that testing, great! > Maybe, that just makes the GUI logic a little more complex-- you'd > probably want to disable one entry while they were typing in the > other, and then it may not be obvious (even with the Reset button) how > to enable the other field again if they changed their mind. > > Or you could just allow them to type names in both fields, I guess, > which would rename both files, but that doesn't seem like a > particularly useful thing to allow. In my mind, getting rid of the radio buttons flattens the logic and interaction. I see no use in disallowing both files to be renamed. Addition: if there are several conflicts and the user chooses Skip, maybe a report should be brought up, a list of all skipped files to make it easy to review them. Not so much a dialog, more a file browser window. -- Thorsten Wilms _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
