Wysiwyg

The introduction of Wysiwyg editors is a useful historical metaphor to what can be done to deal with complexity when expression and manipulation of non-trivial data is required. Before Wysiwyg editors became popular, document editors were called text-editors, since they represented only the text contents of documents. As an intermediate stage of development, special character combinations (or “control codes”) were used to encode and represent what the formatting should be, for example ^i might turn on italics, and so on. This style of encoding is still in use in HTML and its successors where <i>italic</i> are the control codes to italicize. Today, a user of a word-processor does not have to make a distinction between the italic character i and its representation. A word processor allows a user to express their intention to italicize certain text elements.

A more telling example is justification, for example right margins. Pre-wysiwyg, when a user invoked the Justify command, the word processor went through the document and added extra spaces to create the justification. When the user added or removed some text, the spaces often ended up in the wrong place and it was a manual process to remove them all and again justify the text. Running the justify command was a big decision you rarely invoked until you were pretty convinced it was the final version of the text you were justifying. Of course, computer supported justification was still much better compared to what was before, namely manual typesetting, where justification was even more manual.

Today, we express the intentions of italicizing and to keep a text justified in a word processor, not by special control codes or running a command, but the editor keeps and maintains it justified on the screen for editing and also for printing by an internal representation. This is an example where intentional information is not only more compact and effective, but also improves tremendously the usefulness during editing and maintenance.

The word processing software effectively separates the look and feel of the document (“What you see”) from the underlying representation which is used during editing and printing (“what you get”). It thereby makes it possible for the user to create and edit much more complex and effective documents without mastering the control codes or commands.

We see that in Wysiwyg editors the user express intentions which are projected as the text is imaged either on the screen or on the printer. Intentional Software applies a similar Wysiwyg technique to the creation and maintenance of software by separating the representation from the looks and the editing interface. In the realm of software creation we can observe a similar trend where we used to encode only the most critical information – namely the executable algorithm – but we more and more find it useful to encode information about the problem and the process itself – the intentional information, for example as meta data in XML configuration files.

But there is an even closer connection between the use of Wysiwyg and the use of Intentional Software when we investigate the process of software creation.

What was the core Wysiwig idea? Superficially it was the emulation and improvement over the typewriter. But this is clearly not the whole story – for example on a typewriter words do not automatically flow from one line to the next. How did people make words flow on a typewriter after a document had been changed – whether it was a contract, a movie script, or a doctoral thesis? Why, they gave it to a typist who retyped the text. I remember the time when the first thing a graduate student preparing to write a thesis would do was to hire a typist. You may not remember, but before Wysiwyg there were many professional typists. They were employed not so much because people could not type- that was just part of it, but because people could not re-type. They not only originated documents from notes or dictation, but they spent most of their time re-typing already typed drafts which were marked up with corrections or changes.

This was terribly error prone, because when a page was re-typed to fix a sentence or a number, errors could be introduced in other places. So when someone wanted to make a few changes in a contract, there was a lot of discussion in how to make sure that the rest was still OK, in effect the proofreading had to start from scratch. We tend to forget how tricky it was at that time to decide whether an important contract should be retyped after a small change: because the process of retyping could easily cause some mistakes in an unrelated part. If the contract was retyped for a clean copy, the whole page or more would have to be re-checked by all parties. This was completely eliminated by Wysiwyg. We still need to originate documents, but we never have to retype them and suffer the risk of those errors. Of course this is exactly how software creation is working today. When a small change is contemplated, its possible effects on the whole system have to be taken into account.

So in effect, the Wysiwig word flow feature was the emulation of the typist, not an emulation of the typewriter. In other words, Wysiwyg was not just an improvement on the typewriter, Wysiwyg was an improvement on the document creation process. 

There is a very strong parallel with Intentional Software. The parallel to the author of the contract, the script, or the thesis, in other words to the content creator is the domain expert. The parallel to the typist is the programmer (or more, accurately one of the roles of the programmer). Once the first implementation exists, the programmers’ job becomes very much like the typists’ job used to be: to do the repetitive work of accommodating the changes, small and large, and to propagate the consequences of the changes in the software code, in effect doing the word flow.

Programmers are terrible at this. Remember how the frequent retyping before Wysiwyg caused many mistakes. But today software is still created this way. When a change is introduced, other bugs creep in. Many seemingly unrelated parts of the software has to be re-checked. Interaction between different parts of the software is becoming increasingly hard to understand and deal with as the complexity and size of our software grows.

The analogy suggests more parallels. Corresponding to the typewriter we now have conventional programming technologies, tools, processes and platforms. Note how incremental improvements to the typewriter, such as the “correcting white-out tape” did not help with the underlying problem of constant retyping. Similarly, the incremental improvements to the programming techniques will not help with the need for re-doing the “change propagation analysis” or “coding pattern expression” every time a change is made to the code. We also see that a job role, such as typist or programmer, includes many different activities some requiring considerable skills, while others can be readily automated. It is pointless to try to “automate” a programmer, but it can be very valuable to organize the programmers’ job so that some of these simple repetitive activities are done by the machine, freeing up the programmer to do more of the knowledge-intensive tasks. That is what generative programming can do, by recording, in effect, the process by which the resulting software can be related to the domain experts’ intentions, so that this process can be mechanically re-played, just as the retyping and reformatting of the documents of yesteryear is now done automatically by the Wysiwyg editors.

Wysiwyg transformed the document creation process by giving content creators direct control of the process. Similarly, Intentional Software intends to transform the software creation process by giving the business domain experts – the content creators – direct control of the process. Wysiwyg empowered millions of more users to author great looking documents – it is time to do the same for software users.