Inheriting properties for filter matching

@andrew did you ever figure out a solution?

I still struggle with inheritance. Even though it’s not an explicitly named concept in Legend, it runs through all aspects of using filters and is key to understanding the items you see (or don’t see) in filtered Panes. Here’s one example I run into constantly and I have to imagine it’s common for other users.

I use Filters to separate out “Inbox” items. It’s really powerful and efficient. I add new items without any prefix because that’s fast, then I organize them into the main Outline which is formatted with Headings. So my “inbox” Pane is filtered to only show unprefixed items, and the Pane where I work with organized items is filtered to show only Headings (which hides the inbox items). This works great, until I want to dig into my Outline.

It’s so easy to zoom down by clicking Heading prefixes and then back out using the breadcrumbs in the Pane Heading. But when there’s a filter in play, I can’t zoom as far. I eventually get to a Heading containing nothing but
Projects and Tasks. If I zoom into that branch, I end up with an empty Pane. Everything I was just looking at disappears when I zoom in because the scope of inheritance is set by zoom level; children only inherit their parent’s properties while that parent is part of the Pane contents. Once you zoom into that parent, though, it’s not part of the contents anymore and inheritance ceases. The solution now is to clear the filter, and of course you can then use “back” to return to where you were. But why add this extra, unintuitive (and beginner-hostile) step to the end of an otherwise slick process? If it’s a compound filter, this step gets even more demanding. AND making filter changes trips auto-expand, which can be an absolute #(*&$^ when you’re in a large Outline. I have actually mapped shift+click to one of my mouse buttons because I spend so much time re-collapsing Outlines!

While I see plenty of utility in scoping filters per zoom level, this common outcome doesn’t seem to have any value. I would not be surprised if many users start playing with filters, run into something similar, and just throw their hands up in frustration – possibly leaving the platform entirely because it feels inscrutable and unfriendly. I’ve seen some folks here mention that they don’t even use Filters, and I have to think this is part of the reason why. I’ve been avoiding them as much as possible for years. I see two ways to address this;

• Tweak inheritance so zoomed parents pass on their properties until they are fully out of scope. This would solve my example above, but zooming one step further would still result in the same problem (and the solution would then be even less obvious).
• Add an explicit inheritance scope control to Pane options. By default children inherit everything above them, and clicking the option limits scope to zoom level. That way nobody gets unexpected results as they zoom in, and if they don’t like the inclusiveness of that behavior they can make a conscious choice to limit it. I think that fits into how Legend works much better.

BTW I’ve tried setting up the Pane filters differently, where the Inbox is show:unprefixed and the Organized Pane is hide: unprefixed. This does work but creates so much friction that I actually prefer dealing with the zooming stuff above. That’s because now items have to be both moved and prefixed – quickly. Plus I can’t leave unprefixed “notes” or partially-completed items within my Outline. I suppose that could be viewed as a good thing…but for me it’s harder.

Jerud You can do just about anything you want

I almost exclusively use Outline view. One thing I can’t do there, which is what I want to do almost all of the time, is to filter for items that themselves contain all the filter terms - usually a few words - not items that have just one of the words, with any of a long line of ancestors having the others. It’s actually hard to imagine, at the moment, why I would ever want the latter kind of filter, and I almost never get the results I want with a filter in Outline view if I’m looking for more than one word. So that’s when I have to switch to List view, or use global search. But then I can’t expand the matched items to see what they contain. I think that’s what Andrew’s original post was talking about, and I think it’s a very good point. I wish there was an option to restrict matches to items that have all the filter terms, rather than entire branches.

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.

I don’t understand what “make a second pass after evaluating the filter to add children up under parents” means. I don’t agree that the children match the filter terms. All ancestors and descendants of a matching item are displayed, regardless of whether those items match or not - unless they match an exclude filter.

I basically understand the rest of what you’re saying, but I don’t agree with the sort of metaphor you’re using. Children don’t take on the properties of their parents, or inherit them. They don’t get multiple properties or types, like being starred and not-starred at the same time, or being a task with an imaginary bullet. I think it’s confusing to others to describe things that way.

In your first example, A, B, and C do not have the property of being starred. They’re displayed only because in Outline view, all descendants of an item matching the filter are displayed (possibly collapsed). But the descendants themselves don’t actually have the property and don’t match the filter terms.

I stand by my description, with one correction, from “children” to “ancestors”:

1. When an item matches a filter, all its children are shown. This isn’t the same thing as the children inheriting properties. If you filter for high-priority items, all their children will be shown, regardless of whether they have medium, low, or no priority.
2. With a multiple-criteria filter, with “and”, an item will match if it has one of the criteria, and it or any of its children ancestors have the others. Again this is not the same thing as the children inheriting properties.

In your second example, you’re correct that “‘B’ is the only item here that actually matches the filter”. That’s because of rule #2. It has one filter term, and one of its ancestors has the other. Therefore, it matches, and because of rule #1, all of its descendants will be shown, but not its siblings. I suppose you could imagine that B behaves as though it has both filter terms, as though it has all the different attributes, tags, text, and types of all of its ancestors, all at the same time. But I think that’s an unnecessary pretense; in any case it’s misleading to say that the children actually have an invisible star that they get from the parent, and that they match the filter terms. They don’t. If you switch to List view, they’re not there. B has an ancestor with a bullet, so it’s the end point of a branch that matches - and everything after that end point is displayed - but it doesn’t have a bullet itself.

In any case, it would be good if the mechanics were explained clearly in the help document, not by us trying to reverse-engineer how it all works…

Jeff what I want to do almost all of the time, is to filter for items that themselves contain all the filter terms - usually a few words - not items that have just one of the words, with any of a long line of ancestors having the others

This sounds totally valid and useful, and I’m surprised I haven’t personally run into it yet. Have you already played with forcing exact matches for phrases by putting them inside quotes? Whether you like the current behavior or not, it seems like Legend should never match a phrase across multiple items. Rabbits->carrots should definitely not match “rabbits carrots”!

Jeff I don’t agree that the children match the filter terms. All ancestors and descendants of a matching item are displayed, regardless of whether those items match or not - unless they match an exclude filter.

You’re saying that my 1-rule explanation is wrong because your more-complicated one also explains the same results, without showing that my explanation fails to explain them. Doesn’t hold water, and Mr. Occam would object. The children may not be “displaying” these inherited properties but that doesn’t mean they don’t “have” them from the Filter engine’s perspective.

Jeff I think that’s what Andrew’s original post was talking about, and I think it’s a very good point. I wish there was an option to restrict matches to items that have all the filter terms, rather than entire branches.

I think so, too. That definitely doesn’t exist right now and it sounds like a lot of folks would like it to. Discussion needed on whether it’d be global or not, but in any case it could make setting up Outlines a bit more intuitive. Today you have to think ahead a bit to ensure you don’t accidentally “push properties out the branches” and get excessive matches, such as when naming high-up branches with common words. It really sounds like we need a clear way of differentiating between (and talking about) items that match a Filter based on their own properties vs. those that match by combining their own with their ancestors’. I want to start a separate thread on that in General Discussion, but am desperately trying to focus on work instead of this forum today

Jeff I basically understand the rest of what you’re saying, but I don’t agree with the sort of metaphor you’re using.

That’s okay, I wasn’t trying to make a metaphor; I suck at that. I was trying to just establish the foundation, getting to agree on how Legend actually works under the hood. If you know that, then you will never be surprised by the results (or you’ll know if you’re seeing a bug). I based all my above on what Jay posted (back in the Slack days), and hold my assertions to be true as they fully explain all observations without any contradiction.

That said, a good metaphor is EXACTLY what is needed here, because that’s how you explain the feature to users, and how the help docs need to present it. Nobody learns software by learning what the underlying processes are doing; you don’t learn to drive by studying the internal combustion engine (see what I mean about sucking at metaphors?). Your “two rule” system is almost certainly a better metaphor than what I described.

I personally find the concept of “inheritance” intuitive and accessible to a layperson (like me) and the objections to it a bit pedantic. What is the value in continuing to use “parent” and “child” if not to reinforce that relationship? I have a technical background – it’s just not in computers – and every day I hear people use words in ways I know are inaccurate or incomplete. “Power”, “energy”, “traction”, “speed” vs. “velocity”. All hideously misused and utterly misunderstood, even by people who outght to know. But clarifying requires so much work and yields so little benefit that I’ve come to just accept it. I’m not saying I’ll fight for the term tooth and nail…but until one of us comes up with something at least as accurate and intuitive (that fits into an effective larger metaphor), I’m not willing to take it off the table.

Legend plainly appeals to a wide cross-section of users with varied ways of thinking about things. We probably need like 3 or 4 metaphors! Filters are consistently mentioned as a huge sticking point for users new and old, so any efforts toward explaining them in more/better ways are good in my book.

Jeff In any case, it would be good if the mechanics were explained clearly in the help document, not by us trying to reverse-engineer how it all works…

Yes, and I’m going to stop doing that right now. Will see if I can get some definitive input from Jay on this. I wouldn’t blame him if he totally muted this whole thread because man….what a mess to wade through. I’d rather he kept working on the app itself than police our shenanigans!

Jerud Have you already played with forcing exact matches for phrases by putting them inside quotes?

Yes, but a lot of the time I just remember that I wrote something somewhere about a topic, but I don’t remember the exact phrasing I used, just some of the words. That’s probably the most common kind of search I do, at least in the other outliner I use. Kind of like a Google search of my own notes. Legend’s global search is also ok for that, but I can see some advantages to using filtering if I could.

Jerud Jeff I don’t agree that the children match the filter terms. All ancestors and descendants of a matching item are displayed, regardless of whether those items match or not - unless they match an exclude filter.

You’re saying that my 1-rule explanation is wrong because your more-complicated one also explains the same results, without showing that my explanation fails to explain them. Doesn’t hold water, and Mr. Occam would object. The children may not be “displaying” these inherited properties but that doesn’t mean they don’t “have” them from the Filter engine’s perspective.

I’m saying the explanation is wrong because that’s not how Legend actually works. I don’t know if the reality is simpler or more complicated, but it’s not that. Your 1-rule explanation is this:

Jerud - Therefore, ALL children we see in filtered Panes are – somehow – matching the filter. […]
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.

We can refer to the language used in the settings for “collapse matches”, which is what I’m basing my explanation on (plus my own confirmation through testing, and some things Jay said in the new filters thread):

Collapse matches of filters: Changing a pane’s filter will collapse matches that have no matching children. If not enabled, filters show all children of matches.

“Filters show all children of matches” - period - is exactly my point #1 above. Especially regarding why all children of matches are shown, I believe that’s a simpler explanation than that children take on or inherit the properties of their parents, and thus are displayed because they match a filter term like “is:star”, even when they’re not starred. No. It’s just that filters always show all children of matches, simple as that. Mr. Occam would be happy. Once an item matches, the filter just doesn’t pay any attention at all to its children’s properties when determining whether to show them, it just shows them (unless they match a '-term' negate term).

The “collapse matches” setting “will collapse matches that have no matching children”. This contradicts the assertion that ALL children we see in filtered Panes are – somehow – matching the filter. A starred parent with children that don’t have stars will be collapsed because it has no matching children. Those children don’t have or take on a starred property, and they are not matching the filter.

Just to be clear, we’ve been discussing two different things:

1. When an item matches a compound “and” filter because one of its ancestors has the other term (the main topic of this thread): in this case it’s not insanely unreasonable to picture the item “inheriting” all the properties of all its ancestors and thus making the item match the compound filter. Maybe it’s a helpful metaphor for you, but to me it seems like a bit of a convoluted way to think about it. Also, as Andrew points out, “inheriting a property” has a widely-known meaning in computer programming. In Legend, the matching item doesn’t have or contain all the properties of its ancestors. It’s just that a filter in Outline view traverses up and considers the entire branch, i.e. an item and its ancestors. I think that’s simpler than imagining that all the ancestors’ properties, including all their text, and mutually exclusive attributes or types, go into the final item, which is not really the case.
2. When an item matches a filter, in general (discussed in “Collapse matches of filters” not working as expected): “all children of matches” are shown, even if they don’t match. In this case, it’s simply false to say that the children all take on the properties of their parent, e.g. unstarred children take on an “is:star” property, and thus also match the filter. That’s specifically contradicted by the “no matching children” part of the “collapse matches” setting. If all children matched the filter, nothing would ever be collapsed.

It’s clearly incorrect in the second case to say that children take on or inherit the properties of their parents, and thus match the filter, since matches can have non-matching children. Given that, and also since it’s a somewhat dubious metaphor that could be confusing to anyone with a programming background in the first case, I think it would be better to refrain from explaining things to new (or old) users with that terminology.

So again, with a few more details… in Outline view:

1. Filters always show all children of matches, regardless of whether the children match or not. The exeption is if a child matches an additional negation term, it will be hidden. If none of its children match, and the “collapse matches” setting is on, the matching item will be collapsed.
2. Filters with multiple terms consider the entire branch of an item, including all of its ancestors up to but not including the item that is currently zoomed to, to determine a match. Once a match is determined, rule #1 applies.

That may be more complicated, and not so intuitive, but it’s actually the way Legend works, as opposed to simply that “items inherit all the properties of their ancestors when determining a filter match”. Legend can be complicated. That’s my final answer on that topic, it’s been an interesting discussion though, thanks.

andrew Jay wrote a short description of how the new filtering works back in November. It does use some language similar to what Jerud has said, for example: “An item is considered matched if its parent matches, unless it itself specifically does not match”, and “a parent is considered matched if any descendant matches”, though it doesn’t go so far as saying that the item considered matched actually inherits or receives the matching properties itself, which I have the greatest difficulty with.

But it’s contradicted by other language in the “collapse matches” setting. If an item is considered matched if its parent matches, there can’t be any parents with non-matching children to collapse - but there are. If a parent is considered matched because its descendant matches, and “filters show all children of matches”, we should see all its children - but we don’t.

There should be a distinction between an item that matches a filter, and one that’s shown or displayed anyway, despite not actually being matched, i.e., all the ancestors and descendants of a match. They’re different things, with different behaviours. I agree it would be helpful to have a consistent description, probably in the help document, so everyone can understand what behaviour to expect, and be on the same page regarding the meaning of this and other terms when discussing it.