There Are Two Jobs That Need Doing Well Here And Most Applications Suck At Doing Either Of Them Simultaneously
I'm going to agree heartily with Matt Dorn and say that most word processing applications are intended to do far too much. The kicker here is that they are set up to do all of these tasks with surprisingly small yields in terms of work to product ratio. The actual composition of text is secondary in the functionality of word processors to the howling wasteland of features that are piled atop the already overloaded heap in hopes of making a desktop environment. What aids and abets this abuse is that most people are familiar with a single WP interface (pretty safe to assume that the default here is the Cthuluoid horror known in certain circles as MSOffice where only a few scant tentacles exposed to the surface world are visible to hint at the misshapen continent of fangs and other pointy appendages that hides behind that idiotic paperclip) and don't separate the idea of editing text from the idea of formatting text with footnotes, clip art, and other gewgaws. If you come from the elder school of computer use the idea of this separation might not seem so alien. Have you ever written a letter in Quark? It is not pretty and makes the task less about finishing this thing that you eventually need to finish and more about navigating an endless stream of options and menus.
OpenOffice is the shining example of why simply cloning interface is such a shitty idea. It is, more than anything else, a marvel of engineering as evidenced by its amazingly fast evolution and feature to feature compatibility to MSOffice. That said, do we really need a second Galactus in the computer universe sucking down entire planets worth of energy just to sustain itself? I'm guessing not but then again I am just a user who wants his application to work sanely. This means I would like not to feel like I need a independent instance of a computer to dedicate to writing some text. If I were a usability expert then I'm sure I could be adequately distracted by the order of buttons in some print dialog to even notice this catastrophic abuse of resources.
Another distressing part of this text producing monoculture (at least in the corporate/business world) is that this arbitrary inflation of resources moves outward from whatever is produced under its aegis like pollution from an oil spill. Why wouldn't you want to use Word as your default editor in Outlook (that is another rant entirely and by that I mean the idea of Outlook) when the editing interface is so damned familiar? If you need to read some mail through a text based mail client which I do daily as part of my job you'll rapidly understand how atrocious scads of markup and other line trash that is displayed in its plain text incarnation when not paired with Mount St. Office to translate for you. This sounds like the rant of a crank and to a certain degree it is but the one really, really important distinction that needs to be made is that most text reading software for the visually impaired depends on things intended for transmission in plain text to actually read like plain text. In that case, you're spending time and energy to do excessive formatting by default that will make the end product completely useless to the intended recipient.
I can't imagine that users would ever tolerate a return to the plain text editor. I'm not going to advocate the wider use of Emacs by non-programmers or anything as I think that is also a move in the direction of burying users under a pile of features they will never use or even know about. What I would love to see and this is of course would depend on something like being appointed Bad Application Czar by the federal government is the separation of the steps of composition into more discreet portions on the application side.
Why not have an edit portion of an application suite that works like AbiWord only with a feature set reduced to what might be necessary to compose plain old text or another relatively complete yet decidedly non-monolithic text editing (yes, definitions are being stretched here but bear with me for a few hundred more words or so) application or an even more stripped down version of that very basic functionality that when signaled invokes the formatting portion of the application (hopefully a separate and also smaller application) that handles layout and formatting. The implementation that I have in mind is one that also saves the file (text, then formatting, and then the final product) in discreet steps that save individual files instead of dedicating more square feet of memory to caching for an anticipated undo.
I like the idea of applications being strapped together so they're launched in an order that makes sense for doing things with text but pairing them so that each function becomes the domain of a piece of software that happens to do that particular task very well and doesn't require the loading of a small solar system into memory simply to edit a document. Does this make the task more complex? Maybe but it also makes the individual yet important steps of creating documents distinct from one another and doesn't encourage the user to attempt all of these steps simultaneously.
Another point that interests me is what distinguishes a text editor from a word processor. Matt calls attention to this ambiguous distinction in his post in the Challenges section. My mind returned to this question a couple of times during the day when I wasn't immediately occupied with other things. I think I try to use word processors more like text editors. I don't format as I'm typing. This isn't a decision that I made consciously but it developed as a reaction to the addition of many features of MSWORD that are enabled in the default setup. Have you ever really fucked up the formatting in a Word document? I've done it so badly and apparently irreversibly that I ended up saving a copy of the document as text and then opening a copy to work on. The more times that I painted myself into a corner the more often I thought about leaving the text as just text until I was ready to print the sucker out. I think that is what really distinguishes the two concepts for me: word processors are used to create documents intended for consumption as documents by other people and text editors in which features like syntax highlighting, indentation, and parentheses/bracket matching are more prevalent and important are intended more for the production of things that are basically finished once they are composed like programming. Programming is close to a penultimate when it comes to requiring focus on the actual composition of a file.
That aforementioned intended presentation of work done with a word processor is what really makes me feel like my own predilection for simplified flow of tasks and less specific file formats are more important than I initially thought. The weighing of the classic KDE versus Gnome desktop environments in terms of uber configurability against the reductionist view of the desktop as something that must be configured one way and whittled down by removing many common options seems pretty insignificant in comparison to the concerns you should have when sharing documents with other people. This becomes especially important when those documents are produced by software designed to output things for printing and duplication and are often viewed as files on machines configured differently than those of the creator. The model isn't obsolete but it seems pretty broken in a world where MSFT didn't squash every other operating system and piece of software out of existence. Users are eventually going to become more attuned to this more sophisticated digital divide if only by being annoyed to death by various platform adherents, the requirements of government organizations trying to rid themselves of an incompatible document format, or the simple fact that more mail servers are stripped potentially dangerous attachments. Text works for everyone and requires a lot less of its users on both sides of the equation.