Why so many editors?

Most people love that we offer them the choice of editor to use to edit or craft their notes. If you want rich text, like highlighting and colors, you’ll need to use a rich text editor, and almost all web-based rich text editors use HTML as the under-the-hood markup language. But forcing all of our users to have their notes converted to HTML is nowhere near our modus operandi. We promised you portability, so we default to plaintext. If you want rich-text, you must opt in.

Ok, well, what about Markdown—why do you offer like 5 different Markdown editors?

Because writing is a vibe. There are many ways to do it. There are a hundred different configuration options and ambiances you want when writing. Do you want the Markdown syntax to be visible while you type, or do you want it hidden? Do you want the Markdown to render in the same view you're typing in, or do you want a split-pane between raw and preview? Do you want a toolbar, or are you a Markdown pro who knows all the syntactical tricks by heart? There is no one Markdown editor to rule them all.

Ok, but, why not have just one big editor that does everything, instead of ten different editors that fragment the experience?

There are a few reasons:

  1. It's impossible. It’s like asking Microsoft to combine Excel, Powerpoint, and Word into one app. Those poor engineers.

  2. You decrease overall stability. If we built one editor that did everything, from rich text, to spreadsheets, to Markdown, tasks, and code rendering, this editor would be eternally restless and bombarded with updates. Because of the tight coupling, a fix made to code rendering would somehow break spreadsheet functionality, and a fix made to task rendering would somehow make the bold function begin rendering italics. Of course there are ways to properly build modular code, but nonetheless, we quite like the idea of specialization amongst editors. Each of our editors is good at doing one thing and one thing only. Our Markdown editors never ever have to worry about presenting a spreadsheet. They shudder in fear at the thought of some product manager one day forcing consolidation.

  3. I’m going to be fully honest with you: we’re not an editor building company. The surface area of our passions as a team is wide, but no one on our team is particularly passionate about building editors. It’s hard stuff. Which is why we rely mostly on open-source components for most of our editors. The editors we do like building end up not really being “editors” but kind of just specialized applications. Like TokenVault, which is my absolute favorite “editor”. It’s more of an app to manage your 2FA secrets for other applications, and generates 6 digit codes for you to sign in on other services. It's a direct replacement to Google Authenticator, with the added benefit of not losing all your entries when you get a new device.

  4. Building a mega-editor means producing a super proprietary format that you will never be able to escape from. Perhaps a Notion-like block system is what some might be after, but I can only imagine what monstrosity of a data schema those documents produce. Don’t get me wrong: it’s super cool. But it’s not what we’re building.

Editors kind of behave inconsistently between desktop and mobile.

Sigh—yes, editors are most certainly biased towards a desktop experience. Essentially our editor experience is akin to taking Microsoft Excel and shrinking it down to mobile size and hoping for the best. We get pretty good results on mobile 90% of the time. But there will be edge cases. And in most cases, we’re at the mercy of the open-source maintainer for fixes. If mobile is your primary use case, it’s best if you try out the editors you’re interested in there first to see if their UX fits well with your expectations. To be quite honest, the best answer I can give regarding this is: yes, editors are not a mobile-first experience, but given the constraints and goals of our system, it gets the job done.

What does the future of editors look like?

More editors. Believe it or not, we actually have another Markdown editor coming soon. But again, it does something a little different than the other Markdown editors. And we don’t build it from scratch—it’s based on an open-source component.

We’re also eager to push the “app” concept more in the future, similar to TokenVault. Concepts like a password manager, a contacts database, a recipe manager, and other specialty concepts.

And, most importantly, we're investing heavily in an end-to-end encrypted, private Wordle clone, directly in Standard Notes. /s

You'll only receive email when they publish something new.

More from Crafting Privacy
All posts