View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001313 | MMW v4 | Main Panel/Toolbars/Menus | public | 2004-05-10 19:05 | 2010-10-25 14:30 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0001313: Track Browser: make it easy to browse collection like in iTunes/Winamp | ||||
| Description | It would be useful to allow the user to browse their collection in a manner similar to Winamp/iTunes/Real, by enabling View:Browser. The browser would simply be a 'special' set of rows at the top of the Tracklist that allowed the user to select attributes used to generate a query dynamically. The user should be able to configure which attributes to browse by. When the browser view is enabled it should toggle off the Tree view (Ideally there should be a toggle button that allows users to switch between the two). Important: wheelmouse should be active on mouseover in this area. | ||||
| Additional Information | This is related to the filter functionality which narrows the scope of what's presented in the tracklist. Both should probably be implemented at the same time. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Here is an updated specification of how I think it should work: There should be a dockable window 'Track Browser' with 3 listviews of Artists, Albums and Genres as e.g. in iTunes (these items could be configurable, but it could be implemented later). This should work as a filter, i.e. I'd say that tree should be still visible, user could select a node (e.g. Library to see all tracks) and Track Browser would further filter content of Track List. (Technically, there should be two lists present in TFMainWindow, SongList for the filtered list of tracks and a new one SongListFull that would be populated from SongList when Track Browser is shown). Rusty, please review this modification and assign to Petr if you agree. |
|
|
I like the idea, since it allows users to find tracks from among a subset of tracks. I would want to discuss the following beforehand: a) It kind of duplicates the filtering functionality suggested in 0000102, but does it in a manner that is more complex/less usable. The way I see it, most users would want to set 'collection' type filters at this level: e.g.: All, Audiobooks, Podcasts, Music, Kid's Music, but the filtering suggested doesn't achieve this usecase in an easy manner. I guess the question is, what is the purpose of adding such advanced filtering? b) It can be confusing if a user selects a node then a filter then another node (what should happen?) c) How would the following nodes work? Files to edit subnodes, Search nodes, Portable Device nodes, My Computer subnodes (contain tracks not in library), Net Radio nodes, Web nodes. d) This is related to c: The Tree is fairly wide, especially when expanded. I was thinking that it might be useful that when the user has exposed the 'Browse Collection' functionality, that the tree be changed into a simple list (like in iTunes): Now Playing, Library, Radio, Stores, iPod, CD/DVD, Playlists, Search Results. Let's discuss. |
|
|
a) I think that this is a little different functionality, but this kind of filtering could be probably achieved too. What you describe is all related to track genre - maybe introducing supergenres (i.e. having genres in a two-level tree) would help in this. We can discuss in more details over IM... b) I'm not sure about this one, but it seems that filter would have to be cleared on such an operation. c) I think that all nodes including these should work the same way - i.e. their content would be filtered. d) Although it might be useful, I'm afraid it would be a little confusing and would introduce too much complexity to MM (both for users and developers). I'd rather prefer having a simple way of hiding the tree - users might like the iTunes-like browsing e.g. for Party mode. |
|
|
a) What I meant was that my impression of the main benefit of having a 2-stage filter as you suggest is that the user can initially define a filter for the collection of tracks they want to look at, and then browse among those tracks (there's no need for multi-level genres). The proposed implementation achieves that usecase, but a simpler mechanism would be to allow the user to define a filter for their collection. This isn't really an issue, though, as adding such a filter isn't mutually exclusive of the proposed browser. b) Yes, makes sense. c) OK, that's great! I didn't think that would be technically feasible. d) OK--anyhow, it's orthogonal to this functionality. e) One other issue: if we implement the browser filter so that it is sensitive to the context of the tree, we should probably implement search functionality in the same manner. Do you agree? (note: WMP 11 works in this manner). |
|
|
a-d) Ok, so it seems we are generally speaking in agreement about this issue and it can be assigned to Petr. e) It might be useful in some cases, but my understanding of how users most often use this feature is that they simply enter a text regardless of the selected node and expect all tracks to be shown. However, I think we have already discussed this in the past and weren't in agreement... |
|
|
e) Re. context-sensitive search: we discussed something along those lines in the past. We can defer this issue for now, though I'm pretty sure that once the browsing is implemented, it will be a bit confusing that the filters work one way and the search another. As long as we implement it with consideration that this same functionality may have to be implemented for 'Search' as well. |
|
|
Assigning to Petr, the functionality is pretty much described in note 7712 above. |
|
|
done |
|
|
Tested in 1008. It's looking pretty good except for the following: 1) If the user makes changes to the window (e.g. resizes it or goes to party mode and back) then some graphic artifacts appear in the Browser: -An extra column appears to the right of both the Artist and Album columns and the user can't move the column splitter. e.g. the following is expected: The following is what actually appears: -As a result of the extra column, the 'All' entries that appear at the top of each of the three columns are selected strangely (when selected, they appear grey only up to the edge of the weird columns) 2) There should be an context-menu option to 'Show Titlebar' (so that the user can get rid of the titlebar). It should be implemented in the same manner as for the other optional Windows. 3) There are a couple of Tree nodes in which the Album Browser doesn't function. I believe that it shouldn't be displayed in cases where it doesn't work. Thus: -Search : for this node, I think it's preferable to use the browser as a secondary filter (in the same manner that it works for playlists). -Now Playing, My Computer, Net Radio, Web: for these nodes, I would suggest that the Album Browser should just temporarily disappear (and automatically re-appear when a relevant node is selected. 4) (Already mentioned)--If it's not too difficult, it would be really useful if the user could configure (via right click to the heading) which properties to browse by. This is especially important for e.g. Composer due to the improvements in classical music management. |
|
|
Tagging as Immediate, should be fixed prior the first MM 3.0 alpha release. |
|
|
solved 1, 3, 4 |
|
|
done |
