Children items should "inherit" tags for search purposes

Comments

9 comments

  • Avatar
    Keith Wilson

    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!

    0
    Comment actions Permalink
  • Avatar
    Nathan

    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?

    0
    Comment actions Permalink
  • Avatar
    Keith Wilson

    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 :)

    0
    Comment actions Permalink
  • Avatar
    Nathan

    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.

    0
    Comment actions Permalink
  • Avatar
    Keith Wilson

    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!

    0
    Comment actions Permalink
  • Avatar
    Alfred Peters

    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

    0
    Comment actions Permalink
  • Avatar
    Alfred Peters

    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.

    0
    Comment actions Permalink
  • Avatar
    MAX LIN WORM

    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.

     

    1
    Comment actions Permalink
  • Avatar
    Jonas Dam

    I really like the idea of "parent:tag" and "Ancestor:tag"  - This would make Workflowy much more viable as a tool for stuff like Scrum, Kanban and GTD :-D  

    0
    Comment actions Permalink

Please sign in to leave a comment.