Comments

• andang76

  August 15 edited August 15

  Only requirement for me are easy note writing (markdown format is perfect) and easy linking.

  I consider obsidian a perfect fit, expecially for the second requirement, because it offers automatic update of links when note title changes.

  A decent templating feature supports a lot, too, but for this you can also use an external text expander.

  Oh, and being plaintext based and local availability, for future proof. My notes need to be usable for years, besides the lifetime of the app
• harr

  August 15

  My Zettelkasten is constantly changing, so I need an app that can keep up. I like Obsidian, because it adapts.
• tomp

  August 15

  @andang76 said:
  Only requirement for me are easy note writing (markdown format is perfect) and easy linking.

  Oh, and being plaintext based and local availability, for future proof. My notes need to be usable for years, besides the lifetime of the app

  +1 to both of these.

  More generally, beyond easy linking is ease in all operations, and the ability to quickly and easily scan related cards.
• Amontillado

  August 16

  I've long been biased toward Devonthink. There are limitations. I wish I could transclude a Devonthink smart group (stored search) into a Markdown document like you can embed bases in Obsidian.

  Obsidian would be more palatable if community plugins could be global across all vaults, but I think I understand why they aren't. Syncing.

  For ease of entry and linking, it's hard to beat The Archive, for which I've gotten renewed enthusiasm over the past couple of months. Linking as searching does nice things, and I suspect The Archive is about as reliable as orbital mechanics. (No offense intended to flat earthers.)
• msteffens

  August 18

  IMO, a good note-taking app should provide stable note IDs and thus stable note links that don‘t change.

  It‘s fine that an app is able to automatically update its (unstable) note links but ideally this shouldn’t be necessary. And such a setup still causes problems when using those links in external systems (say, in other apps like DEVONthink, Calendar, etc). These external links won‘t get updated when your note ID changes and as such turn into broken links.
• Ryuk

  August 19

  @msteffens said:
  IMO, a good note-taking app should provide stable note IDs and thus stable note links that don‘t change.

  It‘s fine that an app is able to automatically update its (unstable) note links but ideally this shouldn’t be necessary. And such a setup still causes problems when using those links in external systems (say, in other apps like DEVONthink, Calendar, etc). These external links won‘t get updated when your note ID changes and as such turn into broken links.

  Thank you very much for this response! It gives me a huge idea of what to do
• Ryuk

  August 19

  @tomp said:

  @andang76 said:
  Only requirement for me are easy note writing (markdown format is perfect) and easy linking.

  Oh, and being plaintext based and local availability, for future proof. My notes need to be usable for years, besides the lifetime of the app

  +1 to both of these.

  More generally, beyond easy linking is ease in all operations, and the ability to quickly and easily scan related cards.

  Thanks!! That's helpful
• Ryuk

  August 19

  @andang76 said:
  Only requirement for me are easy note writing (markdown format is perfect) and easy linking.

  I consider obsidian a perfect fit, expecially for the second requirement, because it offers automatic update of links when note title changes.

  A decent templating feature supports a lot, too, but for this you can also use an external text expander.

  Oh, and being plaintext based and local availability, for future proof. My notes need to be usable for years, besides the lifetime of the app

  Thanks!! That's cool, I will try to implemment all these stuff!
• tomp

  August 19

  @Ryuk said:

  @andang76 said:
  Only requirement for me are easy note writing (markdown format is perfect) and easy linking.

  I consider obsidian a perfect fit, expecially for the second requirement, because it offers automatic update of links when note title changes.

  A decent templating feature supports a lot, too, but for this you can also use an external text expander.

  Oh, and being plaintext based and local availability, for future proof. My notes need to be usable for years, besides the lifetime of the app

  Thanks!! That's cool, I will try to implemment all these stuff!

  In my view the design style of one file for one note is unnecessarily limiting and produces much programming complexity. It makes things that should be easy, hard. Ideally, in my view of course, is that the entire data structure of notes and links should be resident in memory [1]. It's still a principle of major importance that all the content needs to be exportable as text, but that can easily be arranged when all the data is in memory and you have a good data model.

  [1] In the old days of little memory and small disks, one note per file might have been a better approach.
• msteffens

  August 19 edited August 19

  In my view the design style of one file for one note is unnecessarily limiting and produces much programming complexity.

  While a note must not necessarily be contained in its own file, in my view it‘s crucial that the note is self-contained and that you can ensure that all note-specific info & metadata always travel with that note. As long as you can clearly associate the note‘s ID and metadata with the note and be able to separate individual notes again later, you should be fine w/o individual files. Purely block-based approaches (where you usually can associate an ID with the note block but nothing else) don‘t fulfill these requirements.

  This topic was also discussed earlier here:

  https://forum.zettelkasten.de/discussion/comment/5591/#Comment_5591

  IMO, Zettel notes should be as self-contained as possible. I.e., the Zettel note's body text (or its metadata) should contain all relevant information (like its tags, creation date, linking & citation info, related file info, and of course the Zettel ID). This way, you can do lots of things with your Zettel notes but don't loose anything. All relevant info always travels with the Zettel. E.g., you could transfer your notes somewhere where there's no file path info, like a database, a single text file, or an app that stores files internally using its own naming scheme. Your notes would still remain intact and can be retrieved again w/o loss.

  That comment was a follow-up comment to the below comment (which also touched upon stable note IDs and including the note ID in the note's body itself):

  https://forum.zettelkasten.de/discussion/comment/5545/#Comment_5545

  Btw, a one-note-per-file design must not be limiting, usually it‘s rather that our software is not designed to smartly handle this. E.g., it would be very useful if more tools could dynamically combine multiple notes/files as needed, like in a „Scrivenings“ mode:

  https://forum.zettelkasten.de/discussion/comment/24621/#Comment_24621

  In my own software, I‘ve implemented a kind of „Scrivenings“ mode where all selected notes get dynamically combined into one text view and you can copy & edit them as a whole. You can also drag this text of compound notes somewhere else, edit it there and then drag it back – the text will again be split into its individual notes and the corresponding note files will get updated automatically. This is all possible by having self-contained notes with note IDs being included in the note itself.

  Post edited by msteffens on August 19
• tomp

  August 19

  @msteffens said:

  In my view the design style of one file for one note is unnecessarily limiting and produces much programming complexity.

  While a note must not necessarily be contained in its own file, in my view it‘s crucial that the note is self-contained and that you can ensure that all note-specific info & metadata always travel with that note.

  Yes, I completely agree.

  As long as you can clearly associate the note‘s ID and metadata with the note and be able to separate individual notes again later, you should be fine w/o individual files. Purely block-based approaches (where you usually can associate an ID with the note block but nothing else) don‘t fulfill these requirements.

  With single note files the system has to keep opening and closing notes. If they are mapped to different locations, names, or other relationships, then the software has to keep track of and persist those mappings. Opening and closing many files for one operation is relatively slow, and has to be done over and over, unless they are to be cached; if cached why not keep the entire data set in memory from the start? Yes, whatever caching the OS happens to do helps, but in-memory is still simpler and faster.

  This topic was also discussed earlier here:

  https://forum.zettelkasten.de/discussion/comment/5591/#Comment_5591

  IMO, Zettel notes should be as self-contained as possible. I.e., the Zettel note's body text (or its metadata) should contain all relevant information (like its tags, creation date, linking & citation info, related file info, and of course the Zettel ID).

  Yes, I agree. If the system keeps the data in memory, there needs to be a simple and reliable way to serialize it to text in case one needs to move to another system. That's what I do.

  This way, you can do lots of things with your Zettel notes but don't loose anything. All relevant info always travels with the Zettel. E.g., you could transfer your notes somewhere where there's no file path info, like a database, a single text file, or an app that stores files internally using its own naming scheme. Your notes would still remain intact and can be retrieved again w/o loss.

  That comment was a follow-up comment to the below comment (which also touched upon stable note IDs and including the note ID in the note's body itself):

  https://forum.zettelkasten.de/discussion/comment/5545/#Comment_5545

  Btw, a one-note-per-file design must not be limiting, usually it‘s rather that our software is not designed to smartly handle this. E.g., it would be very useful if more tools could dynamically combine multiple notes/files as needed, like in a „Scrivenings“ mode:

  https://forum.zettelkasten.de/discussion/comment/24621/#Comment_24621

  In my own software, I‘ve implemented a kind of „Scrivenings“ mode where all selected notes get dynamically combined into one text view and you can copy & edit them as a whole. You can also drag this text of compound notes somewhere else, edit it there and then drag it back – the text will again be split into its individual notes and the corresponding note files will get updated automatically. This is all possible by having self-contained notes with note IDs being included in the note itself.

  That sounds very interesting. I get a somewhat similar effect by being able to open editing windows on several notes (one note per window) and dragging them into whatever spatial arrangement I like.
• firozansari

  12:41PM

  I have been using a Luhmann implementation of Zettelkasten through a custom (Slopped) windows application for the last couple of years. Alphanumeric IDs, atomicity, etc., are baked into the application itself. The register is a way to "tag" notes which will land me to specific area, so there is no concept of tags, categories, etc, and also need to to "tag" all notes in that specific area. I wanted to have each note behind another note so I could easily glance at all the surrounding cards while visiting a specific note. Though there is a thematic classification for all notes, just like Luhmann Zettelkasten. The app is not "perfect", but it works as I expected without getting lost in the Zettelkasten workflow.

  Here are a few screenshots using sample medical notes. App has multiple problem, but somehow it's working for me.

  Dashboard
  

  Fleeting
  

  Reference
  

  Permanent
  

  Register
  

  And yes - I use a 38-inch UltraWide monitor so I can see more notes at a time.
• ctietze

  12:44PM

  😆 That's a lot of notes per screen! I never wanted more than 1 note on my ultrawide, now I wonder how good your eyesight must be!

  Author at Zettelkasten.de • https://christiantietze.de/
• firozansari

  12:56PM

  @ctietze said:
  😆 That's a lot of notes per screen! I never wanted more than 1 note on my ultrawide, now I wonder how good your eyesight must be!

  Not enough notes per screen! I’m trying to simulate the workflow of physical index cards, where I can lay out 20-30 related cards on the table at once, and see how they are connected, to make sense of them. I also have a “Zen” mode, where I can reduce the opacity of all other cards and keep only the current card and its related cards more prominent.
• tomp

  3:08PM

  @firozansari said:

  @ctietze said:
  😆 That's a lot of notes per screen! I never wanted more than 1 note on my ultrawide, now I wonder how good your eyesight must be!

  Not enough notes per screen! I’m trying to simulate the workflow of physical index cards, where I can lay out 20-30 related cards on the table at once, and see how they are connected, to make sense of them. I also have a “Zen” mode, where I can reduce the opacity of all other cards and keep only the current card and its related cards more prominent.

  Simulating notes spread out on a table - yes! - that's important. That's very interesting, what you have done. I don't want to have that many because it's too hard to take in and keep in mind. More often I've had as many as half a dozen open at one time.

  The notes in the spread don't have to be limited to being in the nearby ID numbers. There can be others that can join them.

  Don't be restricted to notes, though. I spread out graphics too, like mind maps. I also want to be able to alter the positioning because getting a good layout helps me to understand.

  Here's an example of mine, with not too many items open. I use a second monitor, but it's not widescreen. Maybe it's time I get one...
  
• harr

  3:14PM edited 3:20PM

  @firozansari said:
  Not enough notes per screen! I’m trying to simulate the workflow of physical index cards, where I can lay out 20-30 related cards on the table at once, and see how they are connected, to make sense of them.

  Good idea. I think that a "perfect" ZK app should support seeing and arranging multiple zettels at the same time.

  Some not perfect implementations I remember:

  • Obsidian's Canvas (infinite canvas)
  • Logseq (single pane outliner)
  • Zkn3 (two pane outliner)
  • Obsidian's file navigator (files and folders)
  • Obsidian's Graph (linked nodes)
  • Scrivener