Children items should "inherit" tags for search purposes
Say I have my Workflowy set up as below. When I search for "#todo #urgent", "Get flat tire replaced" should come up.
This behaviour seems natural and far more fluid than individual tagging everything "#todo" individually.
-Projects
-----Car repair
----------Tasks #todo
---------------Buff that tiny scratch out of the windshield
---------------Change cabin air filter
---------------Get flat tire replaced #urgent
----------Notes
----------References
-----Network overhaul
---------Tasks #todo
--------------Buy router
--------------Find better location for router
--------------etc
---------Notes
---------References
-
I can see where you're going with that idea. Though it would be weird for a search to return items that weren't tagged, that seems unnatural from my perspective because it limits your tagging abilities honestly. If I knew everything underneath a tag would be included in a tag, that would mean I would have to change entire structures of my lists. Because while an item with a tag has a tag, that doesn't mean the items below it are inherently tagged as well. It really depends on your structures honestly. For example I can have
- Email Bob #todo
-- He wrote back on 4/4/19
-- Project planner says it's a no go
As you can see in this instance I have a to do, but i would not want all my notes to come back and clutter up a #todo search. Because those are just notes, not actually something to do.
Other reasons for example: I create a bullet that is "to do" , not a tag #todo. Everything in the list is a to do item. From there I use tags to group and label specific things.
Though in my writing structure I have done similar with #todo, as well as my software development structure. So the usage of #todo is very different for me within my own workflowly.
It would be really hard to make it viable to have everything below a tag be returned. Because there could be literally 1,000,000 nested bullets below that tag. Your example shows only a few child bullets. But bigger structures could literally be in the 10's of thousands.
It's a fun idea! Just sharing a different perspective!
-
I appreciate the different perspective-- of course the beauty of workflowy is that everyone uses it in their own way, and I wouldn't advocate for a change if it forced users into a certain way of doing things and not the other way around.
However, I think we might have slightly different ideas of what exactly I'm suggesting. To clarify, I want to first point out something about your "Email Bob" example: if I type those bullets in and search for "#todo", all of the bullets will be returned-- the top bullet will be collapsed by default, so you aren't required to see the children, but if you expand it they're there (such is the beauty of Workflowy!). That seems right to me, and I wouldn't push for anything otherwise.
However, if I, as you described, make a top bullet "To do" and then have "Email Frank #urgent" as a sub-bullet, searching for "To do #urgent" will return no results. That's where I think the problem lies.
Maybe we wouldn't always want to match on parent text, which is why I propose limiting it to tags: if I specifically make the top bullet "#todo", then a sub-bullet "Email Frank #urgent" should be a match for the tags "#todo #urgent".
Does that still sound unreasonable?
-
Sounds like you're looking more for a change of the search functionality from an AND search or string search to an OR search option. In your:
Maybe we wouldn't always want to match on parent text, which is why I propose limiting it to tags: if I specifically make the top bullet "#todo", then a sub-bullet "Email Frank #urgent" should be a match for the tags "#todo #urgent".
That would require some interesting code logic to both find the bullet with the tag (which has a unique ID associated with it) and then also run that ID back up the query logic to find it's parent bullet ID. Depends a lot on how they structure their database. Could slow down search results dramatically :(
It would be confusing to me honestly. Not saying my way is right or wrong, to be clear. But it would be really weird to get the parent bullet returned in a search for a tag. I always associate down, not up, in my bullet structures and especially in my tagging. Parent - Child information. Allows me to use the focus aspect of clicking into a bullet and focusing on that and it's children, ignoring it's parent and the more general information above it. /shrug :)
-
Ah, I think we must still misunderstand each other-- maybe my approach is more far out than I thought, but I'm very much looking for an AND and associating more down than up-- the logic for the search #a #b would just involve matching any children of something tagged #a that contain #b and vice versa, in addition to anything with both #a and #b.
If I take a piece of uranium (which I tag with the property #radioactive), and I put it in a dumpster (which is tagged #trash because that's what it contains), that piece of uranium is radioactive trash and I should find it when I search for things with the property #radioactive #trash.
If that doesn't make sense hopefully someone else can jump in and help bridge the gap.
-
I get what you're saying. I do believe we use workflowy fundamentally differently. Following your uranium example. I wouldn't use tags for that, it would just be the bullets themselves, no need for me to use tags at all.
Much like naming conventions in science.
A dog is a canine, but not all canines are dogs.
Using that structure I would search for the node in question and not want unrelated items showing in the search results as well.
The wonders of the human brain :) we all think and organize information differently :) That's what makes the world interesting and fun!
-
Yeah, I almost hate to say it but this is *literally* one of the main problems that transclusion could solve easily.
Also, one thing I've thought about is having different types of tags. We've got a bevy of symbols we can use in the number row after all. :)
What if we had an inheritable tag tied to ~ or something like that? Then you could have the best of both worlds.
Search "~trash #radioactive" returns
- ~trash
..... - #radioactive -
I think, fundamentally, we're being forced to use tags as a way to structure our data because of the limitations of WF. Tags should be ways to add "meta data" to bullets. Snippets of information that help you determine what workflow to use, how the bullet should look, and help for searches. However, asking tags to restructure the entire document on the fly is asking a bit much. :/ A transcluded bullet could easily have the relevant bullets pulled under it from entirely separate parts of the document. This reduces a massive amount of clutter without forcing WF to use processing heavy searching.
-
Could be done with a different search operator. Dynalist uses parent:tag or keyword or ancestor:tag or keyword.
Its very useful for kanban style outlines. This way you don't have to tag each and every task, for example, with the status tag.
Example:
Project 1
- Done
-- Task 1
- Doing
--Task 2
-- Task 3
-Next up
-- Task 4
-- Task 5
Project 2
- Done
- Doing
--Task 6
- Next up
-- Task 7
This way if I wanted to filter all the tasks I'm doing I'd just search for "parent:doing", without having to individually tag tasks 2,3 an 6 with the #Doing tag.
-
It's not really about restructuring. It's about having a view that simply does not hide the leaves if you're searching on a tag with a term. You search the trees for terms that support AND relationships along single terminable paths in that tree. Then you just keep track of the tagged matches and expand all nodes beneath the tag matches.
You can implement this easily as a special type of tag (please not that long one with a designation. Just a simple literal tag for nested, all subchildren would be handy no matter what) or a filter view on search results. Or provide both to still preserve the original searches for purposes that help with that.
This changes how results are built, but it shouldn't change the fundamental trees.
Is the concern performance? That should be rather easy to calculate.
-
I agree that having a way to drill-down with tags would be extra useful. I think a "simple" way to do this could be to allow clicking on a tag to go to a new view without "searching" for it, similar to the current functionality of clicking on a bullet. For example:
If I click on a bullet, a new view comes up with only that bullet and its children. I can search for tags while in that view, and only the results within that bullet show up.
Currently, if I click on a tag, it seems to go to a new view but the search bar is populated with the tag. Perhaps instead, by clicking on the tag, we could be taken to the new view but without the search bar being populated. Then from this view, we could use the search functionality like the current functionality with bullets.
-
I want this feature. If I make a node of #todiscuss, and put todo tasks under it, I want them to show up when I search for "is:todo and #todiscuss" without having to remember to individually tag every item under the #todiscuss node.
This whole debate can be solved with a toggle: Inherit tags on, or inherit tags off and then everyone can have the flavor of cake they want.
-
It does look nifty, but to me at least, it seems that everything in Tana needs to be tagged or will automate a tag (depending on the context) to be able to become part of their knowledge graph. It doesn't lend itself to minimalism. I try to have as few tags as possible... whereas tags are king in Tana.
> This whole debate can be solved with a toggle: Inherit tags on, or inherit tags off and then everyone can have the flavor of cake they want.
Anything can be solved with a toggle, true. However, there is very little in the way of requests from users in general for this kind of feature. Also, it's not a small project. We have quite the list of features where many users are clamoring for. We also have this proposed feature on our list... but from what I can tell, there are many other features that will make it ahead of this particular one.
-
Tags are why I came to Workflowy in the first place!
BTW, I've bought both your books, and your screencast package, Frank. So I'm invested. But maybe it's not a good fit. I'm building a work-management system now in Workflowy, and also in a few others, in a sort of Tournament Bracket.
-
Sure, you can use as many tags as you want in WorkFlowy. I'm neither for nor against the use of many tags in WorkFlowy. I'm just pointing out what seems to be a core dynamic in Tana. It is interesting. Also, I do not impact the team's decision to build a certain feature or not. I log it for them. What I can tell you, independently of what the team might think of inherited tags, it's not a feature they would build sooner rather than later, judging by the projects the team does have lined up and what they've been talking about.
-
Thank you. Frank, I understand there is no public roadmap, but is there any way we can at least see a list of things, in order, that ARE being worked on? Because wasting time building a (hopefully) time-saving system in a bunch of apps to see which works best is not the best way to be efficient with time!
-
-
https://blog.workflowy.com/new-feature-nested-searches/
Excited to see how it turned out.
Please sign in to leave a comment.
Comments
19 comments