Re: [Muine] Some UI comments

[Jorn Baayen <jorn nl linux org>]

Hi!

On Sat, 2004-02-14 at 22:24 +0100, Lars Weber wrote:

> Hi everyone!
> 
> Now that I've found the time to read through the recent discussions on
> this list, I'd like to make a few comments about the Muine user interface.
> Please note that my comments at this time are completely based on the UI
> as far as I can figure it out from the screenshots I've seen[1] and from
> recent discussion on this list!  The reason is that I'm currently pretty
> busy with other things (upcomming university exams for example) and
> therefore don't have the time to really install Muine, yet :-/
> 
> Anyway, without much further ado:
> 
> Buttons
> -------
> 
> One of the first things I wondered when I saw the screenshot was: "Why are
> all the playback control buttons placed inside the main UI and not on a
> toolbar as they would be with any other app?"
> 
> Personally I think that the correct place for both the
> Prev/Play+Pause/Next buttons and the Add <foo> buttons would be on a
> toolbar with a separator between the former group and the latter.
> 
> The loudness button is kind of special and might therefore better be
> placed somewhere inside the main UI.
> 
> The advantage of toolbar buttons is not only that they are more standard,
> but also that they are easier to hit because of their size in the default
> configuration (without looking ugly).

Yea.. 

I'll explain why I chose to go for a non-toolbar..

This is very subjective, but to my mind a toolbar is something has to do
with documents, manipulating them, viewing in some kind of way, etc. Not
something that has as much .. direct functionality as the playback
buttons. For example, when editing a document in abiword the main action
area would be the area where I type the text. In epiphany, this would be
the browser area. Here the main bits are the control buttons .. 

I'm not sure this is the Right Thing, but to my mind a toolbar would
just seem odd.. dunno.. what do others thing?

> 
> Visualization
> -------------
> 
> I seem to be in agreement with Jorn and others that visualization is a
> gimmick that should only be added to the interface if it can be done in a
> non-obtrusive way.
> 
> What I wondered now is whether it would perhaps make sense to make
> possible visualizations an overlay to the main (i.e. playlist) window that
> shows up after a certain time of inactivity and dissapears again as soon
> as the user clicks onto the visualization.

Hrm.. not at all sure this is a good idea.. because.. imagine Muine
running somewhere in the back of your window stack, some bits visible.
Lots of inactivity there and while working at some point there is lots
of visualization going on there. How distracting!

Actually I think visualization is something that belongs in a separate
app.. I believe that in ALSA other apps can see what is written sound
device, and use that to do fancy visualizations. Then we don't have the
clutter Muine, and for example someone could code up an xscreenhaver
hack that monitors alsa, and uses that for creating fancy effects..
working out of the box with any music player out there.

> 
> Doing it that way would of course be pretty non-standard behaviour;
> however, I see visualizations as a very special feature anyway and doing
> it the way I suggest would have the advantage of not complicating the UI
> at all except for a single entry or sub-menu (vis selection) in the View
> menu.  Disabling this feature by default should further prevent confusion.
> 
> [ Now that I think about it I wonder whether Apple was doing something
> similar with iTunes?  Or maybe it was just overlaying the playlist instead
> of the whole window?  (Hmmm, this might also be a consideration as it
> would allow track-skipping etc. while the visualization is active...) ]
> 
> Album Information
> -----------------
> 
> Okay, before I now start voicing my opinion on what additional information
> I'd like to see in the album selection, let me first state that I *do*
> realise that a) different people will have vastly different opinions on
> what information is most important to display and b) you can only display
> so much information before the amount of displayed information makes the
> list difficult to scan.
> 
> Therefore, please consider my opinion to be only one out of a large crowd
> of different people!  The fact that only a small amount of information is
> displayed is far more important to me than that my personal favourites are
> among them!
> 
> Ok, so what are my personal favourites you ask?  Here they are:
> 
> Year of Release - Especially for artists that have released lots of albums
>                   over a long period of time (e.g. Bob Dylan) the year
>                   often gives a pretty good idea of the kind of music it
>                   contains.
> 
> Type of Release - While this information is kind of redundant for official
>                   album releases (and therefore should perhaps just be
>                   omitted in these cases), in the situation where you have
>                   e.g. several bootlegs of a certain artist in your
>                   collection I think it would be pretty helpful if this
>                   information would be displayed alongside the release.
> 
> As for the second item I don't know whether the common file formats
> provide standard fields for the required information; however, musicbrainz
> at least categorises releases accordingly[3] and in the case where a
> release is not of type (Album, Official) I think it provides pretty useful
> information.
> 
> I think it would be nice if other people would post their own favourites
> here if they have different opinions (Genre is a likely candidate even
> though I don't consider it to be very useful for my personal use).
> Anyway, myself I'll try not to further comment on this topic as I've
> already stated my opinion and in the end it's up to Jorn to decide upon
> what information should be displayed anyway.  (Again, I'll happily accept
> any decision even if it excludes my own favourites.)

I think... adding much more info to the albums treeview would be very
cluttered. Other information like type of release, year, etc are not
useful to everyone I think.. 
What I am working on right now is designing a song/album info dialog. I
could add a button to the "Add album" window opening up this dialog for
the selected album, showing all available information.

> 
> Playing Track Indication
> ------------------------
> 
> IIRC this was something mentioned by Eugenia: that it was confusing that
> played songs were selected in the list but that the selection could be
> moved and therefor highlighting a track different from the currently
> playing one (correct me if I'm wrong... as I said it's not possible for me
> right now to check the current behaviour).  Eugenia (IIRC again) suggested
> to use a different highlight color for selection and playing indication
> and Jorn (yet another IIRC) said that he'd prefer to have the selection be
> reset to the playing song in certain situations.
> 
> What I wondered was the following: "why not just use the already existing
> speaker symbol as a playing indication and use the selection indication
> for what it's meant to be used, i.e. to indicate what tracks are
> selected."
> 
> The point is here that, if the users wouldn't be given the idea that the
> selection indicates what song is playing, he would just be looking out for
> the speaker symbol.  This approach seems to be the most straigt-forward
> one and as long as the speaker is not an insufficient indication of the
> playing song (which I wouldn't expect it to be) I don't see why there
> would be any problems with it.

This is exactly how it worked and works. :) But, the confusing thing is,
a row with a different background colour attracts much more attention
than a tiny speaker icon. How I solved this is by selecting the playing
row whenever the window is de-iconified, its visibility changed, 'next
song' or a button like that clicked. So, this way, the playing song is
selected most of the time. But you can still use the selection to
select, it all works very naturally ..

> 
> The End (for now)
> -----------------
> 
> Ok, that's it for now.
> 
> I actually have some additional thoughts regarding the previous discussion
> of groups, etc.  However, I haven't fully thought them through yet and
> therefore will likely post them at some later time (unless I come to the
> conclusion that they are completely bogus, in which case I'll keep them
> for myself :-p).

Cool. :D

> 
> There are also some more complex (and controversial) thoughts regarding
> the handling of the music collection; but for those I'm missing the time
> right now, so I'll also post them later.

Bring them on ;)


> [1] The fact alone that it seems pretty easy to get a clear idea of how
>     Muine works just by looking at a single screenshot[2] suggests that
>     you are quite a step ahead in terms of simplicity of both iTunes and
>     Rhythmbox, which is great!

Hehe :D


Thanks !

Jorn

> 
> [2] http://people.nl.linux.org/~jorn/Muine/muine.png
> 
> [3] http://musicbrainz.org/popup/attrguide.html
> 
> Regards,
> Lars
> _______________________________________________
> muine-list mailing list
> muine-list gnome org
> http://lists.gnome.org/mailman/listinfo/muine-list