Re: [Usability] Sound Juicer 2 mockup comments

[Samuel Abels <newsgroups debain org>]

On Tue, 2005-01-04 at 15:44 +0000, Ross Burton wrote:
> On Tue, 2005-01-04 at 16:26 +0100, Samuel Abels wrote:
> > From using s-j I know that it immediately starts extracting when the
> > "Extract" button is pressed. That is good, but the button in the new
> > interface is IMO not clear enough (as you already mentioned) to still do
> > this relatively intrusive action.
> > 
> > Having a popup dialog ask the user would be a step backward though. I
> > guess it has the same size as the other buttons to leave the impression
> > that s-j is a CD player and a grabber as well, but I would still prefer
> > it to be labeled "Extract" like in the current version - that looks so
> > much easier.
> 
> I'm not sure what you mean by a popup dialog on pressing the extract
> button to ask the user...  When the copy button is pressed extracting
> will start straight away, just as it does now.

What I meant is that ripping is pretty intrusive (storing a lots of data
on a device is) and when the extract button is not 100% clear in it's
description some people may tend to just try it out and are then left
with junk data on their hard disk. Thus, a descriptive name for the
button should do better than an icon.

> The main window is a read-only view of the metadata.  Editing is being
> moved out into a separate dialogue as most of the time track editing
> won't be required -- the metadata is correct.

I have found that I need to edit at least ~30% of all CDs. Really, I do
not see the advantage of having a separate dialog. Why would you not
want the tracks editable in the mainwindow? In fact, it even makes it
different from the behavior known from nautilus's list view. If the
reason is "it is metadata": Why should a user have to know the
difference between "The track title is the file name" and "the track
title is stored in a metadata database"?

>  If it is incorrect then
> there may be some work required, maybe splitting the title fields into
> artist/title (often FreeDB imports are titled "Artist / Title"), or
> setting the date of each track, the genre, etc.

The date and genre options are not track-specific, so they could be
pushed into a simple separate "Disc Information" dialog window. In fact,
s-j seems to be made more similar to Goobox by using an editor window
for editing tracks. I have commented on the separate editor of Goobox
here

http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00792.html

already.

The artist/title issue could be solved by using a simple check box in
that editor, or in the CD menu, or even automatically by checking
whether *all* track titles have a '/' in their names, then splitting
them accordingly.

> This adds a lot of
> bloat to the dialogue so I plan on splitting it out so that the main
> interface remains simple.

I believe the above solution would even remove bloat from the window.

> > I would vote for HIG-compliance, as the current functionality never felt
> > "right" to me in Totem. Making them separate buttons would be closer to
> > what people know from the real world. Even more, for the same reason I
> > would like a "Stop" button in Totem. Isn't that even more important in a
> > CD player? "Pause" would probably keep the CD spinning, thus also
> > blocking the hardware eject button.
> > But either way, those changes should be made consistently with Totem.
> 
> Pause would stop and unlock the drive, and on play it would resume from
> where it left off.

Wouldn't stop the CD spinning add a delay when you resume playing? Not
sure if that is big an issue since I never play CDs on my computer, but
it is not what I know from my hardware CD player.

>  Personally having both Stop and Pause in an
> interface where they both have identical actions is pointless.

They are not identical, Stop is "Pause and back". It's just that this is
a well know button from hardware players. At least, I miss this in Totem
very often, but maybe I am just not sitting in front of it enough ;).

-Samuel
-- 
 ------------------------------------------------------
|      Samuel Abels       |   http://www.debain.org    |
| spam ad debain dod org  | knipknap ad jabber dod org |
 ------------------------------------------------------