View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014293 | MMW 5 | DB / Backup | public | 2017-07-06 16:04 | 2020-12-17 11:01 |
| Reporter | jiri | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | reopened | ||
| Target Version | 5.1 | Fixed in Version | 5.0 | ||
| Summary | 0014293: Filtering fixes and improvements | ||||
| Description | 1. Filter isn't saved in history, i.e. Back button doesn't restore it after it's cleared. Would probably make sense to implement? 2. When a new filter condition is added, sometimes the dropdown is shown only partially - see the attached screenshot. 3. Per user's request at http://forum.mediamonkey.com/viewtopic.php?f=30&t=87045#p437140 item 3., it'd probably make sense to add checkboxes to temporarily enable/disable individual conditions. 4. Also a request to save/load individual filters seems to make sense. I can imagine a '...' icon there with 'Load', 'Save' a possibly some kind of Delete available. That said, I wonder then how to position this wrt AutoPlaylists - does it make sense to have these as two separate approaches? Would a unification work without sacrificing simplicity of the Filter functionality? 5 .Genre filtering works strangely - modifications to the condition (equal vs contains vs doesn't equal) results in different results - without any value entered! I'd expect that whole library is shown, until some value is entered? 6. The results exhibit quite a bit of flickering/blinking. E.g. when Rating condition is changed from 4 to 5 stars, the results are briefly blank. Would be nice to transition directly from old to new results, without any step between. 7. There isn't any indicator of loading, which should be for some slower operations (e.g. when 'Any' condition is chosen, Rating>4 stars and Genre contains Rock.) The results are blank then for ~1-2 seconds and it isn't clear, whether there isn't any track matching or results will appear later. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2219 | ||||
|
|
Item 2 fixed in build 2073 Item 1 fixed in build 2076 |
|
|
1,2 Verified 2076 |
|
|
Items 3,4,5,6,7 are implemented in 2081 |
|
|
4. While working fine, I'm not sure whether the Save to filesystem makes enough sense. The original idea (although not fully specced here) was to somehow store the Filter in MM, possibly as Auto-Playlists. I'm not sure about the best approach though, so I wonder whether we shouldn't rather disable/hide the current implementation in order to not introduce confusion and decide later how to proceed (probably for MM5.1)? 4b. I wonder whether we shouldn't replace the manual 'Save' function by an automatically maintained MRU list of filters used? I.e. a click on the '...' icon would show a list of ~10 recent Filters + 'Clear list' command. Note that filters wouldn't be saved after every change, but e.g. only when a filter is being canceled. 6. Better, but still not perfect. Enter a more complex condition (Any + Rating + Date + Genre) and then just click Rating stars and click elsewhere without any actual change to rating => For a moment a different tracklist appears. 8. Bug: Not sure how to reproduce, but sometimes there are wrong operators shown. E.g. add Rating condition and it shows 'contain' operator (even though the drop-down correctly lists >, >=...) 9. Rating is editable in the middle of the screen (i.e. stars are shown there). I guess that there's no reason to not left-align them? Btw, I'd prefer to always show star images there, currently when the edit is finished, there's a text 'n stars' shown. 10. Currently the filter shown in Navbar isn't clickable (only the icon is). I suppose that click on the Filter text could result in opening the Filter section in order to start its edit? 11. Bug: Go to All Tracks, create a filter and then click the 'All tracks' header in the Navbar => the '>' icon right of 'All tracks' disappears. 12. Idea: Based on thoughts related to problems 10&11 above I wonder whether the filter text in NavBar wouldn't make more sense right aligned, instead of the Filter icon? I.e. when a filter is _active_, show the navbar as: [Home] > Music > All tracks ..................................................................... [Cancel filter icon] Rating > 4stars ... [View selector icon] 13. Per user request, it would be useful to be able to easily open the last used filter. We might _always_ open the previously used filter and just add 'Reset' clickable text (right aligned?) so that it's easy to start with an empty filter? |
|
|
Item 9 fixed in 2083 Items 4,6,8,13 are fixed in 2086 4) added MRU list and removed Load/Save commands from the overflow menu 13) Implemented + added 'Clear' command to the overflow menu |
|
|
12. I would rather keep it left aligned. I've played with it a bit, but the absolutely positioned [View selector icon] makes issues here. Items 10, 11 are fixed in 2089 |
|
|
Looks good, just: 14. While '>=' operator on Rating shows star images, the '=' operator show dropdown with texts '5 stars, ...'. Doesn't seem to be intentional? 15. While using '>=' operator on Rating, stars can be chosen using mouse click on the images, but on mouse click elsewhere, the images change to text like '5 stars'. Is the change to text necessary? Not a big deal, but would look better if always presented using icons. 16. When operators dropdown is open for Rating and I click any of the stars images to the right, the operator dropdown doesn't close. |
|
|
14/15: Yes, this is intentional, because user can choose more values there like [Rating = 2 stars; 3 stars; 3.5 stars] 16. Fixed Further issues: 17. view filtering does not work correctly for the "Entire Library" sub-nodes, e.g. [Entire Library > Artists > U2], [Entire Library > Genres > Acid Jazz], [Entire Library > Years > 1930's] => fixed in 2196 |
|
|
18. Another issue use quick search "test" -> results show -> Navigate tree Entire Library -> Genre -> Acid Jazz -> Results Show -> Click on Show Filter Icon -> it shows any text "test" . Repeat same with any other quick search word and view filter will always show that as criteria |
|
|
18. Yes, that's because of item 13 suggested earlier by Jiri -- so that previously used filter is always auto-opened: https://www.dropbox.com/s/ihbnsgtkhdnn98q/Screenshot%202019-09-13%2009.36.33.png?dl=0 So I am not sure whether it is a bug at all? But I can understand that may look like a bug to auto-use of the last used filter, so probably we should always start with a clear filter -- as some users on the forum also saw this as confusing. Users can always use the last used filter via the three dots menu > Recently used list => Fixed in 2197 |
|
|
Verified 2197 You are right 18) was not a bug it was sort of regression. |
|
|
A tweak bugs for next builds: 19 ) Entire Library -> Genre -> Ambient/Instrumental -> Results Show -> Click on Show Filter Icon -> Empty Criteria are shown, I Would Expect to have one criteria ([x] Genre equals Ambient/Instrumental) 20) In relation to 19) if I try to recreate Genre equals criteria (Image attached) |
|
|
19) I don't think that the dummy condition [[x] Genre equals Ambient/Instrumental] should be auto-added. This would require auto-adding of a dummy condition whenever user changes a node under the same collection (as the view filter is active until user changes the given collection -- per original design in 0014122) 20) is fixed in 2198 |
|
|
20) Verified 2198 it doesn't occur anymore |
|
|
I've reverified items 1-20. Note re. 19) I understand Peke's point, however, it's a bit late in the game to change the way navigation/breadcrumbs work by making every selection a filter. But it might be something we'd want to consider in the future, but it's not a short-term change as it would affect many aspects of MM. 21) Clicking outside the filter causes the filter to be edited. e.g. For Rating >= *** if the user clicks to the right of the stars --> the criterion is opened for editing! The criterion should be opened for editing only when the user clicks directly on a criterion. 22) [Related to 14/15] If the user tries to edit the logical operator of a criterion it may cause the value to change. e.g. 1 For Rating >= *** click '>=' 2 Change '>=' to '=' --> *** changes to .5 stars! 23) Similar to issue 22), if creating a filter for Genre equals x a) upon selecting 'equals' --> 'click to set' is "selected". Instead the combo-box should be open for the user to select a Genre b) upon clicking 'equals' --> the 'Value' combo-box opens (instead of the logical operator combo-box) 24) Presentation of attributes isn't consistent [minor]: - Press '+' --> categorized attribute list appears - Click on an existing attribute (e.g. Rating) --> combobox displaying all attributes (uncategorized) appears 25) Should filters persist in a Collection? e.g. 1 currently switching from Collection A [Filter X] to Home or Home > Entire Library [Filter Y] to Collection A or Collection A [Filter X] to Collection B [Filter Z] --> Filter is turned off 2 Press BACK to go back to the initial Collection --> original filter is ON 3 BUT if instead of 2, the user manually navigated back to the initial Collection --> original filter is OFF! Thoughts? |
|
|
21) Fixed in 2216 22) this changes because the value type was changed, maybe you are suggesting that 'Rating >= 3 stars' should auto-change to 'Rating = 3 stars; 3.5 stars; 4 stars; 4.5 stars; 5 stars' ? 23) Fixed in 2216 25) Yes, filters persists per collection and are restored when you navigate back in history navigation items. In your test you are mismatching "Press BACK to go back to the initial Collection" and "user manually navigated back to the initial Collection". I don't know what exactly you mean by "user manually navigated back to the initial Collection", but I suppose that you probably just clicked the collection in the tree or on the breadscrumb? If yes, then it is not navigating back, but rather navigating forward to that collection. i.e. in that case the filter/search/selection is not restored as it is a NEW navigation item just added to the history. Lowering priority for items 19, 22, 24 |
|
|
Tagging as resolved to trigger testing in 2216. |
|
|
Tested 2217 22) I'm saying that a change in the logical operator shouldn't affect the value. e.g. For: Rating >= *** If I change: >= to = then the query should show: Rating = *** See: https://www.screencast.com/t/gEYfgSiwgxk If Rating was changed to Year, then the values need to be reset, but if the logical operator changes, they generally shouldn't unless the selected values are invalid in which case they should all be deselected. e.g. For: Rating=***,**** And user changes '=' to '>=", then the values are invalid and should therefore be deselected (or we could add some logic so that for changes to '>' or '>=' it retains the lowest value and for changes to '<' or '<=' it retains only the highest value). 23a) This isn't fixed in 2217. See: https://www.screencast.com/t/hu97YC5bspcK 25) OK seems logical, but I'm not sure it's totally intuitive (would users expect the filter to persist). I guess we'll see... 26) If the user adds/edits criteria, there is often flashing/movement in the UI. e.g. + date --> The criteria is added, then the operator, then the date, then the cursor goes back to the operator and opens it. Or in the case of '+' genre --> Genre contains click to set --> Genre contains __________ --> Genre _contains_v_ _____________ (with contains showing an open dropdown) It doesn't look very clean. |
|
|
Items 22, 23a, 26 are fixed in 2219 |
|
|
Verified 2286 Test verified all the fixes that works and no regressions are introduced If further issues are found it should be opened for post 5.0.1 or 5.1 release |
