Bugzilla – Bug 2701
Need ability to browse multiple tags in flexible order (Multi-Level Browse)
Last modified: 2009-09-08 09:24:31 UTC
NB - this is one of a series of requests, collectively intended to improve usability for users of Classical music. See attachment for detailed proposed specification. See also 2696 - 2700. We need a flexible multi-level browse command that lets the user pick the tag to browse on at each stage of the process. For example, a user might want to select a performance of Beethoven's 3rd symphony conducted by Bruno Walter. He might first browse on Composer, selecting Beethoven. Then he might browse on Artist (or Conductor if he tagged his files that way.) Then when he has narrowing the list of choices enough, he would browse on Album to select "Beethoven - Symphony 3 - Walter" from the list. Later, he might want to hear something played by the violinist Heifetz. He would begin by browsing on the Performer tag and select Heifetz. Then he would pick Composer for the next browse. At the next stage, he would select an Album naming a work by Beethoven to play. When a user has a large collection, using the SB display and the remote with the current browse commands can become intolerably cumbersome if the list of Albums is very long. A flexible multi-level Browse command allows a user to tailor his browsing method to keep the list of choices to a reasonable level. The browsing process would end when the user selects an album or a set of tracks to play by pressing Play or Add. At each stage, the SB display would provide feedback. The top line could display the tag values chosen so far and perhaps the number of Albums listed below. To speed things up, the UI would display a list of albums after the list of tags that can be browsed. So when the list of matching albums gets short, the user can just scroll down and select an album. ** See attachment for more details **
Created attachment 1074 [details] Context description for related requests
Created attachment 1075 [details] Detailed description of requested functionality
Since this is an enhancement request, it's going to need to be moved to 6.5 (where it also makes more sense due to the database upgrade to MySQL.)
6.5 is feature complete at this point - pushing out.
(In reply to comment #4) > 6.5 is feature complete at this point - pushing out. > So... does this mean that this feature request will be pushed out to 7.0+?
No - we'll likely do a 6.6 or something. Now that we have a QA Manager, we have more process - so moving bugs to Future means we'll go through and retarget them for the next releases.
And that our release cycle will be faster. As I said, 6.5 is slated for end of July.