I'm trying to use Obsidian as an alternative to Roam for my projects the next month or so. Been doing so for the last two weeks or so, and I've been very happy with how its working. Thread on why I'm attempting a switch 🧵️👇
While there are a lot of reasons one might switch, the main reason I'm trying is because Roam is too slow. The design is incredibly innovative and the UX is incredible for networked thought, but that doesn't really matter if I can't get work done in it.
Any time I have a couple queries or sets of backlinks open in the sidebar, the slowdown is painful. I'll wait a few seconds to create a new bullet and indent, or have janky scroll. These are core features, and they're barely useable. I've been complaining for at least 6 months.
The truth is - I write a ton into my PKM system. If Roam can't handle my quantity 1.25 years in, I can't trust it as a lifelong PKM. This tweet represents its current state. It may change over time and I hope it does, but I just didn't expect this issue to still be around now
So I'm stress testing Obsidian to see how much I can move over. Odds are good that even if Obsidian becomes my daily driver, I'll still use Roam for specific functions/projects. For example, Roam's block structure is better suited for collaboration.
I am very aware of Roam's current power. I've pushed its boundaries since its early days! Believe me when I say you can do just about any workflow (single player) in Obsidian if you change your own user behavior. Not sure which behaviors I prefer yet.

Roam's feature set is well-tuned to knowledge work, it's just too slow for me. The combo of page and block refs has a greater impact than one might think. However, effective knowledge work comes from personal practice, not software conveniences
I think one of the keys for people switching to Obsidian from Roam is to get good at advanced search, make more atomic pages, and care more about search results than whether relationships between pages are literally being formed in the data structure
Also - functionally, Roam interprets branches of trees (filters and queries) similarly to how Obsidian interprets a flat page (search and backlinks). This is one of the biggest reasons why Obsidian pushes you towards more atomic pages if you care about signal/noise in search
None of the time that I've spent so far on Roam has been a waste even if I do fully switch, because it's not just "a lifetime store of knowledge" for future reference but also notes that I work with in the present. I've experienced immense value working with my notes in Roam.
Re: "Not sure which behaviors I prefer yet."

Since Obsidian pushes you towards having many separate pages vs. deeply nested outlines, there's a good amount more friction to say "X relates to Y but not to Z" as there is in Roam. I discuss more here:

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Robert Haisfield

Robert Haisfield Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @RobertHaisfield

25 Mar
The UX of @obsdmd is sort of like if Emacs were built specifically for writers. org-mode is cool, but very few people want to learn Emacs/elisp just for that purpose.
With the plugin ecosystem and some of its power features, it really feels like an IDE for writers.

What happens when they take that notion further?
Everything @jaydixit demonstrates in this video are trivially accomplished in Obsidian with either base features or plugins that are trivial to install. Not saying he should switch away from Emacs, just saying that this sort of power is way more accessible to writers these days!
Read 5 tweets
16 Mar
Being able to color groups based on a graph view search in @obsdmd is brilliant. Here I'm narrowing my website's contents down to "onboarding" and coloring the results.

However, some of these nodes certainly overlap. If only it showed that somehow? Perhaps split colors?
Given that I can hover preview over any node, this might be preferable to viewing search results in a linear format... ideally with a way to see nodes with split colors, and would require me to have really good titles for notes.
On that note... why can't I color code linear search results in the same way I can color code graph search results? Wouldn't that also provide me with similarly helpful utility?
Read 7 tweets
12 Mar
AFAICT the fact that open source builds on open source is one of its greatest strengths (the practice is cumulative) and its greatest weakness (there’s a ton of baggage that gets kept, especially on projects that value backwards compatibility)
Before working in learnable programming, I had no prior coding background. I’m approaching this with no coding related tacit knowledge, just applying my own design sensibilities.
Emacs is a great example. The core concept is strong, and 40+ years of dev means there’s an amazing ecosystem of prebuilt extensions around it. Backwards compatibility is a value though, so there’s 40+ years of baggage. But what if you could start fresh with lessons vs code?
Read 4 tweets
11 Mar
IMO, Roam is a better interface for Twitter than Twitter. A lot of my knowledge management is in my tweets and their replies. @ollybot_redux and I were were working on Twitter import... who wants to pick up where we left off? Olly put it on GitHub github.com/oliverb123/roa…
Here I have some notes on what a good Twitter import would look like. We were working on import from tweets.js - ideally I'd import all from there, and then set up something more continuous. roamresearch.com/#/app/Rob-Hais… cc @dvargas92495 @houshuang @andyga0 @adam_krivka
Some possibilities for fetching replies to tweets, shared from discussion with Andy:
Read 7 tweets
8 Mar
The light pen was immediately intuitive, while the mouse wasn't. Engelbart put two people against each other on the same task, and mouse users were initially slower, but quickly they outpace those with the light pen. We live in a world of light pens.

"That's the reason why people are bragging that infants can use iPads as if this was a point of pride rather than something horrifying." We infantilize people with apps that are built to be intuitive from the start but can't do anything serious.
"This is why we live in a world where most things are easy to learn, but hard to use. By hard to use, I don't mean that we feel they are difficult, but that we never reach our capacity to meld with these systems because we've chosen this path."
Read 4 tweets
6 Mar
I wonder if DSLs are just the next logical step for apps built for power usage. Let people directly input data and manipulate it, following your apps data model.
That’s not to say that GUIs shouldn’t exist. This thread on designing for power usage makes the argument that there should be a smooth learning curve from beginner to power user. Ultimately, no GUI is gonna be faster or more powerful than a well-designed domain-specific language
If onboarding is the perceived problem... then whatever, they can absolutely be designed to be learnable. Clear feedback loops, affordances for different stages of the learning curve, and minimalist language design. That’s basically been my work w/ GuidedTrack for the last year
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!