I just realized I hate writing on a computer. I think of something, type, search for better words, get distracted by cat-videos, delete, write something else, format and repeat. Writing these two sentences already took me 20 minutes.
There has to be a better way. I’m thinking about creating my own text editor that takes away some of the hassle.
Why I hate writing
I reflected on what exactly makes writing on a computer such a pain for me. I’ve narrowed it down to three key problems:
All the buttons, menus and features of a text editor make it extremely hard for me to focus on the actual text.
Note: I’m not sure if being on the internet is more of a distraction or a benefit – given that things like searching for synonyms greatly improve and speed up the writing process.
Structuring and formatting text almost always disrupts my writing process, because I have to comb through cluttered menus or click fancy buttons.
I spend a good deal of my writing time solely on layout, just to have a document that looks decent. Plus I have to switch to a layout program in order to do that.
Now, I know there are existing applications that cater to some these problems, but none that solve all three of them. That’s what I want to do.
Taking it a step further
I just discovered Markdown. This almost completely solves my formatting issues, except that I now have to convert my text files to HTML before I can work on the layout – which is somewhat cumbersome.
However, this led me to the following idea: What if my editor could convert Markdown on-the-fly – while you are writing? You would always only see the resulting HTML, while under the hood, it would still be a tiny txt-file.
Also, the resulting HTML could easily be styled with CSS. There could be a collection of CSS-files, that – just like themes – would change the entire appearance of your text with just one click. Layout would only be a matter of seconds!
This project just got a whole lot more interesting …
Going Open Source
I decided to make the project Open Source. It will be hosted on GitHub once development has started.
I also want the editor to be web-based, so that it is available to all operating systems and platforms (including mobile).
Can I ask you something?
I finally got to do some research. I interviewed a number of people and talked to them about their use of text editors, asking things like "Which text editor do you use and why do you use this one?". I also asked them about some of the features of my project, like whether or not they could imagine using their browser as a text editor.
Here are the top three findings of these interviews:
Everybody* uses Microsoft Word and hates it because of its complexity.
Nobody* knows Markdown.
Nobody* uses a smartphone to write texts.
So, as a result:
My editor has to be simple.
People that don’t know Markdown have to be able to use it as well.
I’ll focus on the desktop version first.
Here’s the current feature list for the application. Note that this might be a subject to change, so I’ll keep this list updated.
Simple, intuitive interface – no buttons, no menus
Exports to PDF & HTML
Time for some sketching! I put down a couple of ideas and immediately tested them in the form of a paper prototype. Overall, the tests went quite well, but I encountered two major problems:
I separated all the editor’s features (open, save, choose a theme, options …) into three categories and placed three icons on the right side of the screen to represent them. People did generally not understand the categorization or what the icons were supposed to mean.
2) Formatting tooltip
I used a tooltip for formatting options (bold, italic, underline …) that would only appear when something was selected. That feature wasn’t nearly as intuitive as I thought it would be. It also turned out to be completely useless for everyone who knew Markdown.
This might not be for you
The results of the paper prototype made me realize I had to define my target audience more clearly.* I therefore decided to make the editor entirely Markdown-based, so users have to know Markdown in order to be able to use it.
I figured I’d rather make something great for a few people than something generic for everybody.
* It also made me realize that there are some usability issues that I’ll have to take care of.
I’ve conducted a simple readability test so I could start creating a default theme for the editor. I needed a font that is easy to read on both desktop and mobile devices, so I set up a simple responsive website with some text and the option to choose from 9 different fonts. The fonts were chosen following a number of prerequisites, like an Open Source license, multiple font styles and foreign character support.
Each participant was asked to choose one font that was very easy to read and one that was very difficult to read. These are the results:
Source Sans Pro
(~ n = 49, 30% on mobile phones)
Since both Tinos and Source Sans Pro were rated almost equally well, I chose to use Tinos for headings and Source Sans Pro for body text.
Note: I was very surprised to find that both monospace fonts (Ubuntu Mono & Inconsolata) were rated very poorly, given that a lot of (especially plain-) text editors feature these kind of fonts.
The saving problem
I stumbled upon a question that turned out to be quite an important one: How will files be saved?
There are five possibilities I could come up with:
1) Save to an account
Requires users to register. Don’t want that.
2) Save to the cloud (Dropbox, Google Drive etc.)
Useful, but involves some weird security measures.
3) Save to drive
Files have to be downloaded again every time a change is made.
4) Save to the browser (Local Storage)
Very convenient, but if you ever clear your browser cache, everything is gone.
5) Save to email
Similar to local saving except you get an email with your file attached. Same problem as with local saving, though.
After numerous pros-vs-cons lists and countless discussions I decided to go with "Saving to the browser", but also offering additional options to save files locally and send them by mail. I decided against "Saving to the cloud" because many people told me that their local files automatically get synced to the cloud anyway.
I looked back at the usability issues that came with the paper prototype and started sketching some new ideas. I made two major changes:
There are now only two categories of features: Themes and file management (save, open file, new file). Each category is now placed on one side of the screen (one on the left side, one on the right) and has a distinct, recognizable icon.
Instead of formatting options, the tooltip now shows a list of synonyms and rhymes corresponding to the currently selected text.
I set up a quick and admittedly not very pretty interactive prototype to test the changes I made. And – much to my delight – I found no major issues!
I felt confident enough with my sketches to start putting a design on top. I tried to make the interface as clean and unobtrusive as possible – avoiding anything that could potentially be distracting. To enforce this, I chose to hide all the interface elements for as long as the user is writing (i.e., until he/she is moving the mouse*).
* This does obviously not apply to touch devices.
Getting better at programming
Code the core
HTML5 offers a method called execCommand which enables all sorts of text formatting features (like making text bold, defining headlines and so on).
Very fast (native).
I have to write a custom Markdown parser to implement all the syntax features (LOTS of work!).
Browser implementations differ quite a bit.
marked.js is an Open Source Markdown parser written by Christopher Jeffrey. I could use it to convert text and then insert it back into the input field whenever the user presses a key.
Supports every single Markdown syntax feature.
Not as fast, because the entire file will be converted all the time. [found a way to avoid this]
The position of the caret/cursor is lost after the conversion and restoring it is quite a hassle.
3) Faking it
The user types in an invisible textfield and only sees the resulting, converted text. Conversion is handled by marked.js.
Works in a simple <textfield> element. No dependence on HTML5 features.
Caret/cursor and selections have to be faked and updated every time the user types.
I will set up a couple of demos to see which of these concepts will work best.
That's a little confusing
Number 2 from above was clearly the best solution, so I spent the last couple of weeks coding the basic functionality using this method. Once the base was done I ran a simple usability test – just to see if everything was working fine. I handed participants a piece of formatted text and asked them to replicate it using my editor.
It only took me three tests to realize that my concept had two flaws:
1) Block vs. inline elements
Block elements (like headings or quotes) only require one formatting character and thus are converted right after that character is typed (see first image). Inline elements require two formatting characters and are only converted when the second one is typed (see second image). This inconsistency confused participants.
2) Disappearing characters
Markdown characters are hidden when the user is no longer editing the phrase the characters belong to. For emphasized text, for example, the * characters will disappear once the user is done editing the phrase and will only reappear when it is clicked (see second image). In headings, however, the # character will always be visible (see first image) until the user types return or clicks another element, because headings have no enclosing character. Most participants had difficulties understanding this.
Both of these problems are a result of converting Markdown while the user is typing. I will have to think about a better way to achieve this ...
RETURN to simplicity/ ENTER simplicity
I needed to make writing in my editor a lot easier. It was deficient (see above) and just didn’t feel quite right yet. So, for the sake of simplicity, I decided to once again change the foundation of my editor.
It was really just one change, though: Text is now only converted when the user presses the RETURN/ENTER key (or finishes editing a line by other means, like clicking another element). Going back to the line again displays the original text (see image).
And that’s it. No more disappearing characters, no more jumping cursors. As soon as you’re done your text looks nice.
I can’t wait to put this to the test!
The usability tests for the revamped version worked out just great! The participants were able to format and edit text much more easily than in the last testing session and I received very positive feedback (and a few bug reports, which of course I took care of). With the users’ approval I could now finally finish programming the foundation of the editor.
A somewhat stable version is now available on GitHub and free for everyone to download, fork, contribute or take a look at. There’s also a demo of the latest version if you want to play around with the current release. Note that right now (07/2014) there is no user interface yet and everything looks very ugly, but that sure is about to change in the next couple of weeks ...
It’s a boy!
... and his name is Mark. That’s right, my baby editor finally has a name! I spent hours trying to come up with a name that doesn’t include "edit", "write", "text", "word" or any other obvious choice, until my brother told me to "just call it Mark". So there you go. But at least I designed the logo all by myself!
I also redesigned parts of the user interface, because some features have changed over time and others have been added. Now Mark is ready to be released!
After many months of planning, testing, tinkering, prototyping, designing, iterating, coding and cursing, Mark is finally online! As a matter of fact, I'm already writing this entry using Mark!
I'm really happy with what my little editor has become. But there's always room for improvement, right? Help me make Mark even better!