I think it's good to open this bug so all the information floating around about this can be consolidated and people can start knowing what's going on.

I've heard Aaron say a couple times that this will happen in the 0.12.x series. I also know that there has been a lot of thoughts and ideas tossed around about how it should function. It will certainly not mirror the browser features of any other program such as iTunes or RhythmBox. The banshee leadership seems pretty set on that. 

I believe the concept is to implement it as a plugin, but that very well may not be settled. 

Some discussion on this surrounding a mockup by Lukas can be found on the mailing list: http://mail.gnome.org/archives/banshee-list/2007-February/msg00005.html

Yes - there will be a browser in the next series, it's something we're very well aware of. It will also be in core, not a plugin.

Regarding the mockups, I'm particularly partial to this style:

http://picasaweb.google.com/lspierings/Banshee/photo#5028510379276591458

Mockup looks good. I definitely need something like this. It would stop me adding playlist just for particular albums and therefore make more space in the library.

However, not sure how it would work for users with lower resolutions (800x600, 1024x768) as it may obscure the main track list.

As an active user of DAAP I wonder how it would integrate with that. I make playlists for each album and with the patch from 

  Bug 407672 – Banshee doesn't share its own playlists via DAAP

I share these album playlists over my local net. Would the Browser show up as another type of Banshee.Base.Source? And if so should it be available to share albums as playlists over DAAP?

I would not imagine it would show up as another source, I would picture this as something similar to the mini-mode, just another way of viewing, not a source per say. Since it would just be a view, you could use it on any source, that is, your main lib, playlists, DAPs, and DAAP shares etc. 

I'm hoping I can get around to GIMP'ing up one or two mock-ups as well.

I myself find the other mockup - the one where the covers is the part of the song list - more usable, it looks much more integrated. Another pane and another scrollbar is just too much for me - although scrolling through a big db would be faster with the first one...

If the option existed to collapse the browser to the left, I'd be okay with that, but it is going to be cluttering up the screen when I don't want it and taking up room that could be used to see the columns of data on the songs.

Alternately, maybe a button could be presented down by the metadata editor button that put it up and down.

(In reply to comment #3)

The browser is simply an organized filter on top of the current view. It's not a source - it's a feature on top of the view that may be applicable for any source. If you see tracks, the browser will work to filter them for you (by artist/album).

I like the mockup I linked very much because it is a good way to show cover art and the artist/track info. Plus there's room to pack more metadata. I do not anticipate it being any less useful on lower screen resolutions because you'd effectively be removing both the Artist and Album columns from the view when the browser is open. You only "need" to view the Track Number, Title, and Duration columns when the browser is open.

(In reply to comment #5)

Michał, while I like the mockup you mentioned, it is not a browser. It simply shows cover art for the tracks in a grouped manner. That alone does not make it any more usable than what we have now - just a big list of tracks.

One concern I do have is in relation to having any "browser" in a pane of its own akin to the mockup from above.

I like to keep Banshee from getting too long horizontally, and adding this would either cramp the columns themselves or result in a very long window.

Whatever browser is added should be split at least in a manner similar to Rhythmbox (that is to say, with the browser interface above the listed tracks) for usability purposes.

The linked mockup does have a rather unpleasant problem: It becomes impossible to tell to which album/artist a song in the right pane belongs. That's a usability nightmare.

I couldn't agree more Ruben. I'll look into making a mockup of my idea some time tonight and posting it.

Will - read my comments above. The mockup browser on the left eats the space that the artist and album columns used to consume. Horizontal sizing should not even be an issue here - you're trading two of the three typical wide columns (Artist, Album, Track) for the width of the browser. 

What I don't like from the mockup is how the filter is depicted. The mockup shows that when you click an album, the view _scrolls_ to its position, which I do not like (agree with Ruben). I would implement it as a filter where only the tracks belonging to the selected album are in the view.

"Will - read my comments above. The mockup browser on the left eats the space
that the artist and album columns used to consume. Horizontal sizing should not
even be an issue here - you're trading two of the three typical wide columns
(Artist, Album, Track) for the width of the browser."

I think this is a flaw in the design. This would make Banshee essentially inoperable without the browser view - which should not be the case.

While you dislike the Browser trend as set by iTunes, I think it safe to argue that while "Artist | Album | Genre" might not be the best implementation, that leaving the columns as they are _is_ the best way to implement this.

This can be seen as what would occur if one were to select two or more albums in the mock up by different artists: you have a lot of songs visible, and you don't know who the songs belong to unless you've got all that stored in the back of your head.

I think removing the Artist (at the very least) and Album columns for the sake of a Browser is another one of those "usability nightmare"s everyone is so fond of talking about.

"What I don't like from the mockup is how the filter is depicted. The mockup
shows that when you click an album, the view _scrolls_ to its position, which I
do not like (agree with Ruben). I would implement it as a filter where only the
tracks belonging to the selected album are in the view."

I, too, agree.

(In reply to comment #13)
> I think this is a flaw in the design. This would make Banshee essentially
> inoperable without the browser view - which should not be the case.

This would not be the case. If the browser is enabled, artist and album columns get _hidden_. If you disable the browser, the columns show back up. They would never be removed.

(In reply to comment #14)
> (In reply to comment #13)
> > I think this is a flaw in the design. This would make Banshee essentially
> > inoperable without the browser view - which should not be the case.
> 
> This would not be the case. If the browser is enabled, artist and album columns
> get _hidden_. If you disable the browser, the columns show back up. They would
> never be removed.
> 

Even if that is the case, it does nothing in regards to addressing the question of selecting multiple albums by multiple artists.

This would, in effect, force one to close the browser while having multiple albums by multiple artists selected in order to identify tracks at a glance.

I sent a mail to the list regarding this some time ago but it seems as if it didn't ever make it :(

Anyway - I also think that removing (or "hiding", which seems to be the same thing to me) columns if the browser is shown is not a good idea, it's basicly a morphing interface and that's not a good idea generally.

I did a mockup showing a Rhythmbox-like browser which also shows coverart:

http://picasaweb.google.com/michael.monreal/Banshee/photo#5028858339454065922

Now how is this better?
-> No need to change (remove/hide) columns 
-> No change in horizontal window size
-> Ability to filter for artists and not only albums (common use case I guess)
-> Nice way to handle songs that are not part of any known album (look at the "Various other albums")
-> Extending this idea, there could also be a "virtual album" for the favorite songs of an artist or something like that, making use of smart playlist technology but integrating it better into the workflow: "I want to listen to... Stones. What album... hmm, lets play the favorite songs"
-> Nice way to hide the browser (note the \/ sign before Music library: the whole browser area is an expander widget)

If you still insist to implement the first mockup, thing about how to handle "loose" songs and show the artist/album names besides the cover art, because otherwise too much information is lost. Also think how to implement the hiding feature... in my mockup this is much cleaner.

(In reply to comment #15)
> Even if that is the case, it does nothing in regards to addressing the question
> of selecting multiple albums by multiple artists.
> 
> This would, in effect, force one to close the browser while having multiple
> albums by multiple artists selected in order to identify tracks at a glance.
> 

True. I'm also not proposing that what you see in the mockup is exactly what
will be implemented. Rest assured, the issues presented here will be overcome.
I'm simply saying that I like the way the UI looks in the mockup.

First, the browser should be able to handle multiple selected rows. Or maybe a
double click and/or drag and drop to add multiple artists/albums to the filter.

As for showing albums under an artist, what I would like is to actually have a
split pane browser that looks like the mockup, except that say, 75% of the
space at the top will be artists and the remaining 25% of the space at the
bottom will be albums by that artist.

Double click/drag an artist and the view filters to all albums by that artist.
Single click/focus/select an artist and the album view in the browser shows the
albums by that artist - double click/drag any albums in that bottom view and
only those albums will be shown.

Essentially - I'm not advocating that the behavior or *exact* UI design of the
mockup I like is correct or set in stone. I simply like the way it's organized
at a very high level. You can't work out exact usability details, especially
regarding functionality and action, from a mockup.

(In reply to comment #16)

> Anyway - I also think that removing (or "hiding", which seems to be the same
> thing to me) columns if the browser is shown is not a good idea, it's basicly a
> morphing interface and that's not a good idea generally.

I don't think it will be a problem. How often will you remove the browser view? I will bring up these issues with our usability and design teams at Novell. This certainly isn't something to be taken lightly and without much thought as it's a pretty huge UI change, regardless of the route taken.

> I did a mockup showing a Rhythmbox-like browser which also shows coverart:
> http://picasaweb.google.com/michael.monreal/Banshee/photo#5028858339454065922

I really, really am not a fan of the browser on the top simply because vertical space is more valuable than horizontal space. Browser on top means I have less tracks in view.

I've made a new mockup of what I think that Aaron means in Comment #17. Basically it is the horizontal iTunes/RB browser but then vertically. You can find it here:

http://picasaweb.google.com/lspierings/Banshee/photo#5034931709108071314

I've also made another mockup with a treeview:

http://picasaweb.google.com/lspierings/Banshee/photo#5034931709108071330

Created attachment 83227 [details]
Mockup

So, here's the deal: I start to like the horizontal layout a lot, and I like the ability to pre-select Artists before Albums. Splitting this vertically doesn't look very good though... and it also limits the space where album art can be displayed.


So, starting from one of Lukas' mockups I did this: 
- Independant scrollable columns for both Artist and Albums
- Selection in Artists and/or Albums affects the display in the following Columns
- It's possible to select more than one Artist and/or Album
- The column Artists/Albums headers have handy [All] buttons to quickly select all Artists/Albums
- The Album column shows coverart when it is available
- The Artist column is just as big as it always was (+a few pixels of scollbar)
- The Album column can be even smaller than before, because we now have of to 4 lines to display the Album title besides the cover art (+scrollbar)
- The Albums columns shows three "virtual albums": 
  -> Tracks not associated to an album (critical I think)
  -> Favourite Tracks (perhaps all tracks by the selected Artist(s) with a rating bigger than 3?)
  -> Last.fm recommendations for the selected artist (only an Idea)


Personally I am very happy with this, as it seems to be clean and non-hacky, supports the natural workflow, builds on the layout we currently have, doesn't waste any more space (or only very minimally), is *so* much more powerful and as you see, the albums column is very extendable.

What do you think?

I think I like Michael's latest mockup best, so far.

One question though, how will I know which song belong to which album or artist if I have multiple albums or artists selected and does this really matter anyway?

(In reply to comment #21)
> I think I like Michael's latest mockup best, so far.
> 
> One question though, how will I know which song belong to which album or artist
> if I have multiple albums or artists selected and does this really matter
> anyway?
> 

You'd have to close the browser view according to current specifications.

I believe this is a valid concern as I fielded the same query above.

I like first Lukas's mockup (the one using trees) best - the last one shown would be completely unusable on a 4/3 screen - it's just too much...

As far as multi-album selection - I think the best way would be to colour the selected albums in the "middle" pane swapping light/darker (just as the song list is now coloured) but in different colour shades, so that the list would have four colours and the songs would switch (light-light / light-dark) / (dark-light / dark-dark) - the songs in brackets belong to one album...

I'll try and do a mockup later to show what I mean. Also there could be a "forward" - "back" so that we could remember some of the selections we've recently made, 'cause I hate it when I forget to keep my Ctrl pressed to select one more line - and when I'd select some 20 albums and then have my list screwed because of the Ctrl I'd be a bit nervous about it ;]

I like the idea of the virtual playlists very much :) That's something that would be great :)

There's also this idea I've had of a Now-Playing playlist that would keep the currently played song list until we press "Play" on some other compilation - this way we would lose the problem of switching playlists. But that's another topic, I'll try and write some more later.

@ Josiah and Will:
I thought about this, too. But in the end it perhaps doesn't matter *that* much. If you really want a specific album, you can just select a single album in the album column. If you select multiple albums, you see what album the current song is from (playing info) or, worst case, you open the song preferences.

This problem does not occur in a Rhythmbox/iTunes browser... but there you have duplicated display of album and artist (once in the browser, once in the actual list).

The "spec" could also be changed to work more like the SLAB application selector or the new Control Center shell... meaning you select an artist, all songs of that artist are displayed on the right and you can select specific albums to "highlight" albums on the right. But I like the first approach better.


@ Michał
>> the last one shown would be completely unusable on a 4/3 screen 
>> it's just too much...
Not true, did you notice that it has exactly the same dimensions as the other mockups? That is because it is heavily based on those :D
I actually had the same concern (se my comment #16), but in the end you don't need any more space, because the Artist column doesn't take any more space and the space you need for the album art is not very much compared to what you save when writing the album name in more than one lines. No widescreens needed, works find on normal screens.

(In reply to comment #24)
> @ Josiah and Will:
> I thought about this, too. But in the end it perhaps doesn't matter *that*
> much. If you really want a specific album, you can just select a single album
> in the album column. If you select multiple albums, you see what album the
> current song is from (playing info) or, worst case, you open the song
> preferences.

I think that's a poor approach to this. Even Amarok, which has a very similar approach to the current mockups (it really does) continues to display that information.

The difference being, it can afford to as its only using 1 sidebar instead of 2 or 3.

This is valuable information and it should really be displayed even when the browser is open.

> This problem does not occur in a Rhythmbox/iTunes browser... but there you have
> duplicated display of album and artist (once in the browser, once in the actual
> list).

Is having the crucial information for any given song in the viewing window really a flaw or matter of redundancy we should be concerned about?

When listening to multiple albums, users shouldn't have to open an extra window to see that the song's by X artist on Y album.

I like Lukas' first mockup the best (from comment #19):

It shows artist and albums as two separate lists, which is what I was trying to convey as a derivative from the original mockup I liked. What I see being functional for this is the ability to select multiple artists and have the union of their albums show up in the album list; because I think this is necessary, I don't think the second mockup in comment #19 is functional, but I do like it visually. Lukas: you're right on the mark with what I was trying to explain.

Michael: your mockup is visually nice, but I think it does in fact introduce a lot of unused space because of the splitting of artist/album horizontally. Most artists don't have more than two or three albums, and a lot of artists I have only have a single album, so I do not think this design is very functional - or at least it's not a good use of space. I think my 75/25 vertical split idea is probably okay. There can of course be a separator between the two panes.

Also, the problem with splitting horizontally is that some artists have really long names. This works better in the album view of yours, but not so for artists. This is trivial compared to the wasted space with the album view though.

About my first mockup of Comment #19:

Maybe the album view should have a variable height. If the artist that is selected only has one album, the height of the album window should be one album. And the maximum height should be three albums. If more, the list should become scrollable.

Ooh no having a gui jumping up and down is not something I'd like to see... Variable - yes, but only through moving the middle bar - as always.

Lukas, Michał: yeah, it will be variable, but only by using the splitter. I think a _default_ height of 3 albums is a good choice though. 

I was thinking more about this last night, and there's an issue. My solution is that I need to make a concession about the browser.

I am very averse to the browser above the track view because I greatly value vertical space, much more so than horizontal space, and the browser on top eats away at the number of tracks that can be displayed.

However, the issue is thus:

The browser must allow multiple artists and albums to be selected, which means that removing the artist/album columns is not going to work. There will be no way to know which tracks go with which artist/album. This only works if you can only select a single artist and album in the browser, which would be quite a limitation.

My solution is something like the vertical view in Evolution 2.8. You can opt to either display the browser above the track list or to the left. If no manual choice has been made, Banshee will default to the left if the display is 16:9 or greater than 1280x (these are arbitrary for argument sake, we can come up with the best choice as an implementation detail), otherwise to the top. 

This will allow the browser to be effective on all screen resolutions, but most optimal in my opinion on larger resolutions that can accommodate the extra width of the browser without sacrificing columns in the track view.

Any ideas? How's that sound?

As an aside, I've started working on some of the backend code necessary to make the browser work without a dependency on the track view widget, so performance will be good. I'll start implementing a rough working mockup based on this backend code shortly so we can put the good ideas on this thread to the test.

Created attachment 83316 [details]
Another mockup - album diversion

What about something like this - diversing albums by adding a shade to the row's background - Of course scrolling one of the song-list, album-list panes would need to scroll accordingly to the other one.

I think this would be a good compromise.

Either way, I think the possibility to move the browser left / up is great - though I can't think having it in the upper part would work at all when using Recommendations and/or Wikipedia, the way they're used now.

Can't wait ;)

Michal, what if all artists and all albums are selected. I assume there is an "All Artists" item at the top of the artists list, and there ought to be an "All Albums" atop the album pane (when there is more than one album). "The colors, Duke, the colors!"

As a further solution to the Artist/Album column problem Aaron raises, consider: The Album column displays only when there are multiple albums selected, and same with the Artist column. This could be optional in case the user always wants those columns or doesn't like the interface changing on them. I would find this the ideal solution, so long as the columns would resize themselves when appearing and disappearing. I wouldn't want the presence of the Album column to push the Rating column off-window. There would be one width which would be equally divided into one, two, or three columns, depending.

Another note on automatic column resizing: if the contents of one column exceeds the width alloted to it (1/2 or 1/3 some total width as described above), then the other column(s) could sacrifice what unused width they have to the truncated column.

> Michal, what if all artists and all albums are selected. I assume there is an
> "All Artists" item at the top of the artists list, and there ought to be an
> "All Albums" atop the album pane (when there is more than one album). "The
> colors, Duke, the colors!"

I only meant for it to use 2 colors... I know my mockup wasn't so good, but I hoped it would be somehow explanatory...

The colors would swap: light for first album on the list, dark on the next one, light on the next and so on...

I wouldn't like the album/artist columns jump back and forth...

We could save one column by doing this:

http://picasaweb.google.com/lspierings/Banshee/photo#5035545348938268546

This would make the horizontal view also usable for none wide screens.

P.S. This is made on a 1024x768 resolution with respecting the original fontsizes.

Again - IMHO this way wastes too much space. And 3 album-arts? That's too much...

4 album-arts! I agree, that's too much album art. I keep the left "big" album art display off at all times, but some people like it. 

I do not particularly like the album art directly in the track view do denote grouping. It's also going to be a technical nightmare to implement that with the GtkTreeView.

In all, it's just too much album art. Two is enough I think (header and album browser). Three is over-kill, but the big view under the source view is optional.

Also, for future mockups, please attach them directly to the bug to ensure history is preserved. I meant to say that earlier in this thread. If anyone wants to, it'd be nice to have the linked mockups attached with links back to the original comments.

Scott: Also, I agree with Michał - having the columns conditionally hide/show is not good for usability. But yes, I would certainly have the first option in each browser (artist/album) be "All", and those options would be selected by default. Thus behavior would be the same as it is right now until you make a choice in either of the browsers to filter your selection.

Additionally, I'm thinking that we need to extend the search (and really rename it in the UI to filter) to implement the same behavior that can be expressed by the browser UI. In essence, the browser will just be a front end to the search/filter box (but not necessarily enter the filter query visually into the search/filter box).

Maybe a query like:

-artist:"Artist A","Artist B" -album:"Album A","Album B"

Thinking about the search/filter UI and how the browser is meant to be a "front end" to this, I like to point to F-Spot. F-Spot also has a user-visible query bar and for "power uses" it has a text-based query bar. Perhaps when the browser is implemented we can also remove the search entry (and the whole area where it is in) and only show it as needed (see f-spot, evince, tomboy, firefox...)?

I'd like to keep the search box in place. I'm very fond of it and use it constantly.

(In reply to comment #40)
> I'd like to keep the search box in place. I'm very fond of it and use it
> constantly.
> 

I agree with this. The Filter Tool could also complement the browser (eg searching for X song by Y artist that has Z different versions).

(In reply to comment #35)
> We could save one column by doing this:
> 
> http://picasaweb.google.com/lspierings/Banshee/photo#5035545348938268546
> 
> This would make the horizontal view also usable for none wide screens.
> 
> P.S. This is made on a 1024x768 resolution with respecting the original
> fontsizes.
> 

This would make using the browser and then sorting the selected media by anything other than album entirely impossible (or insanely un-wieldly, whichever you prefer).

Yeah, the search is one of my favorite banshee features!

I really think it should just come down to:

a) Artist+Album browser on either the left (automatically/default, provided there's enough screen real estate or user has selected the mode manually) or above the track view (like iTunes, but the album view gets cover art). The functionality here is the same: select multiple artists and or albums to provide a _primary_ filter on the track view

b) No columns will change from how the currently are implemented. Nothing gets hidden/removed depending on the browser view mode

c) Browser is entirely optional (can be closed, but will be on by default in one of the two modes described in (a))

d) Existing search box will not go away

e) Filtering in the existing search with a browser filter applied can further filter the view, just like it does now

I think that's the bottom line. Ideas?

(In reply to comment #44)
> I really think it should just come down to:
> 
> a) Artist+Album browser on either the left (automatically/default, provided
> there's enough screen real estate or user has selected the mode manually) or
> above the track view (like iTunes, but the album view gets cover art). The
> functionality here is the same: select multiple artists and or albums to
> provide a _primary_ filter on the track view
> 
> b) No columns will change from how the currently are implemented. Nothing gets
> hidden/removed depending on the browser view mode
> 
> c) Browser is entirely optional (can be closed, but will be on by default in
> one of the two modes described in (a))
> 
> d) Existing search box will not go away
> 
> e) Filtering in the existing search with a browser filter applied can further
> filter the view, just like it does now
> 
> I think that's the bottom line. Ideas?
> 

That sounds pretty much perfect. =)

That's exactly what I think would work well.

Created attachment 83334 [details]
Albumart browser to browse by a single letter.

Created attachment 83335 [details]
Albumart browser split view

Created attachment 83336 [details]
Albumart browser 75% for artist, 25% for album

Created attachment 83337 [details]
Albumart browser treeview

Created attachment 83338 [details]
Albumart browser with too much albumart

(In reply to comment #44)
> I really think it should just come down to:
> 
> a) Artist+Album browser on either the left (automatically/default, provided
> there's enough screen real estate or user has selected the mode manually) or
> above the track view (like iTunes, but the album view gets cover art). The
> functionality here is the same: select multiple artists and or albums to
> provide a _primary_ filter on the track view
> 
> b) No columns will change from how the currently are implemented. Nothing gets
> hidden/removed depending on the browser view mode
> 
> c) Browser is entirely optional (can be closed, but will be on by default in
> one of the two modes described in (a))
> 
> d) Existing search box will not go away
> 
> e) Filtering in the existing search with a browser filter applied can further
> filter the view, just like it does now
> 
> I think that's the bottom line. Ideas?
> 

Good summary, even better ideas, best musicplayer!

As you requested, I attached all the mockups I've made.

I think the above-described plan is a fine one but I'd like to suggest something quite different. First let me outline what I think are problems with the proposed browser.

* Size. The browser takes screen real estate from the track list. Hiding solves the problem to a degree, but then one must show and hide the browser each time one want to browse artists and albums. Also, when one hides the browser one looses its functional benefits (visual filtering).

* Scrolling. One must scroll this way and that all over the list. I was always annoyed in iTunes when I had some artists or another selected and wanted to view everyone again, I had to scroll to the top of the list and click "All." Suppose you have several artists selected in the browser and would like to de-select one. How are you to find it in the list?

* Selection. If you select an artist in the browser and then scroll away from that artist, you may not know what artist is selected. You can consult the Artist column, if it is visible, but suppose two, or three, or four artists are selected in the browser. Another potential problem: you are going about selecting multiple artists and as you reach for the scrollbar your mouse accidentally clicks the edge of the artist list. Your previously selected artists are deselected and you must Ctrl-click each one again.

* Only artists and albums. One cannot browse by genre or year or any other such thing. I admit it is a niche feature, but iTunes does have genre browsing. I see no way of squeezing another category into the proposed UI.

My idea is a radical departure from the normal browsing paradigm. It draws heavily upon the concept of "filtering" as it was briefly mentioned above and it bears a similarity to F-Stop's tag searching UI. It's rather difficult to put into words so I've made a quick flash animation ( http://lunchtimemama.googlepages.com/movie.html) and I'll attach pictures to the bug report later.

This should give you the general idea. There are filtering categories (Artist and Album) and the user can add any number of filters from any category. The animation shows filtering for one artist ("Me First and the Gimme Gimmies") and then one album ("Are a Drag"). A filter allows you to browse all items in that category (artist or alum) just as the proposed browser does and it also provides searching of just that category. Filters can be removed or changed by clicking on them. So, the user in the animation could click on the "Me First..." button and change the artist or remove the filter altogether. If they change the artist, the album filter (the "Are a Drag" button) would disappear, as it is no longer relevant. Or, rather than changing the "Me First..." filter, the user could add another artist filter by clicking the "Artist" button again. Gtk.Buttons are used in the mockup just to illustrate the functionality and a more salient UI which clearly groups the filters would be required. This idea addresses each of the above problems:

* Size. The filters take up no additional space in the UI. The list of items only appears just as you need it but you continue to have the functional benefits of a browser.

* Scrolling. The search box eliminates the need for scrolling hither and yon.

* Selection. You can tell at a glance what artists and albums are selected and you can easily change those selections without jeopardizing the other selected items (or filters, as I have taken to calling them).

* Only artists and albums. It would be trivial to add other filtering categories such as genre. Banshee could provide the user with a list of filtering categories to display in the Preferences. Artist and Album could be on be default.

I have some further ideas about how the general search box would fit in with this setup, but I'll hold off on that mockup to see if there's interest in this idea. What does everyone think?

OK, I've got another mockup. This is inspired by Aaron's comment on a search syntax to represent the browser's state (-artist "Artist A","Artist B" -album "Album A","Album B"). This is a pop-up browser which is just a graphical front-end for forming those search expressions. In this mockup, the browser actually changes the contents of the search box, but there could easily be another "filter" box so that the browser doesn't tie up the search box. Or some hybrid could be made between this and my previous idea. Here it is: http://lunchtimemama.googlepages.com/movie2.html

Pardon the triple post, but I'd like to further articulate my thinking behind my mockups, particularly the first. Forgive me if I'm repeating myself, but I find it helpful to break the matter down in the following way. A browser serves two purposes: browsing and filtering.

Browsing:
One wants to easily browse one's music, but one does not want to browse all the time. One can do either of two things with the traditional browser when one is not browsing: Hide it or suffer it. Hiding adds a click to the browsing process: *click* show browser *click* select artist *click* play song *click* hide browser (4 clicks). In my first proposal, one need only *click* show browser *click* select artist (the browser is automatically hidden) *click* play song (3 clicks). I'll cover filtering in a second but I will mention now that when the traditional browser is hidden, it is not longer filtering, whereas my proposal continues to do so even when the list of artists/albums is hidden. On the other hand, if one doesn't want to hide the browser, one can suffer it. Suffering the browser all the time means *click* select artist *click* play song* (2 clicks), but the cost is some significant amount of screen real estate. If you have the pixels to burn, suffering the browser is fine, but many people don't. Then there is the matter of finding a desired artist or album. With the traditional browser, one may either scroll the length of the list or detour to the search box in the upper right (*click* select search box *type* *click* on artist in the browser (2 clicks)). My proposal provides a search box for each list which is selected by default (*type* until the desired result is first and *press* Enter (0 clicks)). A downside to my proposal is that each category (artist, album, &c.) is a separate list. One cannot make a selection in the artist list and immediate observe a change in the album list. Some visual feedback, such as the number of matching albums, could be added.

Filtering:
Since the proposed browser allows selecting multiple artists and albums, it is a powerful tool for filtering one's library. There are, however, some issues. As I mentioned, when the browser is hidden, it can no longer filter. There is also the matter of knowing what is being filtered at any given time. The traditional browser provides no guaranteed immediate feedback to that effect: if all selected artists/albums in the list are not readily visible, one must infer from the contents of the track pane or scroll through the browser list. Adding or removing an artist/album from the active filters is also difficult in the traditional browser and necessarily involves much scrolling. Finally, the traditional browser is an error-prone filtering device which depends on the user's dexterous employment of the Ctrl key when selecting multiple items. My first proposal make unambiguously clear which filters are active and allows the user to easily manipulate them.

My first mockup puts and emphasis on filtering and my second focuses on browsing. Perhaps there is some union to be found. It's late and I ought to be shutting up. Whadayathink?!

(In reply to comment #52)
> I think the above-described plan is a fine one but I'd like to suggest
> something quite different. First let me outline what I think are problems with
> the proposed browser.
> 
> * Size. The browser takes screen real estate from the track list. Hiding solves
> the problem to a degree, but then one must show and hide the browser each time
> one want to browse artists and albums. Also, when one hides the browser one
> looses its functional benefits (visual filtering).
> 
> * Scrolling. One must scroll this way and that all over the list. I was always
> annoyed in iTunes when I had some artists or another selected and wanted to
> view everyone again, I had to scroll to the top of the list and click "All."
> Suppose you have several artists selected in the browser and would like to
> de-select one. How are you to find it in the list?
> 
> * Selection. If you select an artist in the browser and then scroll away from
> that artist, you may not know what artist is selected. You can consult the
> Artist column, if it is visible, but suppose two, or three, or four artists are
> selected in the browser. Another potential problem: you are going about
> selecting multiple artists and as you reach for the scrollbar your mouse
> accidentally clicks the edge of the artist list. Your previously selected
> artists are deselected and you must Ctrl-click each one again.
> 
> * Only artists and albums. One cannot browse by genre or year or any other such
> thing. I admit it is a niche feature, but iTunes does have genre browsing. I
> see no way of squeezing another category into the proposed UI.
> 
> My idea is a radical departure from the normal browsing paradigm. It draws
> heavily upon the concept of "filtering" as it was briefly mentioned above and
> it bears a similarity to F-Stop's tag searching UI. It's rather difficult to
> put into words so I've made a quick flash animation (
> http://lunchtimemama.googlepages.com/movie.html) and I'll attach pictures to
> the bug report later.
> 
> This should give you the general idea. There are filtering categories (Artist
> and Album) and the user can add any number of filters from any category. The
> animation shows filtering for one artist ("Me First and the Gimme Gimmies") and
> then one album ("Are a Drag"). A filter allows you to browse all items in that
> category (artist or alum) just as the proposed browser does and it also
> provides searching of just that category. Filters can be removed or changed by
> clicking on them. So, the user in the animation could click on the "Me
> First..." button and change the artist or remove the filter altogether. If they
> change the artist, the album filter (the "Are a Drag" button) would disappear,
> as it is no longer relevant. Or, rather than changing the "Me First..." filter,
> the user could add another artist filter by clicking the "Artist" button again.
> Gtk.Buttons are used in the mockup just to illustrate the functionality and a
> more salient UI which clearly groups the filters would be required. This idea
> addresses each of the above problems:
> 
> * Size. The filters take up no additional space in the UI. The list of items
> only appears just as you need it but you continue to have the functional
> benefits of a browser.
> 
> * Scrolling. The search box eliminates the need for scrolling hither and yon.
> 
> * Selection. You can tell at a glance what artists and albums are selected and
> you can easily change those selections without jeopardizing the other selected
> items (or filters, as I have taken to calling them).
> 
> * Only artists and albums. It would be trivial to add other filtering
> categories such as genre. Banshee could provide the user with a list of
> filtering categories to display in the Preferences. Artist and Album could be
> on be default.
> 
> I have some further ideas about how the general search box would fit in with
> this setup, but I'll hold off on that mockup to see if there's interest in this
> idea. What does everyone think?
> 

I must say, I found myself _very_ impressed by this design. I think it's original and usable.

Oh I really like these. I think the one from Comment #52 is probably the most useful. But I particularly liked the one linked from Comment #53 from a visual point of view.

I really like Scott Peterson's 2 concepts better than anything I've seen so far. I see a problem with the second one though. If I add too many albums, it would quickly fill up the bar. Perhaps using a picture of the album art instead of the name of the album would be useful, but still simply due to the size of the bar, it quickly becomes useless to have too much data in it.

Other than that, those both address my concern of the browser mode cluttering up the interface and taking screen real estate. If I had to pick one of the two, I think I'd agree with Munckfish that the first is the better of the two. I'm wavering on if I like the search option at the top of both the artist and the album windows. I'm not sure what this would add to the larger search context.

(In reply to comment #57)
> I really like Scott Peterson's 2 concepts better than anything I've seen so
> far. I see a problem with the second one though. If I add too many albums, it
> would quickly fill up the bar. Perhaps using a picture of the album art instead
> of the name of the album would be useful

Not every album has existing album art unless the user provides it himself. Most of my albums don't have album art for this reasons ;) Would be bad if they couldn't be distinguished just because of that...

Yes they look good to me too. I think the second one (Comment #53) is the way we need to go.  As mentioned - it should simply be a front-end for the filtering text input.

As for selection concerns - I really think we need a back / forward buttons
just as our web browsers do. This way if something get's screwed we can simply
press "Back" and have our search history there. This would be quite easy to do
using the text driven filters - just remember last five or so and you're off.

I think that the button driven filters would really clutter up the view...
Maybe we could have a choice - button driven filters for simple, and text entry
for advanced filtering? The first one should be a hybrid of Lukas's first and
second mockup. Not two separate buttons for artist/album - just one.
Double-click on the artist would give You all the artist's albums, single-click
would add an artist to my selection and show the albums to choose from -
double-click in the album pane to select just one album, single-click would add
an album to my selection, getting my focus out of the browser for a second or
so would close it. There should also be a single-line "All Albums" at the top
of the album list, so we're able to quick select all albums from more than one
artist.

The browser should always reflect current selection - so that clicking on it
again would show us the things we have selected before, not a clean sleet.

I would also see the place here for multi-disc albums not to be displayed
separately, but as small links beside the cover art saying "Disc 1", "Disk 2",
clicking somewhere on the whole row would give us all the discs, clicking one
of the links would only select us one of the album's discs.

Relying on cover-art in the buttons would greatly decrease usability - I don't
remember all my library's covers since I probably haven't seen all of them
anyway...

The filter entry would need to be a separate text field IMO, cause I'd really
like to be able to search my selection anyway - not by filtering them even
further - just jump to the first matching song. The filter entry could also be
formatted some way (so that queries would be simply read). We definitely need
some parenthesis and logical equations using and/or/not for our filter. I hated
it when I tried to select photos that are tagged this AND that somewhere, and I
could only select this OR that - what's the use of tags this way? The same
applies here - we need all the basic logic operations.

Here's a FPP example: (the texts in brackets are search filters - comma
represents "or", + represents "and")

- Click on Browse, the browser opens
- Double click on an "Radiohead" (browser closes)
[artist(Radiohead)]

- Browse
- Double click on "Coldplay" (browser closes)
[artist(Coldplay)]

- Browse
- Single click on "Radiohead" (browser stays open)
[artist(Coldplay,Radiohead)]

- Click outside of the browser or unfocus from it - browser closes
- Browse - the browser shows us all albums matched by current artist filters in
the album pane, "All Albums" row is selected
- Double click on "Parachutes" (browser closes)
[artist(Coldplay,Radiohead)+album(Parachutes)]

- Browse - only "Parachutes" is selected
- Single click on "OK Computer" (browser stays open)
[artist(Coldplay,Radiohead)+album(Parachutes,OK Computer)]

- Single click on "A Rush of Blood to The Head" (browser stays open)
[artist(Coldplay,Radiohead)+album(Parachutes,OK Computer,A Rush of Blood to The
Head)]

- Double click on "OK Computer" (browser closes)
[artist(Coldplay,Radiohead)+album(OK Computer)]

- Browse - only "OK Computer" is selected
- Single click on "Johnny Cash"
[artist(Coldplay,Radiohead)+album(OK Computer),artist(Johnny Cash)]

- Double click on "Unearthed" (browser closes)
- here [artist(Coldplay,Radiohead),artist(Johnny Cash)] gets simplified to
[artist(Coldplay,Radiohead,Johnny Cash)] and then [+album(Unearthed)] gets
added. Basically - double click on artist cleans the whole filter, double-click
on album clears only the album related parts.
[artist(Coldplay,Radiohead,Johnny Cash)+album(Unearthed)]

- Browse
- Double click on "Johnny Cash" (browser closes)
[artist(Johnny Cash)]

- Browse
- Single click on "Unearthed"
[artist(Johnny Cash)+album(Unearthed)]

- Single click on "Disc 3"
[artist(Johnny Cash)+album(Unearthed+disc(3))]

- Single click on "Disc 5"
[artist(Johnny Cash)+album(Unearthed+disc(3,5))]

-----------
And so on and so on... the basics are: single - add to selection, double -
replace selection - no use for Ctrl+click which always causes trouble :)

I think the way I described it is enough - I know a mockup could be better, but
this way there's no place for misunderstanding, I hope.

While the above mock up(http://bugzilla.gnome.org/attachment.cgi?id=83338) is nice, since it would appear to work at low resolutions, I, for one, am against redundant album art. Seeing it once is fine. Twice (the corner and the "now playing area") is okay, but anything more than that, in my opinion, is overkill, and wastes space, that could otherwise be used for showing more information/tracks. If we are trying to go about this in a way that wouldn't rob low resolution users of their screen real estate,  keeping the number of times/ways we show album art to a minimum would be a good idea. 

If album art is to be displayed with/next to the album name in the browser mode, I would not mind something along the lines of Michael's earlier mock up:
http://picasaweb.google.com/michael.monreal/Banshee/photo#5028858339454065922

I know Aaron expressed some dislike of the more vertical layout, as less tracks could be in view at any one time, however, I think that is the exact purpose of the browser mode: to pin down the artist(s)/album(s) your looking for, and only show you the tracks contained therein, aka, less tracks.  If the whole thing was re-sizable, or better yet collapsible (so that the whole browser would disappear, or "minimize" in some way), thus allowing more tracks to be viewed without the need to scroll. of course, if the browser section did collapse upwards, there would have to be some sort of visual hint, that the browser is still *active*, just not shown, at least not completely. 

Alas, should the idea of a vertical browser be thrown out completely, something like: http://picasaweb.google.com/lspierings/Banshee/photo#5034931709108071330 would sit well with me. 

Once again, I'm more than willing to attempt to help design/code any one of these, I just have little to none experience with mono or GTK, though I do have a good deal of programming experience, just in other languages. 

--Matt

After reading everyone's remarks I did a quick (static) mockup (http://lunchtimemama.googlepages.com/version3.jpg) (I swear I'll attach these to the bug... later). This is a hybrid of my two ideas. The "Browse" button (which I would have changed to "Filter" if I had the time) opens a floating browse window. There should also be a search box on the popup browser but again I did this really fast. This window stays open until you click out of it. You can select artists and albums as you would with a traditional browser (Ctrl-click for multiple selections). As you make your selections, they appear in the filter box to the right.

If there are filters in the filter box, the "Filter" button changes to "Add Filters". This means that nothing is selected when you open the browser and any selections you make are unioned with the ones already in the filter box. This is so that you do not accidentally change your previous filters.

The user can click on the filters in the filter box to change or remove them. This would behave just like my first demo. For example, one could click on "Ben Folds" and have a searchable list of just artists. Or one could click "Songs For..." and have a list of only Ben Fold's albums.

Matt, did you read the above comments? Much of what you said has already been
covered in a *lot* of detail above.

Scott and Michał: I will review your lengthy comments and ideas in the next
day or so. At first glance, I love the new mockups from Scott, but they raise a
whole slew of new questions we'll need to discuss.

Also, when replying to a comment, please do not quote the *entire* comment to
which you are replying. Pick specific points if you absolutely need to directly
reference something. This thread is getting quite long :)

Thanks for all the input everyone!

Scott: it would really, really help out if you create an attachment and then leave your comments in the comments box for the attachment. It will help tremendously with history and evolution of the ideas in this bug. It's already getting really complex to have to cross reference many links and out-of-order comments in this bug.

Out of curiosity, how are you creating these mockups? Particularly the movie ones.

Aaron: yes, it seems I missed a comment or two, or rather, one or two was posted while I was commenting.

I'm really excited to see this much activity/interest in the browser view. 

I actually think that the filtering engine would replace smart playlists... If only the filtering engine will get as advanced. We definitely need genre() rating() last_played() and times_played() in the filtering, and also some more logic - comparison. Maybe we could also have order_by() there? So that we could randomize or order by this and that and those ;)

Am I getting a bit ahead of myself? Shame I can't really help programming...

And I like the movie mockups a lot, too ;]

Created attachment 83425 [details]
Filter Mockup 1

This is a still from my first mockup. The animated version is a .swf Flash file, but it's too large to attach to the bug. Aaron,  I made the animations by creating UI mockups in MonoDevelop and posing them in front of Banshee. I then tweaked the screenshots in Gimp and animated everything in Flash (on Windows, alas).

Created attachment 83426 [details]
Filter Mockup 1 - Shot 2

This is another still from my first mockup. It shows filtering by album.

Created attachment 83427 [details]
Filter Mockup 2

This is a shot from my second mockup as described in comment 53.

Created attachment 83428 [details]
Filter Mockup 3

This is the mockup I reference in comment 61.

Created attachment 83730 [details]
This is what Banshee looks like on a Tablet PC.

One thing that's been skipped over here is an assumption that all displays are 4:3 and that a few are 16:9.  Obviously, the vertical layout is probably the most efficient for these displays, such that the most useful information can be presented with the least scrolling.

I have a Tablet PC, and while I know that puts me at less than a fraction of a percent of users, it's still an issue to think about, because the vertical layout would be entirely useless in tablet mode.   What's important here is that if we decide "vertical is the way to go" or "horizontal is the way to go", there are a few people somewhere that it will be very inconvenient for.  On the other hand, I doubt a configuration option asking if you want it to be vertical or horizontal would go over well when it comes to HIG stuff.

Then, I saw Scott Peterson's comments, which were amazingly original and pretty impressive.  First of all, I like original... just because iTunes does something doesn't mean we can't find a better way.  Also, it sort of fits in with some other radical concepts that have been coming along lately, such as the Slab, Gimme, etc.  Most importantly though is that regardless of your display ratio, it doesn't get in the way.  There's no argument of horizontal or vertical or whatever; it will work for pretty much anyone, and also on lower resolutions, such as 800x600.

Here's a screenshot of Banshee on a tablet for your reference.  The Red area is where a vertical browser would go, the Blue area is where a horizontal browser would go, and the green button is Scott's idea.

(In reply to comment #70)
> One thing that's been skipped over here is an assumption that all displays are
> 4:3 and that a few are 16:9. 

I don't think this has been skipped at all. Read my comment #30. If you are 16x:9y or have ample resolution in x, the browser will default to the left (vertical) otherwise to the top (horizontal). Thus it should default to the top in tablet mode. You can however choose to manually place it either on the left or the top, but unless a manual choice is made, the browser location will default to the optimal location for the display.

> Then, I saw Scott Peterson's comments, which were amazingly original and pretty
> impressive.  First of all, I like original... just because iTunes does
> something doesn't mean we can't find a better way. 

Scott's idea is nice, but there are drawbacks with this as well - namely too many clicks to get to the information you like. For two years I've been hesitant to implement the exact kind of browser iTunes uses, but after lots of testing of ideas and talking with usability folks, the fact is that the split-pane artist/album browser is a sane thing to do - be it on the left or the top. Ours will have album art too. Just because iTunes does something also doesn't mean it's wrong, though I am not really a fan of it (mainly due to its placement, as I've discussed above).

Now, if we really want to go nuts we could also offer the option to pack the browser into Scott's idea of the "Browse" button next to the filter box. 

With the 0.12.x and 0.13.x branches underway, we should probably finalize some sort of design paradigm for this so it can get implemented as soon as humanly possible. =D

I think having such a panel would demand "support for compilations CDs" first (see Bug 432040 for further information).

Otherwise artist which may have just one song in the whole library would get their own entry and the list would be unnecessary long.

(In reply to comment #73)
> I think having such a panel would demand "support for compilations CDs" first
> (see Bug 432040 for further information).
> 
> Otherwise artist which may have just one song in the whole library would get
> their own entry and the list would be unnecessary long.
> 

Well, if any one person is an artist for a given song (including compliation-style items), then they deserve an entry too. That's only logical.

At any rate, it's been a fair while since we've had any movement on this matter.

So, what's the game plan and where does it stand?

(In reply to comment #74)
> Well, if any one person is an artist for a given song (including
> compliation-style items), then they deserve an entry too. That's only logical.

I don't think so. If an artist has just one song for example and this only song is on a compilation CD he shouldn't show up in the list.

I would say, as long as an artist has no "own CD" and is just on one (or more) compilations, he shouldn't show up there.

Maybe there should be an option to show all artist, but for my library as an example it would blow up the whole thing.

(In reply to comment #76)
> (In reply to comment #74)
> > Well, if any one person is an artist for a given song (including
> > compliation-style items), then they deserve an entry too. That's only logical.
> 
> I don't think so. If an artist has just one song for example and this only song
> is on a compilation CD he shouldn't show up in the list.

Well, sounds like we're talking about browsing by artist v. browsing by album. In the former case, you'd expect all of them to be there; in the latter, not. :)

(In reply to comment #76)
> (In reply to comment #74)
> > Well, if any one person is an artist for a given song (including
> > compliation-style items), then they deserve an entry too. That's only logical.
> 
> I don't think so. If an artist has just one song for example and this only song
> is on a compilation CD he shouldn't show up in the list.
> 
> I would say, as long as an artist has no "own CD" and is just on one (or more)
> compilations, he shouldn't show up there.
> 
> Maybe there should be an option to show all artist, but for my library as an
> example it would blow up the whole thing.
> 

But the artist still has a given track, so there should be an entry for him in artists too.

Naturally, the entry for the album should be the same.

(In reply to comment #61)

Not that I'm a developer or anything, but I have to commend Scott on his mockups with the animation and whatnot.  I like your second idea very much and would love to see this implemented.  Would that idea also have option to type-to-find (like your first idea) the artist name?  That would make this just about perfect from this end-user's viewpoint.

Please specify the latest version of banshee you have been able to test this against or let us know that this is no longer a problem. Thank you for helping us keep track of your bug.

The browser seems to be done, but not in trunk ;)
So keep the bug open until the new code is fully merged...

The browser is now in trunk. It can be used to the left of the track view or above it.

*** Bug 508135 has been marked as a duplicate of this bug. ***

Is this available in the 0.13.2 release ?

(In reply to comment #84)
> Is this available in the 0.13.2 release ?

No, only in the (rather unstable at present) SVN trunk. More info on the roadmap here: http://banshee-project.org/Roadmap

*** Bug 523202 has been marked as a duplicate of this bug. ***

I test banshee v1.0 under Ubuntu Hardy and tthere is no way to browse by genre ! I'm really surprise. It's should be good enhancement.

It's done in SVN trunk - will be there in 1.2 that's due soon.

Right... there's a new genre pane in the artist/album chooser now. Shows that some of my genre tags are spelled wrong, d'oh.