Designing a composing interface
To write my blog posts, I use Markdown, a useful language to write simple fragments of text. The text is then "compiled" into HTML, which is then served as a webpage. Since Markdown files are plain text files, I mostly have used plain text editors in the past to write my posts, and I have had a decent experience with them. A week ago I was trying WriteFreely and the difference between their composing user interface and a text editor is very noticeable. I have read people say they love writing in Vim or Emacs, but for me, something more aesthetic is more suited.
I looked around to see if I could find any text editor similar to WriteFreely's composer and found Ghostwriter which looked exactly like what I was looking for. However, the installation process wasn't particularly smooth in Debian, and I also use computers where I don't have root privileges, so I decided that it wouldn't suit my needs. Inspired by WriteFreely's composer, I decided to make an HTML file that would do exactly what I wanted.
Creating my own writing interface
To create my composing interface, I started with WriteFreely's and edited it heavily. The original had a lot of features (including a publishing button), so I deleted most of the code and added some of my own. As of the time of writing, my composer doesn't have many features, because it is supposed to be a simple and distraction-free tool to write content, but I will talk about the couple I have added so far.
Saving the content between sessions
The content you write doesn't disappear when you close your browser—unless you clean the browser's data. I use local storage1 to store the text written, so when the composer is opened again, you can continue writing where you left off. I have whitelisted my domain from Cookie AutoDelete, so I can start writing and get back to it and any point, just opening my browser. I also added a way to edit multiple "entries" at once using query strings to differentiate which one you want to retrieve/save the changes on.
Exporting the text
I found myself pressing Ctrl+s pretty frequently when writing, a habit I have from
coding (always save your changes!). If you do so on Firefox, a pop-up will appear offering you to
save the page—the actual HTML page. I found it quite annoying and decided to assign the shortcut a
different action. If you press Ctrl+s, it will seem like nothing happened, however,
the composer will update the word count and save the text using the system mentioned previously
(it also does all this after 0.2 seconds without typing, so the feature isn't super-useful, except
for getting rid of the saving the HTML dialog).
However, this gave me the idea to add an exporting feature. So, if you press
Ctrl+Shift+s, you will download a Markdown file with the text written. I decided to
make it specifically a Markdown file because it is what the composer is for, however, it can be
used for any other language.
Conclusion
I can now write my posts on a very simple and minimalist interface, without distractions, but with a nice design. All this without the need of installing any software. Finally, I can also edit it to my needs, as I know exactly how it works and have learned basic notions of JavaScript.
Some people have disagreed with making a webpage act like a piece of software, however, it is the most convenient method for me. You can also simply save the HTML file with the dependencies (the CSS and JavaScript files) and use it offline, so it shouldn't be that much of a problem.
- Wait! Local storage sounds like cookies, the ones that track you, right?! Well, in the first place, it is not the same. Local storage doesn't leave your computer (except through JavaScript, you can check it doesn't in the composer). On the other hand, cookies are just pieces of information stored on your computer which are sent to the server. Someone can store a unique ID, so when you visit a website, they know it's you, tracking you around the internet. But cookies are also useful when you log in to a website, so you don't have to do it every time you move around a webpage. Cookies are not inherently bad. ↩
