During the years that I was Evernote’s paperless ambassador, one thing I learned was that organization was a very personal thing. This came as no surprise. Each person is unique, has unique requirements, and the result is a unique was of organizing their notes. What was a bit surprising at the time was how vocal people were about what method of organization was best. I’m not doing that here.
Recently I wrote about what I think of as “how-to versus how-I.” My migration from Evernote to Obsidian is an experiment. My use of plain text files for the bulk of my output is an experiment. Some things work, and I keep those things around. Other things don’t work and I toss them or try to find ways to improve them. So when I talk about how I organize my notes in Obsidian, I am talking about an experiment that I am working on that meets my own unique requirements. What works works for me, and may not work for anyone else. But I think it is good to have examples of what people are doing because there is always the possibility to learn something.
Lessons from Evernote
Consider some lessons I took from how I organized my notes in Evernote:
- The organization grew organically without much initial thought.
- I considered notebooks topical and that all notes related to the topic should go into the notebook.
- I thought of tags as themes: a mechanism that allowed me to span or collect topics together.
This resulted in an overly complicated set of notebooks, where it was sometimes difficult to find something because topically, I put it into one notebook when, thematically, I looked for it elsewhere.
Lessons from Obsidian
I have been using Obsidian for over a year now, and in that time, I’ve experimented quiet a bit. One thing that I have found, is that my notes fall into several general categories:
- Attachments: PDFs, images files and other files stored in my vault that are generally not plain text. Example: a PDF of a W-2
- Documents: Documents are attachments with context. They are wrappers for the attchments. That is, a note in which I transclude an attachment file, in order to provide additional meta-data and context to that file either through YAML frontmatter, note text, or links. Example: a note that transcludes a PDF of W-2 and also contains meta-data (tags, etc.) about the document, as well as any other remarks or links that I add. For more on how I think about document notes, see Episode 1.
- Permanent notes: I am borrowing this term from Luhan’s Zettelkasten methodology. Permanent notes are notes about one thought that can stand on its own, written in my own words, with context added in the form of links and tags. Example: a note about how power differs in the Senate and executive branch, based on reading I have done.
- Maps of Content: Notes that pull together links to other notes in a unified context that allows for easy access to relavant information. Example: a note about a specific vehicle, that links to other notes and documents related to the vehicle, and provides additional context in the form of a timeline or backlinks.
- Writing: Notes that contain writing: stories, letters, blog posts drafts, essays, etc. Example: The note containing the draft of this blog post.
Looking through the notes in my vault, I can generally put each one into one of these buckets. There are some exceptions, of course, like templates or my daily notes file. But the vast majority fit into this framework.
As I was thinking about my requirements for organizaing my notes, I tried to keep all of these lessons in mind.
Since the basis of organization stems from one’s requirements, let me talk about the requirements I had in mind when I was organizing my notes in Obsidian. As I thought about how I might better organize my notes in Obsidian, two requirements began to emerge:
- Optimize for finding things later as opposed to organizing them now. This is something I have emphasized in previous episodes. It takes time to maintain a taxonomy for notes. The important thing for me is not so much how the notes are organized, but how quickly I can find them when I need them.
- Remember that I may not be the only one that needs to access these notes and plan accordingly. Kelly may need access to the notes and she needs to be able to find what she is looking for. We jokingly call this “succession planning” but in reality, if something happened to me, access to my notes, which contain all kinds of information that she would need, would be vital. Finding that information quickly would take some burden off her mind.
(Re)organizing My Vault
These two requirements led to some decisions that I made about how I’d structure my vault.
- Attachements, documents and permanents notes can have a completely flat structure. I typically access these note in one of two ways: via an MOC note, or via a link on another note. It is rare for me to search for these notes directly. The allows for a flat structure.
- Maps of content (MOCs) need to be very easy to find. Because they are topical and provide sturcture and context, they lend themselves to a more hierarchical structure. MOCs are also the most useful mechanism for Kelly to find what she is looking for.
- Writing notes could go into their own folder and be organized in a relatively simple hierarchy, the way I might organize them on a file system.
I went about making these changes. It was not hard to do because Obsidian handles all of the linking and indexing behind the scenes as notes move around. I was tempted to have just four or five top level folders, so that my vault would look something like:
But I decided for ease-of-use to keep to a flatter hierarchy and implement the taxonomy through a different mechanism. At the top level, therefore, my vault looks like this:
The vast majority of my note can be found in the attachments, document, and slipbox folders. I’d guess they contain 90%+ of all of my notes. The structure for MOCs is flat, too, but contains some structure to make it easy to find the MOC I’m looking for. Still, the MOCs make up a small fraction of all the notes, even though they link to many of them.
Some examples I used to test this structure
Example 1: Tax season – MOCs to the rescue
As I write this, I am preparing to send all of our tax information to our accountant for preparation and filing. An MOC for all tax-related documents makes this a simple exercise. As tax documents come in, I add the PDFs to my vault as attachments, create document notes for them to capture context and meta-data, and then add a reference to the document on the MOC note for taxes.
Here is what the “Tax Documents” MOC looks like (with some annotations in red):
In the Tax Documents section, there is a corresponding year for each year in the Tax Returns section and under each section is a list of all of the tax documents for that year, each of which in turn transcludes the PDF attachment as well as meta-data for the yearly summary table.
I’ve tried to make this a one-stop-shopping document for anything tax related. It is useful for more than just tax season. We recently refinanced our house (squeezing it in before the rates started to go up again) and needed to provide some tax documents as part of that process. This made it easy. If Kelly needs some tax information, she know to go to this note, and it will point her to everywhere else she needs to go.
When I go to sent the documents to our accountant, I’ve already got everything in one place. It’s just a matter of uploading the documents to their secure portal.
This MOC meets both by requirements: (1) optimizing for finding things later, and (2) making sure Kelly can find them too.
Example 2: Managing services – herding kittens
I miss the old days when you had your phone bill, you gas bill, and electric bill, and maybe a newspaper subscription to keep track of. Today, everything is a service: from streaming media to software to digital subscriptions, there are tons of services that need to be managed and coralled.
Within my MOC structure, I have folder called “Services” and within that folder is an MOC note for each and every service we subscribe to. Combining the usual utilities with subscriptions and software services, it is a long list. Each service is billed in its own way, on its own cycle. Each costs something different. It can be hard to stay on top of. I do it through MOCs using a simple set of guidelines:
- Each service gets its own note.
- Each note has a specific set of YAML frontmatter at the top to keep track of the basics. I’ll come back to this in a moment. Currently, it looks like this:
- The note itself has two main sections: (1) Service info, which includes things like where the service is billed to, links to managing the account, how to cancel the service, etc. (2) Service notes: if I have to contact support, the notes related to the contact go in this section. The dates are links back to the daily note on the date of the contact. Here’s an example:
- With a note for each service populated with the meta-data, I have a Service Summary MOC note. This note uses the Dataview to summarize all of our “active” services with links to the service note, and listing the monthly and annual costs, and the due date of each. This allows us to view, at-a-glance, all of the services we have, how much they are costing us, and when they are do. If we cancel a service, I mark it’s meta-data status as “canceled” and it drops off our active list. Here is a snippet from that summary note:
This model has worked very well for keeping up with all of our services. The summary note makes it easy to find anything we are looking for. The MOC note for each service contains everything we need to know about that service and its history. There only one place we need to go to look for the information so it is easy to find.
Example 3: Continuity planning – a step-by-step guide
Back when I was Evernote’s paperless ambassador, one of the more popular pieces I wrote was one I called 6 Steps for Life Continuity Planning in Evernote. In our house, we jokingly call this “succession planning” to take away some of the discomfort of thinking about this kind of thing. As part of my migration from Evernote, I’ve been working on using the features of Obsidian to improve upon how we document this continuity planning. An MOC I call “Succession Plan” plays a central role in this.
The Succession Plan MOC centralizes everything that Kelly or I would need if something happened to one of us. It is also written so that if something happened to both of us, the folks who would be responsible for our affairs would have a detailed roadmap.
The document is broken into two parts:
- A step-by-step guide for everything that needs to happen, in a logical order, with links to all of the relevant documents, contacts, phone numbers, email addresses, etc. It is all right there in one place. Go to that note and you have everything you need at your fingertips.
- A kind of annotated index to my Obsidian vault, with links, so that if there is something that is needed that is not in the step-by-step section, there is a framework for locating it in the index section.
I try to keep this up-to-date, and it is still a work-in-progress, but there is enough there that it would be useful in the unlikely event of a water landing. Here is a high-level glance at the structure:
Once again, I’m focusing on finding things later when they are needed as opposed to a deep hierarchical structure to how the notes are organized.
Like any organizational structure, this is a work-in-progress. It evolves as I test things out, figure out what works and what doesn’t, and make adjustments. But this is the closest I’ve come to accomplishing an organization that doesn’t require me to constantly think about where I need to put something, and instead focus on linking to it in ways that will be easy to locate later on. It is an easy system to work with and so far, it is working well for me.
In next week’s post, I’ll talk about archiving notes.
Prev: Episode 17: Six Ways I Use Note Links
Next: Episode 19: Archiving Notes
Written on February 2-13 , 2022.
Did you enjoy this post?
If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!