Building a note taking system that actually works

There are a ton of videos, articles, even full courses about how to configure the best note taking system. I’ve been through many of them, from Obsidian, to Logseq, to Obsidian again, and then finally resting on mdbook and vimwiki, which have now stood the test of time. If I could go back and give myself some advice, it would be to think about the note taking problem in the reverse direction. Instead of building a system and then modifying your behaviour to match it, start with how you actually use notes, and make a system that meets that need. In this post, I’ll go over some of the key considerations in building such a system, and which ones I think actually matter and which didn’t end up making an iota of a difference after having gone through so much change.

Open-source vs propietary

For Obisidian vs Logseq, this is often a huge topic. I would consider myself a huge open-source advocate, and it initially weighed heavily on my switching between the two. “Could I actually put something as important as my notes in something proprietary?” I would ask myself over and over again. Turns out, there isn’t a huge difference unless you are looking to host the system yourself. Rather, I believe this debate for me was largely about control and stability. I didn’t want an application that was changing every week. The rate of change is ultimately up to the development team, and it is this culture that should be a higher priority than the open or closed nature of the software. Ultimately, I think that Obsidian has stuck to their roots in making sure that the system always works with markdown files and that there are few breaking changes. I haven’t been following the development of Logseq close enough to comment on its current state, but in the time that I was using it there weren’t too many breaking changes to the underlying structure.

Syncing

As syncing involves a subscription (for most users who don’t want to setup something complex), initially considering whether syncing is necessary is reasonable. Here cost might be a factor, but if it’s a difference between four and five dollars I wouldn’t worry about it. Instead, what really matters is stability. Losing notes to a syncing error will permanently undermine your trust in the system being a safe storage mechanism. Entering notes in a system that may or may not suddenly delete them can quickly make taking notes feel like a waste of time.

Additionally, it is important to consider if you need to enter notes on the go, or just read notes on the go. This may present differences in how well you want the editor to work on mobile. If it’s just reading, something like mdbook would be fine.

Editor experience

The biggest choice here is outline vs more traditional full page text. While it may seem small, this will be the biggest difference in the day to day experience. Considering how you think is super important — if you think in short snippets, go the outline route, if you think in larger buckets and prefer the space to really expand on ideas, then full page is probably best.

If you use something like vim or emacs then having support for that in the editor may be nice. For me, as a new vim user, having support for the vim keybindings is a key consideration and what shifted me towards vimwiki and mdbook. Obisidian has vim support in the same way that VSCode has vim support, probably 90% of the full functionality would be there. However, there would be different keybindings for doing things like opening the file tree or the command palette. Using vim in Logseq may be trickier, but apparently it can be done!

Searchability

It is essential to be able to find what you are looking for within a few seconds of opening the app. If things are organized in a way that to find something you have to go through a maze of interconnected notes than it may just be faster to run a web search for it. In my current notes setup, it is basically designed as a faster way to get key information relevant to me and my setup in less time than it would take me to google the same thing. For me, a grouping of directories ended up working better than the tagging system, but your mileage may vary. Obisdian seems to be better suited for directories, and Logseq more for tags (although you can use namespaces).

Red Herrings

These are features that I think receive too much hype, and while I was drawn to them at first, didn’t really end up all that important.

Graph view

It may look really cool, and can be fun the screenshot and post about, but I never ended up using the graph for anything. I did link between notes to establish the graph, but didn’t end up using that functionality much either. Usually I would open up the app, search for what I was looking for, then get out.

Plugins

The more complex a system gets, the more likely it is to unexpectedly break, and the less portable it is. In evaluating plugins, a key criteria is checking how they depend on the underlying data structures being modified, or which modifications they apply themselves. Furthermore, plugins can cause issues with each other, as the development is not coordinated between them for releases.

Conclusion

There are many people who have opinions about what the perfect setup entails, but the only person that can decide if something is working is you. There are countless different paths to go down, and the key is to experiment through usage. If you find yourself not using a system, there is usually a reason. It may be too complex, it may take too much time to open when you need it, or there may be a fear of breaking something and trying to keep it in pristine condition. The benefit of notes is having them there, a perfectly ordered system that sits empty helps no one.