“How the app actually works” and “what it feels like the app is doing” are very much at odds here. Combine that with just the challenge of describing/explaining all this in words, and I’m impressed we haven’t started name-calling yet 🤣
I use almost entirely Panes from the Outline Category, whereas it sounds like some of y’all favor List panes instead. To me, List Panes are hard to use. They are clear in how they work, but I just can’t get what I want out of them. Does that sound familiar? Maybe this is a question of two different strategies – and mixing between List and Outline Panes in a single workflow is just hard to do no matter which direction you come at it from? Not a right/wrong situation – we’re just staring at each other across this fence and don’t see what’s so great about the other side…
“Inheritance” may be a poor choice of word, but there is clearly some kind of filtering-connection between parents and children…and I’m out of ideas on what to call it. I’m open to suggestions. Based on my efforts to understand, and some past input from Jay, I believe the following statements are factual and describe how Legend is working (I’m happy to be corrected, please). Note that the “collapse matches” option does not factor in, because it controls collapse-states but not which items are “in” the Pane (they may be rolled up under a parent but they’re still there):
- Legend will display parents without their children (as evidenced by List Panes).
- A List Pane displaying a parent item without children only has that parent “in” it. The not-shown children are not “in” that Pane. Note that parents in List Panes don’t even have a “collapser” – there is no mistaking the fact that their children are not-there. I dislike the way this makes parents indistinguishable from non-parents in those Panes, but it is at least consistent!
- An Outline Pane displays items that match its filter or are required in order to include other items that match.
- Legend does not make a second pass after evaluating the filter to add children up under parents. Pane contents are driven entirely by the current zoom and the filters applied.
- Thus, if an Outline Pane is displaying a parent and its children, those children must match the filter. The parent has to be displayed whether it matches or not – because of the matching child. The siblings do not necessarily have to be displayed, if they don’t match.
- Therefore, ALL children we see in filtered Panes are – somehow – matching the filter.
Simplified tests: Given the unprefixed items: parent with children A, B, C and Pane filtered to has:star.
- Put a star on
parent - All 4 items display, even though parent is the only one that directly matches.
- Remove star from
parent and put a star on B - you will see only parent and B. The other children do not appear. ‘B’ is the only item here that actually matches the filter; parent has to be displayed in order for B to be shown. Note this directly contradicts the assertion that children are always shown with their parents.
Jeff What happens is a combination of two behaviours, in outline view:
With respect, I think your description here is incorrect and actually overcomplicated. There’s only one real rule: The only way a child can be consistently included with its parent in filtered Outline Panes is for it to take on the properties of the parent.
This is straightforward with a binary property like stars above. It gets weirder with other properties, though, which can be multi-state (priority) or even mutually-exclusive (prefix). Complete also has a confusing display behavior with dimming children of complete parents – I’m staying away from that for now. The rule is simple, but can lead to crazy outcomes.
Here’s how I will demonstrate that. The following isn’t very “practical” since it involves mutually-contradicting filter settings – but the very fact that it results in any visible items illustrates my point well:
- For the test items above, set all to no-star. No filter. All are shown.
- Then make
parent a bullet and add bullet (blue) to the filter: No change.
- Now make
B a Task. Still, no change - B has “both” prefixes right now, which means it matches the bullet filter.
- Add the task (blue) filter.
A and C will disappear. A and C are getting a bullet from parent but don’t match for task. ‘B’ is shown because it is the only item that actually matches this filter – it is a bullet AND is simultaneously also a task, from parent. Parent itself does not match but is shown because it’s needed for B.
- Now, negate the task filter (blue bullet, red task).
B goes away, A and C return.
For me, the “i-word” provides a simple explanation of the above that fits the observed results. And per @andrew ’s original question, this still applies to text filters. I use this to great effect in my current workflow in fact; I have tasks divided among 3 branches (with emoji names that won’t be repeated elsewhere) and need some Panes to show only items from one branch. But the Panes have to be zoomed to the top-level document for other stuff to work. So I filter on the desired branch’s emoji (text) and get only items from that branch.
All this is just an attempt to get “on the same page” as far as what is actually happening and why.
Is it good, though? That’s a separate question!!! Going back to my opening statement of this post, I think what ultimately matters is what the app “feels like” it’s doing, regardless of how it gets there.
The current behavior works just fine in a lot of simple, common cases. But it relies on users not getting too adventurous with their filters, either on purpose or by accident. I think that’s the root cause here. The current filters are completely rational and yet totally crazy when you throw in booleans, apply mutually-exclusive terms, or layer properties down through the tree (applying properties to parents, sub-parents, and also children). In my mind, this is a kind of user error in setting up the document/workflow. But it’s one that nobody can be expected to avoid, especially at first. and Legend sure doesn’t do anything to steer you clear of it.
It seems like some kind of “bumper rails” could be good. Limiting the number of filter ‘terms’ to 3 or 4 perhaps, and then popping up a Toast. Don’t prevent anything, but just warn users “Filters with many terms can be challenging to use effectively” or somesuch. Let them know they’re starting to color outside the lines. An “exact matches only” button would also be a kind of band-aid that would help users back themselves out of a corner. I dunno, is that enough? Is it the right approach?
Filters work in a fundamentally simple, extremely powerful and flexible way. You can do just about anything you want – along with 9,999 things you absolutely do not want. Yeah…that’s a problem…but I don’t think the solution is to make filters less powerful nor more complex by adding exceptions and caveats that try to anticipate user intent.
