Re: User Interface proposals

On 01/22/2012 01:33 PM, Sean McNamara wrote:
> 1. Need to know size of library before I attempt to transfer songs
> to an mp3 player (or mobile device with limited space), so I can
> figure out if I need to recompress songs to a lower bitrate or remove
> songs entirely, etc 2. Number of songs is a useful metric for me as a
> DJ because it helps me communicate with other DJs how diverse my
> collection is. Sure I could write a shell script to gather the same
> info, but _why_ should I have to when this excellent functionality is
> already there?
Thanks for those! Did not think about them.

> On the other hand, if you remove the status bar but maintain the
> information that is displayed in it somewhere else in the Rhythmbox
> UI, that's fine with me. I guess I should clarify my viewpoint: I
> don't care that the information *is in the status bar*; I care that
> it is easily accessible *somewhere within Rhythmbox*. If you want to
> remove the status bar but maintain the information (in the same
> textual format it's in now) elsewhere, I'd almost agree with that
> without even looking at the new location where you're going to place
> it. I've come to rely on Rhythmbox for this information, and I'd
> really like to see a shift in GNOME, away from the philosophy of
> flat-out culling features for the sake of simplicity, and toward
> cleverly obscuring or hiding the least-used features so that power
> users accustomed to complexity (*raises hand*) can still use rich
> feature sets, while non-power-users won't be overwhelmed by the
> default behavior.
Took note of this and incorporated it (and more) into the wiki:
https://live.gnome.org/Rhythmbox/UserInterfaceReworkProposals#Disable_Statusbar_by_default

----

On 01/22/2012 05:03 PM, Sriram Ramkrishna wrote:
> Thank you for doing this.  It's a very nice detailed analysis and I
> appreciate it.
Thanks!

> A couple of things: 1)  It would be best to get Jonathan's take on
> the UI.  Without the maintainer involved it will be hard to get a lot
> of the changes.  I would prefer to see understand where RB is going
> to go from his perspective as is proper.  He may or may not have a
> roadmap on the UI.
I'd be glad to discuss this with Jonathan and collaborate to incorporate
his plans. Also, I'll hang out on #rhythmbox, feel free to ping me.

> 2) Secondly, UI design should go through #gnome-design on IRC if we
> want to make it into a proper GNOME 3 app that fits with the GNOME 3
> design.
I'm pinging #gnome-design about this proposal right now.

> Also check the http://live.gnome.org/Design/Apps/Music which has
> some designs already on a music player.
I'm not sure it's a good idea to include the "polish" changes I'm
proposing in the long-term roadmap of the Music app. Music looks
exciting as hell, but it's a looong way. I'd rather see the small
changes discussed here implemented in the current RB, one incremental
change at a time. This is why I separated my proposals in the wiki, so
that they can be filed as individual bugs, and worked on individually.

----

On 01/22/2012 07:29 PM, Michael Gratton wrote:
> 3. Determining the play length of an album/playlist. I am rather
> old-school in that I prefer to listen to whole albums or EPs, in
> their entirety. I never listen to individual tracks. Knowing how long
> a disc will play for can therefore be a useful aid in selecting what
> to listen to[1].
> Since a collection of music on a disc isn't a concrete concept in RB,
> it doesn't do things like display or allow one to sort on disc
> length. The status bar is currently the only way to determine that. I
> believe this also applies to play lists, and hence is important in
> constructing them.
> Of course, if RB would display album length elsewhere, say in the
> browser, I'd be happy for the status bar to go away.
OK, took note of this too in the wiki. Thanks.

----

On 01/23/2012 10:32 AM, Olaf Hering wrote:
> Convert an audio CD to FLAC format. There is now this rather
> uninformative progress bar instead of what was shown in 0.13.3.
> Showing whats really going on like '#4/#13 (42%)' would be really
> helpful.
Indeed, thanks for the use case. Regarding the functional regression
("RB 2.95 no longer reports detailed progression of extractions", I
encourage you to file a bug.)

----

So let's see what's the take of #gnome-design team, and I hope Jonathan 
will jump in when he has a moment.

Thanks everybody for the feedback!

Ronan