Different PARA implementations in Obsidian

I use Obsidian for my PKM system. When it comes to implementing PARA in Obsidian, there are three different popular approaches: folder-based, MOC-based, and a hybrid approach. I’ll provide a quick overview of these approaches and some of their pros and cons here.

Basic structure

Above I have these three different PARA approaches implemented next two each other.

On the left, you can see the PARA structure implemented entirely with folders. Each project (ie. Participate in BASB13, Write blog post on animals that eat their mates, Write book chapter on spiders) is its own folder, as is each area and resource.

In the middle, you can see the PARA structure implemented as MOCs. Each project is its own note, as is each area and resource. The project note links to each of the project notes, the area note links to each of the area notes, etc.

On the right, you can see the hybrid PARA structure. There is a folder for projects, areas, resources, and archives. But then each project is its own note, as is each area and resource. And all the files belonging to a specific project, area, resource, or archive folder reside in some “5 Notes” folder.

The upper-left side of the above screenshot illustrates what the “Projects” note looks like for the PARA structure implemented as MOCs. This is an alternative to having the “1 Projects” folder that the other two approaches have.

The bottom-left and right sides of the above screenshot illustrate what the “Write blog post on animals that eat their mates” project might look like implemented as an MOC.

Each of these three approaches provide the focused context intended by PARA. This context allows you to see all the files related to one specific thing at a time, while hiding all the other files. This allows you to focus on what you’re interested in without getting overwhelmed by everything else in your PKM.

In the folder approach, the context is provided by opening the folder for a specific project, area, resource, or archive folder. In the MOC and hybrid approaches, the context is provided by opening the MOC for a specific project, area, resource, or archive MOC.

Completing a project

In PARA, when you complete a project, the project gets archived and it’s associated files get moved to the next most actionable area in your PARA structure.

Let’s suppose we complete the “Write blog post on animals that eat their mates” project.

In the folder approach, we can see that the “Write blog post on animals that eat their mates” folder has been moved from “1 Projects” to “4 Archives”. It’s old contents have been moved out of the “Write blog post on animals that eat their mates” folder and into the “Write book chapter on spiders” folder and the “Insects” folder.

In the MOC approach, the link to the “Write blog post on animals that eat their mates” MOC has been moved from the “Projects” MOC to the “Archives” MOC. The “Write book chapter on spiders” project MOC includes a link to the “Notes from ‘The Spider Encyclopedia'” note, and the “Insects” area MOC includes a link to the “Notes from podcast on praying mantids”.

In the hybrid approach, we can see that the “Write blog post on animals that eat their mates” folder has been moved from “1 Projects” to “4 Archives”. The “Write book chapter on spiders” project MOC includes a link to the “Notes from ‘The Spider Encyclopedia'” note, and the “Insects” area MOC includes a link to the “Notes from podcast on praying mantids”.

Pros and cons

(Including this screenshot here because it will be relevant to some of the points listed below.)

Monolocation vs multilocation

As you can see with the folder approach, files can only live one place at one time. For example, if we look at the “Notes from podcast on praying mantids” file, it lives in either the “Write blog post on animals that eat their mates” folder (ie. before the project was completed) or in the “Insects” folder (ie. after the project was completed).

In both the MOC and hybrid approaches, files can live in multiple places simultaneously. For example, if we look at the “Notes from podcast on praying mantids” file, it can be linked from the “Write blog post on animals that eat their mates” MOC and the “Insects” MOC at the same time.

Some people prefer having a file live in only one place at a time. This forces them to be very intentional about how that file is going to be used.

Some people prefer the ability for a file to live in multiple places at the same time. For example, suppose you have two projects on the go. You have a file that is relevant to both of these projects. If a file can live in each of these projects at the same time, this prevents you from having to decide which project will be most immediately actionable, and will also provide a more complete context as you jump between working on these projects.

Historical context

As you can see with the folder approach, after the “Write blog post on animals that eat their mates” project was completed, all the notes were moved out of that folder.

In both the MOC and hybrid approaches, the “Write blog post on animals that eat their mates” MOC still links to its original notes after it was completed.

For some people, historical context is important. If they’re reflecting on a project, they may want to know what resources they were working with when they came up with their final project. Or suppose they’re working on a project. They recall a resource that was useful for a previous project that would also be useful now. If they can reference that previous project for that resource, they can find it pretty quickly. Otherwise, they have to put in more effort to figure out where the file is living.

Clutter

As you can see with the MOC approach, all the files live together in the same place.

In both the folder and hybrid approaches, there’s a bit more structure offered by having separate folders for projects, areas, resources, and archives.

Some people prefer to navigate their files using a folder structure.

Others may be comfortable opening certain files directly, or finding files by first navigating to another note (eg. the “Projects” MOC).

Serendipity

For people familiar with Zettelkasten, you may be familiar with the idea of using your notes for serendipity.

These are the three graph views for each of the three approaches after the “Write blog post on animals that eat their mates” project is completed. The left shows the folder approach, the middle shows the MOC approach, and the right shows the hybrid approach.

As can be seen in the graphs, the MOC and hybrid approaches offer more links between your notes. These represent opportunities for a new connection between different ideas to be discovered serendipitously. Nick Milo recently published a great video on how to use the graph view for this discovery process.

Completeness

Part of the PARA philosophy involves the project completion process. When we complete a project, we look at all the resources associated with that project and then ensure that those resources are being appropriately applied to the rest of your PARA structure. (Resources should always be available where they’re most immediately actionable.)

In the folder approach, when you complete a project, a file gets moved to one other location.

In the MOC and hybrid approaches, when you complete a project, links may be created in multiple MOCs/notes. This can cause some people anxiety: what if I forget to add a link somewhere? What if I don’t add links everywhere they’re actionable/relevant?

I would argue that trying to be complete in your creation of links will be stressful and make your PKM system less fun for you; you may even stop using it because you feel like it’s not working or flawed. This is a case where we’re trying to create links just-in-case.

I’d argue a better approach is to create links just-in-time. That is, when you wrap up a project, link those related resources wherever most immediately jumps to mind. But don’t stress about forgetting things. If you encounter a note in the future that would benefit from another link, you can add it then. You can also use the graph view to discover links that may be useful to add (see the previous section, “Serendipity”). This will prevent you from disengaging with your notes due to unnecessary anxiety. (Random side note, we also call this approach the scouts rule in the coding community.)

Conclusion

In this blog post, I provided an overview of three different approaching to implementing PARA in Obsidian. I showed how completing a project differs in each of these approaches. Finally, I discussed some of the differences that you may encounter in each approach.

I hope this was useful! Let me know which approach you’re planning on trying! (And don’t stress too much about getting it right–you can always switch approaches in the future if the one you choose doesn’t jive for you 🙂)