|
|
Have any users complained about this? I find this useful (even across nodes). For instance: - I'll set a filter for Rating > **** and then navigate across nodes - I'll edit tracks for Rating is unknown OR Artist is unknown OR Album Artist is unknown In both cases, I appreciate the filter persisting |
|
|
No, I came across this when using Files to Edit and wondering why files are missing. For now solution A may be good enough (ie. make it more visible the view is filtered). |
|
|
I suspect that the root issue is that filter status isn't obvious is because it doesn't persist in a consistent manner which can result in user expectations not being met. More specifically: - When switching nodes within a Collection, the filter persists - When switching to the parent node of a Collection, the filter is disabled e.g. Collection A subnode (fliter) --> Collection A --> Collection A subnode results in the filter becoming disabled! - When Switching from Collection A subnodes that have the filter enabled to Collection B subnodes that don't have it enabled and then back to Collection A subnodes, then the filter is disabled! I'm not certain what the optimal behavior is, but it would seem that one of the following would probably make the most sense: A) Always persist filter status within all subnodes of a Collection (i.e. switching to the Collection node or any other node shouldn't affect whether it persists for Collection A subnodes. B) Always persist filter status within a Collection and its subnodes. This seems like the most obvious approach, except that filtering is disabled in top-level Collection nodes largely because they're intended to show all content. C) Make filter persistence Global to all Collection subnodes. This would work similarly to the 'Recursive mode' toggle that's adjacent to it. D) Never persist filters. I think that this would be unexpected. I lean towards A) but would appreciate feedback. |
|
|
Note: In 0018909 the 'Recursive' functionality was set to persist on a per Tab basis. I'm still uncertain what the optimal behavior is, but I would suggest that persistent of Filters and Recursiveness should persist in the same manner. i.e. if recursiveness is persisted per Tab, the same approach should be taken for filters. |
|
|
OK, I think that there are different issues to address: 1) The LowLander's objection that after changing a node it is not obvious that filter is still active => it is indicated on the toolbar, but for first time user often not clear 2) There is inconsitency when the filter is discarded as currently different combinations of node+view supports (or doesn't support) the filtering. e.g. changing from Music > Albums [Grid] > Filter: Rating >= 3 stars to Music [List] > Filter: Rating >= 3 stars keeps the filter (as List view supports filtering) BUT... changing from Music > Albums [Grid] > Filter: Rating >= 3 stars to Music [Browser] discards the filter (as Browser view does not support filtering) I see two possibilities: Solution A) Discard filter whenever a node is changed as Lowlnader originally suggested. Pros: Solves item 1) above Cons: User needs to use 'Recently used' filters to quickly re-enable it for the other node/view Solution B) Always keep the filter for all nodes and collections until it is manually discarded (probably per tab basic like the 'Recursive' option for consistency) Pros: No need to re-enable the filter after node change Cons: Does not solve 1) above, i.e. is unclear whether the filter is active and how to discard it This could be solved by adding [^] button to the rules to hide them and keep the rules visible even after node change until user clicks [^] button to hide it manually. |
|
|
FYI: By the [^] button I mean the "Hide editor" button that is currently available for auto-playlists: image.png (11,334 bytes) |
|
|
Solution B) seems cleanest to me. In order to make it clearer that a filter is active & clearer how to close it, how about modifying breadcrumbs to: Collection> Node A > ChildNode B ([filterIcon] Rating > 3 stars [x]) Same approach can be used with recursive functionality: Location > Node A > ChildNode B (All [x]) |
|
|
The discard button on the breadscrumbs is already there, I guess that the confusion raised by LowLander was that changing the node auto-collapses the rules and user can easily overlook the filter indication on the breadscrumbs. Therefore I suggested to add the new "collapse" button and the rules would not by auto-collapsed anymore (on node change), but remains visible until user manually collapses it. This should eliminate the confusion raised by LowLander. image-2.png (18,879 bytes) |
|
|
Agreed--adding a '^' to collapse the filter editing would make it easier to understand how to hide the filter editing controls. It's not perfect since the controls are unrelated--windowing controls should somehow be distinguished from functional controls (we have another example of this when an auto-playlist is edited and '^' 'x' displays). Perhaps moving the '+' to the row below? The issues that the proposal at 0018257:0069277 addresses are that: - It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node. The proposal is to make filters look different and more representative of what they are). - It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter--it just looks like all the other A > B > C > D breadcrumb nodes) - It unifies the mechanisms for enabling/disabling filters/recursive modes |
|
|
OK, I added the collapse button on the right in order to not mix with the (+) button on the left. => fixed in 5.0.4.2664 |
|
|
Verified 2664 Pleas eclose after confirm Ui placement |
|
|
image-3.png (12,199 bytes) |
|
|
The 'Collapse' button works well, and positioning seems fine. BUT: a) should the filter button continue to display once a filter is enabled? b) clicking the Collection node still disables the filter. Is that intentional (that wasn't discussed in solution B), but perhaps you decided it's preferred to have this exception)? Test note: The current fix doesn't address the following related but different issues and should be documented elsewhere before the bug is closed: - It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node). - It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter since it just looks like all the other A > B > C > D breadcrumb nodes) - Recursive mode is a similar type of function, but works differently (via a Toggle). It would make sense that it works similarly to Filters. Possible approach that addresses these issues: Filters: Collection> Node A > ChildNode B ([filterIcon] Rating > 3 stars [x]) Recursive mode: Location > Node A > ChildNode B (All [x]) |
|
|
a) I think that yes, it should continue to display because just enabling the filter adds no rules, so the filter is still empty and clicking it again hides the filter editor. i.e. it has always been a toggle and disappearing the filter icon upon clicking would rather looks like a bug/regression. EDIT: See my comments section [ANOTHER IDEA] below... b) Yes, changing from Music > Albums [Grid] > Filter: Rating >= 3 stars to Music [Browser] discards the filter (as Browser view does not support filtering) => this has been always the case and the filter has been always active just for the selected collection (as originally suggested elsewhere in Mantis) We could either solve by introducing solution A (rather than B) -- 0018257:0068442 or leave it as is (espacially as it is more obvious whether the filter is active or not dur to solution B) - It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node). => I don't understand, what's unclear here? I think that the funnel icon and the rules next to the icon are clear enough to indicate that the filter is active? EDIT: See my comments section [ANOTHER IDEA] below... It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter since it just looks like all the other A > B > C > D breadcrumb nodes) I think that the current discard filter icon is quite clear and it has the "Cancel filter" tooltip. We could change it to '[filterIcon] Rating > 3 stars [x]' but the problem is that once there are more rules then the rules text gets long and the [x] button would get way much on the right... EDIT: I think the [ANOTHER IDEA] below could solve it together with item a) [ANOTHER IDEA] : Currently the funnel icon on the toolbar is toggle between [show editor / hide editor]. What about chaning the toggle to [show editor / discard filter] ? The rationale is that we have introduced the collapse [^] button for hiding the editor already in 5.0.4 |
|
|
We just might want to move the collapse button below the discard button toggle like this: image-4.png (10,418 bytes) |
|
|
Re. a) and b): OK (no additional changes needed). Re. the following items (which aren't urgent--ie. they're post 5.0.4): i) It's not clear when a filter (or recursion) is enabled: what I mean is that all breadcrumbs entries represent nodes in the tree, except for filters and recursion which are different--but the breadcrumb doesn't display them any differently. So at first glance, when looking at the breadcrumbs, it's not obvious that either of these are enabled. ii) It's not clear how to disable a filter: what I mean is that as described above, filter breadcrumb icons 'look' like they would take the user to a node. Yes, it has an 'x' next to the filter icon, but it's tiny and not obviously different than other breadcrumb nodes. Re. the 'Another idea': That approach makes filters and recursion work similarly, which is good, and addresses issue ii) . On the other hand: - it doesn't address issue i) - It would make it unclear how to edit a filter that's enabled (i.e. when a filter is enabled users need to be able to edit it and/or disable it and iiuc this substitutes one for the other). |
|
|
I think that with the current implementation (with the rules editor staying open until collapsed by user) it is clear enough how to discard/disable the rules (or close the editor)... So I would just leave it as is... |
- Anonymous
