The Tools

I suggest that all the average user really needs is a text editor (which saves documents in plain text rather than some proprietary and/or arcane format) that can fulfill the following functions¹ :

• Copy/cut/paste
• Undo
• Find and replace
• Spell check

These functions are handled by the lightweight text editor I’m using to compose this document, gedit for the GNOME Desktop for Linux.

Some ancillary functions, such as image processing, thesaurus, etc. can and should be fulfilled by separate programs that specialize in these features and therefore can do a much better job of them.

But what about font sizes and styles, page numbering, footnotes, indentation, text alignment, etc., etc.–features that do in fact comprise the 10% of features that almost all users need?

Here it’s necessary to draw a crucial distinction between what has become widely known as WYSIWYG (What You See Is What You Get) document composition and what has subsequently been described as WYSIWYM (What You See Is What You Mean), a semantic approach that recommends the document author concentrate on the content of the document without considering the presentation of that content. When composition is complete, the presentation of that document can be outsourced to another program. In my current way of thinking, that other program is LaTeX, a document typesetting system that was originally developed for authors of mathematics- and science-related documents, but which can be useful for any type of document.

What I’m doing here is separating the process of composition from the typesetting of the document, the latter of which I believe becomes a distraction in the composition process. What if in your super-simple text editor, you could easily indicate, say, using a system of easy-to-understand symbols, or "markup" in the relevant parlance, to indicate where your footnotes are, where your emphasized text is, etc. There exist several such systems, but the one that I believe is the most appropriate for the average user is reStructuredText (reST), about which I’ve briefly written in the pages of this site. As for the matter of page numbering, line spacing, etc. in the final document, that would be left to the typesetting system (LaTeX, mentioned above), which would permit you to choose a professionally developed document style which performs those functions according to a standard appropriate to your field of work. The Docutils project (originally project developed to facilitate documentation of the Python programming language) provides reST conversion to LaTeX, which in turn provides conversion utilities to more common document formats like PDF. You could choose to install this system on your own computer, or if a service which provides this functionality were available via a Web site (which I currently plan to develop), you could simply submit your text document for processing via your Web browser and receive a PDF or HTML document in return.

Your source document–the document to which you would make subsequent revisions–would continue to be the fully legible plain text document which uses the reST markup, and which can thus be continue to be edited in virtually any program capable of dealing with plain text.

Other Motivations

Rather than going into further technical detail at this point, I’d like to point out some deeper motivations for wishing to see the word processor consigned to the dustbin of history (or at least for wanting to see it forced to occupy a marginal space more proportional with those 10% of users who need its advanced functionality). The information technology revolution, and in particular ubiquitous Internet access, has resulted in a capacity for distraction that undermines the productivity gains promised by IT as well as the utility of the broad information access it provides. The classic dilemma of how to efficiently turn information into knowledge has never been so acute.

Paul Ford, a Harper’s editor, Web developer, and NPR commentator, has published an extremely insightful article which explores these themes. In it he refers to the measures he has taken to deal with this problem as "Amish computing":

… I can honestly say that since broadband Internet came to my home a year and a half ago my stock of new, fresh, fun ideas has grown very thin. It’s just too much. My mind can’t wander, because, with anything that interests me, I can look it up on Wikipedia to gain some context. Before I know it I’ve got thirty tabs open at once in Firefox. Then new email comes in. … I’ve started using an Alphasmart Neo to draft text, and WordPerfect for DOS to edit and revise. My average daily word count has doubled as a result, and my stock of fresh ideas seems to be replenishing.

Ford subsequently extended these thoughts to a general audience in a recent NPR commentary, suggesting the ubiquitousness of the problem.

What’s interesting about Ford’s analysis for our purposes here is not so much the distraction potential inherent in the Internet, but in the computer–the knowledge worker’s tool–itself. Ford’s solution involves composing text on a device away from his computer, and reverting to a very early version of a popular word processor program which not only has a reduced feature set, but which by virtue of being a DOS program restricts the opportunity for distraction by other items on his desktop (i.e., there is no "desktop" in DOS). Only incidentally does that desktop include a Web browser. Once a painless way of typesetting a document in accordance with what I’ve described above is made available, my suggestion to Ford will be that he do away with WordPerfect entirely and compose his documents in reST directly on his Alphasmart Neo.

Advantages

Leaving aside my own preference for parsimony regarding computer hardware resources, I’d like to summarize some of the chief advantages to the approach discussed above:

• Documents are legible by any text editor and thus fundamentally independent of any single program
• The WYSIWYM (What You See Is What You Mean) approach helps the user cut through the distractions inherent in the use of information technology tools and resources.

Challenges

A few potential challenges to the perspective outlined in this document might include:

• To what extent am I artifically assuming a scarcity of hardware resources in criticizing bloatware? I.e., in 10 years time, might not every consumer electronic device have enough muscle to run even the most bloated word processor program?
• Collaboration: If your document composition process includes a lot of collaboration, how practical is it to convince your collaborators of the legitimacy of this argument, wean them off their dependency on Microsoft Word, and to get them to learn reST, which while basically simple, does have some quirks which will no doubt annoy many users?
• Am I drawing an artificial distinction between word processors and text editors? Is a text editor not just a lightweight word processor?