• General
  • Inheriting properties for filter matching

andrew well, I’m glad that at least I’m not the only one.

AFAIK the only recourse you and I have is to configure the Pane as a LIST type. For some of my needs this is appropriate – even desirable. LISTs are great for serializing work – I can only do one thing at a time so naturally I must know which to do first, then next, then next.

However as the Outline grows it’s too easy to lose context of individual tasks that may be 3+ levels deep. I sometimes create extremely granular tasklists for work that is very detailed, and that loss of context is hard to work around. Breadcrumbs would help, but they only show up in certain Panetypes…and never the ones I want. I wish breadcrumb display were a Pane Configuration option and not just baked-in to certain types.

If Legend were able to differentiate between inherited and autocthonous matches we could then have a button to ignore inheritance in chosen Panes, and it would also provide the mechanism to drive sensible auto-expanding of filter results, too – mentioned in my comment here.

I have long wanted explicit control over whether any given Pane uses inheritance or only same-item matching. I’ve been hoping that if I just understood the way Legend works I could find a way to get these results out of it but have never made any progress.

a month later

@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 did you ever figure out a solution?

    Using a tag instead of a star to flag email items is the only reasonable option I’ve found. Not as slick as being able to star emails and then filter on is:star is:email though.

    I think my use of the term inheritance in this case may not be quite accurate because apparently the filter doesn’t consider a child of a matching item to also be a matching item, since the child item is hidden under the collapsed parent unless the child itself is required to match the filter. If the child inherited parent properties, it would always be considered a match. Instead, there seems to be some other method that is used to consider visible parent properties when a child’s properties match part of the filter in outline view. Not saying something different from what you are, but I didn’t want to confuse others by calling it inheritance.

    To avoid the situation you describe, I usually don’t filter on one type and zoom by the same type. I usually filter on one type (eg, the items I am looking to work with directly, such as tasks) and zoom on parents of those items (eg, typically headings or projects).

    Odd effect of this issue with completed items: try turning off the “hide complete” -is:complete filter so all completed items are shown. Complete a parent item and notice that all it’s children are grayed out even though they are not marked complete (I think this makes sense). Then zoom in on the item that was just completed and you see the children, in this case still grayed out, so for purposes of graying out, it is inheriting the parent’s completed status (even though the parent is zoomed), which makes sense to me. But now turn on the “show complete” is:complete and all the gray items disappear, because the child items themselves are not complete. Change it to “hide complete” -is:complete and all the gray items come back. This is very confusing! Not sure the solution in this case, it makes sense to me that the children actually inherit the parent’s complete status. Maybe completing a parent should auto-complete all its children, then you could treat completed status just like any other item property.

      andrew It’s so nice to hear someone else puzzling through filters, too. I’m not the only one!

      I don’t know of any “right” inheritance concepts, I’m shooting from the hip, here – but I’m pretty sure we’re talking about the same set of behaviors. My understanding of it is: Items pass/fail filter criteria based on their own properties (e.g. star, complete, priority) PLUS the properties of their entire chain of ancestors.

      But this is true ONLY for the portion of the Outline that is visible in the Pane content area. So if you zoom into a parent (it is not displayed), its children will suddenly stop inheriting those properties. This is why your tip to avoid filtering a Pane on something you might want to zoom with is a good one (need to add that to the User Guide!).

      With ‘complete’ it gets real weird because as you point out there is a visual change to those children which is done regardless of whether “inheritance” is in effect. Children under Parents that are complete do draw in a dim font, but they don’t get the grey “priority” bar of a truly complete item, and if they’re a Task there is no checkbox in their prefix. However, when you zoom into their parent – even though they are no longer “inheriting” that complete-status and will in fact behave exactly the opposite way now – they still draw in dim font. YES, CONFUSING. You don’t see a priority-bar (or star, or any other property) applied to children that are inheriting it from their parent – regardless of the zoom settings. Complete status should be the same, for consistency and clarity.

      I worked around my “zooming into empty headings” problem by following your rule and changing the Pane to Group-By Heading without a filter. It actually seems to be a better approach for some other reasons, too (thanks!). I’m only just now learning how to use GB Panes effectively…in the past I’ve sure used them…but not well. 😆

        Jerud I don’t know of any “right” inheritance concepts

        I was trying to make the point that I shouldn’t have used the term “inheriting” or “inheritance” because inheritance is a concept in object-oriented programming that doesn’t exactly apply to the way Legend seems to treat item properties when applying filters, and I didn’t want to create more confusion by misapplying the term. For example, the “grayed out” property is actually the only thing that is truly inherited, while the complete property is not, even though an item’s completed parent may satisfy an is:complete term in a filter that also has another term that matches the item. Not a big deal though, just didn’t want to mislead.

        btw, in addition to zoom causing parents’ properties to not be factored into filtering, this happens with list views as well. While I think the parents’ properties being factored in to filter matching is more confusing than it is worth, I do think it needs to be consistent regardless of the view.

          andrew oh, okay yeah I don’t know anything about programming so didn’t realize there was a terminology minefield. I agree it’d be better if we used a unique term when discussing filter behaviors. Terminology, actually, is one thing I think that we’d all benefit from standardizing on, and one of the first things that I’d like to see in a user guide. It’d make these conversations a little clearer!

          I think I understand why you say “greyed out” (independent from “complete”) is the only actually inherited property and based on that I think we’d both agree that nothing in Legend should be “actually inherited”.

          I go back and forth on these behaviors (depending on what I’m trying to make Legend do at the time 😅), but I think I favor the current method (so long as it’s fixed to be consistent). It’s a simple approach to making sure children appear with their parents appropriately – I have no use for a filter that shows me a matching parent, but hides its children. In simple cases the behavior feels intuitive enough that it doesn’t need explanation – but if you start trying ‘fancier’ Panes it needs to be spelled out. Right now my main beef is with the zoom ‘exception.’ I think there are good arguments for keeping that and also for not having it, and making it explicitly a setting/option (per-Pane) is one of the best ways to clarify, without ‘explaining’, that aspect of filter-matching is there in the first place and how it works.

          I haven’t noticed anything unintuitive with List Panes, but don’t use them extensively. They seem to act as expected where I do. Are you saying children match filters using their parents’ properties even in List Panes?

            Jerud Are you saying children match filters using their parents’ properties even in List Panes?

            No, in List view, an item has to match the entire filter solely based on its own text/properties in order to be shown. So you may apply a filter in Outline view and see matching items, then switch to List view and see fewer or none at all.

              andrew OK, that’s what I thought. To me, using a List Pane is equivalent to “turning off inheritance”. I used to think that needed to be a button, but I realize now it only really makes sense in a flattened structure so I’m cool with it. Showing “inherited” matches in a List Pane would be very hard to grok, I think.

              I re-read your original question and thought I would try responding to that better.
              I see how the behavior you describe is disappointing you, but it is definitely consistent with how properties pass to children across the board in Legend (except the grey/complete display detail we’ve discussed).

              My gut response on rereading was: “if an email-under-a-starred-parent isn’t the same as an email-with-a-star, you should be using something besides a star on those parents”. I know that’s a jerky thing to say, but I’ve had to overhaul my own plans plenty of times because Legend just didn’t do what I was trying to make it do. Sounds like you may be there now. Stars in particular have that connection to email which makes them problematic if you’re using them on anything besides emails – unless you just don’t have any email attachments in your Outline.

              Another approach would be to have personal ‘rules’ about what “level” you apply certain properties at. One of my rules is that priority can only be applied to Tasks. That can help with problems like this, too – but can easily be a huge pain in the neck, too.

              It does seem like adding an option such as “exact matches only” – the same button that we already have for GB-tags panes – would open up more flexibility here because then you could specify when you want to only see items that match according to their own, self-contained properties. You can do this with a List Pane - you just lose your Outline structure in the process. So an option like that would let you keep the Outline but use the more strict matching. Parents would only be displayed if they themselves match the filter, or are required to reveal matching children.

              That’s an easy ask, but maybe it introduces problems we haven’t thought of.

              I think “inheritance” isn’t an accurate term for what’s going on in Legend, and will be confusing to everyone if it starts getting using it in the forum. Children don’t inherit properites, like priority etc., of their parents. What happens is a combination of two behaviours, in outline view:

              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 have the other. Again this is not the same thing as the children inheriting properties.

              I agree with Andrew’s comment here:

              andrew I think my use of the term inheritance in this case may not be quite accurate because apparently the filter doesn’t consider a child of a matching item to also be a matching item, since the child item is hidden under the collapsed parent unless the child itself is required to match the filter. If the child inherited parent properties, it would always be considered a match. Instead, there seems to be some other method that is used to consider visible parent properties when a child’s properties match part of the filter in outline view. Not saying something different from what you are, but I didn’t want to confuse others by calling it inheritance.

              Most of the other comments above are still vadlid though. I’m one of those people who find filters in outline view bewildering, and not at all what I expect, and yes, that’s why I don’t often use them. The “collapse matches” setting helps a little, but it’s all still just weird. It took me a very long time to learn that I should use List view to get something more like what I was looking for - just show me all the items that match the filter, and not any that don’t. I haven’t had the time to think through how it should work though.

                “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.

                1. Put a star on parent - All 4 items display, even though parent is the only one that directly matches.
                2. 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:

                1. For the test items above, set all to no-star. No filter. All are shown.
                2. Then make parent a bullet and add bullet (blue) to the filter: No change.
                3. Now make B a Task. Still, no change - B has “both” prefixes right now, which means it matches the bullet filter.
                4. 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.
                5. 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.

                • Jeff replied to this.

                  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!

                    • Jeff replied to this.

                      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.

                      Regardless of what algorithm is used (and it could be one of those discussed here or very possibly another approach that ends up with the same results), I do agree it would be helpful to have a detailed description from @Jay of how he intends for it to work (both the outline/list filtering and outline auto expand/collapse) from the user’s perspective so that we can provide feedback on functionality and language as well as help identify bugs.

                      • Jeff replied to this.

                        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.

                          Jeff Thanks, I either didn’t see that post or forgot about it 🙂 but it is helpful to revisit that. And yes it should be fleshed out more and put in a more visible place than buried in a big thread.

                          I like the way the matching and the auto-expand/collapse actually works now, with a couple caveats being (1) it would be nice to have partial expansion like Workflowy and Dynalist, and (2) it’s weird and inconsistent that different items match the filter depending on your zoom level or if you are in List view rather than Outline view so it would nice to have some control over this whether through settings or filter language. But I agree that the language that describes what is considered “matching” and what is collapsed needs to be made more consistent.

                            andrew I agree that changes in zoom should not impact filter matches. I see why it does…but don’t see how that behavior is expected, intuitive, or useful. 2 reasons:

                            1. If the leaves of your tree disappear exactly when you’re going in for a closer look…that’s pretty enraging.
                            2. You could conceivably build a filter that only showed items while zoomed into a parent which did not itself match the filter. Then when you zoomed out, you’d get a blank screen. That makes no sense.

                            Could you please describe “partial expansion” from Dynalist / Workflowy?

                              andrew Thanks for that!

                              I’m beginning to believe that no amount of pure explanation or ingenious metaphor can really do the job of making Filters an accessible tool – not by itself. Adding things to Legend that “support” the way filters work – such as these “partial expansions” may be a key part of the solution.

                              I don’t love the half-turned ‘collapser’ idea. Easy to miss and not very specific. But better than nothing.

                              You know how the words that match a Find are highlighted in yellow to help spot them? I wonder if a similar visualization could work with Filters to indicate the exact items which are matching a filter. Would also be just plain useful for troubleshooting, too. Default it on, but able to toggle off. Could be done many ways – ideally something elegant enough that it could be left on while working and not be in the way. The right margin seems to have enough space for this.

                              Powered by: FreeFlarum.
                              (remove this footer)