(Or: Do you want to process words? Don't you really want to process a document? )
I am not really thrilled with the term word processor, as it is not particularly descriptive of the sorts of things people actually want to do. Unlike the "good old days" when WordStar and Wang Word Processors were "king," these days, people don't process "words;" they want to build tables (that are not words), insert pictures (that are not words), include spreadsheets or graphs (that are not words). Even "back in the good 'ol days," people weren't really working with "words;" that is a task for a dictionary, thesaurus, or some other such "word" manipulation tool. It was always "documents" that people wanted.
Unfortunately, too often these days, people have so little grasp of the language that they are using that they cannot even spell the words or string them together in correct order.
The term that I favor over "word processing" is document processing, as it more correctly describes the thing that people are actually working with.
Some common varieties of documents include:
Letters
Reports
Memos
Theses
Faxes
Documents might contain nested instances of other documents (e.g. a fax may be composed of a cover page that is attached to a letter and some other documents). One could develop a whole taxonomy to represent specializations of reports, where the following examples merely scratch the surface of the richness of representation that is possible:
Corporate Reports
Financial Reports
Monthly Financial Statements (released to management)
Quarterly Financial Statements (released to shareholders)
Annual Financial Statements (that include a full-scale annual report of corporate operations)
Budget details
Budget summary
Federal tax returns
State tax returns
Sales Reports
Graphic reports
Numeric reports
By Region
By Product Group
By Customer class
Manufacturing Reports
Defect rates
Consultants' recommendations
ISO 9000 certification reports
Labour productivity
Memos
Company-wide announcements, complete with "secrecy classifications" and legal disclaimers
Corporate News
News about industry activities
Agenda for departmental staff meeting
Weekly/monthly status report
Internal job postings
Product Sales
Product overview
White papers
Product specifications
Sales pamphlets
Personal Letters
Letters to family/friends
Christmas cards
Thank-you notes
Letters to insurance company
Letters to IRS
Legal letters
Court summons
Expropriation
Filing for divorce
Land deed
Request to serve as juror
Keeping purpose to this, these are all sorts of documents with which one might reasonably attach some sort of common structure, perhaps creating a "template" containing some combination of formatted text and graphics to allow individual documents to be written more quickly.
People tend to use word processors to "manage" many of these sorts of documents, generally making up uninsightful names on file systems that ultimately make finding old documents a big headache.
They would be far better off having some more formal document management system, as well as some sort of "template" to simplify the process of creating each sort of document.
Unfortunately, adding "structural" intelligence has the tendancy to make document processing systems somewhat more complex to use. Ensuring that users can handle the sophistication is not a trivial task. There is value to having the user interface discourage them from doing "wrong things;" if the interface does not also encourage them to do "right things," then users will get frustrated, leading to rejection of the tool. Thot and Amaya are good cases in point; while they may ensure that documents are nicely structured, but I always found that I was fighting against their structuring approach.
Equally importantly, "half-powerful" tools are all too common. The "GUIed" HTML editors that I have used generally do not handle HTML comments very well, either omitting them or otherwise changing their formatting. I use HTML comments as indicators for HTML reprocessing, and thus if those comments are "mangled" or omitted, my web pages are mangled as a direct result. Lyx, a LaTeX generator, is "afflicted" in the much same fashion. It uses a subset of LaTeX functionality; if you modify a Lyx file beyond that subset, Lyx can no longer be used to edit the file without "mangling" the results. Proposals to build improved configuration systems to assist with Linux system administration frequently suffer from much the same problem; if your X11 configuration makes use of tools like the M4 macro language, then it may prove impossible to construct standardized tools to manage the configuration.
OpenDoc provides still another view of this; it builds up documents using "object components." While mighty cool, this kind of architecture failed. I'd speculate this is because the intricate interfacing between different object types led to explosive complication in the software necessary to support it, which made it unmaintainable in the longer term.
In stark contrast, users like Microsoft Word, because it lets them do virtually anything anywhere at any time in the document. It may be unfortunate that it encourages them to use physical markup rather than structural markup, but they are nonetheless rarely frustrated. (At least, not until the writer gets the document nearly complete, and a "graphics" person finds it impossible make the sweeping revisions required to make it look attractive in the time needed.) The designers at Microsoft may produce some supremely awful products, but they are not dummies at producing things that provide "user satisfaction" by making it easy to make the computer do something that appears to be useful when the user clicks on things.
There is a huge number of projects listed to develop a "libre" word processor that runs under Linux. Unfortunately, most of these projects appear to be moribund, and none of them are really "complete." The Linux Word Processor Project seems a lot like The Great American Novel, something that lots of people get started, but are never able to complete. Everyone seems to get about half-done and then gives up on further development.
I would argue that this all points to the notion that constructing a really good WYSIWYG word processor may in fact be the most difficult programming task known to man. There is little doubt but that creating a spreadsheet package is enormously simpler; the use of a grid of fixed-width cells fundamentally simplifies the task as it tightly constrains the flow of data across the medium.
The problem with constructing a WYSIWYG document processing system is that it simultaneously combines many sorts of complexity all at once.
Arrangement of letters into words, with associated kerning policies, all of which is dependent on the fonts characteristics that include:
Family (Times Roman, Helvetica, Palatino, Sabon, Centaur...)
Size (10 pt, 12 pt, ...)
Weight (light, medium, demibold, ...)
Other characteristics such as slant, italics, ...
Arrangement of words into lines of text, hopefully with some attempt being made to maintain consistent interword spacing, interline spacing, and maybe even consistent weighting of text on the page.
Then comes "paragraph structuring," where indentation both left and right, spacing, font selection, and line justification all vary based on the "paragraph type."
Different parts of a document will need different page formats:
Margins will vary in double-sided documents depending on whether the page falls on the left or on the right;
A title page may be formatted very differently from the text;
Indices may have further formatting policies;
The flow of text in conjunction with double column text complicates things further.
The various sets of "rules" build up an overall set of "document specifications" that represent a complex dynamic program. (See Dynamic Programming.)
The TeX system was designed to handle these sorts of systems with extreme precision, and does so quite well. Unfortunately for those that would like to see "visually dynamic" representations (such as WYSIWYG), the TeX system provides an relatively "static" representation. It really is "batch"-oriented.
TeX and LaTeX are designed to allow structural markup, which is not nicely compatible with the "physical" markup that WYSIWYG encourages, which begins to touch on the real complexity problem:
Users of WYSIWYG want to be able to drag "controls" around to change parameters dynamically.
They want the controls to modify the policies;
sometimes just locally ("I want an extra inch of empty space right here; don't touch the rest of the document."),
or for a region ("Use italics for this word"),
or, sometimes, to shape the policy for the whole document.
These remappings affect the presentation of text at varying "logical levels." Moreover, better word processors do provide some degree of structural markup (not unlike what LaTeX offers), which nicely multiplies the complexity.
By providing this sort of interface, it becomes necessary to simplify the way things are presented so that the results can be interactively recomputed "in a flash." Quality is lost at this point. Moreover, users are often not sure at a point in time what kind of change they really intend to make.
Should shifting the margins for the current paragraph affect other paragraphs? The answer depends on context:
If the user is tuning the overall document style, then the answer is absolutely "yes."
If the user is fine-tuning the final presentation, the answer is partially (but not absolutely) "no."
On the one hand, the change does not directly imply any changes to "display policy" throughout the document.
On the other hand, it probably will have some impact on the formatting of following paragraphs due to the movement of text. If, for instance, the paragraph changes in length by 1 cm, then it makes sense to shift the rest of the document upwards or downwards based on the impact of that change composed together with "document policy." Which may or may not change the appearance of the remainder of the document significantly.
The big question is, of course, which "document policy" is to be kept and which is to be ignored when making changes.
The first result of this ambiguity is that the user interface for this is highly complex to code. The programmer's job is made difficult. Which is unfortunate, but arguably not a critical problem. It is the programmer's "job" to provide a good program; the needs of the many (users) arguably outweighs the needs of the few (programmers).
The second, more problematic, result of the ambiguity is that it is difficult for the user to predict how the overall formatting of the document will be affected by any given modification.
Thirdly, typesetting that produces attractive documents uses a large variety of "rules" that together represent a complex set of tradeoffs with which the user may not be familiar. A user knowledgeable about typesetting may break the rules with intent to attain a particular result. More often, users don't know what they're doing, and would get better results if the computer enforced the rules on them.
| Prev | Home | Next |
| Running "Foreign" Word Processors on Linux via Emulation | Up | An Alternative Approach: Text Editor/Presentation Language |