⁨36⁩ ⁨Comments⁩

Page ⁨2⁩
In reply to Maciej Smoła Maciej Smoła

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).

In reply to Maciej Smoła Maciej Smoła

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:

  • antiarrhythmic drugs
  • ablation"]] #note
    .> Topic:: Atrial fibrillation

[["What about:

  • X
  • Y
  • Z?]] #student question
    .> Student:: Mark Cuker
    .> Date:: 2023-10-29
In reply to Maciej Smoła Maciej Smoła

"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-

In reply to Santi Younger Santi Younger

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

The best workaround so far is Jeff Harris' CSS workaround. Which was posted here in the slack community

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:

  1. Having a "Document" Node type whose content is rich text, like a Word Document.
  2. Expand on the existing Node capabilities so we can compose documents with Nodes.

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):

  • Ability to set a Cover Image/Unsplash for a Node.
  • Headings
  • Text Paragraphs
  • Quote Blocks
  • Multiline Code Blocks w/ Language Syntax Highlighting
  • Tick-based code blocks: Example
  • Links: Choose between Text Links & Previews. Ability to easily change the link text.
  • Bold/Italic/Underline/Strikethrough
  • Highlighting
  • Image Embeds: URL, Upload, Unsplash
  • PDF Embeds
  • Multi-Column Layouts.
  • File Attachments.
  • Simple Tables.
  • Diagram/Whiteboard (This is a whole separate other thing, which I'll bring up in another thread)

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.

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.

image.png

I especially liked the way only the first line shows if the node is not selected.

image.png

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.

  • Why 8 hours of sleep is important #long-form
    • Intro
    • Argument 1
    • Argument 2
    • Argument 3
    • Conclusion

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.