Winston

Explain the problem as you see it

Sometimes, working with 'advanced features' may not be that sophisticated if we can make it understandable. In many 'no code' editors, we're increasingly seeing them adopt visual builders.

Some sophisticated stuff in Tana that take a while to get, and to get right - even for seasoned users like myself:

• Building queries - AND/OR/search expressions/etc can get confusing
• Building command workflows or AI workflows

Don't get me wrong, the live search controls/commands and all have received significant work and are great. I'm just wondering whether there's something even better as an option for people.

Why is this a problem for you?

I was just talking to a friend about how to use commands and search queries and needless to say it really turned her off - looking at it from her pov - If I were a no-code person, just looking at 'code like' stuff just makes it seem like an unsurmountable wall.

I feel like these things are not 'difficult to get', it is just that the interface has to allow people to understand it much more easily.

Suggest a solution

They say one image speaks a thousand words - a graphical interface would make this much, much easier. Take inspiration from these examples:

https://github.com/DeabLabs/cannoli

===

I'm also thinking of multiple-agents in AI

===

These are all still compatible with nodes in Tana. Just throwing some ideas out. :)

Explain the problem as you see it

The Inbox can get very flooded over time because of the one-way traffic. It becomes very boggy and difficult to process. Often, I find myself thinking that if I had the choice, I would be able to sort it immediately on capture, instead of having to do it twice in a row.

The current method would be:

• Capture a link by Share menu on mobile, or a web-capture equivalent via the API
• With some modifications, we can add a supertag to the inserted link (but the official capture app does not provide this too)
• The link is left inside the Inbox (and usually it's unprocessed, meaning that it becomes a clickable link with a URL field, but it does not automatically convert into a website title with opengraph details, or embed if it is a youtube video).

Why is this a problem for you?

1. The inbox becomes very heavy to process over time.
2. Wasted time, because when we can process it up-front (at the time of capture), we are forced to shift the time of processing (i.e. shifting nodes around, tagging, etc) to when we actually go through the Inbox. Also, we may forget the context in which it was captured by the time we process it.

Suggest a solution

Here's how the Chrome extension for Notion works - They allow you to directly send links and resources into pre-created databases (synonymous with Tana's live searches):

I propose:

• Allowing us to supertag links shared via Share Menu, or any other captured method (or if there is an official capture extension on chrome, to do this too)
• If tagged, to directly capture to the day node that it was captured, instead of hogging up the inbox.
• Still allowing us to capture to Inbox if unsorted.

How is this useful?

• If we have certain projects within Tana, we can directly send resources that we think is useful directly to the project, instead of having to process it along with other resources of other projects. It becomes double triaging.
• We can sort things according to their nature - Notes, thoughts, voicenotes, twitter links, comments, etc

Explain the problem as you see it

I need a way for Tana to manipulate my attention. Currently, it has **zero **ways of providing feedback on my attention.

For example, I'd love for Tana to notify me when a criteria is met: Some examples:

• Notification of deadlines: For example, system date/time matches the date/time field - as a notification that a time has been reached. This is useful for task completion, deadlines, approaching deadlines, spaced repetition...

• Providing alerts of a word count being reached

• In future, providing alerts about a duplicate node being created

• Notifying collaborating members of new changes or mentions

• Triggering certain reminders /prompts when editing in a particular supertagged node

• Reminding the user to complete mandatory fields / checkboxes that are left incomplete when the node is collapsed

• Announcements to corroborators

• A new update is available, or downtime messages of the system

Borrowing inspiration from programmable attention from Andy Matuschak, and also the fact that nearly every social media platform uses notifications as a way of directing attention intentionally throughout their app/site. I think it's an important feedback mechanism.

Why is this a problem for you?

I often get absorbed into my work to the point that I lose track of time and get side-tracked sometimes... and sure I may use an external program or clock to try and do that. But if Tana is gunning for an "everything OS" then it should prevent contextual switching by helping to direct attention in intentional and user-engineered ways. I think that it is a meta-level way of helping to intentionalise our work and helping to corroborate with others.

Suggest a solution

Tana could have another button in its sidebar for 'notifications', and have the 'toast message' popup like it is using for AI notifications already. I'm sure a better implementation can be made.

Explain the problem as you see it

Build title still feels very primitive and definitely can improve further.

We also have lesser known techniques of displaying fields like ${X|..} or ${X|?}.
I'd love to be able to have non-fields be optional and dependent on whether fields are there.
I'd also love to be able to edit field content "in-situ" within the built title.

Why is this a problem for you?

For example, sometimes I like to wrap my field content with brackets "( )". However, given that we cannot control the optionality of these characters, they tend to just appear as empty floating characters - e.g. "node title ()" (built from ${name} (${optional field|?}). Sometimes I also use other characters like "->" or ":".

Another frustrating thing is that when I change the name of a field, it does not automatically change the text (understandably so).

It's a problem because as the size of the database increases, it becomes more difficult to maintain. These things will help to 'plug the gap' and ensure a less buggy experience for users.

Suggest a solution

I would like to propose:
1) something similar to the Live Search filters, where we can copy and paste fields directly.
2) some documentation or guided help or workflows/inspirations/use cases for people to build titles properly.
3) the ability to edit field data within the title, and not always requiring to place ${name} at the beginning of the built title which is pretty restrictive

Explain the problem as you see it

Sometimes I have really long texts / notes/ essays that span almost 14 batches that need to be sent... In such cases, I get a flood of these messages:

Followed by:

Why is this a problem for you?

It becomes a problem because the remaining batches that are not able to be processed are literally "lost information". There is a doubling of the delay before retrying which works, but when 10 other prompts are being sent simultaneously, eventually it will hit the maximum number of retries and a lot of the batch will become lost.

Another issue is when I'm running multiple AI generations for different nodes. They end up competing against each other.

So for both "batch prompt processing" and "multiple generations", having too many simultaneous connections end up leading to stopping of the generation.

Suggest a solution

It would be really nice to be able to set a maximum number of simultaneous queries to the openAI API, and be able to then 'queue' it. Having a queue somewhere which is viewable would also be really cool.

Explain the problem as you see it

Currently, we only have one output from running one prompt. This means if we want to fill up multiple fields, we need to use multiple prompt:field pairs.

Why is this a problem for you?

This adds up to a lot of set up time, difficulty in editing these prompts later, etc. It also makes it difficult to combine these multiple field inputs with an external API or code, or perhaps another prompt. It would also save costs.

Suggest a solution

I suggest using function calling that openai has enabled. This means being able to specify a function name and description, and then allowing it to output the values of multiple variables. I also suggest that we are able to map these variables to fields.

Explain the problem as you see it

At the moment, it looks like this:

Why is this a problem for you?

It's so convoluted and I can't see the time at a glance.

Suggest a solution

I suggest making it cleaner. If the date is "today", then the time listed on that day should just reflect the time, instead of adding the date as well. In the example above, it would just reflect "21:31 -> 22:41" or be able to customise it to "9:31pm -> 9.41pm"

Explain the problem as you see it

There is a challenge of tracking down the origins of nodes especially when filling out fields of parents, instead of nesting them directly under the parent. Tana currently lacks the ability to add nodes as contextual content within fields, and due to this, we lose a lot of that power of contextual notes that Tana offers.

I usually start by referencing a node (ie. 'altered consciousness') like so:

I then decide to want to add some notes from the Fish textbook into the referenced node like so:

What happens above is that I am just editing the node, but I am unable to leave a breadcrumb (i.e. in future, I will not be able to know where this particular information is living and coming from at a glance). This behaves differently from when I nest it directly as a contextual note.

If I nest the node directly, I hit ctrl-shift-down and it creates that zig-zag line, indicating contextual note created, like so:

After doing this, this way shows me the breadcrumbs (to Fish's Clinical Psychopathology):

Therefore, it works with nesting children, but not with nesting children inside fields.

Why is this a problem for you?

There's an inconsistency here, which is possible when I nest the node, but not possible when I want to nest the node within a field instead. The other issue that arises is that the breadcrumb of the attribution itself becomes lost.

If I use the conventional way of turning it into text, I am unable to insert it into the appropriate field and fit it into existing context, like so - here the text about frontal lobe dementia cannot be inserted directly into the pre-existing context.

Suggest a solution

I suggest that ctrl-shift-down allows us to select whether to:
(A) add into an existing field as a contextual node
(B) or nest as a child node under the parent as contextual content

Explain the problem as you see it

The current system requires a somewhat tedious and memory-dependent process to locate specific nodes in the system. I often struggle to remember the exact spelling of the nodes (or the exact wording) I want to reference. This makes using the @ command to search for nodes difficult at times, as it requires precise spelling to return results. For example, to locate a specific node from my wishlist, I need to search using #wishlist and sort the results by date created. This is a task I find myself repeating on the homepage numerous times.

Why is this a problem for you?

This issue slows me down sometimes. I have attempted multiple workarounds, such as creating a default wishlist search, so I can quickly retrieve it using @wishlist. However, this challenge is persistent across different nodes with different tags. Also, I've tried @#wishlist, which kind of works but it is not able to filter further, as it is quite randomly sorted, also it does not work when looking for particular child nodes under parent nodes that I can identify.

Suggest a solution

To address this issue, I propose the implementation of a Quick Search Command feature that allows users to find nodes quickly and efficiently, even if they do not remember the exact spelling. This could involve a command that allows me to make a fast search to narrow down the node. For instance, using natural language commands such as "Find node with #wishlist created last week" or "Find node tagged #chapter under parent node for #book". Or an alternative solution could be to refine the @ dropdown to make it easier to trawl through different filters.

This way, we can retrieve nodes in a more intuitive and efficient way, without needing to remember the precise spelling or where it is exactly located. It would streamline workflow and make for a more satisfying referencing experience.

Explain the problem as you see it

This one has to do with the logic in searches. It was raised as a point by a subreddit member who uses Roam, and argued that this particular logic is unable to be replicated in Tana:

Link to comment: https://www.reddit.com/r/TanaInc/comments/13qv8t0/comment/jlj03oh/?utm_source=share&utm_medium=web2x&context=3

So I tried it out.

In Roam, this is doeable as such:

In tana...

Why is this a problem for you?

Use-cases include:

1) Looking for something or a person mentioned in a project: Replace TERM-A with a project, TERM-B with something mentioned in the project
2) Looking for a node mentioned on a particular day

The advantage of this kind of query is that we can retrieve the actual node (not the parent node) where the logic conditions are fulfilled.

And I checked - yes, Roam can also handle deeper than 1-level-deep queries without fancy search operators. In this case it is two:

Suggest a solution

I suggest being able to have this type of cross-generational logic that would expand the capability of the Live Search much more. I'm sure many heavy users of the Live Search would agree.