'Collapse matches of filters' not working as expected

wilhelmmedetz

I have three items with different priorities

A - priority Medium
	B - priority High
	C - no priority

When filtering for ‘High priority’ I get the expected result

A - priority Medium
	B - priority High

When filtering for ‘Medium priority’ I get

A - priority Medium
	B - priority High
	C - no priority

which in my opinion is wrong (or at least useless) and should be

A - priority Medium
	B - priority High

Bug-Priority: High

Jorge

wilhelmmedetz I think the reason you are getting that result is that it is showing your item A- Priority Medium and allits contents (regardless of priority) because you are visualizing it in outline mode. If you were to visualize it in LIst mode the no priority item should not appear.

wilhelmmedetz

Any chance to change this behavior (being a heavy Workflowy user all my lists use filtering as described above, Dynalist would filter the same way)?
Also thinking of mathematical set theory PriorityHigh OR PriorityLow should not include items with no priority.
In Workflowy (or Dynalist) I could collapse and the expand the item A to then see all child items.
The flat list view is no real alternative, as I want/need to see the items in their hierarchical context.

Jeff

I think wilhelmmedetz has a point. With “collapse matches” on, if you filter on the word “medium”, the result is collapsed, as expected:

But if you filter on medium priority, it isn’t:

But I don’t understand his expectation to see medium and high - it should just show medium, collapsed, because none of its children match that.

Jeff

wilhelmmedetz Also thinking of mathematical set theory PriorityHigh OR PriorityLow should not include items with no priority.

You didn’t mention trying to filter on PriorityHigh OR PriorityLow. Maybe an actual screenshot of what you’re trying to accomplish would help.

wilhelmmedetz

A filter for medium medium priority has the meaning any items with priority greater than medium.
The same problem would occur when filtering for ‘#priorityMedium or #priorityHigh’ in the following example:

A - #priorityMedium
	B - #priorityHigh
	C - no priority

Would also display item C.
Screenshot:

Jeff

wilhelmmedetz A filter for medium medium priority has the meaning any items with priority greater than medium.

Ok, I didn’t realize that, I thought it was only “medium”. I just tried using “pri:med” instead of clicking on the medium-priority button, and it does only show the “medium” item, collapsed, as expected. So I guess the button must in fact do “pri:med+”, i.e., “pri:med or pri:high”. And I just saw that the tooltip when you hover over the button says “Medium+”, so that’s correct.

Without “collapse matches”, when an item matches a filter, you see all of its children too, even if they don’t match. I think what’s happening in the screenshot is that both A and B match the filter. A is not collapsed, because at least one of its children matches the filter. So you see all of its children.

In other words, this isn’t a bug, it’s working as designed. I don’t disagree with your expectation to not see the “none” item, but that’s how Legend works at the moment.

andrew

wilhelmmedetz Like Legend, Workflowy also includes all children of any matching items, however it has a partially expanded state where it will expand an item only to reveal children that also match the search but not show any non-matching children. It uses a weird partially rotated expand/collapse icon to indicate it is partially expanded. If you click it will collapse, and the click it again it will fully expand to reveal the non-matching children.

I think this functionality may be what you are looking for?

wilhelmmedetz

andrew Yes, this would be the ‘ideal’ behavior for me. But I could also live with having to zoom in to see child items.

Jerud

I’m not sure I quite followed all the comments above, but just based on the original post, I’m saying this result is not a bug because it follows Legend’s standard rules of “inheritance” for children. For the purposes of matching filters, a child item takes on all properties of its parent that do not contradict a property it already has.

In the example, item C has no priority. So it “inherits” the medium priority of item A – it’s parent – and thus matches the filter. If it were pri=low, it would not inherit and would thus get filtered out by the medium filter.

This would not happen in a List Pane because flattening the Outline obviates inheritance.

This is how Legend has (I’m pretty sure) always worked, and it’s taken me years to come to grips with it. It somehow makes sense and yields intuitive results – right up until it doesn’t. And then my brain turns inside-out. But in the end when I work through it, I realize that the alternative – not “inheriting” properties – would have as many if not more negative effects. For example, getting a filtered Pane containing only parents, then you have to zoom – and clear the filter – just to view the children of one of them, then “back” (twice), then repeat to look at more children….I mean, where’s my pen and paper?

I think there are some cases where being able to keep Outline structure but disable this behavior can be useful and might work better for some folks. Some additional discussion about “inheritance” is at the following thread, as well as the idea of a setting to disable it:
https://forum.legendapp.com/d/377-inheriting-properties-for-filter-matching

I’m pretty sure disabling this globally would be a disaster, and I suspect that in most cases users can come up with a workaround in their structure/workflows to compensate. But disabling it per-pane could indeed be useful. Just not sure if it’s worth adding the complexity…

I build my Outlines so priorities never “stack” because they are particularly mess to filter when they overlap. Either the parents get priority or the subs do, but never both.

Jeff

Jerud it follows Legend’s standard rules of “inheritance” for children. For the purposes of matching filters, a child item takes on all properties of its parent that do not contradict a property it already has.

In the example, item C has no priority. So it “inherits” the medium priority of item A – it’s parent – and thus matches the filter. If it were pri=low, it would not inherit and would thus get filtered out by the medium filter.

I don’t think that’s correct at all. I don’t think children inherit properties like priority that way. It’s just that Legend simply shows all the children of any item that matches a filter. It doesn’t matter what they are, or what properties they have or don’t have. As I expected, a low-priority child is not filtered out by a “medium+” filter:

andrew

Jeff You’re right that it does not inherit the way @Jerud describes in that parent properties are not simply inherited when no item property is specified, but in outline view, when determining if a child matches, it does combine all properties of the parent (text AND properties like priority, star, type, etc.) with the properites of the child (i.e., the union of the properties, maybe properties are encoded in text and concatenated?), so in effect the child labeled “high” in your example has both pri:med and pri:high properties and will be considered to match pri:med as well as pri:high as well as pri:med pri:high.

Since pri:med+ is equivalent to pri:med or pri:high, all items will match on the pri:med term, including the children since the parent has pri:med, and thus be shown:

But if you add a negative filter to hide low priority, it will not show the low child even though the parent matches, because it does not match:

It could also approximate this by first showing all children of matches and then removing children that match negative filters. Also, the auto-expand/collapse seems to expand to reveal matching items and collapse matching items themselves unless a child’s property matches a filter term on its own. Just can’t tell these for sure without knowing the code. Maybe @Jay can chip in here to clear this all up!

Jeff

andrew when determining if a child matches, it does combine all properties of the parent (text AND properties like priority, star, type, etc.) with the properites of the child (i.e., the union of the properties, maybe properties are encoded in text and concatenated?), so in effect the child labeled “high” in your example has both pri:med and pri:high properties and will be considered to match pri:med as well as pri:high

I don’t think it’s as complicated as that. The rule is all the children of a matching item are displayed. Simple.

It’s not the same as the child actually matching the filter, combining properties, a union or inheritance of properties, or having both high and medium priority at the same time… I mean, I guess you could think of it that way (and maybe that’s actually how the code works) but it seems like over-thinking it for users.

It makes sense that if you add a term to specifically exclude something, that anything matching that will be hidden, even if it’s a child of a parent that matches the other terms.

Always showing all non-matching children of matching parents is often not what people want, as this example shows. And the “collapse matches” doesn’t really solve it very well. But always hiding non-matching items could be annoying if you want to see inside a matched item. It sounds like the approach of Workflowy and Dynalist is a good compromise - hide all non-matching children by default, but have a mode where you can individually expand a matching item to see all it’s children if you want to.

Jerud

No, in these examples, the low- and no- priority children are gaining the med-priority of their parent (yes, they are having BOTH priorities) and are thus matching filter. Try adding a -pri:low or a -pri:none and see what happens. My brain gets real turned around with priorities (because they have the ‘greater-than’ behavior) but I think you’ll see those children go away.

Jeff I don’t think children inherit properties like priority that way.

https://forum.legendapp.com/d/377-inheriting-properties-for-filter-matching/15

That is my best shot at talking through this. I am absolutely still wrestling to grasp filters and would never say I “know” how they work. I’m totally open to other ways of looking at it…but have not yet seen anything that disproves what I’m staying. Every filter result I’ve seen – crazy, nonsensical, and useful alike – can be explained by a single simple “inheritance” concept. I’m sorry that name is so troublesome with respect to other apps, concepts, backgrounds, etc. but I don’t know a better one. Jay has tried to explain this to me in the past, and I may be getting it wrong. Working through these threads has really forced me to think hard about this so I’m grateful for this discourse…and really looking forward to getting to the bottom of it.

I think we need to be sure we’re all on the same page with how it’s working NOW, before we talk about how to change it. None of my above should be taken as an argument about what “should” be happening or what users want/need.

Jerud

andrew it does not inherit the way @Jerud describes in that parent properties are not simply inherited when no item property is specified, but in outline view, when determining if a child matches, it does combine all properties of the parent (text AND properties like priority, star, type, etc.) with the properites of the child (i.e., the union of the properties, maybe properties are encoded in text and concatenated?), so in effect the child labeled “high” in your example has both pri:med and pri:high properties and will be considered to match pri:med as well as pri:high as well as pri:med pri:high.

Yes, this. The way I said it before made it sound like the inheritance was because the child had no priority, and although that’s not what I was really trying to say, it is indeed wrong and I hadn’t even considered that situation before. This discussion has forced me to spend a lot of time playing with filters and killing off some improper ideas I had.

wilhelmmedetz

Jerud Jeff andrew

I want to come back to my original point of this discussion.
To make things easier I would suggest to use tags instead of priorities (I think the same principles apply to tags as to priorities).
I did not try to switch from Workflowy to Legend because Legend always showed the children of matching items.
In January ‘Collapse matches of filters’ was introduced to Legend - so I had the hope that it now might work for my requirements.

I have set ‘Collapse matches of filters’ to true.

‘Collapse matches of filters’ currently is a global setting (maybe it could be switched to a search-specifi setting, but this would be another discussion).

I have would use the following example:

Unfiltered items:

a #t1 #t3
	b #t2
	c #t3
	d

Search: #t1

a #t1 #t3

Search: #t2

a #t1 #t3
	b #t2

Search: #t3
In this case band c should be hidden (for my understanding of ‘Collapse matches of filters’).

a #t1 #t3
	b #t2
	c #t3
	d

@Jay could you comment on this? What is the exact meaning of ‘Collapse matches of filters’? Could it be extended/changed to hide all non-matching children? Would it be possible/make sense to make ‘Collapse matches of filters’ a search-specific switch?

Jerud

wilhelmmedetz I want to come back to my original point of this discussion.

Good Idea.

It seems to me we are mixing up two completely different behaviors. As usual, part of the problem is we don’t have a standard vocabulary for discussing some of these finer points. So my choices below may not be agreeable to everybody but I’ll just specify the following for the purposes of my explanation:
Collapsing refers to whether or not a parent item is expanded to show its children
Show/Hide refers to whether an item is present at all in a Pane (as a result of matching a Filter)

That is, if there is just a single parent in your Pane and it has no “collapser” (the > to the left) then it is the only item shown in that Pane. But if there is a collapser and you can expand the parent to reveal three children, the pane actually contains all 4 of those items. There are 4 items shown. Whether you expand or collapse that parent, it doesn’t change the fact that all 4 of those items are “shown” – just which ones are “visible”. You can verify this by watching the pane stats, the small numbers at the very bottom of the Pane. “Filter” (items matching filter aka “shown”) will stay the same as you toggle the collapser but “Visible” (items you can actually see on the screen) will change.

All that preamble is to say: The “problem” you describe is worded as if it’s an issue with which items are shown – which ones match the filter. But the setting you’re referring to (Collapse matches of filters) has nothing to do with which items are shown. It ONLY controls how Legend automatically expands (or doesn’t) parents in the pane.

Now, the confusing bit is about when this setting works, because it implies that a child can match a Filter either by combining its own properties with that of its parent, or by considering only the child’s properties. This setting is the only place I’m aware of in Legend that even mentions that difference, and it’s clear there are several improvements that need to be made around communicating and describing it. But the short story is: the specific behavior originally described in this thread is as-expected and is therefore not a bug.

It sounds like you – and at least a few vocal others – want a way to specify if children will match a Filter only based on their own properties or if the properties of their parents should factor in. I may actually agree with that, myself. But that would be best treated as a Feature Request because the current behavior is, in fact, as-intended and entirely usable if not preferred by many. I’m sure it will get a ton of discussion if you post up a request. I am not going to move this thread into the Feature Requests area because it’s already a confusing discussion and starting it out with an existing thread will make it worse.

Jeff

wilhelmmedetz In your “search: #t3” example, I assume you mean “b and d should be hidden”, not “b and c”, correct?

In Outline view, all ancestors and descendants of a matching item are displayed, with the exception of descendants that match an exclude filter term.

Again, it’s a little difficult when you don’t show actual screenshots, but: in your “search: #t1”, the children ‘b’, ‘c’, and ‘d’, aren’t hidden. Rather, ‘a’ is collapsed, when you have the “collapse matches” setting on. There’s an important difference. You can click on the collapse/expand triangle to the left of ‘a’, and you’ll see the children. The “collapse matches” setting never hides anything. It only collapses an item that matches the filter, when none of its descendants match. In the “search: #t3” example, ‘c’ matches, so ‘a’ is not collapsed, and you see all of its descendants, as expected.

I understand what you want it to do - hide ‘b’ and ‘d’ - but that’s not what “collapse matches” is meant to do. It’s not broken or malfunctioning, that’s the way it works. I agree that it would be useful if you could do what you want, but at the moment, you can’t. It’s not supported by Legend.

Jeff

I posted the above before I read Jerud’s comment, so I’m responding to it here:

Jerud Now, the confusing bit is about when this setting works, because it implies that a child can match a Filter either by combining its own properties with that of its parent, or by considering only the child’s properties. […] It sounds like you – and at least a few vocal others – want a way to specify if children will match a Filter only based on their own properties or if the properties of their parents should factor in.

Just pointing out that wilhelmmedetz simplified his latest example, so that it has nothing to do with items matching a compound “and” filter when their ancestor has one of the terms, and they have the other. I don’t believe he’s asking for a way to not consider ancestors’ properties in matching such a filter. His concern is only that all descendants of a matching item are shown, even when they don’t match the filter terms. He’d like the non-matching descendants to be individually hidden, which “collapse matches” isn’t designed to do.

I think it’s a reasonable feature request. The question would be how to implement it in the user interface. It sounds like Workflowy has a method that works, but there might be some other method too, though I don’t have any other suggestions at the moment…

Jerud

Jeff I generally agree with everything you’ve said in the last two posts. However, I think the following needs to be clarified:

Jeff His concern is only that all descendants of a matching item are shown, even when they don’t match the filter terms.

This is not explicitly true, but practically speaking, it does seem like it much of the time.
I have already showed that a Filter which only matches some children will only result in those children showing.
This is easy to see, no compound terms required. Just filter for text that is unique to a single child (and none of its ancestors). You’ll just get that one child under the parent.
The trouble is that very often, children are matching because of their parents’ properties, which is not made super clear. This will naturally scoop up all children together (unless, as you have pointed out, some of them are specifically filtered against by an additional term).

So, I agree that Legend would benefit from an option (per-Pane) to “strictly” match Filters using only the properties of the individual items; no “inheriting”. By making that an explicit option it would clarify the alternative, and give a choice to those users who specifically need to disable that. Note this would only be relevant in Outline Panes.

BUT, I think that option will end up being more restrictive than many are imagining, and we’ll see complaints the opposite direction – that expected items are being excluded. For example: when you #tag a parent rather than having to individually apply that tag to every single child…“strict matching” for that #tag will return just that parent. I do think that’s what some of y’all want – but I also think for many it’ll turn into “oh, I want it to act this way here but a different way there…”. Legend isn’t going to be able to read minds – either your Outline is structured to work with one approach, or it’s built for the other. This is the burden Legend places on users and is the nature of such an open-ended and versatile tool. Legend does what you tell it to…whether that’s a good idea or not 😅

It’s also, of course, a big liability and why Templates and Guides will be so important. I have started pulling together a framework for that…but it’s real big job, y’all. My priority is helping with bugs right now. One hurdle at a time…