Explain the problem as you see it
At the moment, it is not possible to write essays, emails, blog posts, or other long-form content in Tana in a smooth way. Although Tana works great for outlining ideas, it would be incredible to have a dedicated mode that allows long-form writing options.
Options such as:
- Headings
- Line breaks
(just these two things would make a massive difference)
nice bonuses would be: - Quote blocks
- Lists (numbered and bulleted)
Why is this a problem for you?
Since Tana currently lacks support for long-form writing, we are forced to use other tools for writing long-form content.
This makes it hard to continue the work all in Tana. It prevents us from having all research, outlines, and drafts in the same app.
Workarounds
The best workaround so far is Jeff Harris' CSS hack. Which was posted here in the slack community
Edit: Unfortunately that post was lost in Tana's community slack history, and even then that css hack isn't working anymore.
After reading the comments below this post, I wanted to share a bit of how I'm working around Tana's limitations, in case anyone find it helpful, you can see me showing a demo of my current workflow in this YouTube video
At the moment I rely on a lot of workarounds, having a better system built in to Tana to specially allow line-breaks and headings (h1, h2, h3...) would be great.
───────────────
While Markdown syntax would be incredible, the most important aspect of this feature would be the ability to easily paste long-form text into other apps like Gmail and preserve all formatting.
Similar requests:
As pointed out below in the comments, there's a similar request here: https://ideas.tana.inc/posts/26-line-breaks-inside-a-node
While that's definitely super useful by itself. I would argue that it's important to go beyond just "line breaks inside nodes" and also have a dedicated "long-form" writing mode that enables not only line breaks but also headings, lists, blockquotes, and other formatting options for an overall better long-form writing experience outside of enforced bullet point structures.
Thanks
42 Comments
Related to this: Focus mode (https://ideas.tana.inc/posts/331-focus-mode)
Totally agree.
I would like to add that adding the ability to tag many nodes at the same time is not a sufficient workarround.
A single multi line node is not the same as multiple nodes writen one after another.
Sometimes, multiple lines add up to a whole, and each line only makes sense as part of that whole.
Every time a line is tagged, the other lines should be tagged as well. Every time a value is writen to a field of a line, the same value should be copied to the sme field of all other lines. Every time a line is referenced, the other lines should be referenced as well, and the reference should be ordered one after the other exactly in the right order.
An example:
An explanation that includes a diagram. In many cases, the explanation is structured in the following way: a simle explanation of the idea, a diagram, and then further elaboration. Right now, this explanation is forced to be split between at least 3 nodes, even though it is a single explanation. If I want to reference this explanation, I can't, I can only reference parts of it. I am forced to either reference all the nodes that the explanation contains and order them correctly, or reference only one node and hope that everyone looking at the reference will understand that it's partial and that they need to look at the original node.
I also agree that having a "title node" in the cases I presented is also not a sufficient workarround.
Some things don't have a title. I find that forcing the users to title things creates what I like to call "Title Hell", where you write everything that you want, but you are not finished because you cannot find an appropriate title for it.
It is frustrating, and it makes you resist writing, because you know that after you are finished with writing the things you acctualy want to write, you also have to do "chores" and choose a title for it.
And the worse part is that ussually the titles are worthless. You never use them when you search for what you wrote. And they convey so litle about the accual content that you have to constantly alias then whenever you use then as a reference anyway.
I think the best way for Tana to enable long-form writing is to enable export to OPML using an outline format that Scrivener can parse nicely. Scrivener sits between block/node-based text architecture and flat-file architectures, and it is widely used by writers of all kinds. It would be a great application for Tana to export nodes to for long-form writing.
Embedding a Google doc might be a suitable workaround.
With automatic doc creation and naming it would be pretty transparent. The same thing for sheets also would have a use, specially if you can map a node field to a particular sheet cell value (i.e. the result).
Adding to the long form, multiline text tagging.
It would be very useful to be able to tag group of nodes OR a multiline text, with a way to add fields to them, like:
[["Treatment of atrial fibrillation includes:
.> Topic:: Atrial fibrillation
[["What about:
.> Student:: Mark Cuker
.> Date:: 2023-10-29
"I just felt the biggest reason why I would like to have an easier way for long form writing, strictly meaning multiline nodes."
This is exactly my issue.
While I would also like formatting of long form text per the OP, this is the most important issue for me.
It's driving me crazy that I can't write notes and tag the entire "paragraph" or "page" or list of nodes. Here is an example:
I have a input from a user study. I wrote the note, but I can't write each separate input point in one giant paragraph. Of course I need separate lines for each point. But, I don't want each input point to be tagged individually. They make no sense unless they are part of the whole.
I want to find the entire note with the intro paragraph and all the "points" (nodes). They are one whole. But I can't do this with Tana.
Nodes are great and important. But, of course, we need to be able to look at, and act on, a set of nodes (i.e., a page) as one entire unit.
If Tana doesn't support this, then they are letting the backend data structure dictate how users think and use Tana. That would not be good for the long term.
This is exactly what is stopping me from using Tana as my repository.
Thanks for listening!
cheers,
c-
You mention the solution below, which I cannot access (older than 90 days). Is the workaround described somewhere else? Could you copy it here? Thanks
Hey I get you, that's definitely annoying about slack 90 day deleted messages. I made this YouTube video about it, and here's a blogpost where Jeff gave me permission to share the code
I'd just like to also throw in my vote for multiline nodes and rich long-form editing. Tana can't be an all-in-one solution without it. Personally, I need all of the standard rich editing capabilities so that I can compose proper documents. I'm split between implementing this in two different ways:
Either way, I need the ability to compose properly formatted documents with the following capabilities in some form (some of these are already present in Tana):
Example
I agree @Jeremy! those features would be incredible, I see how integrating all of those are a sturggle for the Tana team, but definitely worth adding long-term.
I think starting with line breaks and headings would be a great starting point.
I want to use Tana to collaborate with my team a lot more. My goal would be to draft out long form content (blogposts, newsletters, emails etc...) and then copy paste them to wherever I need to publish them.
Since Tana is not able to allow long-from writing with headings and line breaks, I'm forced to find an alternative like Google Docs or Notion, which is annoying since Tana would be a lot better if it had this feature.
Tana would be perfect if added the
Focused writing feature to hide bullet points refer to this Focused writing feature of Scrivener
Add another level of titles to have H2 and H3 like the title options in the Ghost editor.
I must absolutely add my voice to this. One thing I loved in Obsidian was creating an outline and then slowly it would morph into a full blown text. Here I cannot do this, I have to switch programs when I want to actually write. It kind of breaks my flow, but I love Tana too much to switch. Please add support for longform!
i'm coming from Workflowy. The way they solved this to my liking was to allow the user to enter the equivalent of a description in long form. That way the node could serve more like a title and the description would be the text.
I especially liked the way only the first line shows if the node is not selected.
As a writer of posts that use conventional headings, paragraphs and sentences, presumably I am a 'longform' writer. And, yes, I would very much like to take my workflow in Tana to this stage rather than having to always move to a different environment.
The Tana philosophy focuses on resolving problems. Well, here is a problem. Tana makes bullets. However, pretty much everything published, whether online or in print, is in paragraphs and sentences.
Bullets are for agendas and PowerPoints (and bullets are out of favour for PowerPoint decks these days).
So a writing environment that only produces bullets is... producing something that can't be used without conversion.
(1) A capable export converter to produce clean text would help (easy solution)
(2) A view mode that produces Markdown headings, paragraphs and sentences — which can be shared/exported -- would be great. A proper solution.
OK, more than an afternoon's work BUT it would be transformative for Tana and open up its appeal to a larger and broader community, especially writer types.
Add another vote for long-form writing. I'm coming from OneNote and this is where that tool excels. I think possibly a short-term fix with some of the primary text modifiers as mentioned in this thread, but the ultimate goal would be the implementation of a full-function, long-form text editing function.
Given the reasons of the team to not put too much information into a single node I would appreciate a "long-form" node view. Basically the first node is the "title of the document" for example let's make a short post about an argument.
The parent node containing the title gets a new "long-form" view which can be triggered via shortcut. Each paragraph below is a separate node but the bullets are removed so we get closer to the long-form format. Different types of nodes can then be inserted below such as code and formular one they make an appearance in Tana.
The long-form solution is just a different way to view an assortment of nodes rather than combining all information in a single node. This make referencing of i.e. the arguments somewhere else in Tana easier and allows the nodes to stay small and not harm the performance.
Given that the bullets contain some information about the nodes I would suggest shades of nodes to easily distinguish references etc.
Will anybody (or has already, how would we know, if they might no be tagged as such) chime in from the Tana-People?
This is an important task for them to at least comment on, right?
I assume they’ve had their heads down getting their paid plans ready, but I sincerely hope this is top of the list in the future.
Tana has so much potential, but is still missing something as simple as a line break I know there’s likely a tech/database reason but it’s frustrating.
Excited to get a response from the team soon.
It has to be top priority. I’m watching and waiting at the moment and unable to use Tana as it does not produce what I create!
It makes beautiful stacks of bricks and timber but cannot build them into a house!
I am hopeful that this will be remedied soon so that I can join a paid plan.
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.