What if I had to move to TANA?

[fragefrank]

Inspired by the What if you had to move to Obsidian? thread, I’ve been contemplating how feasible it would be to migrate from LogSeq to TANA. I love the flexibility and open nature of LogSeq, but I’ve found myself struggling a bit with managing my information effectively, especially as the lack of structure in my use of tags, templates, and namespaces has introduced some inconsistency.

I know the upcoming database version of LogSeq might address some of these concerns, and so its definitely worth waiting for it, but I’m still curious about what a potential transition to TANA would look like. From what I’ve gathered, TANA offers a native LogSeq import format, but I’d love to hear from anyone who has firsthand experience with this.

Specifically, I’m wondering how TANA import would handle:

• Namespaces

• Tags and Nested Tags

• Queries (Simple and Advanced): Do queries get imported? (At least simple queries into Live Searches ?)

• Properties (Page and Block Properties)

• Code Blocks

• Link Aliases

• Block References and Embeds: Are these preserved, and how, or lost in the import process?

• Instances of Templates: Are templates parsed as supertags in TANA with the import, or do they remain as static markdown text? If the latter, is there a way to convert them ?

• Todo Items (TODO, DOING, LATER, etc.)

• Deadlines on Tasks

• Assets in the Asset Folder

Are there any other important considerations to consider about such a transition ?

[daviddelven]

I hope I spare you some struggling periods. I’ve been (and I am) a Logseq user before Tana alpha was launched 2 years ago. I am also a Tana Navigator and I am aware about the current state of the art within its development. The Logseq import was an initial easy/basic way to have your Logseq data inside Tana, but that feature has not been developed further after its initial release.

After 2 years of Tana deep diving, my journey brought me back to Logseq again, not as a replacement but as a way to expand and make my processes more honest.

I wrote this article this summer The Data Accessibility Shift: Comparing Local-First and Offline-First Approaches | by David Delgado Vendrell | Medium , and that’s what makes me re-activate the Logseq pillar within my Information and Knowledge managements.

This is my current use case between Logseq and Tana:

Quick Capture

• Tana’s mobile capture tool can be invaluable for capturing fleeting thoughts, ideas, or observations when you’re on the go. Use it to jot down anything that comes to mind, without worrying about organization or structure. Set a regular schedule (e.g., daily or weekly) to review these captures. During this review, decide which items are worth transferring to Logseq. This process acts as a filter, ensuring only meaningful information makes it into your long-term PKM.

Incubation Space

• Think of Tana as a greenhouse for your ideas. Use it to nurture concepts that aren’t yet fully formed. This could include rough outlines for articles, initial thoughts on projects, or connections you’re starting to see but haven’t fully explored. As these ideas develop, you can use Tana’s features to add structure or connect related thoughts. Once an idea has “matured” - meaning it’s clear, developed, and ready for long-term storage or action - transfer it to Logseq. This approach keeps your main PKM system (Logseq) clean and focused, while still giving you a space to play with nascent ideas.

Specialized Projects

• For projects that particularly benefit from Tana’s unique features (like its structured data capabilities or specific views), use Tana as a temporary project management tool. This could be for research projects, complex planning, or any short-term initiative that requires a lot of interconnected data. As you work in Tana, keep in mind that the end goal is to summarize and transfer key information to Logseq. This might involve creating periodic summaries, extracting main points, or creating a final project overview to add to your Logseq knowledge base.

AI Meeting Assistant

• If you find Tana’s AI meeting assistant particularly useful, consider making it your go-to tool for meeting notes. Use it during or immediately after meetings to capture discussions, decisions, and action items. After the meeting, review the AI-generated notes, make any necessary corrections or additions, and then transfer the key points to Logseq. This could involve creating meeting summary pages in Logseq, adding action items to your task management system, or linking important information to relevant existing notes.

Strategy Overview

• The overarching strategy here is to leverage Tana’s strengths for specific, often short-term or dynamic uses, while maintaining Logseq as your primary, long-term knowledge repository. This approach allows you to benefit from Tana’s unique features without risking data fragmentation or lock-in.

Implementation Tips

• To make this system work smoothly:
  • 1. Establish clear workflows for transferring information from Tana to Logseq.
  • 2. Set regular review periods for your Tana workspaces to ensure information doesn’t get lost or forgotten.
  • 3. In Logseq, create an indexing system or tag that indicates which notes originated from Tana, allowing you to track the flow of information between systems.
  • 4. Regularly reassess this hybrid approach to ensure it continues to meet your needs and adjust as necessary.
• Remember, the goal is to create a system that enhances your productivity and knowledge management, not one that adds unnecessary complexity. Be willing to adapt this approach based on your evolving needs and experiences.

[daviddelven]

In the future, when the Logseq DB version comes into the market, we’ll all have to reassess our processes and decide what is suitable for our ultimate goals. (future-proofing, accessibility, cloud-functionalities, AI-driven processes, etc…).

But we are not there yet, and it is not tomorrow when we’ll have that scenario.

[fragefrank]

Thanks for the analysis. I’ll ponder if a split is what I’d need. I think I’ve seen people speak about LogSeq vs Obsidian in a similar way as ‘greenhouse’ vs ‘long-term’. At the moment my sense or worry about using two apps is that it may add to the confusion about where something ‘is’ rather than help with it.

Am I reading right that import from LogSeq likely just wont’ be any good ?

[daviddelven]

It is just a way to end up with your Logseq data inside Tana, but it won’t be organized as the Tana architecture is designed for. In fact, any Data transfer between TfT apps is seamless. Over time, and based on my own experience, I’ve realized that the all-in-one approach is a fallacy. The number of benefits that approach promises end up failing compared to the fact that we, at the end of the day, use several tools, no matter how. The key here is becoming aware of the need that all we do belongs to a process. As long as we draw it and we become aware of its workflows and procedures, I’m not concerned about confusion, because it is documented and its habit is acquired by the user.

If you want to see what you get from a json backup from Logseq inside Tana, you just need to use the trial version or ask for the invitation. But, again, don’t expect any advanced interoperability: different architectures.

[fragefrank]

Watching this, I think the DB version will be fine for me. Looks promising !

Updates on the Logseq DB Alpha