I try to operate on the “Nothing Doesn’t Go in Here” principle. Flipping through the notebook that is on my desk right now, I see shopping lists, notes from conference calls, sermon notes, a little chart I made when working on some invoices for Relay, a doodle of the Widgetsmith icon I made for some reason, and a lot more. A receipt for a recent meal with a friend fell out of it onto my lap; I’ll probably tape that into the notebook for safekeeping.
The good thing about Field Notes is that you don’t have to care about it. It doesn’t feel pristine like some other brands. So, I mainly capture similar things, but I group them by date. I have meeting notes, programming session notes, random ideas, outlines, journal entries, etc.
These notebooks are a trail of breadcrumbs dating back almost 15 years. If I flip through an old one, I get a glimpse of what was going on in my life at that time. I can go to the notebook I was using when we launched Relay, or when I quit my job. I like having them on hand; seeing them in my studio each day makes me happy.
I never scanned my old Field Notes but kept them safe in a wooden box. I don’t care if they are destroyed someday since I use my notebooks as a temporary capture tool. If something is interesting, I’ll transfer it to my GTD system or just scan that part of the notebook.
January 2025 marks Script Debugger’s 30th anniversary. It’s been a very long run for a two-person effort. Script Debugger began as a Classic MacOS product, survived Apple’s near-death experience, transitioned to macOS X and migrated across 4 CPU processor types. We are so grateful for the support we’ve received over these years. This support allowed us to keep working on Script Debugger much longer than we ever imagined.
Shane and I are retiring and the effort and costs associated with continuing Script Debugger’s development are too great for us to bear any longer.
I bought this app about 2-3 years ago because I was getting serious about learning AppleScript, and in a short amount of time, it became an important part of my workflow. As I mentioned, I learned AppleScript with the help of Script Debugger’s awesome live inspection feature.
Since then, I have used this app to build many scripts that I use in my everyday workflow.
I don’t know the current state of AppleScript inside Apple, but I know that the difference between Script Debugger and Script Editor is night and day. Script Debugger should be part of the system, which is why I feel sad that another great Mac app, especially one with such a long history, is getting retired.
In June 2025, Script Debugger will no longer be offered for sale and all support and maintenance will cease.
At this time, Script Debugger will become a free download. Links to all versions of Script Debugger back to 5.0 will be posted, along with registration numbers that can be used to activate the software. These free versions of Script Debugger will be provided as-is and without any maintenance or support.
Currently, the developers plan to leave it as is. The problem with this approach is that any future macOS update could break Script Debugger. It’s not like 1Password 7, which, after years, I still keep around because I’m not going to migrate to their stupid Electron app. Script Debugger is a complex beast, so any new Windows Vista-style “security” dialog could kill it in an upcoming version. And boy, Apple has been really into “Cancel or Allow” lately.
Will Script Debugger become an open-source project? No. Unfortunately, there are portions of the Script Debugger source code we do not have the right to release.
I’m not sure how the app could be saved. I created a topic on MPU to let people know about it. Open-sourcing will not work since there are licensing issues, so the last resort is for someone to buy it. Or maybe some people in the Macscripter.net community could take care of it as Late Night Software “contractors.”
I don’t know yet, but it’ll be pretty sad the day when Script Debugger stops working.
Just an aside: it makes me wonder why we have Emacs and Vim still around alive and well…
GTD is a collection of relatively simple tactics for coping with, prioritizing, and organizing the things you want to do. Many of the methods relate to organizing your own projects, using a handful of context-based to-do lists (e.g. a list of things to do at the office, at home, while waiting in line, etc). These lists consist of simple tasks. Those tasks are, in turn, derived from another list, of “projects” – things that require more than one task, which can be anything from planning dinner to writing a novel to helping your kid apply to university.
I have never seen next actions mentioned like this: tasks that are derived from another list, a list called projects. The thing I like about OmniFocus (and TaskPaper) is that projects are outline headings, and next actions are simple rows. It naturally blends the two together.
Most of the internet is still on the web, which means it can be bookmarked, which means that it takes me one second to add it to the group of things I’m staying on top of, and one second to remove from that group. I get up in the morning, middle-click the “unfucked rota” item in my bookmarks pane, make a cup of coffee, and then sit down and race through those tabs, close-close-close.
It takes less than a second to scan a tab to see if it’s changed (and if I close a tab too quickly, the ctrl-shift-T “unclose” shortcut is there in muscle-memory, another habit). The whole process takes between one and 15 minutes (depending on whether there’s anything useful and new in one of those tabs).
I like the idea of using tabs as a list for next actions; however, my main concern with this approach is that it doesn’t clarify why I need to open a specific tab. It feels like a variation of the “Waiting for” list, which can serve a similar purpose. I can access this list daily, quickly scan it, open links from the task notes, and even update it with new information.
Their poor information management skills force them to rely on constant notifications from whatever apps they install and to which they nearly-instantly read or reply, never batch-processing anything in their life.
And they are perfectly fine with it. Oh, they might complain the way some people complain about the weather: “It’s colder than I thought it would be today”, but still not returning home to get a sweater.
And the systems which these types are involved in (jobs, school, groups, clubs) are kowtowing to them more each year. In fact, often those very same systems are run by the same types. It is, to them, unthinkable that anyone would “go rogue” and not have a smartphone lighting up their face 200+ times a day. They see well-managed, calm, distraction-free people (or those trying to be) as cabin-dwelling off-grid and out-of-touch people who are “missing out” on how “easy” life is if you just let everyone and everything ping you with every update.
My all time favorite is the text message about the “email I just sent you”. I know my darling, I keep my shit together.
A few years ago, I found a hidden video series about how David Allen does GTD. I instantly downloaded it and merged it into one video.
While browsing today on YouTube, I stumbled upon two existing videos from this series that are still available. The rest are removed or marked as private, I don’t know…Edit: actually I checked the video and these in fact are the same ones. But I wanted to share them because they are pretty interesting.
Luckily, I saved the full video, although I can’t share it here. If you are interested, maybe you can ping me via email. Otherwise, I embedded the two existing videos here as an introduction.
I looked into how Tailscale works behind the scenes, but I’m still not sure I need a 3rd-party tool to create a virtual network for my devices. There are a couple of cool uses of a network like this, like syncing DEVONthink and OmniFocus over WebDAV using my Mac mini. Still, I also have an Apple Watch, which doesn’t seem to work with Tailscale, so I can’t sync OmniFocus with my Mac mini there like I originally planned.
Initially, I was looking for something that could give me access to my Mac mini outside of my network to get to my file archive stored on my external drives connected to my Mac mini. But giving it a second thought, there is a good reason we have the distinction between Cold Storage and Active Storage.
For me, Active Storage is iCloud Drive, which is synced to all my devices. Cold Storage is not something that I should have access to all the time (not to mention ransomware and other dangers). So, from a security point of view, it’s a good thing that I have a local Mac server and a remote Linux server used for different things. Each of them requires a different level of security, and Tailscale merges them all into one network, which I’m not sure I’m comfortable with.
I’m thinking about shelving this whole idea of reaching my Mac mini server outside of my network and making a distinction between private networks and public networks. A public network means it should be available anywhere, but it should be end-to-end encrypted. This is what DEVONthink and OmniFocus do: each uses my WebDAV server running on my public server as a syncing backend, but these apps store data encrypted.
On the other hand, my private network should be guarded, and data stored there should have a good 3–2–1 backup plan instead.
So, instead of using the network as a transport layer to access my file archive, I’m thinking about using an external drive to bring a copy of my archive with me when I’m away.
I’m playing around with Tailscale, but I’m not sure about the privacy aspect of being on a VPN all the time. I want to sync DEVONthink and OmniFocus using a WebDAV server on my Mac mini, but running Tailscale 24/7 raises some questions.
Is it really end-to-end encrypted?
Does all traffic go through the VPN?
What about network issues when using a VPN? I’ve seen some connection drops in the OmniFocus sync logs when I used my Mac mini as a sync server.
I love the idea of having my private network of devices available everywhere. But I don’t trust random companies with my data, so I want to do my research before I start to use Tailscale with all my devices.
It feels like talking to myself, which helps me to externalize my ideas, and find solutions quickly to problems. It’s like a pre-thinking phase for capturing ideas in a timeline format, then organizing them later in a mindmap or an outline.
Slack has a similar idea of why you should start to message yourself. When you open your profile and press the Direct Message button, the following message appears on the top.
This is your space. Draft messages, list your to-dos, or keep links and files handy. You can also talk to yourself here, but please bear in mind you’ll have to supply both sides of the conversation.
Others also wrote about this idea in more detail. It is the modern version of emailing ourselves.
Messages is actually a pretty cool candidate for this workflow. It is available on all my devices, I can pin messages for reviewing them later, and it is still the best way to share information between my devices when AirDrop and Handoff farts themselves.
How to set it up?
Texting with ourselves in Messages is a bit weird since every message will be sent back in the same thread duplicating everything. We can avoid that by registering a new iCloud account and sending messages to there.
I have a sparse iCloud sandbox account which I use for testing. I logged in from my old MacBook Air, then I started to write thoughts for myself over iMessage.
We have to log into a separate iCloud account at least once, otherwise, Messages won’t pick up the account as a proper recipient.
This is yet another version of the capture step in GTD
This idea was cool, but for me it quickly fell apart. People get the idea of writing stuff down, but they forget that it needs to be processed later.
When I had to pull out data from Messages, it was hard to mark my processed position in the timeline.
I started to use a marker message by typing 5 equal signs which is similar to how I mark my processed position in my notebook using a double line.
This is a very important note about something.
====== ← This is my “processed” bookmark. Anything above this line is processed and I don’t need to see it again.
When I process, I usually reference information between apps, which means that I like to link to the source or at least copy the text out into a place that I can link to.
There is a hidden URL scheme in Messages, but it is really hard to link to messages.
sms://open?message-guid=UUID
If there is a data detector visible in your message (like the text of “tomorrow 9:00am”), Messages will underline it, and you can create a new event or a reminder by clicking on it. Creating a new reminder will also add the link to the message which you can copy.
Getting links or text out of Messages is actually bit convoluted.
I just found a unique new app today called Strflow, which mixes note-taking with a messaging interface. It works exactly like I wanted to use Messages.
Why it is better than Messages?
There is a “Copy Note Link” command for every note.
Notes can be edited after they are created.
There is a minimal Markdown-like syntax available, which lets me have the right amount of formatting for quick notes like these.
I love unique apps like this one – that’s one the reasons I love the Mac, since you can always find interesting tools like this – although it still has some missing pieces.
iOS version (the developer mentioned that he’s working on it).
Spotlight integration: it just feels right to index and search snippets of information in Spotlight.
Better export: we get a JSON file on export, but since the app uses Markdown for formatting, why not export proper Markdown notes?
It would be even better if I could define a date range for exporting, so processing information can be done outside of Strflow.
Although there are unique links for each note, getting them is a bit hard. I have to ⌃Click and choose the “Copy Link to Note” command from the context menu which is not available in the app’s menubar.
strflow://show-note?id=UUID
Selecting notes can be done using the trackpad, but having keyboard shortcuts for navigating up and down would be useful to select one or multiple notes.
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.
But the truth is, unless you’re a longtime Mac user who has integrated your personal collection of utilities into the way you use your Mac, you might not need all that much. So that’s my advice for people getting new Macs who don’t carry that legacy with them: Start with what’s there and then explore when you find where the built-in tools can’t meet your needs.
Jim writing about his reading note publishing process:
I like to let my notes sit for a couple days (or even weeks). I find that if I come back to a note and still find it interesting/insightful that means it’s worth keeping, so I put in the work of cleaning it up and publishing it.
I don’t do this. If I see something interesting, I usually publish it immediately (like this post). On the other hand, I have a Zettelkasten site, which contains more in-depth notes that are also coming from reading notes. However, that site is so new that I haven’t really published anything that counts as reading notes there yet.
I just bought MailMate a couple of minutes ago. It turns out I love to use plain-text email for writing and reading. It’s just way easier to edit my emails in MacVim than to fuck around with the Mail.app compose window.
The Things integration is also pretty cool. I can get the complete plain-text email in the to-do note, which is way more excellent than the jumbled text-fest I had previously parsed by the Things mail service forwarded from Mail.
I’m still developing my workflow around the rule-based smart mailboxes, which are pretty powerful.
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.
Like Apple Notes, the Journal app works without the Files app. Instead of your journal entries being discreet text files or similar that can be managed in the file system, they’re built into the app itself. It might work, like Apple Notes, using a SQLite database within the Journal app container.
Keeping a diary is more personal on the other hand. It helps us to write about our feelings and nice or bad things that happened to us.
This is the reason why I like to have the On This Day notification from Everlog in the morning.
Both of these practices provide a clearer picture, bringing us closer to the state of the past than just a simple memory.
Our memories give a false image because we can only remember the good things. This distorts the past and overvalues things that were not as good as we remember.
We can’t trust our memories, but we can trust a diary/journal, since it acts as a bookmark to the past, showing what happened in our lives. It functions as a backward tickler file, bringing things from the past to us. This retrieved information helps us to better understand ourselves in the future. We can see the difference between the past and our current state clearly, which can provide a new perspective on how we handle a current situation.
In essence: both of these practices allow us to compare our present self with our past one and draw conclusions.
So back to Apple Journal…
The only thing I see myself using Apple Journal for is the missing “add a description to multiple photos” app for now.
Sometimes I want to have a short description of an event that is stored in Photos, and since both apps are from Apple, hopefully, the integration will be better than duplicating my photos into yet another app as attachments.
Otherwise, I don’t see myself migrating away from Everlog in the foreseeable future.
E-mail, text/MMS, RSS, a blog/personal website, podcasts, forums. What did I miss?
These fundamental tools are still around because they are the best tools where you are in control of what you are interested in and what you can discover.
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.
So one thing I consider a compelling use case for a big iPhone and a small iPad mini is using them as a mobile writing environment. I could easily publish an essay from my iPhone or iPad mini just by thumb-typing. I want to explore this use case in more detail in the future.
We have had people doing this for years now, watch and read the following stuff from Patrick Rhone or Yuvi Zalkow.
I have a MacBook Pro and iPad Pro to write, so why am I interested in this phenomenon? I like when people think outside the box regarding their device usage.
The iPhone and the iPad mini are considered content consumption devices by almost everyone, which I’m afraid I have to disagree with. I create all kinds of things using these devices. I take photos, write notes and blogposts, sometimes create/edit Shortcuts, and SSH into remote servers to fix issues. Heck, I even edited an entire podcast episode on my iPhone using Ferrite while I was sitting on the train. It was actually quite fun to do. Being an owner of a big phone like the iPhone 14 Pro Max, I’m even expecting myself to use it more to create rather than consume.
Thumb-typing lengthy notes and blog posts on these devices maybe seems to be an ineffective way to write. Still, there is a focused environment to be found here—especially if you set up iOS to send only essential notifications—so even a smartphone can be a device that makes you focused.
I’m not going into details on notifications here, but let me just tell you, it’s not your smartphone that makes you distracted. It’s your laziness to set up notifications properly that makes you distracted.
