Explain the problem as you see it
One common pattern from daily outliners is to create an event with inline references and simply add tasks underneath:
Example:
- Meet with @Dhara
- Work on presentation #todo
We can do this in Tana of course, but if we then need to set up a search node for all #todo which descend from a node with a reference to @Dhara we can’t.
Why is this a problem for you?
This is often the easiest way to introduce relationships in an outliner, simple hierarchy
At the moment to avoid this simple query limitation I have to do work around a like add a “Person” field in my node.
Suggest a solution
Simply open up search queries to allow Descendants of @Dhara (Ie descendants of inline references)
6 Comments
Should this idea merge with this one:
https://ideas.tana.inc/posts/24-search-based-on-parent-field-value
My use case is closer to the one described in this Idea, but I think the functionality is similar.
This is the single biggest point of friction stopping me from using Tana regularly at this point. The beauty of Roam is that it there is no resistance on my part to jotting down thoughts in a Daily Note and figuring out exactly what they are later. This works because I can highlight some word or add some tags (both just pages in Roam) and then indent and take a bunch of notes and know that I can always find them later, as the indentation itself serves as a very simple relationship.
The complexity (and enormous power) that Tana adds to this is that you can define particular entity types and fields, and use those as the means of searching and organizing. The biggest question in my mind is how to embrace that power without losing the ability to quickly capture things that are not yet defined. I think this suggestion goes a long way towards that end, but I'm sure that it's also just part of the larger question.
I don't have a specific feature suggestion for this, but ideally the best workflow would be able to quickly capture relationships in the way you can with Roam (without needing to specify entity types or fill in fields), and then have a way to iteratively define those relationships over time. Maybe a way to see when a reference doesn't have a supertag and easily add it without leaving the referencing node? I may add this as a separate feature request at some point, but I'm capturing it here for now as it's all related to the same problem.
Echoing @Sam Applebaum's sentiment here. I've come from Roam Research as well—my days are often full of meetings and context switching and I don't always have time to upcycle and structure my notes.
One of the things we use Tana for is to have confidence that we haven't missed any promises made to other people. For example, if I tell [[Rachel]] that I'll get back to her with meeting times, I like that I can run a query for all #tasks tagged with Rachel or her organization. For structured notes, e.g. #meeting, we can auto-populate a #task from the fields on #meeting. However, sometimes requests will come in by email, Slack DM, Whatsapp, etc while I'm doing something else.
In Roam, I'd simply be able to go
And whenever I'm next in comms with [[Rachel]], be able to query all TODOs associated with her.
However, in Tana, should I forget to populate the task field; this task would dissipate into the ether. While there's a workaround in that I can create a query for all #tasks that aren't associated with a person or an organization, this does give me a greater feeling of anxiety in general when using the system—that important tasks are slipping through the cracks!
Two things would solve this:
Arguably #2 creates a more robust data structure!
Adding on here...
The ability to filter References feels like a fundamental part of a linked outliner, but admittedly, that's probably because of my experience using tools like Roam / Logseq.
As the amount of information grows in a workspace, this becomes critical to finding information if you're using inline references. (The diagrams below hopefully show what I'm referring to.)
At the moment, it seems like even live searches can't narrow down this information (it has to be contained within the node, as opposed to indented underneath a reference to the node)
This is exactly what I am missing as well.
Is there any news if this will be included in the feature set? Or if there's some alternative potentially?