I can relate to ZettelDistraction. My biggest issue with my Zettelkasten, now that I’ve accumulated a decent number of notes over the years, is that I just don’t trust my past self. It’s as if he’s another person—I have to rethink everything, double-check the info, make sure the sources are actually correct.
On top of that, there’s the issue of information overload: redundant or even duplicate zettels, and good, valuable stuff getting buried in a pile of junk.
I’ve also tried guessing how useful a note might be for my future self, but honestly, it feels like a total waste of time. The best approach I’ve found is to organize my zettels into “boxes” (whether it’s folders or tags doesn’t really matter) and use them as quickly as possible for a specific project. Even better is only writing zettels with a project in mind—a fully top-down system. In other words, declaring PKM bankruptcy after each project.
@KillerWhale said:
Ever since I discovered the method and I glimpsed how valuable it could be to my use case (writing stories, which relies extremely on emergence), I have been tweaking, experimenting, trying software, finally landing on Obsidian for a long time, importing decades of notes into it, drowned, retreated to Bear in search of a lighter environment, finding myself looking for a more powerful environment again, getting drowned in Obsidian again, rinse and repeat.
I am now trying an experiment: declaring PKM bankruptcy. Begin an entirely new Obsidian vault, free from the years of "I want to learn that but never get around to" plugins (ahem Dataview), half-baked CSS snippets and various layers of sediment that has accrued and made the whole thing unwieldy. And then only add building blocks only if I commit to them and master them to make sure that I grow with the environment and methods.
My previous content, which has never been properly processed anyway, will become a giant inbox for the future. In the meantime, I'm still working in Bear, as I prepare – as a strictly hobby project – a proper future Obsidian vault, only adding back functionality that I find myself missing.
I'm sure people here found themselves starting their Zettelkasten / PKM again from scratch or wanting to. Did you? How did it work for you?
This is the benefit of a feature minimalistic approach: There is almost not clutter. I never had to restart my system since the beginning. Only endure the hardship of difficult to export formats, which was gone after Christian converted me to plaintext.
In my Zettelkasten, there should be even old Zim-Wiki files with the complete Zim-Wiki Meta-data. This is no problem.
No, you're absolutely right. Although I do like me bells and whistles. In this new approach, I'm taking care to separate the interoperability of content (plain text, with affordances that can be used even if the app goes away; block links, for instance, can still be followed like UIDs would) while using separate parts of the app as a different, proprietary beast entirely (Dataview). But the two approaches should not be mixed; it should be recognised that having everything in the same place is a convenience, not a must-have. In essence, it's two different apps living under the same roof, opening cross-linking, which is nice, but could be a database app.
Okay, now I have to research database apps…
"A writer should write what he has to say and not speak it." - Ernest Hemingway
I'm reminded of poor online friend Jack Baty who can never seem to settle on a PKM approach, oscillating between 5 or so over the years, including publishing platforms/blogs.
It's easy to reply "Don't! There's no greener grass on any side."
But that also misses the point, I believe, when in the end one just wants to explore and tinker. And not get stuff done all the time.
All that being said, I believe there's hope in simplicity of a Zettelkasten, but maybe that's not what is being searched for 😅
Regarding inboxes and the Collector's Fallacy, I use Zotero as my "inbox" for most things. If I find a worthwhile source, I'll record it in Zotero. If there is a PDF attachment, I'll add it to my media directory and add it to the citation, with the Better BibTeX citation key as the filename. Otherwise, I will leave Obsidian open for this week's note. I write "fleeting notes" on loose paper or in odd notebooks. Most of the time, the fleeting notes go into the trash.
In Obsidian, the Calendar plugin works with the Periodic Notes plugin to show the current week. The Calendar in the rightmost pane in the screenshot below helps this unscheduled old fool stick to a schedule. I'd rather see the current week than use a Daily Note since these accumulate. The screenshot shows this is week 48.
I use the Front Matter Title plugin to display the value of the title: YAML variable, which in my system is the id: followed by the H1 (level 1) section header. I configured the plugin to show the title: variable in the search leaf and suggest modal dialog boxes. WikiLinks will automatically include the title alias.
The Front Matter Title plugin's configuration includes the note filename, identical to its YAML variable id: in my system, with the note title: YAML variable as its alias. In source mode, this appears as follows.
In Obsidian's "reading view," the WikiLinks show the filename, equal to the note ID (id:) followed by the linked note's title (title:).
A keyword followed by a timestamp is the latest and, God willing, the last iteration of my ID formats. Unfortunately, the screenshots only show the older hybrid Folgezettel IDs. @Sascha was right again: there is no point using Folgezettel in a digital system (for me, anyway) because they add unnecessary complexity; they take time to generate, and I never look at them again. The keywords at the beginning of an ID help me locate related notes, trading off over-categorization for ease of reference. I have an Obsidian template to create new IDs. Timestamps by themselves have been disorienting; I have yet to drink the timestamp ID KoolAid.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
It isn't, strictly speaking. I should have said "future proof". If the dev and/or Obsidian stop maintaining it, it still relies on a custom way to parse data and that feature will not work in other Markdown apps. Where block and header links, as well as transclusions, can still be followed manually through search.
All that being said, I believe there's hope in simplicity of a Zettelkasten, but maybe that's not what is being searched for 😅
Experimentation is indeed fun, but fun should be limited to its rightful place 😅
Hey, I managed to settle on a task management app (OmniFocus) and I haven't moved from it in over ten years. There's hope for me yet.
"A writer should write what he has to say and not speak it." - Ernest Hemingway
@KillerWhale said:
It isn't, strictly speaking. I should have said "future proof". If the dev and/or Obsidian stop maintaining it
It is quite future proof as basic dataview syntax is self-explanatory, it will be easy to quickly script replacements if you need. You can make it even more future proof by moving dataview queries to separate page and just embed them. They don't make your data unusable in any sense
@KillerWhale said:
It isn't, strictly speaking. I should have said "future proof". If the dev and/or Obsidian stop maintaining it
It is quite future proof as basic dataview syntax is self-explanatory, it will be easy to quickly script replacements if you need. You can make it even more future proof by moving dataview queries to separate page and just embed them. They don't make your data unusable in any sense
If you are able to reproduce the function yourself and you can do it in a way that it doesn't throw any nuts in your engines.
I, personally, fail even the first condition. So, relying on Dataview would be a "soft" boxing in for me. I would have all the text files, but also would have a workflow dependency that creates quite some change resistance.
Comments
@KillerWhale
Embrace the progress!!!
This thread is really good.
I can relate to ZettelDistraction. My biggest issue with my Zettelkasten, now that I’ve accumulated a decent number of notes over the years, is that I just don’t trust my past self. It’s as if he’s another person—I have to rethink everything, double-check the info, make sure the sources are actually correct.
On top of that, there’s the issue of information overload: redundant or even duplicate zettels, and good, valuable stuff getting buried in a pile of junk.
I’ve also tried guessing how useful a note might be for my future self, but honestly, it feels like a total waste of time. The best approach I’ve found is to organize my zettels into “boxes” (whether it’s folders or tags doesn’t really matter) and use them as quickly as possible for a specific project. Even better is only writing zettels with a project in mind—a fully top-down system. In other words, declaring PKM bankruptcy after each project.
This is the benefit of a feature minimalistic approach: There is almost not clutter. I never had to restart my system since the beginning. Only endure the hardship of difficult to export formats, which was gone after Christian converted me to plaintext.
In my Zettelkasten, there should be even old Zim-Wiki files with the complete Zim-Wiki Meta-data.
This is no problem.
I am a Zettler
@Sascha But, the bells! The whistles! Dataview!
No, you're absolutely right. Although I do like me bells and whistles. In this new approach, I'm taking care to separate the interoperability of content (plain text, with affordances that can be used even if the app goes away; block links, for instance, can still be followed like UIDs would) while using separate parts of the app as a different, proprietary beast entirely (Dataview). But the two approaches should not be mixed; it should be recognised that having everything in the same place is a convenience, not a must-have. In essence, it's two different apps living under the same roof, opening cross-linking, which is nice, but could be a database app.
Okay, now I have to research database apps…
"A writer should write what he has to say and not speak it." - Ernest Hemingway
PKM: Bear + DEVONthink, tasks: OmniFocus, production: Scrivener / Ableton Live.
how is dataview proprietary?
I'm reminded of poor online friend Jack Baty who can never seem to settle on a PKM approach, oscillating between 5 or so over the years, including publishing platforms/blogs.
It's easy to reply "Don't! There's no greener grass on any side."
But that also misses the point, I believe, when in the end one just wants to explore and tinker. And not get stuff done all the time.
All that being said, I believe there's hope in simplicity of a Zettelkasten, but maybe that's not what is being searched for 😅
Author at Zettelkasten.de • https://christiantietze.de/
Regarding inboxes and the Collector's Fallacy, I use Zotero as my "inbox" for most things. If I find a worthwhile source, I'll record it in Zotero. If there is a PDF attachment, I'll add it to my media directory and add it to the citation, with the Better BibTeX citation key as the filename. Otherwise, I will leave Obsidian open for this week's note. I write "fleeting notes" on loose paper or in odd notebooks. Most of the time, the fleeting notes go into the trash.
In Obsidian, the Calendar plugin works with the Periodic Notes plugin to show the current week. The Calendar in the rightmost pane in the screenshot below helps this unscheduled old fool stick to a schedule. I'd rather see the current week than use a Daily Note since these accumulate. The screenshot shows this is week 48.
I use the Front Matter Title plugin to display the value of the
title:YAML variable, which in my system is theid:followed by the H1 (level 1) section header. I configured the plugin to show thetitle:variable in the search leaf and suggest modal dialog boxes. WikiLinks will automatically include the title alias.The Front Matter Title plugin's configuration includes the note filename, identical to its YAML variable
id:in my system, with the notetitle:YAML variable as its alias. In source mode, this appears as follows.In Obsidian's "reading view," the WikiLinks show the filename, equal to the note ID (
id:) followed by the linked note's title (title:).A keyword followed by a timestamp is the latest and, God willing, the last iteration of my ID formats. Unfortunately, the screenshots only show the older hybrid Folgezettel IDs. @Sascha was right again: there is no point using Folgezettel in a digital system (for me, anyway) because they add unnecessary complexity; they take time to generate, and I never look at them again. The keywords at the beginning of an ID help me locate related notes, trading off over-categorization for ease of reference. I have an Obsidian template to create new IDs. Timestamps by themselves have been disorienting; I have yet to drink the timestamp ID KoolAid.
GitHub. Erdős #2. Problems worthy of attack / prove their worth by hitting back. -- Piet Hein. Alter ego: Erel Dogg (not the first). CC BY-SA 4.0.
It isn't, strictly speaking. I should have said "future proof". If the dev and/or Obsidian stop maintaining it, it still relies on a custom way to parse data and that feature will not work in other Markdown apps. Where block and header links, as well as transclusions, can still be followed manually through search.
Experimentation is indeed fun, but fun should be limited to its rightful place 😅
Hey, I managed to settle on a task management app (OmniFocus) and I haven't moved from it in over ten years. There's hope for me yet.
"A writer should write what he has to say and not speak it." - Ernest Hemingway
PKM: Bear + DEVONthink, tasks: OmniFocus, production: Scrivener / Ableton Live.
It is quite future proof as basic dataview syntax is self-explanatory, it will be easy to quickly script replacements if you need. You can make it even more future proof by moving dataview queries to separate page and just embed them. They don't make your data unusable in any sense
If you are able to reproduce the function yourself and you can do it in a way that it doesn't throw any nuts in your engines.
I, personally, fail even the first condition. So, relying on Dataview would be a "soft" boxing in for me. I would have all the text files, but also would have a workflow dependency that creates quite some change resistance.
I am a Zettler