I write a lot every day, but I don’t publish a lot of it since I have this fear of being judged. But I have a lot of ideas and thoughts that can be boring for some people but maybe interesting for others.
I ramble about tools and workflows in Day One and my Zettelkasten. Those are private posts that are not necessarily useful to anyone, but I want to publish them anyway because I can see a history of my thoughts, which can give someone else an idea.
That’s what #DigitalGarden is about, but it is still different. Sometimes, I want to write a journal entry and be done with it. I don’t need a full-fledged Zettelkasten all the time.
Actually, I’m afraid of publishing these ideas, but as we have had success with open-source software in the last couple of decades, maybe open-source thinking can be a helpful thing to master, too.
What do I mean by that? Blogposts without much crafting and maybe even with a lot of grammar errors, but the idea is that I can write about something, then continue thinking about that idea in a new post, and so on. Maybe I’ll run into a conclusion and come up with something cool or ignore the whole thing at the end, but the critical point here is that I should flex my writing more, and my blog is still the best place for that.
I started using iA Writer a couple of months ago for my Zettelkasten writing, and having it as a backbone of my Jekyll site turned out to be great. On the other hand, I still kept my writing workflow in Ulysses, especially for long-form writings. I just wrote about how I use Ulysses projects in my writing workflow.
I wonder if having iA Writer as my only writing app is beneficial. I start to think it is, so I’ll discuss that in this post.
Keeping my writings in a Git repository
Git should be used by more people, not only by developers. It is a powerful system for keeping track of changes in a project, and it’s easy try out new ideas by creating new branches.
Git is made for text, so keeping writings in a repository is a natural workflow. For me, it’s new, though; I always used some form of library-based app for managing my writings where you can export the final product, but the raw material is usually kept in a proprietary database or file format.
iA Writer, on the other hand, uses standard text files – specifically Markdown files – and keeps them in the file system, so we can store our files in Git repositories, which can be edited directly as folders in iA Writer. I use Tower on the Mac and Working Copy on the iPad to manage all my Git repositories and to commit my changes.
The beauty of keeping my writings as simple text files is that I can work on them using multiple apps (even in Ulysses). I like the idea that I can write in iA Writer and edit my documents later in MacVim/ iVim or BBEdit. Different text editors are made for various purposes so that I can use the best one for the task. There is no one-size-fits-all.
Keeping my Markdown files simply in the filesystem, I can also capitalize on other tools like Tmux for managing Vim sessions; using it, I can even write in the Terminal (the original distraction-free writing environment) and have access to multiple panes.
Git is also an open system so I can push changes to any standard Unix-based server over SSH. Keeping my writings up-to-date between devices is not automatic but pretty straightforward to do.
I kept groups where all sections were sheets, then duplicated these groups before significant edits and assigned version numbers for each group, like v1, v2, etc. These names had no meaning other than having a version number for the group.
The triggers for duplicating groups were the following:
Collected and sorted my Zettelkasten notes.
Finished the first draft.
Checked the grammar with Grammarly (which is just another form of editing).
The final version before publishing the post.
Since I can use Git directly with iA Writer, I no longer need to duplicate groups manually. I can use Git to keep the history and mark important milestones.
Keeping history in Git is pretty straightforward: I can commit my changes and have a version history on every file. I can create branches for each writing project, so my main branch only includes finished and published content. This is not that important since all of my posts are siloed into separate folders, but I still keep pull requests open for each article to comment on and see the history of changes in a nice interface.
Pull requests also mark a project’s start and end at the point of opening and merging. This is more of a psychological benefit I like to have: I feel a sense of accomplishment when I finish a project and merge it into the main branch.
Managing milestones is done through Git as well: I commit in Git that I "Published XYZ v1" or "Published XYZ v2", and then optionally, I tag these commits to mark the end of a milestone.
iA Writer can also publish my writings directly to my blog; this can be used as a marker when I reach a writing milestone. There is no need to duplicate anything locally, but I can export a manual version and keep it published as a hidden post on my blog if I want to return to a previous idea I removed.
I call these posts seedlings, and they aren’t visible in any listing, but they have a direct link, which I can use to preview how the final post will look on my blog.
I created seedlings as a tool primarily for gathering feedback from others on a document. It is my homegrown collaboration feature, which uses my site, where I’m entirely in control of my content. I can publish a hidden post, and then people can leave comments as feedback so we can collaborate without external tools.
But most of the time, I "collaborate" with myself, so I’m leaving comments on my seedlings as notes, which can be migrated back to the actual draft.
Creating pull requests for writings
GitHub pull requests are powerful tools, not just for coding but for writing, too. As I develop my writings, I can keep track of them in separate branches and associated pull requests in my Writings repository.
Pull requests allow me to annotate my text files with comments, which can serve as a built-in to-do system for my writing projects. There is a similar feature is built into Ulysses, where I can have annotations and notes on a sheet, which is one of the benefits of having a library-based app backing my raw content.
On the other hand, using open formats makes using different tools for different jobs on the same content possible. So, in this case, pull requests can be used as an annotation and journaling system around the post I’m writing. When I’m done, I can merge the PR into the main branch as I do in my software development workflow, then publish the final article on my blog.
Writing in the Terminal
Using Vim in the Terminal for writing is a new experience for me. I usually work all day in the Terminal, but I have yet to consider it a writing environment. Technically, it is the original "distraction-free writing app."
My primary text editor is Vim; next to iA Writer, I started using Tmux to keep my writing sessions open with Vim inside. It is my favorite place to do development work and works well for writing projects, too.
The beauty of plain text is immediately apparent in the Terminal. My eyes love the nice Gruvbox Dark theme, and more importantly, all of my CLI tools are just a couple of keyboard shortcuts away.
I’ve started to use my Mac more for writing-related projects lately. It is one of the most flexible environments (alongside my iPad) for managing my blog and my Zettelkasten. I spent a lot of time optimizing my Terminal environment for development, so having it available for writing is beneficial since the command line is the best place to work on any plain-text project – the two just pair really well since the UI is also text-based.
I can also jump into a running Tmux session from my iPad using Blink and continue my writing session from where I left off.
Section-based writing
In Ulysses, I used sheets for every section. I don’t have sections in iA Writer, but I can have separate Markdown files and include them as content blocks. Content blocks are not a standard Markdown feature, but they are so easy to work with that I’m fine if other apps don’t support them.
Sections are numbered and represent a sequence. When I want to create a new section, I add a unique number in the sequence. I name my sections 001.md, 002.md, 003.md etc. This workflow is similar to how Stephen Wolfram manages his notebooks in project folders: he creates a new file in the folder and starts writing.
I have a bunch of other conventions too. When I’m doing designs, I’ll typically keep my notes in files with names like Notes–01.nb or SWNotes–01.nb. It’s like my principle of not having too many file categories: I don’t tend to try to categorize different parts of the design. I just sequentially number my files, because typically it’ll be the most recent–or most recent few–that are the most relevant when I continue with a particular design. And if the files are just numbered sequentially, it’s easy to find them; one’s not trying to remember what name one happened to give to some particular direction or idea.
A long time ago I started always naming my sequential files file–01, file–02, etc. That way pretty much any sorting scheme will sort the files in sequence. And, yes, I do often get to file–10, etc. But in all these years I have yet to get even close to file–99.
I see this workflow being similar since writing projects can contain other types of assets, not just Markdown. Markdown files in iA Writer can also include code blocks, which can be stored as separate files. Think about that for a second.
Separate code snippets mean I can run these files directly in the Terminal using Ruby, Swift, or any other CLI tool. This gives me an interactive thinking space for code, like outlining, journaling, or mind-mapping. We have interactive notebooks in different environments, but I can make my writing projects similar with automation. It can be a great way to test and document code.
Let’s say I’m working on a new software project: I can have a docs folder that contains Markdown files linking to external sources in the actual code. Additionally, I can use iA Writer to embed source files as content blocks. When exporting the final version, source files are converted to Markdown code blocks in the output document.
Section-based writing also allows me to work on any part of the text at any time. This is a more natural bottom-up approach that is better than trying to fit my writing into a linear flow, where I start my post with the intro and then write the rest from top to bottom. Writing is the act of trying to fit random ideas together into a final story arc.
Using iA Writer Authorship for marking Zettelkasten notes
One of the main reasons I want to keep all my writing in iA Writer is their new Authorship feature.
It was intended to mark content pasted from other authors or generated by AI, but I want to hack around its intended purpose by marking text that was added from my Zettelkasten differently.
Since I mainly edit my Zettelkasten notes in iA Writer, using the same app as an end-to-end workflow for my final writing projects makes sense. I can switch between my notes and writings and copy and paste text into my drafts. Here’s where the Authorship feature comes into the picture. Since I can paste my Zettelkasten notes as text acquired from other sources, iA Writer would mark these paragraphs in a different style. I actually like this since edits are clearly visible over my original Zettelkasten text.
I have a global Authorship setup in my iA Writer settings, where my Zettelkasten is marked as "Other." This feature was intended for text copied from text-related AI apps, but if you think about it, my Zettelkasten is a "thinking partner," according to Luhmann, so in that sense, marking it as authored by "Other" sources makes sense.
Zettelkasten provides a system that, much like GTD, outlines the necessary physical steps for learning about something, generates new ideas from that knowledge, and links concepts to write a cohesive long-form text.
Creating a story is like developing a skeleton. We will add our precise thoughts on top of this skeleton. These thoughts can come from our heads, or if we use an active note-taking system, our notes can serve as a basis for them.
When we use these notes, we still have to form them in a way that makes sense in the context of the current story. The Authorship feature lets me highlight the differences between a piece of text that is just a source of a draft and the actual text I edited.
Since most of my articles contain notes developed in my Zettelkasten, I want to see these differences. Visually getting a difference between the original note and the edited version makes sense. It lets me visualize the differences between texts from other sources or texts I’m actively writing.
Using iA Writer as an end-to-end writing app
As I mentioned, I’m editing my Zettelkasten in iA Writer. I’m also editing my writings in iA Writer. How about including AI in the same app as well?
I developed a tool a few months ago called RubyGPT, a Ruby gem that lets me use ChatGPT in the Terminal. I also integrated it into iA Writer using Apple Script so I can have an ongoing ChatGPT chat session saved into a Markdown file. These chat sessions are stored in my ~/Documents/Chats folder, which is also added to my iA Writer library. Sadly, this tool only works in macOS, although I can export ChatGPT chat sessions from Drafts, too, where I’m using this action to have a similar workflow.
All my writing-related plain text lives inside iA Writer, so I consider the app an end-to-end tool for all my writing needs. In theory, I can do this with Ulysses, too, which can also work on external files, but iA Writer doesn’t hide the Markdown syntax, so I can see the original text as John Gruber intended.
With the Authorship feature, I can also see the changes I made to externally generated text, regardless of whether it’s coming from an AI source or my Zettelkasten. I still have to do the work and edit this text into a proper post.
I love this integrated workflow of starting with reading, having highlights processed into notes, getting these notes under control, and then using them as the building blocks of my posts. This workflow lets me naturally develop ideas and use them in places where they make sense.
No need to force anything.
I can write about whatever I feel like at the moment.
There are multiple systems where you can only append new information at the end of the chain. There is no chance to modify the history in these workflows (or it’s very convoluted).
But why is it beneficial to use an append-only workflow? I’ve been fascinated by these systems lately since we can learn so much about our workflows by keeping previous states around.
The core idea of an append-only information storage system is to only add new information without removing existing data, which has excellent benefits: we can see ideas getting developed, we can keep versions of a file, or we can capture information for the historical sake of it.
Analog systems like the Antinet Zettelkasten or the Bullet Journal force us to organize information by appending it. Digital systems can be used like this too, but they need the right mindset from us so we don’t remove mistakes.
In this post, I’ll discuss using email, Zettelkasten, and Git in the append-only information organization context.
Email is a popular workflow for developing ideas
In essence, idea development leverages the fact that you rely on the history of the idea as you progress it. Its history serves as a breadcrumb to go back in time and see how it was developed.
Drafting something is a long process, and the most apparent tool some people use is email. It can be a great append-only note-taking tool and storage medium. Here’s an excerpt from How I use append-only log to store information:
If you are working on a piece of text for a long time, you can just keep it as a draft and keep working. It will be auto-saved.
I am a fan of the bullet journal method. Handwritten text is immutable. The same goes for emails. Once you send it, it becomes immutable.
To show another example of how email can be used for drafting, here’s how Steve Jobs used email to write his Stanford commencement speech:
In January 2005, John Hennessy, the president of Stanford, asked Steve to give the commencement address to that spring’s graduating class. Steve agreed.
On and off for the next six months, Steve took stabs at writing his talk. He emailed stories and memories to himself. He asked friends, Apple colleagues, and the screenwriter Aaron Sorkin for their thoughts. In the end, however, he wrote the speech on his own. Even three days before the event, Steve was unsatisfied with his talk. He sent it to a friend, warning, “I’ll send it to you, but please don’t puke. I never do stuff like this.” He was still refining the speech the morning that he gave it. Uncharacteristically, Steve read from the lectern, rather than memorizing his text (as he did with Apple keynotes) or speaking extemporaneously from a few scrawled notes (as he did in nearly every other talk).
Steve was happy with the speech—he emailed himself a copy a few days after giving it—but he generally deflected the praise that he received for it. “I bought it on CommencementSpeeches.com,” he joked to one person. The commencement address has been viewed millions of times online and is included[…]
Steve Jobs once mentioned that he constantly sends notes to himself in his inbox as a reminder. This process is similar to the capture method used in Getting Things Done (GTD). However, GTD does not address how we can use our inboxes to develop ideas further.
Using our email Inbox effectively to develop ideas
Sometimes, I also use email to develop ideas in my inbox during the GTD capture phase. Although I think there are better tools for this – like Drafts or my Zettelkasten – some conversations are present only in email, so I can leave notes for myself in a thread by starting a reply to a message and sending it to my address. This workflow feels like a poor man’s version of HEY’s sticky notes.
I have a separate “Inbox” contact card saved with the +captured text appended to my email address (someone+captured@domain.com), so when I want to remind myself about a message, I’m emailing ideas to this address and use the conversation view in Mail to develop them further by replying in place.
I can also schedule these messages, which act like an integrated Tickler File. I can leverage that Mail has an excellent conversations view, so the Send Later feature can resurface any thread when I’m scheduling a forwarded message to myself. It will reappear in my Inbox with the whole conversation, which gives me the context to figure out what the note is about.
A quick aside about Remind Me and Follow-up in Mail: We have features in Mail in iOS and macOS that could be useful for emailing follow-ups, but they have two problems.
Remind Me only works for emails in the inbox, so if I archive an email, it silently moves it to the top of the Archive mailbox which is useless.
Follow-up is a black box driven by “AI,” and there is no way to set it up manually for specific emails that I want to track.
It uses three days by default, but I’m not sure if it works for every sent email.
On the other hand, I also use a GTD “Waiting for…” list to track items waiting for a reply. → 2.7.8
To conclude, emailing notes to ourselves is semi-private. We’ll see the email as part of the thread, but others won’t. This way, we can leave notes in place, even in threads with others.
Here are some concrete contexts where I’m adding notes in an email thread:
code review comments
ideas about a project we’re discussing
capture an idea on the phone, which can be seen later on the desktop when I’m processing emails
Appending information in a bottom-up system like GTD and Zettelkasten
Both GTD and Zettelkasten are bottom-up approaches for getting a grasp on ideas. These frameworks don’t start with what we want to achieve but what we have now.
In GTD, the idea development process is the Natural Planning Model. In a Zettelkasten, this is the follow-up note method (or Folgezettel): letting ideas be developed naturally.
The outline-based Zettelkasten
As I mentioned, follow-up notes show how an idea was sparked and developed over time. Understanding this development process heavily depends on the context of the actual Folgezettel.
Since follow-up notes show us the idea development, we can safely say that we aren’t storing the result of our thinking but the thinking itself.
What’s more important is to keep these ideas structured so we can follow their line of thinking even for years to come.
I can’t say that Luhmann’s Zettelkasten implementation was a big outline because it is way more complicated than that. But I still like to organize notes in a master outline structure for my version of the Zettelkasten since high-level branches are what get me started on an idea that becomes something more complex later.
The Zettelkasten outline shows me the history of idea development. When I add a new note to the Zettelkasten outline, its place will define the order of the note relative to others. It means that the note is connected to a parent and/or a sibling so that I can see the development of an idea in a thread-like structure.
I only append to the Zettelkasten outline and never move stuff around since I use numeric IDs to mark their fixed position. This is a customized version of the alphanumeric note ID that Luhmann used in his Zettelkasten.
Since mine is organized in an outline structure, there is no need to link all notes to every direction. In the tree structure, all notes can be connected to a parent, next, and previous sibling. Not all of these connections are present, but one will be there since a note needs to be appended somewhere in the outline.
Because we usually organize conversations around threads, our thought development can be understood as a conversation with ourselves (or our Zettelkasten, if we use the analogy by Niklas Luhmann).
The outline-based Zettelkasten will force us to think about the place of a note in relation to other notes. Much like the physical Zettelkasten, in an outline-based digital version, we have to append the note to a tree structure. This method will ensure that we automatically have follow-up notes.
The capture log
One of the most interesting steps of GTD is the capture step. A capture log is a journal-based version of the inbox, where ideas are appended in a timeline-based manner.
The capture log was an idea first mentioned by Merlin Mann, where he explained that he wanted to yell into the void and let Siri capture his ideas with automatic metadata like creation date, location, and, optionally, the weather. It’s yet another inbox that we have to process.
The inbox is a medium that stores items that change frequently. It is a temporary holding place for new information in the short term. We mainly change information in it (add and remove), but in the append-only workflow, these items can be kept as an idea log, too. If we use inbox items as a trigger to create new projects and/or next actions in our GTD system, after creating these, we can complete source items in the inbox and log them. In that sense, we have a capture log as an automatic journal where we keep a history of our ideas. As Merlin said, it’s like the tail of our life.
Keeping versions
There are two ways people keep file versions around. If you worked on any source material like Word or Photoshop documents, you are probably familiar with versioning your files using the “Save As…” command.
There is an ongoing meme about sending the “final final final” version to a client, so in theory, this is not a desirable workflow. Still, with a proper workflow in place, we can use it to mark milestones in a document lifecycle.
But before we go there, let’s talk about Git since it’s a tool created for this exact task: keeping versions of files.
Versioning with Git
Git is an append-only information storage system, too, because when we change code in the software development context or update any text kept in a Git repository, we’re adding a new state to a source material. We pack it up in a commit, which is then appended to the log.
Versioning makes software development more manageable since we don’t have to worry about how changes are looking in our working copy: the code is constantly forming. The state stored in Git will show changes, mistakes, refactorings, and removals, which is the natural part of everyday work. Git lets us see the natural evolution of the code base, which is similar to other examples mentioned here.
Git can be used for keeping the history of non-code-based source files, too, like photos, illustrations, PSD files, Markdown writings, etc. My Zettelkasten is a Git-based source material, which I use as a starting point to write about interesting ideas.
People forget that Git isn’t just tied to store source code. We can create a Git repository for almost any source material we’re working on and keep a history of the evolution of these files.
Keeping manual versions
Sadly, keeping a Git repository works only with file-based apps. It doesn’t work for database-based apps like Ulysses, which I’m writing this article in.
On top of Git, it’s still worth keeping manual writing versions, especially after reaching milestones like the first draft, the first edit, or the version before spell-checking. We can usually keep manual versions around in database-based applications by simply duplicating the primary resource of the app.
I like how Aaron Draplin duplicates layers in Illustrator to keep a history of changes and branch out new ideas. In the same way, I duplicate groups in Ulysses for writing projects so that I can have a trackable / branchable writing workflow. Ulysses also keeps versions of projects, but manual versioning can be tied to milestones in the writing workflow.
My versioning system is based on the following rules:
I keep a group where all sections are sheets, then I duplicate these groups before significant edits and assign version numbers for each group, like v1, v2, etc. These names have no meaning other than having a version number for the group.
The triggers for duplicating groups can be the following:
Collected and sorted my Zettelkasten notes.
Finished the first draft.
Checking grammar with Grammarly (which is just another form of editing).
The final version before publishing the post.
It can change, so this group will allow me to compare what type of changes I usually make after I publish something.
Conclusion
In this post, I collected many workflows that follow the append-only organization system. To recap:
Email can capture information and take notes in conversation threads.
The outlined-based Zettelkasten allows us to create follow-up notes for long-term thinking and idea development.
Git and manual versioning is a great way to try out new ideas on source files.
These workflows are appending new information at the end of a stack, so we will have a breadcrumb to see how changes affect our work over time.
The main idea I would like to highlight is that by appending information, we don’t delete anything; we add new information at the end. Having all changes visible in the chain (even the bad ones) makes it harder to erase mistakes.
There are multiple ways to develop ideas. Sometimes the best one is where you can’t change the history of an idea. It’s there as breadcrumbs to go back in time and see how an idea was developed.
Choose any email client you like and basically dump all your PDFs, notes, digitized papers, files into it as it arrives from various sources. Just write a meaningful subject that you can search for later. You can use labels or folders to organize, but mostly just send it to an email address of your choice and archive it. Usually, you will not even read it again after you have saved it.
The E-mail format itself is well understood and has many features. The max attachment size of most service providers is around 20 MB. It’s more than enough. Try to use plain text for just taking short notes and messages to yourself. If you want to dump more than 20mb of files, just archive it or split into many emails or upload it to cloud storage and copy and paste the link to email.
When you need the information. It’s there. Always.
No more fiddling with the file managers, renaming. It is saved as it is.
Even if you would like to edit, you can just forward the message again to yourself with the edit and delete the original one.
You can also use it to schedule mails and track future tasks, TV shows, anime, movies or Reminder to yourself in the future. If you are working on a piece of text for a long time, you can just keep it as a draft and keep working. It will be auto-saved.
I am a fan of the bullet journal method. Handwritten text is immutable. The same goes for emails. Once you send it, it becomes immutable.
I don’t know if other use emails to store all their digital content in emails like me. But it’s a pretty neat trick.
In January 2005, John Hennessy, the president of Stanford, asked Steve to give the commencement address to that spring’s graduating class. Steve agreed.
On and off for the next six months, Steve took stabs at writing his talk. He emailed stories and memories to himself. He asked friends, Apple colleagues, and the screenwriter Aaron Sorkin for their thoughts. In the end, however, he wrote the speech on his own. Even three days before the event, Steve was unsatisfied with his talk. He sent it to a friend, warning, “I’ll send it to you, but please don’t puke. I never do stuff like this.” He was still refining the speech the morning that he gave it. Uncharacteristically, Steve read from the lectern, rather than memorizing his text (as he did with Apple keynotes) or speaking extemporaneously from a few scrawled notes (as he did in nearly every other talk).
Steve was happy with the speech—he emailed himself a copy a few days after giving it—but he generally deflected the praise that he received for it. “I bought it on CommencementSpeeches.com,” he joked to one person. The commencement address has been viewed millions of times online and is included[…]
These use cases are similar to how I use email threads to develop ideas in the GTD capture phase, where I’m leaving notes for myself within an email thread. All I have to do is send a reply to my own address by replying to an email, so Apple Mail keeps the message in the same thread.
One of the benefits of using this method is that I can still see the email as part of the thread, but my notes will be kept private.
This is helpful for various purposes, such as making code review comments or jotting down ideas by replying to email notifications but changing the recipient to my own address, which acts a bit like the poor men’s version of HEY’s sticky notes
I also have another app where I keep journal entries called Everlog. I’m thinking about applying the same append-only storage idea there and never editing my Everlog entries after I added them. It is also an append-only app, where entries shouldn’t be changed afterward, only deleted. I can always add a follow-up to an entry but I should never change it, so I can see how something was developed over time.
This is why I like to use Drafts for capturing and drafting ideas. I can easily edit them while I’m working on the idea, but I shouldn’t change them too much after I share them with their destination app (except when I continue working on them).
I like these ideas, but especially gathering all information.
Let’s say I need to reply to an email. I start by reading the email I’m supposed to reply to. If there’s any more information I need to be able to answer that email, I go and get that information. I then dump all the information I have into an email draft for easy reference, and write my email from there.
I learned this behavior by keeping a Zettelkasten for writing. It is always easier to start with existing content rather than starting from scratch.
These days I even use journaling as a tool for getting started. If I have no idea what’s the next action on something, I begin to write about it in my notebook. Sooner than later, I figure out something by rambling about the problem in my journal.
You don’t need to start a second brain, or do some weird PKM stuff, you just need to have a place full of things that will help you out. Record things you find interesting, things you need to remember, things that might help you work later on, literally anything you might need later on. You don’t need to start a commonplace book or anything, you just require a notebook around, all the time.
I start to wonder if there is a more straightforward way to manage ideas other than keeping a full PKM or Zettelkasten.
This year is going to see my journal/log’s 10th anniversary and 100th notebook.
I read the whole article and took a lot of notes which inspired me to think about how I can consolidate my capture (logging) habit a bit more into one place, but still keep multiple capture tools.
After finishing this essay, it feels like Dave accidentally invented GTD for himself in a different form based on a stream of captured ideas that are moved up in the chain to have projects and next actions.
The part at the end where he writes about weekly, monthly, and yearly recaps feels very GTD-esque.
I actually tracked my time in a notebook like this before. I had a timestamp of when I started and when I ended a session of work. I have a long history of working in sessions, as I used to do a lot of freelance work, which requires time tracking (a session means that I focus on one task for a more extended period of time). My only question is how Dave transcribes his notebook entries into his digital system? I did it by hand, and it was awful.
Anyway, this is an excellent write-up of a fantastic system that I’m going to use as inspiration.
I constantly tweak my workflows this time of the year. I usually provide tools for others—that’s what I do for a living—but I also have to keep my knives sharp.
I like to think about my Zettelkasten being a large outline. Keeping it inside Bike could be beneficial.
I’m trying to mimic the analog Zettelkasten (or Antinet).
I won’t use an analog one since I like the digital one’s benefits better, but I also want ideas from the analog one.
I’m a programmer and I use my Zettelkasten to understand coding concepts. I have some code snippets stored in SnippetsLab, so it’s easier to link to those from my Zettelkasten outline than keeping them on paper.
I can use the classical LuhmannIDs to add an ID each note.
I can nest notes under each other.
I can easily link notes together thanks to the Bike and Hook integration.
Disadvantages
I don’t have backlinks, but I’m not sure I need that inside a Zettelkasten.
daunting projects to compete with little dopamine hits
How can I increase the dopamine hit of completing a project?
When you have a digital Zettelkasten, there’s a third option: do small things with small notes, straight from your phone.
When we have a small amount of time, we can do small things with our notes, even on our phone.
A lot of small steps can take us very far.
Yet instead of these tiny actions adding up to essentially nothing, they feed your curiosity in a productive way and drive your projects forward.
GTD takes us closer to our goals with small steps.
We have to set up small next actions when we are tired, so we can do a lot of small things which gives us some form of baseline success.
Instead of using my brain power to try to remember things, I’m using it to write better articles, newsletters, and books. I finally found a bicycle for my mind.
We have to use the brain for doing creative stuff, not remembering things.
Yes, we should rethink educational curricula centered around memorization, but looking things up is at some point a waste of working memory. That’s brain power that could be used to think creatively, rather than to try to grasp a bunch of facts just retrieved.
Instead of looking up information that we have to understand, we can use the energy of the brain for creative things.
Sometimes ignorance is more comfortable than learning, because learning means we have to go through the work of changing.
Learning is harder than ignoring facts.
It’s not so easy it’s boring, and it’s not so hard it’s a slog.
We can create new permanent notes with Craft inline of another note, which can be extracted out into a new note.
Some examples of fleeting notes, from my own Zettelkasten:
Uses of fleeting notes:
highlights from books
highlights from articles, blog posts
our ideas
Yes, Henry Ford’s assembly line went quickly by eliminating waste, but the cars had to be designed first – a process that wasn’t so easy to speed up.
It’s easier to automate a system than invent it. That’s a long and hard process.
As you read, make fleeting notes.
…
Once you’ve exported your highlights, review them and highlight, once again, the parts of those highlights that are the most interesting.
…
Look at the highlights of your highlights and re-write the interesting ones in your own words.
I’m taking notes as I read, I don’t rewrite them afterward.
Associative thinking promotes a positive mood, so it shouldn’t be a surprise how fun this task is.
It feels good when we find a connection between two Zettelkasten notes.
Now take only the most interesting ideas from the literature notes, and turn each into individual permanent notes.
…
Next, I have a link back to the literature note from which I wrote this permanent note. That looks like this:
We can link permanent notes from literature notes, so we can see in backlinks where it’s coming from.
If you try this process and it feels boring to you, it may be because the material you’re reviewing doesn’t feel relevant, doesn’t interest you
It is a warning sign if we are bored while writing our Zettelkasten. It means that we don’t care about the topic, or we know it well already.
The main con of Folgezettel is it’s unnecessary in a digital Zettelkasten. Folgezettel is most advantageous in a paper-based Zettelkasten, because it allows you to easily arrange paper based upon how a sequence of notes follow one another.
Having a series of notes (or outline of notes) can be helpful in a digital Zettelkasten too because we are forced to stop and think about where a new note should fit in the outline.
create keywords based upon patterns you see, which inform theories you’re working on.
Having an index is the same as having “Table of Contents” notes.
The writing process starts when we create our notes using the physical routine of the Zettelkasten method. We’re proactively making drafts by connecting our notes, so instead of writing everything from scratch, we can collect related notes together and edit them to form a more coherent basis for a manuscript. In practice, we’re trying to find order in our notes, because from the Zettelkasten’s perspective, each note can relate to another one from any direction.
This whole workflow is the result of the Zettelkasten letting things naturally emerge.
Connecting Zettelkasten notes together shows us each milestone of a forming thought. It is a history of idea development, so it’s not made to store reference information. We aren’t storing the end result of our thinking but instead of the thinking itself.
GTD and the Zettelkasten methods are bottom-up processes, which means we don’t start with setting a goal that we want to reach, but instead we work with the things that we have at the current moment. The Zettelkasten – similarly to the Natural Planning Model of GTD – naturally let your notes to form into a concrete thing. It is the complete opposite of the traditional view of research which starts by setting the final goal or state that we have to reach.
A practical tip for writing a note in a Zettelkasten is to write phrase the first sentence as a quick summary. Every article on Wikipedia starts like that this, so it’s very easy to get a quick grasp of what is the article about. Later more background information can be detailed.
Reusing my blog to be my Zettelkasten can be beneficial because I’m always planning to publish longer blog posts, but at the end, I just don’t do it. I don’t enjoy the process of writing long-form articles, because it forces me to think about the content from the reader’s point of view. It makes me nervous since it’s a very different state of mind, other than just writing for myself.
I write a lot of things every day and one of those things is my Zettelkasten. It contains short notes (Zettels) which I captured, processed, and organized. It has interesting content – for me at least – and I like the process of writing in it.
The idea to merge the essence of blogging with the process of keeping a Zettelkasten is very interesting, which should be explored more deeply. A WordPress blog as a tool for keeping a Zettelkasten fits very well because of the following reasons:
Zettelkasten should be searchable, this blog is searchable as well.
Zettels should be linked together. Since a blog is just a website, it’s made for making links.
I can easily tag my notes on a blog.
Each Zettel has a unique ID in the form of a public link, I don’t have to generate IDs manually.
Keeping a public Zettelkasten can be a concern, but I can mark some Zettels as private.
Today, I constantly remind myself before publishing any article that I am publishing this on my blog (which means that I can publish anything I want), and that it doesn’t matter if people read it or not. I’ll just keep doing my thing, because I enjoy doing it.
Maybe this is the best article yet about using the Zettelkästen method. Use it as an entry point for the system, then head over to zettelkasten.de to learn about the details of each step in the process.
I like to take walks when I have to think about something. I capture rough ideas with Drafts by writing down bullet points on my iPhone.
Later, when I sit down and process these notes, I try to edit and rephrase a draft into a full-blown zettel, which is added to DEVONthink.
I keep these ideas in DEVONthink for a couple of days to let my subconscious mind make connections and may came up with better solutions. I always add multiple follow-up zettels linked to the original one.
Since these zettels and all the related reference material kept in the same group in DEVONthink, I can use Shortcuts on iOS to create a mindmap from it. The generated mindmap links back to each original zettel, so this makes a visualized version of my notes. It helps me to use the mindmap to create a plan and may came up with concrete next actions, that’ll be moved into OmniFocus at the end.
