As a part of my tentatively titled Kill Your Word Processor project, I’ve been trying to think of ways to expand the audience for it, particularly because I’ve more than once been frustrated by collaborators’ insistence on the use of clunky word processors and browser-based WYSIWYG editors which I’ve long since given up on.

I even posted a note on the Backpack forum, where users have been exposed to the Textile lightweight markup syntax, trying to get others’ opinions on the matter, but it seems I’m preaching to the choir over there.

I have, however, been encouraged by what appears to be an increased interest in lightweight markup that seems to be part of a broader paradigm shift led by the spread of "Web 2.0."

But ultimately tangible results will be the most effective means of persuasion–e.g., a beautifully formatted LaTeX document converted to PDF, and a crisp, clean Web page springing from the same source; a demonstration of the tools that make such results effortless, etc. Still, I wanted to at least lay out some of the rational arguments here, hopefully with the end result of compiling a concise list of the benefits of the moving to lightweight markup.

There are at least two technologies that have preceded the current wave of interest in alternatives to bloated word processing software–one rooted in the requirements of collaboration on document composition, the other in the benefits of separating the production of content from its presentation.

Wikis emerged on the strength of their usefulness for collaboration on documents. The limited utility of passing Word documents back and forth as attachments via email should be apparent to most by now to anyone with enough familiarity with the Internet to know that there are tools (e.g., Wikis) that make that technique unnecessary. Among other benefits, most Wiki software packages have built-in versioning features as well as warning features to deal with simultaneous edits.

Wikis in fact sprang from the "Extreme Programming" (XP) community and from one of the guiding principles of that community: "Use the simplest thing that could possibly work." For that reason, Wikis did in fact incorporate and promote the concept of separation of content from presentation through the use of exactly the kind of simplified markup languages that are under discussion here. From c2.com, the site of the original Wiki:

Wiki’s emphasis is on content, not presentation. The simple markup rules make people focus on expressing their ideas, not making them pretty. Some people have found that working in this minimal medium improves their writing.

Unfortunately, in many cases, more technically inclined users demanded the ability to include HTML formatting by typing angle brackets which make the raw input of a document difficult to read, while the less technically inclined demanded the inclusion of word processor-esque WYSIWYG editors. The degree of accommodation of such requests varies from package to package, but clearly not all Wiki users were convinced of the benefits of simplified markup. This may be because those markup languages were not particularly well thought-through.

The concept of separating content from presentation has a more venerable heritage, however: It’s embodied in the LaTeX typesetting system, which was derived from TeX, which in turn was developed by Donald Knuth in the 1970s. Ubergeek protestations notwithstanding, composing a document in LaTeX’s own syntax is far more painful than composing in a word processor, but the content/presentation concept is firmly embedded here, as is the benefit of being able to compose in any text editor.

LyX is an editor that takes a lot of the pain out of composing LaTeX documents. While I don’t consider it very useful for my purposes, its documentation does make some interesting points about the importance of content/presentation separation:

Part of the initial challenge of using LyX comes from the change in thinking that you, the user, must make. At one time, all we had for creating documents were typewriters, so we all learned certain tricks to get around their limitations. Underlining, which is little more than overstriking with the "_" character, became a way to emphasize text. You were forced to figure out column sizes and tab stops, and set them, before creating a table. The same applied for letters and other right justified text. Hyphenation at the end of a line required a careful eye and a lot of foresight.

In other words, we’ve all been trained to worry about the little details of which character goes where. Consequently, almost all word processors have this mentality. They still use tab stops for adding whitespace. You still need to worry about exactly where on the page something will appear. Emphasizing text means changing a font, similar to changing the typewriter wheel. This is the underlying philosophy of a WYSIWYG word processor: "What You See Is What You Get". Unfortunately, that paradigm often results in "What You See Is All You Get".

This is where LyX differs from an ordinary word processor. You don’t concern yourself with what character goes where. You tell LyX what you’re doing and LyX takes care of the rest, following a set of rules called a style. …

So, the basic idea behind LyX is: specify what you’re doing, not how to do it. Instead of "What You See Is What You Get," the LyX model is "What You See Is What You Mean" or "WYSIWYM." It’s a powerful idea that greatly simplifies the mechanics of writing documents. This is also why LyX isn’t so good for creating posters and flyers—in this case, you do want to specify exactly where everything goes, because there are no functional units like paragraphs, sections, etc.

(To be fair, most word processors do in fact have a similar "style" feature to help you concentrate more on the content and impose a uniform look on your documents, but almost nobody uses it, probably because the nature of the word processor discourages its use.)

In spite of the fact that LyX is an application and not a markup syntax, you could easily replace the word "LyX" in several parts of this passage with "lightweight markup" and gain a firmer understanding of the benefits of the approach I’m describing. This passage is also interesting for indicating the circumstances under which this approach is not appropriate (e.g., posters and flyers).

Finally, in a recent thread on David Heinemeier Hansson’s site titled "Why do people still use word processors?", Hansson responds to a challenge to his rhetorical question and makes us aware of the false dichotomy between "technical" and "nontechnical" users vis-a-vis the difficulty of using a lightweight markup like Textile:

Reader: "People" are generally not IT professionals. It’s hard enough for some to even understand the concept of a table. It’s very hard for quite a few to understand the simple concepts of HTML. LaTeX is harder still to learn and use. … Textile is a good start and leverages some users, but probably not my mother, anyone else in her generation, or a significant part of the entire private sector.

Hansson: I was puzzled that students attending HA.dat (computer science and business administration) would suffer to Word when there were plenty of alternatives that didn’t require a bachelor’s degree in CS. … Your mother is excused, they were not.

I.e., there’s no reason why lightweight markup shouldn’t be appealing at least to computer literate users, even if non-computer literate can’t reasonably be expected to live without the word processor’s conceptual link back to the pre-digital world of typewriters.

In a lengthy post earlier this month, I took a first stab at describing a word processor-less approach to document composition and formatting. A key component of that approach is the use of what has variously been referred to as "humane text," WYSIWYM (What You See Is What You Mean), and "lightweight markup"–formatting syntax that allows you to compose a document–in a completely human-readable manner, without angle brackets–in plain text in any text editor, browser text field, or device, and run it through a parser to turn it into a format more suitable for your audience, such as HTML or PDF.

Searching the Web for those who have gone before me–particularly on the matter of convincing the technologically disinclined of the benefits of weaning themselves off of their dependency on Microsoft Word (or any other word processor or even browser-based WYSIWYG editor for that matter)–I began to discern the emergence of an eerie pattern: Interest in lightweight markup seems to correspond with the rise of the so-called Web 2.0 technologies.

First, I (re)discovered the existence of other lightweight markup languages besides the one I’m used to working with, reStructuredText; the principal ones are Markdown and Textile. (I should note here that various Wiki software packages have long provided their own markup formats.) Later, I learned that Textile (or some variation of it) is used as the default formatting syntax for 37signals‘ excellent personal information management tool, Backpack. 37signals had previously created the application that made Ruby on Rails famous, and in fact employ the creator of this Web framework, David Heinemeier Hansson. Ruby on Rails’ exploitation of the Ajax technologies in large measure has marked it as a kind of technological standard bearer of Web 2.0, as suggested by the first product offering from Adaptive Path (a key promoter of the Web 2.0 idea), Measure Map, also created on Ruby on Rails.

As if that weren’t enough, the other major lightweight syntax project, Markdown, was created by Mac-oriented blogger John Gruber, who is employed by Joyent, a company whose work appears heavily to leverage Ruby on Rails and Ajax, and which had previously acquired TextDrive, the company whose founder is responsible for Textile. The circle seems complete.

So where does lightweight markup fit into Web 2.0 conceptually speaking? It might be worth explaining what I mean by Web 2.0, since there seems to be no commonly accepted definition of this relatively new industry buzzword. One intriguing definition I came across (I forget where): "Web applications that don’t suck." For those inclined to a more formal explanation, I recommend Tim O’Reilly’s (his company coined the phrase) treatment of it, as well as Paul Graham’s reflections (though in light of the present topic, I can’t help but think that his suggestion to create a Web-based version of Microsoft Office is misguided).

Aside from noting that it was made possible in part by the mainstreaming of broadband Internet access (Ajax-laden applications tend to take a long time to load otherwise), maybe the best way to gain an understanding is to list a few of the more prominent examples:

• Google Maps, but especially the so-called "mashups" like chicagocrime.org and housingmaps.com, which use the Google Maps open API map data from a third source onto Google Maps’ super-responsive, desktop app-like interface, which popularized Ajax overnight
• del.icio.us, the "social bookmarks" manager, which aggregates the "tags" that users apply to their favorite sites and makes the results of that tagging available to all other users, allowing them to take advantage of the network effects that redound as a result of mass use of the site.
• Wikipedia, the collaborative encyclopedia, which until recently was open to editing by all Internet users, even without requiring registration of a username. As Graham notes, "experts have given Wikipedia middling reviews, but they miss the critical point: it’s good enough."

One of the common threads of these applications is their embrace of openness. In many cases this means using Open Source software and participating in Open Source projects, in recognition of the effectiveness of that approach in creating quality software in a short period of time. But perhaps more importantly it means open standards, including Web standards like XHTML and CSS, as well various XML dialects for sharing data between applications via Web services.

It is probably this fundamental quality of openness which has motivated the interest in lightweight markup among the Web 2.0 cognoscenti. Plain text is among the most platform-neutral technologies imaginable, requiring no special software to use, no special browser plugins, very minimal hardware requirements. It’s agile; when used with appropriate parsers, input can be repurposed for any number of uses, "decoupling" it, so to speak, from dependency on any particular application, just as Web 2.0 technologies tend to do with their functionality.