Winston's Comments
-
-
-
Ideas
- Formula Field
In reply to
Kelley Chambers
Kelley Chambers
Never. Stop. Learning.
Jun 15, 2023 While there are a lot of great things coming down the pike with AI, it's still not there. Very few know how to use it and a lot more are not comfortable with its existence. Formulas are an inherent co...Hugely agree with this. I hope some of the Tana team has played around with these formulas in Notion or Clickup so that they understand how powerful these "formulas" can be. It is one of the bedrocks of "Notion templates", and people sell these formulas. But if they are working on it, I'm pretty sure the Tana team can integrate it well enough.
For example, August Bradley's pretty famous Notion PPV framework relies on the bedrock of formulas. He's never going to try out Tana for real when Notion offers a much more efficient workflow, along with relational databases and 'bidirectional relationships' among databases.
The difference between AI and formulas:
- Formulas are free while AI costs a lot of tokens
- Formulas offer far more control over the output with more predictable results
- Formulas offer conditional loops (if/then, etc)
- Formulas offer mathematical operations crucial for manipulating numbers on spreadsheets
- Formulas are usually more "immediate" and do not require the clicking of a button to run - it's immediately reflected in realtime
I really like the AI thing going on, but sometimes the output can be quite unpredictable. Also, it's costly over time. And I'd love
-
-
Another use-case example - in this case I'm trying to pull in other nodes that have the same field values
-
Here is another example of a visual graph, but this time a data framework for LLM is implementing it - https://twitter.com/jerryjliu0/status/1667196226255884289
-
Agree. In an age where data and identify theft is prominent, E2EE is really increasingly important. Imagine someone having access to your journal which contains information someone else would never know - paves the way for socially engineered hacking methods. Furthermore, I have hesitated putting more sensitive information in Tana at the moment. I think this would be really crucial if Tana is thinking of onboarding corporations.
But then again E2EE is going to be difficult to implement.
-
Agree! This would add more dimension to the semantic fields if bidirectional fields are enabled
-
Do you use Windows? You can hit the Windows key + "period" button to open the native emoticon panel. You can do a search on it
-
-
Ideas
- Formula Field
I've been thinking about this - Tana still needs this function despite AI. AI might help but it's too overkill for simpler formulas like these. Besides, having formulas like if/then or concatenation would be far quicker if run natively by Tana
-
-
Ditto on this, it adds a lot of friction having to untag, edit then retag. Also editing fields in-situ would be a really cool implementation without needing to open up the node.
-
In reply to Deleted UserDeleted User
May 9, 2023 What about also adding these as views? The mind map screenshot really made me think that these could also be implemented as views for nodes and to act as kind of a local graph or mind map.It's difficult, because how would you represent this kind of graphic without knowing some form of 'code'? Some of the forking, would be difficult to replicate especially in layers. You'd probably need to know mermaidjs or something else funky. I think Tana would do well if it could rethink the whole canvas thing that other apps are putting out and really integrating it directly into the data structure.
-
I've come across several implementations that seem quite interesting.
Taskade's Mindmaps
Remnote plugin: Rem-graph
Infranodus graph
===
I think that Tana has to carefully consider this, because the graphical interface is something that is far more intuitive to the human mind than pure text.
The way many apps do it, like Logseq's whiteboard or Obsidian's canvas or Scrintal or Heptabase - they don't really seem to catch the essence of this... It's about the relationships created, not just the graphical representation of it. And Tana has the advantage here because of 'named edges'.
Imo, the above apps have taken a step towards incorporating graphical design, but it doesn't match the fluidity of thinking that can be done on pen-and-paper. The connections made in graphs must carry the same weight as actual bidirectional links. The problem is figuring out how...
Could we have predefined connectors like parent-sibling connectors (implying superset/subset), sequence connectors (implying causation/sequence/time), and so forth? And then the other question is how do we retrieve a part of the graph? How would a node look like?
I think in a world where AI is really picking up, the graphview would become a competitive advantage (until at least AI doesn't become fully multimodal yet)
Things like these just do not translate well into text:
-
-
Ideas
- Taxonomy: A "network graph" of supertags, and how they connect via extensions and field instances
This sounds great. Could be a re-workup of the Schema page essentially, which currently only acts like a dumping ground
-
-
-
Ideas
- Formula Field
I wish we didn't have such a low limit on monthly votes, but I would vote this one too if I could. I use Tana to track a lot of numbers. Spreadsheet-like formulas (or like Notion) would enable loads of additional creative workflows, such as makeshift spaced repetition and a productivity dashboard.
-
-
This would be really valuable.
-
I would love to have reuseable aliases. For example, if I used the word Apple, apples, der Apfel and 苹果 - I should be able to refer to that one node "apple" with any of these aliases.
-
-
Ideas
- Bidirectional Fields
No, because the point I'm raising here is that there should be a way to have bidirectional context. Using a search field is a workaround, not a solution to that inconsistency. Not to also mention the pain of having to toggle open the search node, and adding new entries under the search node - clearly different to fields, because nodes live locally under fields, while search nodes do not house nodes locally - they get automatically housed under the daily page.
The advantages may not be as clear with just two types of supertags. But they become clearer when we start to involve multiple supertags and relationships become more complex. Some form of bidirectional context must exist... A close parallel to this are Relational Databases in Notion.
-
I have another usecase where I'd like to pull out all the content fields of a particular tag. For example, I'd like to pull out all the contents by filtering "#tag" AND ".summary" (summary field in #tag), then have it processed by AI to create a to-do list, triage, etc.