To create a heading in Markdown, at the start of a line, you put a hash character # followed by a space:
To create a second level heading, you put two hash characters, and so on:
OK, all that’s good to know, I guess. But so far I only see a bunch of weird characters floating around my texts that I was told would format them in a certain way. But I don’t actually see them.
Now, one way of showing them as what they really are is by highlighting the Markdown syntax characters # and *:
Now I can see my italic text being…italic, but I still don’t see my H1 heading. Surely it can’t be the same size as my body text, right?
Well, …drum roll…
It’s the split-pane!
With split-pane, I can finally see my big phat H1 heading!
Split-pane was(and is) everywhere:
(Inkdrop)
However, under this setup, I would have to shift my attention, from my editor on the left side, to the split-pane on the right side, and again. This would be exhausting.
What if we got rid of the split-pane, but we still could preview our stuff as we write? Sure we can!
A step in that direction can be seen in TOAST UI editor:
You can literally add or delete the hash characters to get to your desired level of heading. And the coolest part is: you can see the heading’s size adjusts right there in real-time!
Very nice!
Some editors don’t seem to take this real-time visual feedback all the way though. Examples below show the italic text in the heading is formatted in the editor in real-time, but not the heading itself:
Anyway, I can’t help but notice the Markdown syntax characters # and * are still sticking out even though technically we are already in preview mode while we write. In other words, we are not exactly WYSIWYG yet.
Now, let’s take a look at a few editors that might take us there: writing Markdown in a strictly WYSIWYG fashion without a split-pane.
Here is how Notion do it:
No more # and * sticking out! We are finally in the realm of WYSIWYG!
Same thing in Atlassian’s Confluence:
In both of them, users can easily create headings and italic texts by entering their respective Markdown syntax characters. This is a user flow and a mental model we have been accustomed to in every editor that’s mentioned here so far.
But here is the thing: when it comes to editing, users are forced to switch to an entirely different flow and mental model.
For example, to change a heading’s level in Notion, you have to double click to select a text in order to bring up a floating toolbar where you will find and select the type of heading you want:
Similarly, in Confluence:
Sure, keyboard shortcuts are available. But they are also an opposing user flow and mental model. They can complement the main flow but not replace it.
At this point, we can form a first principle for a Markdown editor: adding and deleting Markdown syntax characters is each a cause-and-effect that’s inextricably linked to each other.
We can observe this principle in the split-pane world:
Entering and deleting characters has been a part and parcel in online writing and editing since the advent of personal computing. If it’s possible to enter certain characters to create certain UI element, it should be possible as well to do the reverse – editing the characters that you have entered – to edit the said UI element.
As of this writing, there are only a handful of editors that seem to follow this principle. Let’s take a look.
Marktext editor:
But the principle doesn’t apply to the heading which can only be changed with keyboard shortcuts.
Here is Typora editor:
Unlike the italic text, users don’t get instant visual feedback when creating heading. And like Marktext, editing heading can be done only with keyboard shortcuts.
The closest editor that follows our first principle is Obsidian editor:
That’s what I’m talking about!
A minor thing to point out there is the body text becomes italic too when you delete the closing asterisk of the italic text in the heading.
And finally here is a Markdown editor I’m working on:
Conclusion
All modern Markdown editors allow us to adopt a user flow and a mental model in which we can enter Markdown syntax to create UI elements such as headings and italic text. But, in almost all of them, the reverse is not possible – to edit the UI elements, you are forced to adopt an entirely different flow and model.
This post was a journey in search of my ideal editor: a place where visual feedback is immediate from an action as singular as entering and removing a character, and a place where you can see, and feel, every pulse of your written thoughts.
