Re: [Muine] Muine UI idea for the future



Hi,

> 
> > 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) 

Not sure what you mean with accelerators? Like, going with your mouse
over the tray icon and pressing keys? I think it would be kinda crack..
it's just as easy, when you have moved your mouse there anyway, is to
click, press 'n' for next and press escape to close the window again..
(that sounds like crack too, i know, but less crack than having specific
keybindings :P )

> 
> > 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.

We use HIG spacing already.. 

In Eugenia's mockups the window spacing is a bit different, but the HIG
does not mention anything about that, apart from the case of dialogs.
And this certainly isn't a dialog. I think having a 12 pixel border on
the window is, as long as not recommended by the HIG, a silly thing in
this case as it requires a lot more eye scanning to get to, for example,
the playlist that way...

> 
> > 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.

Yeap.


> > 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...

I fixed this one in CVS by selecting & scrolling to the playing song
when the user:
- opens the playlist window from the tray icon
- presses next/previous
- etc

(but not on EOS! so you aren't disturbed on your organising actions
whenever a song ends.. the selection only changes when you explicity do
something)

It has solved the problem for me.. 

I also tried the giving the playing row a different colour approach, but
it turned out to be messy and confusing.

As for graying out playing songs.. good idea, added to the TODO.

> 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.

Yeap..

The big problem of Rhythmbox is that it only fits one usage case,
fitting about 50% of the music playing population.. it only works well
if you like to play whole albums. When you "just want to listen to
music", xmms is a lot easier to use.. (I have both playing behaviours,
and was frustrated by having to switch between RB and XMMS all the time
..)


Cheers,

Jorn




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]