Re: [Muine] Muine UI idea for the future

[Viet Yen Nguyen <nguyen cs utwente nl>]

On Fri, 2004-01-30 at 10:05, Eugenia Loli-Queru wrote:

Hi,

> I have re-arranged a few things, so, in my suggestion we have the playlist
> and its buttons on the left hand side, which is the first thing a user would
> do (at least for left-2-right users). 

This is indeed a good and perhaps could be tried. 

> This design has many ways to view the application. You can leave visible

[... views stuff...]

> lot of people who like an SDI interface more than an MDI one. ;-)

The problem with multiple views is the increased users mental model of
the application. From an user perspective, the current way of handling
"states" is the best: a maximized state and a minimized state (the tray
icon). But what could perhaps be a good idea is to add accelerators to
the tray icon just like Rhythmbox or is this already implemented? (I'll
compile the latest Muine next monday) 

> I tried to keep the HIG's spacing into mind in this mockup, so the borders
> of the widgets in regards to the whole window are now a bit bigger than the
> current Muine.

It is indeed a good idea to handle the spacing accordingly to HIG. Maybe
an item on the TODO list.

> also added the Shuffle and Repeat options here (might be better to only have
> them in the menubar instead?).  

Menubar would be better, since repeat and shuffle aren't exactly oftenly
used options.

> I would also advocate to get rid of the
> "Playlist (XX minutes remaining)" text. It takes space, makes the interface
> more bloated and that information sounds more like a punishment than
> actually useful information ("you got 17 more minutes to sing and dance,
> after that, back to work!").

It does help when you want to add new songs or albums on time.

> Now, the most important change I did in the playlist though, is the way it
> handles selections. I used Muine all day today and I got more than 3 times
> confused as to which song was actually playing, because of this scenario:
> User starts playing a song ("Rasputin"), the little icon appears before the
> song name in the playlist and the list item gets this teal/blue color
> because it is selected. User single-clicks another song from the list
> ("Orinoco Flow"), but doesn't activate it. User goes elsewhere. User comes
> back and sees "Orinoco Flow" being selected, but "Rasputin" actually coming
> out of the speakers. User initially believes it is a bug! Paying closer
> attention user sees the little icon on teh left of the song name. Still, it
> is confusing without much paying attention and trust me, no one wants to pay
> attention to music players which are "background" applications, we got work
> to do. ;-)

Indeed, this is quite confusing. Secondly, maybe it is a good idea to
gray out the played songs.

> So, this is what happened a lot to me today, and I didn't like this UI
> behavior which leads to confusion. What needs to be done is to change the
> selection/color behavior to this:
> Always have the teal/blue color as in the mockup for the song that's
> playing, but when a user single-click selects another song, please use a
> lighter-color to represent the selection, cause otherwise it just gets
> confusing as to which song actually currently plays. An idea would also be
> to use that lighter color for mouse-overs as well, when the user mouse-overs
> over songs in the playlist.

Perhaps selections should go lost when the application losed focus, but
to be quite honest, I am not fully aware of the possible implications
with this solution...

> The Playback area adds a progress bar (which as I mentioned above, resizes
> automatically when its view resizes). 

A progressbar is indeed a nice thing, but it isn't really necessary and
not exactly oftenly used. But I do agree that there might be better way
to have more feedback on the actual state of the player (playing, paused
etc). A visualization plugin is indeed a nice way, but also quite
meaningless. Does anyone else has a good idea on how to do this?

> If no album cover can be found, please use Muine's icon image or another
> icon, but not the Gnome logo,  cause that would be more relevant, I think.

I agree on this.

In general I find some elements of your mockups quite interesting and
worth trying, however in general I agree with Schmid that it makes Muine
quite complicated. 

And what Jorn told me a few days about Muine in general, is that he
wants to have a music player that would fit the needs of the general
user. So, from what I understand, one music player to rule them all.

Viet Yen