Bruce F. Donnelly's Comments
-
-
In reply to
Bruce F. Donnelly
Bruce F. Donnelly
Dec 25, 2023 I ran into this recently. One way to do it might be to place an ordered list of the sub-nodes, or actually their identifiers, in a system field that is simply rendered as a list below the node. I'm g...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:
- the sub-nodes' reference numbers,
- their order, and
- 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 ran into this recently.
One way to do it might be to place an ordered list of the sub-nodes, or actually their identifiers, in a system field that is simply rendered as a list below the node. I'm guessing something like this already happens. They could then be rendered according to different settings:
- bullet with or without a highlighted circle, as now;
- a simple list with no bullet or number, but with a faint underline wherever there would be a filled circle;
- an unordered list with bullets with an underline as above; and
- an ordered list replacing the bullets with numbers.
Hovering over the empty space, bullet, or number would render the bullet point as in #1, above.
A poem could be rendered as #2 above. When we click on the sub-node to view it as a page, a faint line over the text would indicate that it is part of something larger.
-
-
Ideas
- Option to hide fields
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.
- Create an "Outline" view. That is, in addition to List, Table, Cards, Tabs, and Calendar views, add an Outline view.
- 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.
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.