The making of BLUEPHRASE
The Demise of Word Processors
The origins of distraction-free writing
by Joe Honton
This is the story of how I finally abandoned word processors in favor of distraction-free authoring tools.
In 2011 I finished writing my fourth book after months of careful rewriting, editing, typography, layout and proofing. I had a everything in order for the printer and binder. It was something to be proud of, and I was happy to have it all behind me.
The next phase of my project was to be the manuscript's conversion into a digital book format, to reach online readers. Initially, I figured this would take just a few magic keystrokes, but as it turned out I was wildly mistaken. The tools to convert a word processing document into a finished eBook were barely usable, and the online services to help me with this seemed too eager and too meager.
As a long-time computer programmer, I wasn't going to let this defeat me; after all, an eBook is just HTML and CSS wrapped into a zip file. Surely I could handle that — and eventually I did — but the experience left me dissatisfied. Why was it so hard to convert a word-processing file into HTML? Why were there so many little details that kept needing my intervention?
Shortly after that experience, I started working for a software company that was developing a tool to help with this very problem. I set to work with gusto and learned from first-hand experience the answers to my own questions. First, I lead a team of engineers through the development of a converter from Adobe InDesign to HTML/CSS. Then I lead a second team through the development of a converter from PDF documents, and a third team that worked on tearing apart Google Docs. It was reverse-engineering at its best. We could see how decades of advances in technology were layered on top of one another, and how new problems were approached while keeping old solutions intact. These were sophisticated tools, with intricate inner workings.
Then that butterfly in the Southern Hemisphere flapped its wings, once more disturbing the cosmos . . . and the inhabitants up North . . . and me.
Oh, chaos! One day I was riding the crest of success, the next day I was without a job. This was upsetting. Not because of money or self esteem, but simply because the work wasn't finished. As an author I still had the same needs, but no one was around to make a serious attempt at fulfilling them.
The battle for the author's attention
I took a deep look at the problem from this new perspective of failure. Not so much what we did wrong, but more what we failed to do right.
An author's job is to assemble words into meanings, to shape thoughts into expressions, to transmit ideas across time and space and experience to a distant reader. This is not a simple job, obstacles abound. Lack of clarity on the subject matter at hand. Inexperience with the craft of writing. Inability to hear words as the reader hears them. Forgetfulness. Inattention. Distractions.
Word processors are of no help with any of these obstacles. I would even go further, and say that they exacerbate the problems. And I don't say this in a finger-wagging way, because I was there throughout the rise. In 1983, I wrote a neat little algorithm to right-justify paragraphs by interspersing spaces between words. Later, I worked for five years at Wang Laboratories, the multi-billion dollar company whose name was synonymous with word processing. And when personal computers arrived, I was an early adopter of PageMaker, the desktop publishing tool that helped to propel Microsoft into stardom, when the state-of-the-art was MS-DOS 6 and Windows 2.11.
At the time, word processors were focused on solving just a few key writing problems: rearranging words, correcting mistakes, organizing sections, cataloging collections. Yes, they could justify paragraphs, and italicize phrases, and adjust whitespace, but these were in support of the writer's need to bring clarity, and the reader's need to comprehend.
Then Windows arrived on the scene — and WYSIWYG (you know, what you see is what you get). That's when word processing stopped focusing on authors and their readership, and began solving problems related to typography and typesetting and the graphic arts. That's when the author's job started shifting away from the subject matter and the craft and the reader. Suddenly, there was phalanx of buttons across the top of word processors, standing by, armed and ready to conquer the manuscript into submission. So we went into battle, experimenting with fonts just because we could, playing with colors like a painter with a Da Vinci palette, emphasizing words that required no emphasis, shortening our sentences into fragments because bulleted lists were so cool.
The word processor won, while the author lost; distractions and temptations ruled.
In the midst of this battle, newcomers arrived in the form of markup languages. Their goal was two-fold: break the proprietary formats employed by the enemy, and use an easy to read, easy to parse text-based format, that anyone could read and write. As we all know, the result was fantastically successful, and today we have a large industry of professionals whose jobs are dependent upon its continued success. But unfortunately for authors, markup languages did nothing to improve their work situation. Instead, we ended up with more WYSIWYG, in the guise of browsers with automatic spell-checkers underlining our mistakes with wavy red lines, and grammar checkers admonishing our use of the passive voice, and self-important tools informing us how many adverbs we should drop. Just more distractions.
Less fluff, more stuff
As an author, what I wanted was a distraction-free writing experience. One that was similar to the blank slate I used in my work in software development. There, the work followed an interative three-step process: write, test, correct. That's what I wanted as an author: a clean slate where my thoughts would flow, where I could read my creation as a reader, and where I could correct my words when needed. What I purposely did not want, was all the extra buttons, and popups, and external voices telling me how to do my job. And the irony is that today's writer is exhorted to concentrate on content, as if it was something we'd forgotten, as if power words in our titles, and animated graphics, and all the sparkle that's so easy to create were all that we cared about.
I wanted less fluff and more stuff. I wanted to keep the goodness that I saw in HTML, but discard the awkwardness and clutter that was preventing it from being truly great.
Let me reveal the secret that nobody in the software industry talks about. Writing HTML sucks. Reading HTML sucks even more.
One day, when I was at a technical meetup to learn a new programming paradigm, someone asked about blogging software. He wanted to hear first hand about the tools people used for their own writing. My answer was HTML, from start to finish. He turned away from me agahst.
Yes it's true. Nobody in their right mind would actually write HTML, it's a horrible experience. First there is that awkward keystroke sequence to create each opening tag, then an even more awkward sequence to create the closing tag. Need a word italicized? Just try it for yourself:
Shift ⇧+< i Shift ⇧+> the word Shift ⇧+< / i Shift ⇧+>
It's the most difficult dexterity challenge ever invented. Repeat that for every paragraph, every list, every special term, and your left pinky finger starts to rebel, while your mind concentrates on getting it right, and soon your train of thought is on your typing skill, not on your composition.
Then there's the reading experience. The clutter of tags and more tags (yes two for everything!) makes it difficult to see your own words. And the lack of necessity: why do you even need a paragraph tag? Can't the <p> just be assumed? Or lists — you've just created a list container by typing <ol> or <ul>, why do you need all those <li> tags, can't they be implied?
I know it sounds like I'm ranting, but actually, these types of thoughts were just the first steps toward defining a better way.
Remember, one of the primary goals behind HTML's design was that it should be easy to parse (easy for a programmer that is, not a reader). And it is. Even a novice, working through a good college-level course in computer programming, can write an HTML parser with just a day's work. But that should never have been a goal, because the awkward keystrokes and the visual clutter drove people to find alternatives.
Consider this: Wikitext is the language behind one of the most popular websites on the Internet; it's used by hundreds of thousands of people, and its raison d'etre is to make HTML easy to use. Or consider this: Markdown is the language that software developers use to document their work; the very people that created HTML, eschew its usage in their daily work. Or this: WordPress is the most popular tool for creating websites, with one of its primary purposes being content management without the use of HTML.
Underneath the covers, HTML is the lingua franca that enables all these alternatives to be understood by browsers, and, getting back to my original problem, with ePub readers. HTML is not going away, so there's little point in any solution that doesn't embrace it. The folks at W3C, the World Wide Web Consortium open standards community, have carefully refined the language to cover every needed possibility. Its ubiquity is deserved.
So, turning back to that question about writing software. What did I use? With ambivalent feelings, it was HTML. I just wished for a way to discard its surface blemishes while keeping its inner beauty.
But that's tomorrow's story.