Bruce F. Donnelly

If Tana wants to be used for note-taking and outlining, it needs to make writing essays easy. The best learners write essays and make mind maps to learn. Mind maps are a heavy lift, but essays should be easy.

I suspect the Tana way would be to make a "long form" view. For an essay, each sentence would have a tag, like #introduction, #thesis, #support, #conclusion, and so on. For a poem, the tags would include #stanza. Then, the "long form" view would render this as an essay in a readable and editable format, the way that CSS renders text. Each tag could have formatting properties, like a paragraph format in a word processor. Gonna suggest this.

Oh, and the sub-nodes' order would be stored too, even when sorted alphabetically, for instance. This would let people put in blank lines between stanzas, for instance.

That is, the field would store these:

1. the sub-nodes' reference numbers,
2. their order, and
3. how they are supposed to be rendered.

Note that these are all stored in the node, not the sub-nodes. That way, the option of how to render the sub-nodes would only be stored in one place, not in each individual node.

I agree with @Chen both that there's a problem, and that there's a better way. Yes, it's a problem that you can't see a node's child nodes without also seeing that node's fields. I also think there's a better way.

1. Create an "Outline" view. That is, in addition to List, Table, Cards, Tabs, and Calendar views, add an Outline view.
2. The minimum viable solution for the Outline view would be to simply hide fields by default. Then the Tana team could add features to Outline view over time.

I can think of a couple of features to add, but these are beyond the basics.
One would be to allow users to show selected fields as nodes with a colon between the field name and the field's value, like "Author: John Smith." A series of auto-complete steps in the ctrl+k menu would accomplish this. The user would ctrl+k on a field and then type out the following:

• Show field in Outline view: only this instance
• Show field in Outline view: all instances in this outline view
• Show field in Outline view: all instances in all outline views

The last option would change a toggle on the field's configuration page.

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.

Oh, and this is probably related. I'm sure, in fact have seen, that many people have problems pasting lines that wrap. Depending on what I am pasting from, lines that definitely wrap in the original may or may not wrap in Tana. So Tana does have something that reads as a line break internally to Tana, and it can sometimes be inserted at every line-end, depending on the application and the format from which one pastes.

I had success pasting a carriage return character from Word into Tana, but I don't know how Tana is interpreting it. When I pasted that carriage return character back into Word, Word interpreted it as a space. If we knew how Tana was interpreting it, maybe we could insert an alt code character or something, at least as a workaround. Not that a workaround is what we need, ultimately! Ultimately, we need a better solution, but in the meantime, a workable carriage return character would suffice for some purposes.