Andric Tham's Comments
-
-
I think targeting a reasonably open standard (like Obsidian-flavored Markdown or LogSeq-flavored Markdown) might make sense.
Especially when paired with the ability to setup a regular backup schedule to be sent to an offsite location like Dropbox, Google Drive, or S3 (of the user’s choosing).
LogSeq in particular is open source and an outliner, like Tana. If the backup were to omit any Tana-specific nodes like search nodes, perhaps it’ll be good enough to retain at least the raw data in outliner form where the nodes’ bidirectional links are preserved.
Obsidian-compatible Markdown files where each top-level node is a Markdown file and children are bullets, could work too. Referenced nodes become block references, and inline references become [[wikilinks]], and search nodes stripped out.
I could live with either of those for data portability.
For images, the relative links should be preserved and all media should be exported to a folder. Obsidian should be able to handle this. I’m unsure about LogSeq, but there should be a way they handle images too.
-
-
Ideas
- Bidirectional Fields
In reply to
bharat
bharat
Aug 22, 2023 If we are supporting this kind of relationships, i think one important option to validate is whether the relationship is one to one (person - id) one to many (team members - project) many to many (c...If we are supporting this kind of relationships, i think one important option to validate is whether the relationship is
one to one (person - id)
one to many (team members - project)
many to many (classes - students)I don’t know if SQL-style relationships are necessary, although when modeling certain domains, being able to restrict how many instances of a type of something can be related to another type of something could be essential to ensure correctness of data.
What you’re after is the ability to constrain a relationship’s cardinality.
I believe I stumbled upon some unpolished area of Tana where it’s possible to set cardinality of any given field. I think it might have been an abandoned feature?
-
-
-
Ideas
- Bidirectional Fields
In reply to
Spirit LoveRoot
Spirit LoveRoot
Sep 7, 2023 One potential issue I see here with bidirectional linking along with aliases is that eventually most of the words in our nodes will be tags and only the most mundane will not be tags. Because eventual...eventually most of the words in our nodes will be tags and only the most mundane will not be tags. Because eventually we will want a "page" for everything in our pkm.
Well, yes, every word in any text suggests a relation between concepts that are in that text. One could argue that that’s the purpose of writing text in the first place.
Guess what groundbreaking technology was recently integrated into Tana that’s designed with the ability to understand these latent relations in text? That’s right, LLMs.
Although, I’d argue that latent relations suggested by words inside text (unstructured data), is not quite the same as bidirectional relations inside fields (structured data).
It’s the difference between a vector database and a SQL database. Bidirectional relations between entities are not the same as bidirectional relations between words (technically, n-grams, if you’re using LLMs).
The former can be modeled with relational algebra or graphs as pages of tuples, the latter with linear algebra as n-grams in text embedding space.
The former requires a structured query (such as SQL or Datalog) sent to a database query planner, the latter requires inference that runs on GPUs.
The two shouldn’t be confused or conflated.
-
-
Yes! #tags and @mentions being cut from the scope of the mobile app is perhaps the biggest thing I miss from full-fledged Tana.
I get that they needed to cut scope to launch, but it’s been months since launch now! Bring back #tags and @mentions please
-
-
Ideas
- Inline code formatting
Any movement on this? I found out that if you paste text from elsewhere that is styled as such (probably wrapped with
<pre>tags in HTML) then Tana accepts it and handles the styling properly.All I’m asking is for Tana to add the backticks as a formatting trigger!
Makes no sense to be pasting code from another text editor just to get this to work.
-
-
In reply to
Ecto Kly
Ecto Kly
Jun 6, 2023 I agree that Capturing ideas on the fly is critical. Great discussion. I think that a possible solution to address the issue in the main topic is the development of a dedicated mobile app. By having a...There’s already a mobile app called “Tana Capture”, I think you probably missed that one.
-
-
Ideas
- Inline code formatting
Came back to check on this, was disappointed not to see any movement.
If only I could add more votes to this. Absolutely essential feature! Even the comments here have inline preformatting. -
-
-
Ideas
- Bidirectional Fields
In reply to
Maciej Smoła
Maciej Smoła
Apr 22, 2023 @Andric Tham do you know if there is any example of edges, annotated edges and edge properties to help visualizing that?Try the Neo4J Sandbox. Comes with graph and table visualizations of graph data. Not quite an end-user system, but that’s where apps like Tana can shine by innovating on the UX.
-
-
I get that local-first is hard and comes with challenges with data consistency. I also get why Tana tries to invalidate sessions when the app is updated, to prevent drift.
But all this said, I wish Tana erred on the side of good user ergonomics rather than easy development.
I think the biggest point of friction here is the long load time as your Tana workspace(s) are loaded into memory.
Whatever you can do to ensure lazy loading or local caching is appreciated.
Right now, Tana is a bit of a “worst of all worlds” type of app.It’s not local-first like Obsidian or LogSeq, yet I’m paying the up-front cost as a user to load all that data into memory without benefiting from local caching beyond a single session.
It’s not an optimized cloud-based app like Notion, where content is lazy-loaded as I navigate. So I can’t benefit from (faster) initial loads.
It’s very similar to Roam, which has the bad habit of loading your whole graph into memory each time.
A good compromise would be to let me locally cache just my personal workspace, in local storage or a SQLite DB, however you implement it, as long as it loads near-instantly and writes reflect optimistically while syncing in the background.
Surely there’s no need to ensure perfect consistency between multiple users, since my personal workspace is single-user. I don’t mind if there’s eventual consistency between the canonical cloud store and my local cache, as long as every session loads near instantly after perhaps the first cold boot.
Also, there’s no need for this to be a native mobile app. It can be a PWA, with the web interactions spruced up to work well on touch devices and web workers leveraged to do some of that syncing work
-
I think the biggest point of friction here is the long load time as your Tana workspace(s) are loaded into memory.
Whatever you can do to ensure lazy loading or local caching is appreciated.
Right now, Tana is a bit of a “worst of all worlds” type of app.
It’s not local-first like Obsidian or LogSeq, yet I’m paying the up-front cost as a user to load all that data into memory without benefiting from local caching beyond a single session.
It’s not an optimized cloud-based app like Notion, where content is lazy-loaded as I navigate. So I can’t benefit from (faster) initial loads.
It’s very similar to Roam, which has the bad habit of loading your whole graph into memory each time.
A good compromise would be to let me locally cache just my personal workspace, in local storage or a SQLite DB, however you implement it, as long as it loads near-instantly and writes reflect optimistically while syncing in the background.
Surely there’s no need to ensure perfect consistency between multiple users, since my personal workspace is single-user. I don’t mind if there’s eventual consistency between the canonical cloud store and my local cache, as long as every session loads near instantly after perhaps the first cold boot.
Also, there’s no need for this to be a native mobile app. It can be a PWA, with the web interactions spruced up to work well on touch devices and web workers leveraged to do some of that syncing work.
-
-
Ideas
- Bidirectional Fields
In reply to
Olli Tiainen
Olli Tiainen
Apr 22, 2023 A question I'm pondering: Should the connections between supertag instance fields contain information? So for example: If "A" (#solution) is a solution to "B" (#problem), The question of "why" it i...I think it matters. Annotated edges are an essential component of graphs.
With Roam-style backlinks, there aren’t any annotated edges between pages that link to each other, but at least the unstructured text does that job of adding context.
With fields, the field label does all the heavy-lifting, but the problem is that they behave like columns in a relational DB than they do edges in a property graph.
What is a desirable mental model here? Is it analogous to relational DB joins, with automatic backlinks, like how Airtable and Notion have implemented it?
Or is it analogous to a property graph where any node can have any type of edge and you can optionally annotate that edge with properties?
Tana seems closer to the latter right now, but end-users are more familiar with Notion/Airtable style UX.
Not sure how to reconcile these differences, but my preference is err on the side of flexibility, which means figuring out a good UX for property graphs where nodes can have properties, but edges can also have properties.
Edge properties could perhaps work like “contextual content”, or that feature could be expanded and rethought to better fill this role. Certainly, that’s the only way you can annotate context when you link between two nodes right now. It works for unstructured data, but there must be a better way for structured data which hopefully isn’t yet another new concept.
I think backlinks make a ton of sense, too, since it’s just backward traversal in a graph, but they need to be rethought (shouldn’t use Roam-style backlinks UX as they’re suited only for unstructured data, and shouldn’t also use Airtable-style backlinks as they’re suited only for relational DBs).
The current “Appears as X on Y” UX, where X and Y are static strings defined by the user, worked in a pre-GPT world, but perhaps backlinks can be semantically transformed by GPT, so “[Person] appears as a [Client] on [Projects]” can instead show up as a magic backlink field on Person that automatically parses that the field label should be called something like “Client for Projects”, or whatever GPT deems fit.
-
-
-
Ideas
- Bidirectional Fields
I posted a duplicate request before realizing this already existed. Here’s what I said:
Explain the problem as you see it
If you reference a node from within a field, that reference shows up in the “References” section of that node, not in a field within that node.
When specifying structured data (i.e. fields) on a record (i.e. a Tana node), one expects relations between two records to be handled consistently on both sides of the relationship.
In other words:
If a relation is defined as a field on a record, then the relation should show up as a field on both the incoming and outgoing side of said relation.Instead, the current status quo uses a backlinks-style UI which is borrowed from last-generation tools like Roam, LogSeq or Obsidian which is optimized for handling relations found within unstructured text.
It feels strange that the fields and views UI are borrowed from Notion and Airtable, but bidirectional fields didn’t carry over. This mismatch of UI idioms is frustrating.
Why is this a problem for you?
This is a problem only because Notion and Airtable handles this so gracefully, and Tana does not.
Since Tana is attempting to implement a superset of Notion and Airtable’s databases, this can be classified as a feature regression of sorts, especially if a user (i.e. me) were to migrate from using one of those tools to using Tana.
Example scenario:
Let’s say I have a field inside #Task called “Projects” that is of type “Instance” referencing nodes of type #Project
Inside a #Project, I might have a field called “Tasks”, where I want to see nodes of type #Task that reference said project
This example scenario works out of the box with Notion and Airtable, and doesn’t work with Tana’s fields, which is a crying shame!
Suggest a solution
The easy solution: Make relationships between nodes that are defined inside a field bidirectional. This probably only makes sense for nodes that have a schema inherited from a supertag.
The ideal solution: A better way to define cross-schema relations, replete with the ability to visualize fields and how they relate across #Supertags, probably using some kind of boxes-and-arrows no-code UI that looks like an ER Diagram.
-
-
Second this!
Since Tana is still in early access, I can tolerate an MVP version of this with an API and an officially-maintained Siri shortcut which posts to that API.
As an early version, if it could handle Markdown-esque formatting with fields and supertags, much like Tana Paste already does, that would be a win.
100%. I know this isn’t a specific feature request, but if I were to title it I would call it “Polish your app to at least feature parity with competing free apps, before selling it as a paid app”
Tana feels half-baked right now and I think there’s similar sentiment on Slack.
The AI Chat in particular needs to have feature parity with either Notion AI (RAG-based Q&A) or Poe/TypingMind (an unopinionated LLM client).
Right now it’s as basic as someone’s overnight hackathon project built with the Vercel AI SDK. Actually, worse than open source hackathon chat UIs I’ve tried: it doesn’t follow the structured output of Tana nodes format 100% of the time, and doesn’t accept multimodal input.
Not to mention they decided to include Dall-E and charge for it, when even ChatGPT offers it for free. I think if this is Midjourney or Flux Realism LoRA level of quality, it would be worth charging for. Otherwise it should be free as in beer.
Charging for Tana AI right now feels like a ripoff, even though they’re just passing on the cost of the OpenAI API to us.