Re: [Muine] A few suggestions

[Jorn Baayen <jbaayen gnome org>]

Hi!

Thanks a lot for this new bunch of suggestions! :)

I'm going to address them one by one.

>         == Keybindings ==
> 
>         The use of <Space> as an accelerator for "Play" is pretty
>         awkward mostly because <Space> is used in most other
>         applications to activate widgets (i.e. buttons) when navigating
>         by keyboard.  Maybe <p> should be used instead like in totem.

You're right. I made it <space> when Totem itself used space as well.
Will fix in a minute.
 
>         == Cover Display in Main Window ==
>         
>         There will likely be many people here who disagree with me on
>         this one, but I personally dislike the display of cover-images
>         in the main window (whereas I really like them in the album
>         selection window).  Not only does it feel like overuse to me,
>         but it also gives the main window a "heavier" appearance than
>         would be necessary I think.  Additionally, the image makes it
>         more difficult to use Muine with a main window in a size both
>         space efficient and pleasing to the eye (e.g. close to the
>         "golden" 1 to 1.6 ratio).

I see your point, however to me personally this is pretty valuable
information. It allows to me figure out what album is playing by quickly
glancing at the main window, without having to read the text and having
to try to remember where the song comes from. Of course we could add an
album label, but imho this would be worse clutter... as it introduces
more text to the window.
     
>         == Library Button Behaviour ==
>         
>         It's not only inconsistent but I guess also confusing for new
>         users that one of the Buttons in the library dialogs ("Play")
>         closes the window whereas the other ("Queue") doesn't.  It would
>         seem better to me to either change both buttons to close the
>         window (and then also change the "Close" button to "Cancel") or
>         to change both not to (and then maybe scrap the "Close" button
>         altogether).

This one has come up a lot, but:

- It doesn't make sense to click "play" (or "play next") twice.. and
therefore it is the kind of action you would expect to close the
dialog. 

- Having the "play-closes-dialog" behaviour allows for quick-and-easy
song/album selection. When I press "play", it plays, and that is that, I
don't need to bother with closing the window.

- "Queue" on the other hand is a "playlist building" kind of action,
when queueing most people queue a few objects, not just one. Having to
go into the window over and over again would be a bit of a pain. This
argues against having the dialog close on queue.

So, this is not an easy one to fix. The current behaviour is the best I
have been able to come up with thus far. It might be a bit confusing for
first time users, but once they have clicked both buttons once, they
will know how it works. 
  
>         == "Play Next" Feature ==
>         
>         Often I miss a way to easily select a track or an album to be
>         played after the currently playing track.  Maybe if the "Close"
>         button is removed (as suggested above) it could be replaced by a
>         "Play Next" button.

This has also come up a lot.. and I agree, I would personally like to
see it too. But I feel having having thee different buttons for more or
less the same action is a bit overkill. But if three is, then two is too
of course .. 

For now, it is possible to achieve this by dragging songs or albums into
the playlist.

But a better solution would be so much nicer here. 

Some brainstorming (not necessary good ideas, some even straight out
bad, but still, ideas):
- Merging all actions into one button, and clicking this button
resulting in a pop down menu
- Putting a dropdown button next to the play button a la epiphany,
nautilus: "Play now", "Play next", and, if totally on crack, "Play now
and close window" and "Play next and close window".
- A popdown button next to the queue button, with the following two
radiomenuitems: "Queue at end", "Queue after playing song".
- A checkbox saying "Queue after playing song"
- Putting a popdown button next to the play buttons in the *main
window*, "Play song/album", "Queue song/album", "Play song/album next". 

However, these are all workarounds for the real problem. The real
problem being that we have got the following use cases, and no decent UI
for all of them:
- User wants to start playing one object, and queue a few more
- User wants to queue up a few objects
- User just wants to quickly play one object
- User wants to play an object next
      
>         == Cover Fetching Privacy Issue ==
>         
>         Fetching album covers automatically from Amazon violates the
>         privacy of the users by making it possible to acquire a list of
>         the albums on their computer.  While this may seem like a minor
>         issue, the users privacy shouldn't be taken to lightly I think.
>         Therefore (and for lack of a better solution) I'd suggest adding
>         a pop-up dialog asking whether covers should be fetched from
>         Amazon whenever coverless albums are added to the library.

Yes. A popup would be very disturbing though.

Ideally I would like to move the Amazon fetching code out of Muine into
some tagging app, as it is actually a music management, not playback
task. 

So I think that for now, until this magic application steps up, we
should just leave it as-is .. unless somebody really objects, in which
case I can add a gconf preference.
      
>         == Album- and Song-Browsing ==
>         
>         Perhaps the biggest problem I currently have with Muine is with
>         browsing the library.  Because of the search it's quite easy
>         with the current interface to add songs or albums to the library
>         whenever you know exactly what you want to play beforehand.
>         However, personally I more often open the library without a
>         clear idea of what I want to play and currently it's pretty
>         difficult to get a good overview on what is available on the
>         system.  The fact that the entries in the album-dialog are
>         primarily sorted by artist and not by title (as I think would be
>         more consequent with the current interface) only badly
>         substitutes for real browsing.

Fully agreed.

>         Of course, browsing would necessarily make the dialogs more
>         difficult to understand and this brings up the complicated
>         question of where the ideal balance is between functionality and
>         ease of use.  Personally I consider basic browse functionality a
>         pretty important feature that I'd expect to be a help to quite a
>         large percentage of the targeted Muine user base.  Therefore I
>         think it justifies a slightly more complicated interface.  The
>         following is an example for an interface that I'd say fullfills
>         the "slightly" requirement:
>         
>         http://www.brokenbits.de/lars/cruft/MuineLibAll.png

This is pretty good.. but the amount of widgets and their alignment
dazzles me a bit. But I think we might be able to come up with something
refining this idea a bit ..

One tiny improvement - I guess - would be moving the "By artist" thing
to be under the list, so that things would line up a bit better.

Some brainstorming for alternatives:
- Using a combo box instead of the list. Or a combo box-like thing,
popping down a scrollable list.



        
>         The Info button is just an idea.  The drop-down in the upper
>         left would select the type of items displayed in the list below
>         and would contain entries like "By Artist", "By Genre", "By
>         Release Year", "By Release Type" and "By Release State" (for
>         more info on the last two items see:
>         http://musicbrainz.org/popup/attrguide.html).  When text is
>         entered into the Search entry the items in the list would change
>         to list only the relevant entries:
>         
>         http://www.brokenbits.de/lars/cruft/MuineLibQuetsch.png
>         
>         The dialog would look similar for the song-selection.
>         
>         == Separate Windows for Songs and Albums ==
>         
>         It feels a little bit strange to have two separate "Add Song"
>         and "Add Album" dialogs because you always have to decide
>         whether you want to play individual tracks or complete albums
>         befor you open either of the two (unless of course you open both
>         of them at once).  Often however, you need a list of the
>         availiable music before in front of you before you really decide
>         what you actually want to play.

Originally I had the idea of introducing a separate browser window at
some point, much like your mockup. But it would also show both albums
and songs.. if the songs could be grouped as an album, only the album
would be shown, and for single songs single entries would be added.

>         The problem with this item is: I havn't come up with a good idea
>         yet of how to combine both song- and album-selection into a
>         single dialog without the dialog getting too complex.  If
>         someone else has a goog solution here that would be nice :)

Yes ..

>         == Multiple-Enque Bug ==
>         
>         There's currently a problem when I hit the Queue button in
>         either of the two library dialogs: the second time I pressed the
>         button it doesn't add the next item even though it get's
>         automatically selected before the button is pressed the first
>         time.

Works for me.. what version are you using?
(Btw it would be great if you could move this one to bugzilla, then we
can have the feature/UI discussion in this thread, and have the bugs
handled off in bugzilla. I look at all muine bugs in bugzilla when I get
the bugmail, so I can promise you it won't get lost ;) )

>         == Problem with some (bogus?) .ogg files ==
>         
>         [This is perhaps a GStreamer issue, but I'll mention it anyway.]
>         There are a few .ogg files on my system that Muine just skips
>         whenever I add them to the playlist.  file reports the following
>         for those files:
>         
>         Ogg data, Vorbis audio, stereo, 44100 Hz, ~0 bps, created by:
                                                    ==

Smells like a broken file or something. Is there an ID3 tag on it maybe?



Cheers,

Jorn

>         Xiphophorus libVorbis I (1.0 beta 1 or beta 2)
>         
> Ok, that's it for today.  The list got a little bit longer than
> expected :)
> 
> As always all the ideas are just suggestions and I won't start an
> argument for their inclusion.  But comments are of course welcome!
> 
> Regards,
> Lars
> 
> _______________________________________________
> muine-list mailing list
> muine-list gnome org
> http://mail.gnome.org/mailman/listinfo/muine-list