View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003464 | MMW v4 | Playlist / Search | public | 2007-09-02 08:13 | 2008-12-30 22:15 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 3.1 | ||||
| Summary | 0003464: Make Search bar options more clear | ||||
| Description | Currently there are the following options in the Search toolbar: 1. Current Selection 2. Entire Library 3. Library (filtered) I'd suggest to: A. Remove 3. in case user doesn't have any Filter active. (but remember the option in order to highlight it in case a Filter is activated) B. Dynamically change the text in 3., i.e. something like 'Library (Classical)'. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
| related to | 0003040 | closed | Ludek | Implement proper full-text search |
| related to | 0002570 | closed | petr | Library node should show all tracks in Library |
| related to | 0003754 | closed | Ludek | Search bar: Configureable search mode on a per root node basis |
| related to | 0004963 | feedback | jiri | Allow for easier switching between multiple libraries |
| related to | 0005092 | closed | petr | 3rd column of track browser doesn't work properly |
| related to | 0003508 | closed | Ludek | AutoDJ options needs "from current filter" option |
| related to | 0005118 | closed | petr | 'Search Selected' interacts incorrectly with the Track Browser |
| related to | 0005712 | new | Search Dialog: unclear whether it searches entire library, current selection, or active filter | |
| related to | 0005893 | new | Search: Subsequential character searches always do Search from next track in list and do not include current |
|
|
Assigning to Rusty for a review, assign to Ludek then. |
|
|
Taking a step back, we've previously discussed the fact that 'collections' should probably appear in the tree (rather than require a right-click in order to see that they exist). e.g. Library (AudioBooks) should be a top level node in the tree that is collapsed. In addition, we've discussed in bug 0002570 that library contents should appear e.g. when 'Library' or 'Library (Podcasts)' is selected. Given the above, might it be better to just always search based on whatever content is displayed? (i.e. based on the active node / subset shown ? If the user wants to expand the subset they could just click 'Library' in the tree... On the other hand, we could implement this similarly to how you've suggested e.g. Current Selection Entire Library Library (Audiobooks) Library (Classical) ... Amazon Wikipedia . . . Note: i think that a new bug may be required for showing Filters in the tree (I can't find this). |
|
|
Comment from Jiri (accidentally entered as 'additional information'): I agree, if we decide to show Filters in the tree (which we probably will do, because of movies), it will actually change this issue. |
|
|
I was actually thinking about Video and Pictures when i wrote my comment. So if the user was in Audio mode, the searchbar would search based on the selected Library node or subnode (unless the user manually chooses another search in the search dropdown--the search dropdown would only contain audio options). If the user was in Video mode, the searchbar would search based on the selected video library node or subnode (unless the user manually chooses another search in the search dropdown--the search dropdown would only contain video options). BUT--if the user chooses another search in the search dropdown (e.g. search for Library (classical) when the selected node was Library (Podcasts), then the search results would be meaningless UNLESS mm switched nodes. I think that this could work, but I'm not certain...it might be confusing (in which case it would mean that we should eliminate the options on the Search bar entirely). |
|
|
Yes, what I meant was to leave only the choice of searches, either: 1. Current Selection 2. Library (current filter) {i.e. as you wrote, only the currently selected filter, like Audio, Video, etc.} I don't even need 1., but I think that this was requested by several users. |
|
|
Sounds good. |
|
|
I think that current implementation is just good, why we should eliminate the 'Entire Library' option? If I am in a filtered library and I want to use quick search in order to find a track in my entire library then why should I switch current filter? Because we have implemented 0003754 - I would only change the default search mode i.e. Search Mode: - Library or sub to Library node: [Library (Filtered)] - Playlist node: [Current Selection] - Podcast node: [Current Selection] - Radio node: [Entire Library ] - Web node: [Amazon ] - Device or My Computer node: [Current Selection] Do you agree? |
|
|
I think that what you're saying makes sense, except that the filters should be explicity listed as Search options e.g. instead of always showing 'Current Selection' the dropdown should show e.g. Entire Library, Library (Classical), Library (Video), etc. (=item 1) Here's how this could work: If focus is in the Library (Video) node, and the user does a search in that node, they would expect (by default) to search 'Library (Video)' (i.e. the options in the Search dropdown should specifically indicate 'Library (Video)' so that it is more clear what is being Searched). When the search is performed: 1) the tracklist is updated 2) the track browser is updated to show only relevant filters If the user then switches the search dropdown to 'Library (Classical)' and does a search, then focus should switch to the 'Library (Classical)' node, and the tracklist/track browser updated appropriately.(=item2) If the user then switches the search dropdown to 'Entire Library' and does a search, then focus should switch to the 'Library' node, and the tracklist/trackbrowser updated appropriately. If the user switches _nodes_ e.g. to the 'Library (Kids)' node, then the search bar default should change to _'Library (Kids)'_. This last issue may imply changes to 0003754 as currently implemented.(=item3) Note: For each of the searches, a node containing the search results is created (as is the case today), but as described above, focus does not rest on the search nodes. (=item4) Item5: The 'Current Selection' function would probably be better off as a 4th item in the Track Browser since the track browser is always used to refine the contents of the Node and Search. This could work very similarly to the 'Find' bar in firefox. It would appear at the bottom of the Track browser and would appear as follows: Find: _______________ v Next ^ Previous [ ] Highlight all One final note: all of the above presupposes the implementation of 2570 and the creation of individual nodes for each filter (item 6). |
|
|
Reminder sent to: Ludek fyi--assigned to Jiri for review, but your comments are needed as well. Thx. |
|
|
Ok, supposed that the creation of individual nodes for each filter (item 6) will be implemented then this proposal would make sense, but user should have an opportunity to define which filters he would like to have in the tree(Defined in 'Filters & Views' option panel). Re: Item 4: I would only create the node containing the search results in case of 'Entire Library' only (as is the case today). And focus would switch to this created node (in case of the 'Entire Library' searching). Reasons: 1. If a user would save the node containing the search results as an auto-playlist then the results would be same (otherwise we should add also filter conditions to the created AP) 2. This also covers the case if the user would define the 'Library' node not to be presented in the tree. |
|
|
Let's defer this discussion after multiple Filter support is implemented, we will better understand what's actually needed then. |
|
|
One other idea: some users expressed the idea that they would just want search settings to persist (i.e. always use the last used search mode). |
