|
It goes without saying that any filtering should work on the current sub tree (which may be the whole tree then of course, if the current item is the source item), because filtering is about de-cluttering, whilst otherwise (whole tree is filtered), there is, in most cases, enormous clutter before and after the filtered data you're after.
("you" being the user here)
Currently in UR, you can avoid that indeed, but the proceeds to get there have to be qualified as crazy.
Let's say you have a "bold" flag for the title items (=headings of sub-trees) of the first 2 or 3 indent levels of your tree, you want to filter one project sub tree, with its heading on tree level 1, and you want to see some special flags on project levels 1 and 2.
Now you first replace the bold title flags in your project (sub tree) by bold-scarlet title flags, then you simply filter out all bold (but regular black) title flags: Done... but in your project, you will need to maintain the new formatting for your headings, and that's not very intuitive it seems.
As for the de-clutter aim of filtering, I should perhaps explain HOW that is deemed to work, since many developers don't seem to see it must de-clutter, the above-mentioned competitor e.g., and as said, clutters the "filtered" view by all the "necessary" in-betweens, in order to also maintain the tree's graphics aspect = indentation; on the other hand, I must admit that over there, you would not use the (more or less useless then) "filter view" but the (correctly working) "search", as filter.
But I wanted to explain.
Let's have a project sub tree, with, on its level 1, 20 or 30 headings, and on its level 2, about 150 headings, distributed among the 20 or 30 level-1 headings, i.e. each of those bearing something between 5 and 30 level-2 headings.
Now, how much of those headings will you (HAVE TO!!!) preserve? In today's UR, all 170 or 180, all those of level 1, and all those of level 2; otherwise, you'll risk filter orphans (and, of course, not even speaking of possible special flags in project level 3 or below (i.e. above, numerically); or then, you pack all your level 2 headings into level 1:
instead of
1 - this
with 2 - that
1 - another one
you'd do
1 - this
1 - this - that
1 - another one
etc
which means you will have so much of clutter that "filtering" might not even make much sense anymore; of course, both solutions, since both will display 180 titling infos (30 plus 150, or 180 in just one level, doesn't matter) for your special flag items (which you're after, after all, your titling isn't but to "situate" them!), will give very good "situational" info for your specially-flagged items...
but that, your tree does it already, and filtering is about just seeing as much meta info as you WANT to get, for your current task, and here comes real filtering into play:
In the tree, you have precise locations for what you're after: 180 different ones, it's as fine-grained as you need it sometimes.
But to get an overview, you would NOT want this, you would just want all of your specially-flagged items indeed (and of ALL indentation levels that is, not only of project level 1 or 2), but situated into the above-mentioned 20, 30 "tree geographics" delimiters of project level 1, and then, it's not hundreds of meta info items anymore, with just some of the real info you're after, but it'll be dozens of - all the! - real info items, with just the amount of meta info you need, i.e. 20 or 30 "super groups" (but everything in correct tree order), and from there, whenever necessary, you switch back to the tree, in order to "situate" your special items even further, more "locally", or for whatever other reason.
Thus, it's also clear as day that (correctly ordered) filtering in the search pane is preferable, since then you can switch forth and back without having to use a visual toggle which will hide you one of the two views at every given moment, be it the one or the other then.
|