I want to see all the Markdown that I’ve written, even if the end user won’t. Do I click it, double-click, triple-click? What if I’m just using the keyboard? It’s not so much that these features aren’t useful, it’s that they break my flow. I can’t stand the work of futzing with the app to change a heading level, for example. In contrast, I’m not a fan of the one-mode-to-rule-them-all design where Markdown formatting automatically converts to styled text, hiding the formatted code (implemented in some form by Dropbox Paper, Typora, Ulysses, and Bear). Having both edit and preview mode active at once can help you feel more connected to the finished product. It’s kind of like static site generators that auto-refresh so that you can see your changes as you make them. What it looks like matters, and having a preview can give you a feel for that. Writing Markdown is not the same as writing code. I happen to like Markdown editors that provide a side-by-side or paned design where I can see both at once. Similarly, many Markdown editors have separate modes or views for writing, editing and reading.

From vi(m) to Google Docs, separate modes for writing and reading seem to appeal to writers. But perhaps there is an exception for text editing software. UX principles tell us that modes are problematic. Consideration #1: Separate writing and reading modes Here are some key considerations for Markdown editing apps to help the words flow. I’m going to give you some options (including my favorite), but more importantly, I’ll walk though features that these apps offer that are especially relevant when choosing. And the more you write it, the more you want the tooling experience to disappear so that the content takes focus. If you run or have recently switched to a static site generator, you might find yourself writing a lot of Markdown.

Macdown shortcuts