It’s time to abandon Microsoft Word. It’s an archaic tool based on an out-dated model of personal publishing that encourages writers to worry about formatting and layout design instead of writing, and it’s rooted in the era of the stand-alone PC, so it’s ill-suited collaboration and distributed teams.
My first engineering job was at NASA in late 2001; I left and joined a start-up and finally ended up at a Fortune 500 company. Through all those moves, Microsoft Word was—and remains—the only tool for writing documents, be they analyses, specifications, plans, etc. In the corporate workplace, the only applications that ever challenge its dominance are Outlook, which specializes in rapid and temporal communication, and PowerPoint, used to convey superficial understanding to people who only kind of care.
The bad
Word’s problems are a byproduct of history. It was firmly established as the de facto word processing standard well before the birth of the internet—when documents, books, and letters were still the primary means of written communication. Along with a printer, Word enabled a single person to become a publisher, and its user interface reflected this goal. In Word the user is a writer, editor, and publisher. This unfortunately merges two distinct activities and makes it impossible to write without simultaneously designing.
Contrast this with the process for traditionally published writing. Authors deliver manuscripts not books, and journalists deliver copy not newspapers. Obviously writing evolves during the publishing process (and authors like Tufte are fastidious about controlling the content and design of their work), but historically, content comes first, then editing, then publishing.
The ugly
Word’s second problem is a hostility towards collaboration. Documents are stand-alone files that can only be edited by a single author at a time. Multi-person edits are either made serially, in a canonical version of the file, or in separate copies later merged. When multiple copes are edited in parallel, file sharing is probably accomplished via email or a shared fileserver. Email is incapable of tracking who has what version of the file, and thus the baseline for any set of changes. Fileservers have a similar issue (and filename taxonomy is not a substitute for metadata).
The built-in merge and compare tool is laggy as hell, non-intuitive, and creates an enormous mess in the file because it tracks both content and formatting. Formatting settings and version history are metadata that I don’t want mixed with my content.
Compare this abomination to the simplicity of merging separate changes to a text file using modern software development tools like Mercurial and KDiff3. Unfortunately, since Word files are binary, these tools are hamstrung when dealing with docx.
The good
So what alternatives could replace Word as the word processor, and email, fileservers, or SharePoint as an ad hoc version control system? The requirements:
- a markup language that captures formatting intent without having to specify the page design details in the content
- content stored as plain text, so it can be easily diffed, concurrently edited, and then accurately merged
- a way to insert figures, tables, and equations
- a way to beautifully render this bare-bones content into a finished document.
The first two goals are easy: low-overhead, readable markup of plain text files is what Markdown was invented for, and any modern version control system (Mercurial, Git, etc.) can solve the configuration management and collaboration issues.
For visual content arbitrary images can be inserted, and unlike Word, when updated graphics are saved from the creating application they don’t need to be re-pasted into the document.
Lastly, since Markdown is rendered into html by script, CSS controls the formatting, which ensures that it’s consistent across the team.
This solution: Markdown text files for content, Mercurial for version control, and CSS-formatted webpages for document rendering replaces the Word Swiss Army knife that does several functions poorly with three ultra-specific tools that kick ass at their respective duties. It lets writers focus on writing in a format compatible with mature tools to control and manage the evolution of their work, and abstracts layout and design to (CSS) experts who can make it awesome.
As a proof, this article was:
- derived from a question I posted on SuperUser
- written on a Mac in Byword
- edited on an iPhone in Nebulous Notes
- stored in a DropBox folder containing a Mecurial repository of other blog posts and works-in-progress
- and published to the web using Pelican