Context

• I've been using Banshee for a few years because Rhythmbox seemed unmaintained

• I absolutely loved the move to GTK 3.x, Rhythmbox is still a fantastic lean and fast general player

• I was disappointed to see the interface kept its flaws

• I'm doing a few proposals here to improve the default user experience. Just like Felix did in another list of ThingsThatAreWrong, it does not mean I'm working on them. I'm trying to implement a few ones, without any promise of result. Real patches very welcome.

• I sent these proposals to the rhythmbox-devel mailing list on 2012-01-22

• Once we got some feedback on the mailing list (especially: identify already-discussed/adressed items), I'll file the relevant bugs in Bugzilla and will link to them back here.

TL;DR, what would be the target?

After

Before

Assumptions

Still with me? Okay, let's go. I'm making a few assumptions that I hope to be in line with the GNOME approach:

• The user is called Bob.
• Bob is not stupid, he just wants a simple music experience without having to dig into messy configuration details, so that he can get his stuff done.
• Bob uses a resolution of 1024x768.
• Defaults should be good for Bob, because he won't change them.

Proposals

1. Compact UI elements

Problem: a typical Rhythmbox window contains lots of unused chrome. The following illustration is not mine (it was found on a discussion thread on OMGUbuntu), but illustrates well the problem (note: to this screenshot should be added the chrome of the menu, which is not shown because this user uses Ubuntu's global menu):

Proposal: compact UI elements and disable some by default. The improvements will be separated into a series of steps.

As-Is. This is the current UI:

1.1. Merge Toolbar and Timeline

Implemented on 2012-03-28

Rationale: these toolbars do not gain anything by being separated, and compacting them is largely OK in any modern resolution.

Proposal: merge Toolbar and Timeline

Result:

1.2. Disable Statusbar by default

Rationale: Bob doesn't care about the fact that his library is "14866 songs, 43 days, 15 hours and 23 minutes, 84.1 GB"

Proposal 1: let's disable the Statusbar by default but leave it as an option for savvy users who value this piece of information

Proposal 2: several commenters in the mailing-list point out use cases where the information provided by the status bar is critical, quoted below:

1. "Need to know size of library before I attempt to transfer songs to a mp3 player (or mobile device with limited space)" (Sean, 2012/01/22)

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" (Sean, 2012/01/22). Additional comment by Sean on 2012/01/22, I don't care that the information is in the status bar; I care that it is easily accessible somewhere within Rhythmbox.

3. "Determining the play length of an album/playlist. 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" (Michael, 2012/01/23)

4. Showing the progress of an audiocd->file extraction (Olaf, 2012/01/23)

Given the mixed contextual/permanent nature of the use cases, Proposal 2 could consist of two changes:

• For the contextual actions ("Number of songs", "Determining play length of an album/playlist", "Showing the progress of an audiocd->file extraction"), transient overlay yellow bottom status messages (a la Chrome / Firefox4.x / Nautilus3.x) look like a good idea.

• Remains "Need to know size of library". For him, and if contextual statuses are implemented, maybe disabling the statusbar by default makes sense. Of maybe we could display the size somewhere else, like below the "Music" entry in the sidebar?

Result of proposal 1:

1.3. Remove the Artist/Album headers of the Browser

Rationale: Bob doesn't need to be told that left pane lists the artists and right pane the albums: it is already mentioned by the bold first line saying "n artists (numberOfSongs)"

Proposal: let's hide the headers of the browser.

Result:

1.4. Transform the Menubar into a "global menu"

Rationale: the menus are too rarely used to be worth their chrome cost.

Proposal: move to a Chrome / Epiphany 3.3.4+ global menu. Needs definition of the contents of this menu, and reorganization. Clues can be taken from the way Epiphany did it

Result:

2. Move cover art into timeline

Implemented on 2012-03-28

Rationale 1: Album art, just like title, artist and album, is relative to the currently-playing song. As such, it should be part of the timeline.

Rationale 2: Bob sometimes just uses the library view, so he disables the sidebar. However, when doing this he loses the cover art

Rationale 3: For users using the Play Queue, the cover art takes up valuable space for the Play Queue.

Proposal 1: move cover art to the timeline. Drawback: considering the default sidebar size, it would mean the cover art is ~1/2 smaller in the interface. I think it still looks great though. Implementing a big full-size preview of the covert art when hovering/clicking the timeline preview might be a good idea (that's what Banshee does, by the way).

Proposal 2: duplicate cover art to the timeline. Drawback: duplicating UI elements looks awkward.

Result of proposal 1:

3. Use no stars or smaller stars

Rationale: the smaller stars displayed when no rating is set add unnecessary visual clutter.

Proposal: do not display these small stars

Drawback: the rating feature becomes a bit less discoverable. Showing dimmed start when hovering the ratings, a la Banshee, would help to address this issue.

Result:

4. Avoid duplication of artist/album/title between window decoration and seekbar

Rationale: artist/album/title is duplicated: it is both in the window decoration, and in the seekbar. Suggested by Sean in the mailing list.

Proposal 1: Always display "Rhythmbox" as window title.

• Pros: TODO
• Cons: static, people using GNOME 2.x or LXDE or any window manager displaying windows titles in the window list will lose this "quick preview" feature

Proposal 2: remove artist/album/title from the seekbar

• Pros: TODO
• Cons: we lose the nice visual bold/italic formatting currently used in the seekbar. Also, GNOME will at some point introduce hiding of the title bar for full-screened apps, so it doesn't sound like as good idea to rely on it to provide critical information to the user.

Result:

TODO

5. Comments

• why not making this changes step toward the mockups for Music (http://live.gnome.org/Design/Apps/Music) , like epiphany did toward web (http://live.gnome.org/Design/Apps/Web) ? Many of your changes are close to Music mockups, such as the toolbar changes.