Revamp of Bloggie's Markdown Editor

Tan Jun Rong avatar

Tan Jun Rong

Photo by Todd Quackenbush on Unsplash
Photo by Todd Quackenbush on Unsplash

In Bloggie or any other blog platform, the content is the meat of the platform. In order to make great content, the Editor plays a big role. Therefore, we have been paying a lot of attention to improving the Editor than other parts since the beginning.

We released the first prototype of our Editor a few months back, and we've been using it heavily ourselves, even for editing documents that are not intended to be posted in Bloggie. We figured out that this is the best way to truly understand the pain point and the experience of our Editor.

And it actually worked out pretty well!

Since then we have been fixing small bugs and enhancing the Editor incrementally. However, there are a few things that can only be fixed by a major revamp. A major revamp is hard to come by, but it finally happened last week! 🔧 👷

Let's talk about the revamp in this post.

1. Double Scrolling Issue

In older version of our Editor, the page height is very tall. The empty page itself is scrollable due to its tall height (refer to picture below).

tall page height
tall page height

This by itself is not an issue, the problem arises when the content becomes longer than one page. That time, we will have a double scrolling issue. See picture below.

double scrolling issue
double scrolling issue

The user experience quickly became annoying ☚ī¸. When we want to scroll the content, we might easily and accidentally scroll the outer page.

We wonder how this issue is solved in other well-known sites.

Github

So we checked Github which is easily the most used markdown editor for us (being a programmer). To our surprise, Github is also suffering from the double scrolling issue 😮

double scrolling in Github
double scrolling in Github

Well-known sites usually have solid reasoning behind their UX. They have been through many iterations and perfected the experience for a long time after all.

So we tried to make sense of why it is done this way. After comparing to another few sites, we found out that the double scrolling in Github must have been intended.

In Github, while writing a comment, we often need to read the context from another comment. Hence the double scrolling.

why double scrolling in Github
why double scrolling in Github

In Bloggie's case, we are writing a single post, so we don't need double scrolling, so we moved on to check other sites.

Medium & Qiita

In the case of Medium and Qiita, they have a clear solution to this issue. They both fixed their control panel at the top or bottom. The only scrollable area is the content area.

Qiita's Editor 👇
Qiita's markdown editor
Qiita's markdown editor
Medium's Editor 👇
Medium's markdown editor
Medium's markdown editor
Bloggie's revamp editor 👇
Bloggie's revamped markdown editor
Bloggie's revamped markdown editor

2. Auto Saving Feature

We noticed that there is an important feature to make an editor reliable ãƒŧ the auto-saving feature. Without this, we might have lost hours of writing if we accidentally close the tab or if internet connection is lost.

Where to place the status?

To implement this, we need a place to show the status of the auto-saving. Otherwise, users wouldn't know that the post has been saved.

In the end, we shoved it into a blank space at the bottom.

bad placement for 'save' status
bad placement for 'save' status

This is not ideal because we will need to scroll to the bottom of the page to see it.

After the revamp, the status bar is fixed at the bottom, and will always be visible regardless of the scrolling position.

showing 'status' at always-visible-control-panel
showing 'status' at always-visible-control-panel
How frequent should we save?

Another question about auto-saving is how frequent should we save itnot ?

If we save it too frequently, it can be annoying. Typing a sentence might cause it to save 30 times easily.

If we did not save it frequent enough, a user might lose their content.

After some trial and error with some educated guessing work... 🔍đŸ•ĩ

We decided on the following rules:

  • auto-save is only triggered when a user starts typing (it does not save right away, read below 2 rules)
  • auto-save when a user starts typing, and stops for 3 seconds
  • auto-save after 5 seconds since a users starts typing, even typing doesn't stop for 3 seconds

We have been using this for a while and we felt good about it. So we kept this rule. 😀


3. Centralized control

By fixing the control bar at the bottom, the control elements are now all hidden at the beginning, and will only be revealed when we hit the publish button.

This way, the page looks much cleaner and we don't have to make any decisions about publishing (e.g. tagging, cover image) until we are about to publish. Asides from the page itself is cleaner, it also helps the users to stay focus at one thing at a time.

publishing decisions are centralized
publishing decisions are centralized

I hope you enjoy the post, and that's all for now, see you in the nextin post!
🎨🖊👋

Tan Jun Rong avatar
Written By

Tan Jun Rong

Android Programmer who likes writing blogs, reading, coffee, snowboarding.
Published in Bloggie
Enjoyed the post?

Clap to support the author, help others find it, and make your opinion count.