WYSIWYG Or Not To WYSIWYG
|This piece was originally published in the National Capital Atari Users Group (NCAUG) monthly newsletter. Light editing and URLs added 2002/01/06.|
As owners of computers possessing graphical interfaces we can easily slip into a “WYSIWYG or bust” mentality. However, the reality of the situation is somewhat different: Character applications are often just as functional as their graphic counterparts.
Thinking along graphic/character lines, we can divide applications (programs) into three classes: applications that are suited to Character Interfaces; those suited to Graphical interfaces; and Mixed applications. Our computing roots are based in character interfaces, so some traditional character based applications jump quickly to mind: Terminal Emulators, Command Line Interfaces (i.e., shells) and Editors are three such programs.
On the Atari ST, Terminal Emulators are for the most part still in the domain of Character Interfaces. An example of this is the VT52 emulator that comes with the ST. However some programs, like STalker, are beginning to move into Graphical interaction with the User through the use of resizable windows and mice. It is important to remember, however, that because these Terminal Emulators are attempting to emulate a character device (i.e., a terminal), they will never be totally graphically driven.
It is worth briefly noting that X-Windows terminals (i.e., graphical terminals) are beginning to appear; and at the Summer’89 USENIX conference Sun Microsystems demonstrated an X-Windows terminal emulator running on a 1040ST.
Command Line Interfaces (CLI), or shells as they’re sometimes called, are unfamiliar to many ST Users. That is because instead of a CLI, we have GEM—a graphical shell. This is a prime candidate for a Mixed Application, because while the graphical interface of windows, grow-boxes, and mice is very nice for new computer users, an experienced computer user is sometimes held in check by the graphical interface. For example, when you’re attempting to perform an operation on a selection of files, a character interface is sometimes more easily able to allow the action.
The Gulam command “rm c1*.bak” will delete all the files that begin with “c1” and end in “.bak”. Try that from GEM!
It appears to me that the application which has move most quickly to a graphical interface is the editor; and thence the Word Processor. Maybe it’s because we intuitively would like to add illustrations to our documents. “A picture is worth a thousand words,” as it were. Paradoxically, however, this application is one of the most resistant to reasoned decision-making. By that I mean, while CLIs, Terminal Emulators and Spreadsheets are chosen with their application (use) in mind, editors and text processors have become a band-wagon: “DeskTop Publishing” (DTP).
DeskTop Publishing’s popularity is exactly what has spawned this article. Let’s take a look at both graphical and character based DTP Applications. As we will see, they both have weaknesses as well as strengths.
Putting plain-jane editors and word processors aside (WordWriter, 1st Word Plus, MicroEmacs, etc.) when we think of DTP on the Atari ST we probably think of Timeworks DTP, Calamus, PageStream, and others. However these programs are all graphically driven. Generally speaking, taking their features as a group, these programs exhibit the following characteristics:
While the above features list may look like nothing but good news, it is more appropriate to regard them as “limits” or “guides” rather than simply “good features”. Guides are wonderful if you want to go where they’re leading; otherwise they are a hindrance.
WYSIWYG works wonderfully when you have a relatively high power computer with lots of memory and a high resolution display. The more detail with which you display an image, the more processing time/power it takes. This means that text composition needs to take place outside of your DTP package so that you don’t spend too much time waiting for the computer to play catch-up as you type. Unfortunately this is generally a one-way door: Once you have imported the text you cannot export it for editing without throwing away your formatting.
Related to this is the placement of images within your text. Images are not usually included in a document just because they look nice. Pictures generally relate the the text somehow. But, DTP packages don’t normally place images relative to your text. Instead they place an image somewhere on a specific page. Now what happens if you insert three and a half pages of text before the picture? Well, because the picture was tied to a physical location, you must now manually move the picture.
Also, because frames are placed physically on a page, if we have made odd and even pages a little different (for a book) then when we insert a single page everything may be thrown off; forcing us to move the frames around by hand. This causes problems for footnotes too. If a certain page has footnotes then we must make a frame just for the footnotes. It has to be sized by hand, and like our picture example it may have to be moved if text is inserted or deleted.
Avid users of WYSIWYG applications are probably livid by now, because I have only drawn out the negative aspects of WYSIWYG applications. However, my goal is not to state the case for WYSIWYG desktop publishing.
Although the names of WYSIWYG DTP packages sprang to mind, you will probably be hard pressed to think of even one character based package. I only know of one character based DTP package for the Atari ST; though I’m sure others exist. That package is TeX (pronounced tek). On other computers there are many similar packages, and so the following list of features includes general concepts (as the WYSIWYG list did):
The aforementioned “livid WYSIWYG users” may be saying “So What!! The features lists are pretty much the same!” The two lists are very similar, but two fundamental differences exist. Stated from character DTP’s point of view, these two differences are:
Let us continue the comparison from the character point of view. Because the text is always in ASCII form, its entry can be done on ANY computer and editor that produces ASCII files. For example, several team members can do document preparation be they on the office mini-computer or their personal micro; and work can be easily taken home and edited on a much less powerful home computer, because ASCII editing doesn’t require much memory or computer horsepower. Another benefit of ASCII source is that database software can generate reports with formatting commands embedded—allowing the report to be sucked directly into the DTP package without any other overhead time.
Relative placement of text has other advantages. It means that the even/odd page insert problem (described above) no longer exists. Frame drawing and placement is done by the DTP program, not by you. The program draws its own frames and positions them at format time, not at entry time; so if a full page has been inserted, all of the following pages are simply bumped along—including any special touches you’ve added.
Because pictures and footnotes are attached to a specific piece of text you are always guaranteed to have the picture/footnote close to its description—without having to place it manually.
At last, the unfair comparison is over. We’ve seen the down-side of WYSIWYG DTP software and the up-side of character based DTP software. Both types of applications have their strengths and ideal uses, and I hope I have helped you see where character based DTP fits in.
I should note here that a few WYSIWYG DTP programs have attempted to reach a compromise between the character and graphical advantages. The most notable of these is Ventura, which runs under MS-DOS. Ventura keeps its files in ASCII form; embedding its formatting commands much like one would do in a character base product. While you work within Ventura you have all the advantages of WYSIWYG. But, you may edit Ventura’s files with any text editor, and gain many of the advantages of character based DTP.
On the Atari ST, Timeworks DTP attempts to provide Ventura’s interface and features. While not as powerful as Ventura it does go a long way to overcoming some of the objections I raised. I wish its developers would add Index and Table of Contents generation.
In the office where I work as a Programmer/Analyst, we have settled upon a character based DTP package for doing our system documentation. We have both micros and minis in the office, and it is important that we be able to edit files on any of the machines. We also use standard formats for our documents, and it is easy to both set up and use the program’s macro files. For those interested, we use HighStyle, from Lattice Corp., on an HP Vectra driving an HP LaserJet II with softfonts. At home I use Calamus on a 1040ST driving an Epson LX-80 printer.