No. This Should NOT Be Native to Roam

• Blog Post Complete
• Notes
  • Feedback
    • Stew Fortier
    • Joshua Mitchell
    • Michael Koutsoubis
  • images
    • 
    • 
• Content {{word-count}}
  • One of the most popular replies I get after releasing a RoamJS extension on Twitter is something to the effect of "Wow! This feature should be Native to Roam!"
  • Here's one from my good friend Josh:
  • https://twitter.com/joshacheson/status/1311456868942962688?s=20
  • And another one:
  • https://twitter.com/OGreenius/status/1321833308498522112?s=20
  • I understand the frustration. External scripts have a higher barrier to entry, mostly because they lack the trust you've established with the primary product. There's also a significant FOMO discovering a feature that other power users have been taking advantage of while you were left in the dark.
  • Despite all of this, I fundamentally disagree. The approach the Roam team has taken to make a very simple app that is highly extensible is one of its strongest assets. There are three reasons why - simplicity, priority, and community.
  • Simplicity
  • When was the last time you tried to use Yahoo? Was your immediate reaction "there's so much stuff here, what do I do"?
  • Now think about Google. It has a single search field. You fire up the app and know exactly what to do - start typing in a search query in the text field. From there, you have access to the world's knowledge through the internet.
  • 
  • The most effective apps are ones that are the simplest to get started. These simple apps then become even more powerful when they allow users to build extensions on top of them. Google Chrome has a simple, straight forward use case with over thousands of extensions that could fulfill the thousands of other unique use cases.
  • Roam has taken the same approach. They're brought a simple interface with one fundamental feature: networked note-taking. With just writing notes and backlinks, you could transform how you take notes from the archaic hierarchical model to the more natural networked thought model. The simplicity makes it dirt simple for anyone to get started using Roam.
  • As users become comfortable with Roam, they start to develop their own systems. These personal systems lead to personal problems that apply to some but not all users. This is where extensions come in. Users can simply install the extensions that most empower their specific use cases as their usage of the product evolves.
  • If these extensions were native to Roam, it could bloat the product. It risks making the product harder to understand, slower to use, and longer to get comfortable. With features installable instead of native to the platform, the vision of Roam's primary use case becomes clearer to users.
  • One should not install all possible extensions. That's like saying one should download all the apps from the app store to your phone. Instead, develop your own systems in Roam and take note of when a roadblock arises. Only then should you search for a Roam extension or hidden feature that resolves that use case.
  • Priority
  • There are certain features that appear at first glance to be low hanging fruit. They make it tempting to say as users "why don't you just implement it?" Sort icons, emojis, and integrations are fairly common in numerous apps. What's taking you so long!
  • Developing a feature to the standard that web applications are expected of today takes several man-hours. Any given feature brings with it hours of brainstorming, user research, design, implementation, and testing. A simple sort button could take a week at some companies.
  • But, the biggest cost of chasing low hanging fruit features is not the time investment. It's the opportunity cost of what you don't get to implement. Time spent on one feature means that there are other features that continue to not be implemented. With Roam's current team size, this prioritization becomes especially important as they weigh the tradeoffs of the various feature requests.
  • Bardia Pourvakil, community manager from Roam, runs multiple office hours through Zoom. In a recent one, he mentioned that the team is looking to prioritize what they consider to be "unsolved problems", instead of the solved ones like a mobile client or other UI elements.
  • The Roam team is currently working on making a publicly accessible backend API. This will blow the doors open on all the possible integrations and services the community will be able to build on top of it. We could tackle the solved problems, giving the Roam team the freedom to explore problems that include offline mode and multiplayer.
  • Community
  • Why does the roamcult itself exist? How was the team able to inspire a passionate group of people to engage intimately with the product?
  • There are probably multiple reasons for this success. The one that I want to highlight is the way they invited the community to contribute to the ecosystem.
  • One of the best ways I've seen to foster an engaging community is to empower its members to contribute to it. Node.js took off primarily because NPM made it extremely easy to contribute and share packages with other developers. Reddit is popular because each individual subreddit is made of content created by the community.
  • Roam enabled this same dynamic by first introducing [[roam/css]]. Members of the community were able to create and share custom themes with each other catering the platform towards their tastes. This inspires the community to engage far more with the product than if Roam rolled out their own themes.
  • Then they introduced [[roam/js]]. This led to the rise of custom extensions that are similar to Google Chrome extensions in that they are native to Roam. No matter what device you're on, your graph will have the extra functionality. This has led to projects like Roam42 and RoamJS.
  • One could point out that it's in my incentive to say that features that I'm building should not be native to Roam. I argue the opposite. I'd be ecstatic if any of my tools become core to the product. It would mean less code for me to maintain and more time to spend on more interesting problems.
  • The next time you come across a feature that you feel should have been core to the product, consider the alternative. How much simpler is the product without it? What is the team working on instead? How much more engagement is there now in the community? I am then thankful that certain features are not native to Roam.