Skip to main content
tana
Product Company Community App Get early access
Community
Search
Log In
Log In Sign Up
Bruce F. Donnelly

Bruce F. Donnelly

Joined Jul 24, 2023 Last seen Apr 3, 2025
Posts 5 Comments 7

⁨Bruce F. Donnelly⁩'s Posts

Newest Top
Newest Top
Bruce F. Donnelly Bruce F. Donnelly Aug 20, 2024

Long-form node

Actions

Explain the problem as you see it

If Tana wants to be used for note-taking and outlining, it needs to make writing essays easy. Some of the best learners write essays to learn. An outliner builds an outline for an essay or thesis, so Tana needs a workflow that gets the user to one.

Meanwhile, Tana is heavily structured, so free-form & long-form writing couldn't be more out of character. If you write an essay separately without linking back, you might write in Word on the side. Users should be able to drill down from a claim back to notes and sources.

Why is this a problem for you?

I want to be able to take notes, summarize them into points, and arrange them into essays, theses, and so on. I can get to an outline in Tana, but then I have to go outside Tana to write it out. I want to drill down from a readable page to the original notes and highlights.

Suggest a solution

Superficially, this sounds like it only requires some tweaks. Line breaks inside a node
would be useful for some nodes, but it wouldn't help to close the gap between an outline and formatted written output. Long-form writing in Tana is a great idea, but it needs to address the structure of an outline.

I would create a kind of node that formats an outline:

  1. The user would highlight an outline and use a command to insert it into a long-form node.
  2. Initially, the bullets would appear within the long-form node just as in the original outline. They would render it as a single unbroken paragraph of inline text.
  3. The user could then use tags to wrap individual lines or sets of lines in tags. One tag would be <contextual text>, for text used only in the node--for connecting sentences and so on. Another would be <sentence>, which would supply a contextual period if one is missing and a contextual capital first letter if it isn't capitalized. <paragraph> is obvious, as is the numbered list tag, and so on.
  4. A contextual <break> could be inserted inside a node.
  5. Eventually, the user should be able to create their own contextual tags that "extend" various tags. For example, a <thesis-paragraph> wrapper would wrap the first part of the outline before the first outdent, but it would also be a reminder of the paragraph's structural place in the outline. A <point-sentence> and a <counterpoint-sentence> wrapper would remind the writer of points and counterpoints. If desired, a node tagged #hypertag could be wrapped with an <inline-quote> tag if it is short and a <quote-paragraph> tag if it is long. Each could have its own user-defined contextual text added. E.g., an <inline-quote> would be supplied with contextual quote marks around it and ellipses if it doesn't have a period at the end or a capital letter at the beginning.
  6. The long-form node should have a toggle to turn rendering on or off. It could be a three way switch: rendered, tags shown, and tags hidden. Thus, a single node could be toggled between rendered and non-rendered formats.
  7. As a bit of error-catching, a rendered node that is not wrapped in a tag would retain its bullet. That is, a rendered node with a <break> tag in the middle would be rendered with the break, but it would retain its bullet--unless the user wraps it in a <sentence>, a <paragraph> tag, etc.
  8. The rendered version of a tag should be capable of being cut-and-pasted into conventional text with line breaks, etc.

Perhaps I fleshed this out too much, but the key pieces are,

  • a long-form text node for long-form text;
  • tags either akin to XML tags or as XML tags that live _contextually _in the node and both to give it structure and to tell Tana how to render them;
  • one tag is a <break> tag that could be inserted _contextually _inside a node;
  • the option to view long-form nodes in their rendered form or not either/both globally by default or with a toggle in the long-form node; and
  • contextual text that lives only in the node.

Some version of this would be huge. Incidentally, table views in Tana could be turned into properly tagged tables suitable for cutting and pasting.

1 ⁨1⁩ ⁨comment⁩
Bruce F. Donnelly Bruce F. Donnelly Feb 14, 2024

Problem: query, supertag, and indented childrens' semantics are all different.

Actions

Explain the problem as you see it

It's useful to have a semantic function in fields, but it seems like it solves a problem that arises because the has-a of fields and the is-a of supertags aren't semantic--at least not the same way that searches are.

Why is this a problem for you?

I need to learn two or three ways of understanding the Tana system, rather than just one.

Suggest a solution

Search nodes and ordinary nodes should have the same organization and syntax. It would start with a blank node and go from there.

Let's start with an ordinary node:
Nineteen Eighty-Four#book
Author | George Orwell#author

(Apologies for making do with this form's formatting tools)

A search node for all books written by George Orwell would look like this:
[_]#book
Author | George Orwell#author

In other words, a search node would be exactly the same--except that it would have a placeholder instead of, in this case, a book title.

You would need to port over some syntax from search fields, but that could be a good thing. You could build more complex searches:

[_]#book
Author | George Orwell#author OR Aldous Huxley#author

[_]#book
Author | NOT George Orwell#author

. . . etc.

The flip side of this could be really powerful. You can use "GRANDPARENT" in a search node. So what if you could use it in a mini-live search in an ordinary node? Or "ANCESTOR"?

You could have an ordinary node that quotes its ancestor. You would use an "ANCESTOR" placeholder:

Nineteen Eighty-Four#book
Author | George Orwell#author
Quotes
“She’s a meter across the hips, easily,” said Julia.#quote
Author | FROM [ANCESTOR]

This would appear like this:
Nineteen Eighty-Four#book
Author | George Orwell#author
Quotes
“She’s a meter across the hips, easily,” said Julia.#quote
Author | George Orwell#author

The text "FROM [ANCESTOR]" would simply be replaced with text from its ancestor until or unless that's updated. It should probably have a different background to make it clear.

You could also include semantic functions in children:

George Orwell#author
Affiliations | Democratic Socialist
......................| NOT Communist

(Again, sorry for the wonky formatting.)
This means that you could search for all authors who are not Communists and find Orwell.

Obviously, big all-caps look ugly, so semantic functions should probably be distinguished more subtly for readability. Perhaps, again, a different background.

In summary, each step you take to combine the semantics and syntax of ordinary nodes' children and search nodes would help make searches easier to understand and make ordinary nodes more searchable.

0 ⁨0⁩ ⁨comments⁩
Bruce F. Donnelly Bruce F. Donnelly Aug 23, 2023

Popup temporarily taking you to a canonical location to tag a node

Actions

Explain the problem as you see it

As I noted elsewhere, I understand why the Tana team opted for auto-initializing fields when nodes are created or tagged. Since nodes can appear by reference anywhere, it wouldn't do to have them change their contents with every context. On the other hand, I often want to add information in a more intuitive way. Tana is flexible, but it demands that users use disciplined workflows. In fact, users share workflows almost as they do templates. That is not necessarily conducive to right-brained thinking.

Why is this a problem for you?

When I compare and organize information, as I did in Tana while taking notes on policies regarding the homeless, I usually find it useful to work in live search. However, sometimes I want to enter the information in one location even though the its fields only auto-initialize properly in another context—typically a tree or a live search that I think of as "canonical."

Suggest a solution

When you tag something, for instance, #author, you get a popup that asks you if you want to create it under your "My books" node, which will ensure that everything auto-initializes properly. It prompts you to enter any information the node you are creating will inherit when it auto-initializes: in this case, you might be prompted to enter a #book. For instance, I might mention an idea about language from Orwell in my Today node. Then I tag him #author, and get taken to my list of books and authors. Once I'm there, I write out his full name and tag 1984#book as the source. When I'm done, I go back to the Today node, where I can place a reminder to finish filling things out. The UI interrupts me only enough to fill out the critical information. It would also be a mnemonic device reminding me of how I store information.

Behind the scenes, I imagine the "canonical" location I choose would be stored in a system field.

I've made a couple of suggestions that include the idea of a "canonical" location in which a tagged node should be created. I'm not including that as an actual suggestion since it is an idea latent in workflows. Many workflows include the idea of a "canonical" location without saying so specifically. What I mean is a user-defined location where tagging a node and filling in fields puts the information in the right place in the right hierarchy.

0 ⁨0⁩ ⁨comments⁩
Bruce F. Donnelly Bruce F. Donnelly Aug 23, 2023

Create a command to "flash" tags under a node

Actions

Explain the problem as you see it

People are messy and want to enter information in different ways. First, we might list an author's books, and some might have quotes:

My list of authors
Arthur Arturo #author
How to Write a Book #book
How to Get Paid for Writing a Book #book
You might think you don't need a lawyer, which is why your publisher drank champagne at your book launch. #quote
Why Most Writers Need Day Jobs #book
It can be embarrassing for both parties when a diner recognizes her bussboy from a book jacket. This is when you speak in tongues and hide in the kitchen. #quote
...

Second, we might list authors of books:

My list of books
How to Get Paid for Writing a Book #book
Arthur Arturo #author
Bob Lawson, Atty. #author
You might think you don't need a lawyer, which is why your publisher drank champagne at your book launch. #quote
...

Third, we might list the author and book under a quote:

My list of quotes
You might think you don't need a lawyer, which is why your publisher drank champagne at your book launch. #quote
Arthur Arturo, #author; How to Get Paid for Writing a Book #book.

This is why it's smart to fill in auto-initialized values when, and only when, nodes are created. Otherwise, the data might change depending on context. Good job, Tana! However, this assumes users always add information in the same way. Since there's no evidence of brain meat evolving a proper logic gate, this may be a bad assumption.

Why is this a problem for you?

First, it's a problem with the Readwise integration. I gather that Readwise can't properly initialize fields because of limitations in Tana's API. It's also a problem for me when I want to create a tagged node, e.g., a quote, before the node (a book in this case) from which it expects to pull information.

Suggest a solution

Please note:
I have three suggestions, of which this is the first. I will largely repeat the above text, so sorry for the repetition. As you note in your philosophy, it's a long way from problem to solution, and I want to present options.

Create a command to "flash" tags under a node the user chooses, and include that node in the metadata for that tag. This would do a couple of things. It would re-initialize the tags, so that they filled in their auto-initialized values. Second, it would mark one location as canonical. How would this work? Let's take a list of books. It is in the format

My list of books
[Book Title] #book
[Author Name] #author
...
[Quote] #quote.
...
[Another Book Title] #book
[Another Author Name] #author
[Another Quote] #quote
...

The "flash" command would would go like this:

  1. The user places the cursor in the node that is the ancestor to all the nodes s/he wants initialized. It need not be a tagged node. In this case, it would be "My list of books."
  2. The user types control/command K and then, "flash nodes tagged #quote below this node."
  3. The UI would throw up a warning saying that this will change data in x-number of nodes, but reminds the user that it can be undone.
  4. The user presses <enter> to agree.
  5. All the nodes tagged #quote get "flashed" and their auto-initialized values get inserted.
  6. The user checks a random #quote node to see whether it is done correctly.
  7. If the user makes a mistake, the user can then hit "undo" until s/he sees the new value go away.
0 ⁨0⁩ ⁨comments⁩
Bruce F. Donnelly Bruce F. Donnelly Aug 23, 2023

Commands for up and down generations

Actions

Explain the problem as you see it

As Maciej Smoła noted in "GREAT-GRANDPARENT and higher levels of PARENT search operator," "There is no way to reference a node that is more than GRANDPARENT level above search node."

Why is this a problem for you?

I want to be able to refer to nodes all over the place in a tree that is "canonical" for my workflow. See the idea noted above.

Suggest a solution

GREATGRANDPARENT is a lot of typing, and it's just one option. Perhaps either a family of commands or one command that takes parameters as you type it:

PARENT becomes UP_1
GRANDPARENT becomes UP_2
GREATGRANDPARENT becomes UP_3
GREATGREATGRANDPARENT becomes UP_4.

PARENTS_DESCENDANTS becomes UP_1_DOWN_N

Parent's grandchildren would be UP_1_DOWN_2.

Realistically, there has to be a limit. UP_10_DOWN_10 is ridiculous unless you want to fry eggs on the processor.

0 ⁨0⁩ ⁨comments⁩