Olli Tiainen
Olli Tiainen's Comments
-
- Ideas
- New Node type — Comment
-
Also: % completed e.g. if there are 10 subtasks, 3 of them done, the circle would show 30% complete.
-
- Ideas
- Focus mode
Opening a node to a completely new window might also do the trick. Slack does this very well for discussions.
-
In reply to Maciej SmołaMaciej Smoła
Feb 10, 2024 @Olli Tiainen do you have an example of how does it like in Roam or other apps? -
- Ideas
- Detachable panels
Slack does this quite nicely nowadays!
-
- Ideas
- Hiding sidebar via Ctrl+K -> Hide sidebar should keep the cursor/focus at the current position
-
- Newly Released Feature Feedback
- Request for feedback on Tana Publish: Pages!
I love the idea of this feature, but the actual implementation seems buggy, incomplete (as in lacking features that Tana does natively), and very unpolished in many ways.
For me, the ideal solution would be to publish the node pages as they are - with all their functionality and look and feel but isolated them from the rest of the database (unless links between nodes are explicitly defined).
I don't understand at all why this wasn't done first - before applying new UI/skins to the content.
-
In reply to Kevin KoperskiKevin Koperski
Sep 6, 2023 100% support this feature. I find the current panel/dock setup fairly limiting. The way RoamResearch did it was, for me, incredibly productive. You could easily open any node in the right sidepar/pan...I did like Roam's implementation a lot! But I do like the feature of having more than two vertical panels too. So some kind of a mix of that flexibility.
Roam made it possible to make any node the main node with a click of a button iirc. This is possible with Tana too, but not without losing all other panels.
-
- Ideas
- Focus mode
-
Related to this: Focus mode (https://ideas.tana.inc/posts/331-focus-mode)
-
- Ideas
- Bidirectional Fields
In reply to Maciej SmołaMaciej SmołaMay 4, 2023 I see, so then we would be able to for example explain the mechanism of Vitamin D by describing the relation itself. Have you seen that implemented in UI anywhere? Where should it go in the app like T...Yes. This is also what Andric refers to with
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
The point here is that connections between supertags never contain any additional structured or unstructured information that explains the context.
I haven't seen any good UX for this - nor can I immediately imagine what a good simple solution could look like, especially in a bidirectional context. But here's what a bad and complex solution could look like that would do it's job in the context of this very narrow example - but it would probably hardly generalize:
The node "Osteoporosis #symptom" has a field "caused by" that would take multiple supertags + unstructured data as input
In the field, I would write
-- [Caused by] "Vitamin D #nutrient" deficiency because Vitamin D helps absorb calcium.
-- [Caused by] "Estrogen #hormone" reduction because Estrogen suppresses bone resorption.The node "Vitamin D #nutrient" has a connected field "Effects". The field would automatically contain
-- [Effects] "Osteoporosis #symptom" caused by Vitamin D #nutrient" deficiency because Vitamin D helps absorb calciumThe node "Estrogen #hormone" has a connected field "effects". The field would automatically contain
-- [Effects] "Osteoporosis #symptom" caused by "Estrogen #hormone" reduction because Estrogen suppresses bone resorption
-
- Ideas
- Bidirectional Fields
In reply to Maciej SmołaMaciej SmołaMay 4, 2023 @Olli Tiainen @Andric Tham wouldn't mentioned "connection between supertag instance fields information" be contained within the field title and description?In simple relationships, yes, such as:
- Person (supertag) is a member of a Project (Field instance for Projects)
- Project (supertag) has a Team member (Field instance for Persons)
But in more complex relationships, this doesn't work anymore:
- Nutrient (supertag) "Lack thereof causes" (Field title for #symptoms)
- Symptom (supertag) "Is caused by the lack of these nutrients" (Field title for #nutrients)
It doesn't work because field titles don't capture the context of these relationships (the edges). For example, Vitamin D (#nutrient) reduces osteoporosis risk (#symptom). But the context is that this is because Vitamin D helps the intestines absorb calcium from your food. However, neither the fields nor the field titles can capture this explanation of the connection. Instead, the information must be recorded either "under" the medicine or the symptom node, where it doesn't directly explain the relationship and isn't available bidirectionally through the fields or even via backlinks.
-
- Ideas
- Bidirectional Fields
In reply to Andric ThamAndric ThamMar 13, 2023 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...Your "ideal solution" is related to what I'm suggesting here: https://ideas.tana.inc/posts/148-taxonomy-a-network-graph-of-supertags-and-how-they-connect-via-extensions-and-field-instances
-
- Ideas
- Bidirectional Fields
In reply to Andric ThamAndric ThamApr 22, 2023 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 unstruct...Brilliant thinking. I'm in awe.
-
- Ideas
- Bidirectional Fields
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 is a solution belongs in my mind more to the connection between A and B than to either of the nodes.
-
- Ideas
- Bidirectional Fields
Quite simply: I am a cousin to my cousin. And that relationship should be expressed only once, not twice, like the current ontology structure requires.
Similarly, if John is working on a project, then the project has a contributor John.
There may be better solutions, but one way to implement this is to create automation/mirroring rules to instance fields of two supertags i.e. "When #person is added to #project's field Team, add that #project to #person's field Working on".
-
- Ideas
- Bidirectional Fields
From a discussion I had with Matt (from Tana):
Olli Tiainen
[10:07 AM]
I'm in specific very very very (did I say very) interested in your work regarding bidirectional fields Stian mentioned you were experimenting with
[10:08]
And by bidirectional fields, I mean, that if there are two #organization s A and B and organizations have a field [Competitors: #organization] - then if I insert B as a competitor to A's field, A would appear as competitor in B's field too.Olli Tiainen
10:09 AM
Or similarly, i.e. Project - Client - Team member relationships would show up in all of them without needing[10:10 AM]
Well, I think it's really the most important additional feature I could imagine having in Tana. It would basically replace my needs for Airtable.Olli Tiainen
[10:11 AM]
If I tag connect a team member to a project, then if I look at a list of projects, I'd like to see the team members listed
[10:11]
Or if I have a client A that is having a problem B, if I look at the list of problems, I can see all of the clients that have that specific problem
[10:12]
Almost all fields with instances are, in my mind, bidirectional.
[10:13]
References at the bottom help yes, but they are not the same thing at all and don't really help structure and work with the information. They only make the connections somewhat visible.
Even when I'm writing solo, I'd sometimes like to use comments to highlight sentences/paragraphs I need to rewrite.