Re: [Usability] UI review of overwrite dialog

[Kai Willadsen <kaiw itee uq edu au>]

On Mon, 2005-04-04 at 09:19 +1200, Matthew Thomas wrote:
> Kai Willadsen wrote:
>  > Isn't the correct solution to this problem simply never to write a
>  > partial track?
> 
> How would you achieve that, other than the way I suggested below? You 
> could remove the "Cancel"/"Stop" button from the interface, and you 
> could fix every last hang/crasher bug in Sound Juicer, but how are you 
> going to protect against kernel panics, xkill, power cuts and so on?

Sorry - you suggested changing "Cancel" to "Stop" because that describes
what S-J does. Why not just make it *actually* cancel the operations?
You say in bug #172544 that this is unrealistic, and I'm wondering why.

>  > 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.
> 
> I don't see how. If I didn't click "Stop" before the track was finished, 
> the partial file would be replaced by the complete file.

This is the bit I don't get. You mention replacing the old file in step
2, but then talk about creating a new file in step 3 if they're
different, named according to the difference in metadata. As far as I
can tell, this could leave you with files like:
Tricky - Mellow.ogg
Tricky - Mellow (3:33).ogg
where the first is a partial copy, and the second is the full version.
My mail was just trying to figure out a way to make this not happen.

To state more clearly: I think Sound Juicer should automatically replace
obviously-partial tracks with full tracks without prompting.

> If I did click 
> "Stop" before the track was finished, there would be no change -- the 
> file would still be the old partial one, but I'd be no worse off than I 
> was before.

Agreed.

> It's probably just that it's too early in the morning for me, but I 
> don't see how that makes any difference to what I suggested.

Just pointing out that even if you fix S-J's cancellation behaviour,
it's always going to be possible to start with a partial track that
should be replaced.

>  > 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.
>  >...
> 
> I don't think that would cover enough ground. In the case where someone 
> just clicks "Extract" by mistake, and then immediately clicks "Stop" (as 
> opposed to clicking "Extract" deliberately, and only realizing their 
> mistake several seconds later), the partial file might not even contain 
> full metadata yet.

Which is fine, because the track was cancelled and shouldn't be written
at all. And even if it were written, then presumably your proposal of
appending detectable differences to the filename would mean that there
wasn't any dataloss anyway.

-- 
Kai Willadsen <kaiw itee uq edu au>