Re: [Usability] UI review of overwrite dialog
- From: Matthew Thomas <mpt myrealbox com>
- To: "usability gnome org" <usability gnome org>
- Subject: Re: [Usability] UI review of overwrite dialog
- Date: Mon, 04 Apr 2005 09:19:52 +1200
Kai Willadsen wrote:
> 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?
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?
> > 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.
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. 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
> And you can't necessarily assume that people will only use S-J, or
> that other rippers will be as sensible.
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.
> 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.
] [Thread Prev