Challenging PARA’s Traditional Folder Approach
Recently I wanted to get a new pair of glasses.
To gather the necessary materials (such as the parameters needed for Zeiss SmartLife lenses), and to set a rough plan and deadline for myself, I created a new project note: [[260127 Buy new glasses]]
If following the PARA methodology, I should now put it in the Project folder, right?
But then I thought—why must it be created inside the Project folder?
Don’t forget:
Tiago is still using his (outdated) Evernote. He uses folders to distinguish PARA because he only has folders available—the weak Evernote doesn’t support more modern approaches.
Just as Zettelkasten uses complex numbering to build links, because physical paper cards can only work this way.
I believe if Luhmann had today’s bi-directional linking notes, he would unhesitatingly choose to use properties and bi-directional links to build his card box.
So, notes can be placed anywhere—as long as you add the corresponding #project tag or PARA: Project property, then it can be considered a project.
Similarly, to archive something, you don’t need to move it to the Archived folder—just set it to PARA: Archived.
PARA requires moving folders because that’s its way of avoiding distractions.
Although in Obsidian moving a note or folder isn’t a big deal, it still causes some hassle.
Moreover, many times, such movement also breaks the natural clustering of notes themselves—you need to split several highly related projects into scattered pieces—simply because some are completed while others are still in progress.
In Obsidian, we have Bases. With just one Filter condition, we can hide all archived notes. So why bother moving them?
Remember: structure your notes for goals, don’t be bound by form.
You don’t move notes to an archive folder for the sake of “PARA Structure”—you do it so you don’t have to see them when you don’t want to.
As long as you achieve this result of filtering your view, choose whatever method works.
Moreover, when you truly understand PARA’s architecture, you don’t even need to limit yourself to PARA as the only property.
You could completely use a separate archived checkbox property to represent archiving, while keeping its previous type: project property to indicate it’s an “archived project.” At the same time, you could also have “archived resources,” “archived areas,” and so on.
Just like this:
type: [[project]]
archived: true
Our properties can exist simultaneously—this is where properties are superior to folders.
In summary, the PARA methodology itself has its merits, but also its limitations.
For those who recognize the value of PARA methodology, you can completely try to break through the limitations imposed by the outdated software it was based on, and use new technologies to achieve better results & workflows with less friction.
