The debate between Evernote and Roam is well-covered. Instead of sending off notes to rot in obscure folders, you shoot them into a hyperlinked second brain where anything can connect to anything. It's a magic, and it changes the nature of how you think.
But I'm here to talk about what I see as the biggest challenge in Roam, and I invite the #RoamCult to correct me where I'm blind. My biggest beef is the fact that it's a "mono-graph" - a flat space where all objects are equal.
A task, a note, an event, a habit, a project, and an essay are very different information primitives.
Roam is great if you are creating a woven network of like objects, but it doesn't come with a set of tools to define "information object types." The flat nature of the Roam graph means that every object is equal, and it's up to the user to enforce a structure upon each entry. This leads to low-fidelity nodes and monolithic graphs.
I wonder if there are advantages in an "object-oriented" system (like in C++), but no-code, and tailored for personal knowledge management. An "object" implies structure, but it is very different from a folder. An instance of an object can inherent not just properties, but interfaces, from it's parent. This means that every entry in the Note graph comes with a set of relevant graphs that it can form bi-directional links with (ie: Essays, Tags, Projects).
I'd argue that Roam is a "mono-graph," while an object-oriented system would act as a "multi-graph."
This is an essay about information architecture. It's already clear what the advantages of Roam are over Evernote. But maybe some things are less clear:
- The limitations of a mono-graph
- The advantages of a multi-graph
- Which tools we could use to build a multi-graph
In Roam, every entry is thrown into the same mono-graph. The only property that it auto-inherits is the date of creation. A single graph might contain a wide range of things. If you want to imply structure, you can use indentation, template "stamps," or remembered phrases, but structures are fragile and hard to upkeep.
With a multi-graph, each graph is an object type (a note, a task, an event, a habit, a person, a tag, an essay, a project, an area). We aren't creating graphs based on content (Roman history vs. Greek history), but on information primitives. All of your projects will exist in one graph, all of your notes exist in another graph, etc.
Roam is about linking entries to each other, but an object-oriented system is about an architecture of linked graphs. Even though the back-end is "fixed," any instance within this architecture still has tremendous flexibility in how it's associated to entries in related graphs.
In Roam, every entry can be linked to any other entry. Bi-directional linking is the main feature that draws people to Roam. There are no restrictions or rails, and by using brackets [[ ]] - you can create associations on the fly as you are typing.
A multi-graph allows for bi-directional linking as well. The difference is that an object, depending on the graph it's in, has a smaller but more relevant set of objects it can link to. For example, let's imagine that our Notes graph is linked into 3 other graphs (Tags, Essays, Projects). Each note now inherits 3 relation parameters. I can link a note to 12 tags, 4 essays, and 2 projects. Even though there is a rigid structure that links the underlying primitives, I still have the ability to loosely associate an entry as I would in Roam.
In an object-oriented system, an entry inherits it's range of possible links based on which primitive graph it's in.
Roam has a pretty manual way of adding parameters to an object. If something is an Essay, you can stamp a template into it. But if the nature of an Essay changes down the line, you wouldn't be able to update the Parent once and have it reflect in all Child instnaces.
In a multi-graph setup, we define a series of parameters that can get applied to every instance within a graph. For example, every essay might have a Publish Date, a Status Field, and "Featured" boolean. Whenever we create an instance within an Essay graph, it will auto-inherit these fields.
Within a graph of like-objects that all share the same parameters, we can auto-generate a range of useful views that each give us a specific insight.
A tool for object-oriented design
This might sound counter-intuitive, but the best tool we have for object-oriented design is Notion. It's super common to build out folder-based structures within Notion, but an object-oriented design enables us to have rapid input and networked thought. The idea that Roam is for gardeners and Notion is for architects might be incorrect.
Roam is a mono-graph.
Notion is a multi-graph.
Here are some signs that you are using Notion in a folder-based paradigm over an object-oriented paradigm:
- Your projects are scattered and not unified into a single database
- You have to navigate several pages deep to input information
- You have aesthetically pleasing dashboards with no linked databases
- You only occasionally use relations & roll-ups
- You only use Notion for one thing (content calendar)