Re: [Usability] UI review of overwrite dialog

[Kai Willadsen <kaiw itee uq edu au>]

On Fri, 2005-04-01 at 02:33 +1200, Matthew Thomas wrote:
> That would be true, except for another bug: if you realize that Sound 
> Juicer *is* just replacing existing files with identical files, and you 
> click "Cancel", it doesn't actually cancel -- it leaves you a partial 
> file for whatever track it was working on. That could be improved 
> slightly by using the more accurate term "Stop" ... but only slightly.

Isn't the correct solution to this problem simply never to write a
partial track?

> So, step 2: If Sound Juicer is copying to a destination where a file 
> with the same name already exists, copy to a temporary file first, and 
> replace the existing file with the temporary one only when it's 
> finished. That way, no matter when "Stop" is clicked, you're left with a 
> complete copy of each track.

Except that, as you've pointed out, you might have a non-complete track
to start with, which would leave you with one complete and one partial
version of the track. And you can't necessarily assume that people will
only use S-J, or that other rippers will be as sensible.

What if (as part of step 3) the song length is also checked, and if the
length is the only piece of metadata that *doesn't* match, then assume
that we have a partial copy to start with and overwrite it without
prompting.

(Of course, possible dataloss here, but realistically I can't think of a
case where you're going to be overwriting a music file with exactly the
same metadata, same length, etc. when the files are actually different.)

> There, we've fixed all the situations where replacing might cause 
> dataloss. Or have we? What if the existing files were created by another 
> program (or even a future version of Sound Juicer) at a different 
> bitrate, or with a better encoder?
> 
> So, step 3: If a file with the same name exists in the destination, and 
> the temporary file (once created) is found to be different from the 
> existing file, append the detectable difference to the name of the new 
> file in in parantheses. For example, "Real Estate (192 kbps)", or "Real 
> Estate (SoundJuicer)", or (as a desperate last resort) "Real Estate 
> (SoundJuicer 2.10)". For bonus points, if this is true for all tracks in 
> the album, append to the album name rather than to every track name.
<snip>
> Bonus alert removal: When finished, don't say "The tracks have been 
> copied successfully" -- it's not true if I skipped all of them, and it's 
> annoying even if I didn't. Instead, if any tracks *were* copied, get 
> Nautilus to open the actual folder window so I can see them for myself. 
> This isn't necessary *ideal* behavior (I'm still thinking about that), 
> but it's better than the current behavior, as follows. If opening the 
> folder is what I wanted to do anyway, it saves me a click. And if it's 
> not what I wanted to do, then closing the folder is exactly the same 
> number of clicks/keypresses as closing the alert would have been.

How about adding a single prompting dialogue at the end (or the
beginning) of the process pointing out which tracks are duplicates, what
the differences are and asking what to do about it? Every time I tried
to phrase this, it sounded horrible, but something to the effect of:

"You've just copied better quality versions of all these tracks than you
had before. What do you want to do with the old copies?
[Keep] [Replace]"

-- 
Kai Willadsen <kaiw itee uq edu au>