[Rhythmbox-devel] Reconceptualizing the UI

[Thomas Lunde <tlunde mac com>]

In the Jukebox thread, we've been trying to discuss UI changes to Rb.  I
was replying to Dan's email when I realized that I'd been making a huge
mistake -- the same mistake that the current Rb docs make.  And the
reason why Radio doesn't seem to fit within the current UI:

We've been using the word "Library" to mean two different things.  


1.  The set of all tracks stored on the local system (or possibly from
locally mounted servers) that Rb knows about.

2.  A specific area of the UI -- the one that is on the lower right hand
corner, and which usually has colums of Track, Title, Time, Rating, etc.

Number 1 definitely makes sense as "the Library".  Each track is an
entry in the Rb database, and certain information about that track is
available because of that database, whether the song is playing, or not.

Number 2 has been known as "the Library" (I speculate) because of how
Rb's database has been implemented.  It was originally the display area
for the entire library.  Then the browser was implemented; then the
search box was implemented (or perhaps I have the order wrong, but the
point is the same).  Once the Browser and the Search box were made
availiable, the "Visible Library" was cut down to be the subset of the
(Full) Library based on the selections in the Browser and/or the
contents of the Search Box.  

The display area described by Number 2 should _not_ be called the
Library.  To someone who doesn't know anything about iTunes or Rb, or
how they are implemented, calling this area the Library is confusing. 
When the tracks go away, can I get them back?  Are they being deleted? 
Should I go to the trash can to recover them when they disappear from
this "Library"?  

Perhaps we can call this area the "Track Information" area.  That's a
clunky name -- please come up with a better one!


After thinking through the implications of that, here's what (I think)
makese sense:


Right now, the UI has four main areas according to the documentation: 
the Side Pane (for sources), the Player area (for controls), the Browser
area, and the Track Information area (called the Library in the docs,
even though the accompanying screenshot shows an item labled "Library"
in the Side Pane).

Colin wants to get rid of the Side Pane.  Ok. 

We need some kind of a UI with which to interact with playlists, and a
place to show (and edit) their contents.

Let me suggest that the proper UI for Rb also has four areas.  The
Player (as now, although I might suggest a renaming to the Control
area), the Browser (as now), the Track Information area (as now), and
the Play Queue area.

Like the Track Information area, the Play Queue area would have columns
displaying information such as Song Name, Time, Artist, Album, etc.  I
think that one might want _different_ columns in the two areas,
however.  In the TI, I might want to know the bit rate, the format, the
Comments about a particular track; but in the PQ, I might want to see
Genre, Beats Per Minute, and other things relevant to the flow of music
that I've been and will be hearing.


The Play Queue area would have a pop-up menu at the top of that area. 
The pop-up menu would have the following contents:

---------------
Music Library
---------------
Jukebox Mode
---------------
Playlist 1
Playlist 2
Best of the 60s
Pop Favs
Bach's Best
Etc.
---------------
New Playlist...
---------------

The default selection would be the entire Music Library.  Jukebox would
have a sub-menu with the items

---------------
Music Library 
---------------
Playlist 1
Playlist 2
Best of the 60s
Pop Favs
Bach's Best
Etc.
---------------

(i.e. everything except New Playlist (and Jukebox mode so we don't
recurse forever!))


The Play Queue area would define what (sub)set of tracks the user may
now listen to.  The Browser and the Track Information area would be used
both to select subsets of that subset and to edit the Jukebox or
Playlist selected.  

The contents of the colums of the Play Queue would display what the
upcoming tracks are, and possibly a memorializing of what tracks were
recently played.  (In iTunes, there are  two popups to indicate the
display of 0/5/10/15/20/25/50/75/100 "recently played" songs and
"upcoming" songs.  I think that produces too busy of a UI.  Better that
the user can direcly select the size of the window devoted to this
function and the program automatically shows whatever it can of the past
and the future -- probably in accordance with a ratio which the user can
set in the (rarely accessed) Preferences window.)

The track listing of the Play Queue could be made any size -- even
zero.  As long as something is selected in the pop-up menu, Rb will know
from what to play.  

The Browser will allow the selecting of subsets of the set chosen in the
Play Queue, as it does now for the entire music library.  Thus, I can
leave the PQ set to "Music Library" and quickly select a particular
album by a particular artist.  When the PQ's pop-up is set to a
particular Playlist, then the Browser is limited to the tracks in that
Playlist.  

When the PQ's pop-up is set to Jukebox, it would default to a
randomizing mode across the entire music library.  If the user does more
delicate mousing, it is possible to use the jukebox mode across any
particular playlist.  (Since it should be able to build Playlists which
contain the attributes "Is In Playlist X" and "Is Not In Playlist Y",
then any arbitrary subset of the entire Music Library can be randomized
across in jukebox mode.)

The New Playlist... selection would bring up a dialog box where the user
could enter a name for that playlist and choose to have the playlist be
automatically created by criteria, or manually edited.  

As it does now, the Track Information area is a scrollable informational
area of attributes of certain tracks.  Also, as now, the set of tracks
which the user may scroll through is bounded by the intersection of the
subsets chosen in the Browser and by any entry in the Search box.  (The
Browser being newly limited to what is set in the Play Queue pop-up
menu.)

If the entire Music Library is selected in the Play Queue's pop-up menu,
the Browser can see every track.  If an Automatic Playlist is selected,
the Browser can only see the tracks bounded by the criteria of that
playlist.  (Any Automatic Playlist needs a submenu item of -- Edit
Criteria -- in the PQ's pop-up.)  If a (manually edited) Normal Playlist
is selected, the contents of the entire Music Library are available for
the Browser (and the Search box and the Track Information area).  Edits
to Normal playlists are done by double clicking on track names to add
tracks, or by drag and drop onto the track rows shown in the Play Queue.
The track listing of the PQ will be the scrollable, to disclose the
contents of the entire Playlist.  It will have a section (at the top, I
suppose,) where tracks that were recently played are shown.  This
listing should normally slowly scroll as tracks are played.  A
user-definable ratio of this area (from the Preferences pane) should
show past played to upcoming tracks.  (Although if the user manually
scrolls the list into the future or past, it should stay there for ....
60 seconds? ... before returning to the defined past/future split line.)

The track listing of the PQ should be editable for addition (by drag and
drop from the Browser and Track Information area) and deletion (by
selection and then a Del key or a right click Remove Track) and
re-ordering (by direct drag and drop within the list).

The user should be able to resize the Rb window.  If the PQ, the Browser
and the TI area are all visible, they would change size proportionally
(until some minimum size).  The user should be able to turn off (by menu
items?  or disclosure triangles?  or both?) the display of the each of
the PQ (except for the pop-up menu), the Browser and the TI.

Whew.  Thanks for reading so far down.  What do you think?

thomas