(This blog post originally appeared on David Crandall’s website.)
The tools we use are important. The tools we use at work, the tools we run our business with, the tools we use as individuals in our daily lives.
They affect how we work and, more importantly, how we think. Because of this, thinking about the tools we use the most is a good use of our time.
Recently I’ve been thinking a lot about one of the newest tools in my personal toolkit: Roam Research.
Roam is more than a note-taking app. It’s designed to specifically facilitate thinking, which is rare in a tool. As I’ve become more engaged with this tool, I have tried to think about how it might evolve.
Here’s some of my thoughts.
Roam(an) Architecture
Let’s start by dividing the application into 3 distinct architectural layers:
- Presentation Layer – how the data is displayed and acted upon by the user
- Service Layer – how the data is accessed and moves between the database and presentation layers
- Database Layer – where and how the data is stored.
Breaking it into layers makes it easier to think about how each component could be expanded and enhanced.
Breaking it into layers makes it easier to think about how each component could be expanded and enhanced.
Roam’s Current Service Layer
Aside from entering text normally, the only exposure users currently have to the service layer is the ability to import and export text from Roam.
However, import and export are only available manually through the Roam web interface with the two options for file types:
- Markdown – human-friendly text format
- JSON – computer-friendly text format.
Choosing human-friendly and computer-friendly options is a great choice! Further, those two specific choices are widely accepted formats and lay the foundation for compatibility with numerous other tools.
There is a third option available in the form of plain text via copy/paste. This is a basic computer function available on all platforms making Copy/Paste the universal API. Roam did a great job of making sure it works well.
But all of these options (Import, Export, and Copy/Paste) are manual processes available only in the web interface.
Thinking about how the presentation layer interacts with the database puts emphasis on the Service Layer. Currently, the Service Layer is invisible and only accessible to via Roam’s default UI.
Extending the Service Layer: Roam API
There are two options for expanding the Service Layer:
- Adding functionality
- Opening access to external tools.
No doubt the developers behind Roam will continue to add functionality to the Service Layer. They’ve shown a strong track record for doing so thus far.
However, the exciting choice is opening access to external tools via a Roam API.
API stands for Application Programming Interface and acts as a service to connect pieces of software together. The benefit of an API is a standardized data format and access which allows software to use that data. In the case of Roam, this would allow third party software to submit and receive information in a consistent manner.
An API opens up a ton of possibilities.
First, a Roam API would enable programmatic import/export in addition to the current manual process. Data could be sent and synced from your favorite app or tool with minimal effort.
Using an API to fill the Mobile Gap
While I use both PC and Macs all day long, my preferred interface is my iPad Pro. I’m excited about a Roam API because there are a host of tools available that could send data programmatically. Drafts, for example, is one of my favorite apps and is where most of my text starts.
All my blog posts (including this one) start in Drafts and make their way through a serious of scripted actions before finding their way to WordPress and this site. I’d love to be able to start text in Drafts, process it, and send it to Roam without manually copy/pasting it.
I’m speculating here but once the Service Layer becomes accessible via an API, Roam will be an even larger component of people’s data ecosystems. That’s the benefit of APIs, they reduce the friction of adding applications to a users toolkit by leveraging applications they already use.
Right now, Roam is weak in the mobile sector. But by opening up access via an API, existing mobile tools can help fill the mobile gap. Allowing iOS apps like Drafts, Jayson, Toolbox Pro, and other developer focused tools to communicate directly with the database opens up the type of data people can add to their database.
Note: while I’m not as familiar with Android apps, I’m certain there are options available to Android users to fill this same gap for them too.
And that’s just mobile.
I can’t even imagine all the possibilities of what people will do when they can interface with an API on their computers using code.
Once an API is available, a whole host of computer based applications and web applications become counterparts to Roam. Consider interactions with Zapier and IFTTT or running Python scripts from your desktop and the possibilities enabled by an API are endless.
Extending the Presentation Layer: Custom UIs
Currently, users can only interface with Roam via the default UI.
In an attempt to customize the interface, numerous people (myself included) applied custom CSS via browser plugins to enhance their experience as much as CSS allowed. The development team officially blessed custom CSS by creating a mechanism to use CSS scripts stored in Roam.
This was a popular decision!
The response to Roam embracing custom CSS is an indication of how much the community wants to tweak, enhance, and share their experiences.
I believe if a robust API is created, developers will create custom interfaces for Roam outside of the default UI. Custom UIs in the form of other web applications as well as desktop and mobile applications.
These additional applications would leverage Roam’s data structures but be enhanced by new ideas from other developers. The same Roam database could be used in one tool focused on writing, one specifically for research, and a separate tool designed for consumption.
None of this detracts from Roam or its business model. All of a user’s Roam data is available to be exported today as they’re not locking in users by imprisoning their data. They understand allowing data to be accessed by other applications increases how users interact with their data. This only serves to strengthen Roam’s place in the marketplace.
Extending the Database Layer: Accessing Other Databases
This last one is deep speculation but I think it’s highly likely it could occur at some point in the future.
The database layer could be extended by allowing users to reference other databases besides the one they’re currently in.
This is where I get really excited. Imagine being able to link between your own databases. Or the public databases of other users.
Already, there are numerous Roamans (hmm…is this the correct term?) who have created public databases with the intention of sharing them. I have one I use for sharing literary works and others can be found at Roam Public.
It’s Coming
I initially communicated these ideas in a Twitter thread which received a ton of positive feedback.
Of particular note was this response:
Aaaaand @DavidCrandall_W goes on the Deep Design list too.
Epic thread about Roam's platform possibilities. Based on my talking with @Conaw this is all on the actual roadmap; David's just seeing it before most people.https://t.co/SepamcbJFl
— Malcolm ?cean (@Malcolm_Ocean) June 8, 2020
This part had me super excited: this is all on the actual roadmap. That’s exactly what I was hoping for! I think Conor and the rest of the Roam crew are planning on a long-term product and I’m excited to see where it goes from here.
I’m not generally this excited about applications. But when a tool has had this kind of impact and created the type of supportive community Roam has, it’s because there is something more to it. I’m invested in Roam at this point and believe it has an exciting future.