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.

Comments

[Steve Marx]

Charles, I'm having trouble following your connection between WYSIWYG and retyping. The problem was that it was impossible to change a part of the contract while guaranteeing that the rest of the contract remained unchanged. That problem is solved by using a text editor, WYSIWYG or not.

I agree that the iterative software process suffers from a similar problem: changing one piece of a large system usually doesn't guarantee that the rest of the system is unchanged. To fix that problem, we'll need a way to quantify the dependencies (and perhaps reduce them when they're prohibitively numerous). Then, as with the contracts, we could change one clause and be guaranteed that the other clauses remain the same.

Is that what you're suggesting? You don't make it clear how you intend to address that problem.

[Charles Simonyi]

Dear Steve,

You are right in that "normal" word processing also has the retyping advantage I attributed to WYSIWYG. I've just bought through abe.com an antique copy of the Algol 60 report that was produced in 1960 on a Flexowriter without retyping. The report was stored on 8-level paper tape which was played through the teletype-like machine and a new tape could be punched with corrections - a very early example of what you are talking about. But I think you will agree, that before WYSIWYG this was not a realistic possiblilty for most people; in other words WYSIWYG made the largely theoretical advantage accessible to large number of people.

The quantification of dependencies that you mention is embodied in the generator. Some say that this may be hard to do. But programmers, for better or worse themselves already express the dependencies in their daily work, and the generator is just a more explicit, more permanent, and re-executable manisfestation of what already exists. The generator is described in other posts in this blog.

The advantage of generation is available today in many special instances: there are many Domain Specific Languages (DSLs) and many generators, just like there were many word processing systems before WYSIWYG: from Daconics, from Wang, from IBM and Xerox of course. But we need some overarching unification to make the benefits practical for more people and that is being argued here.

[Steve Marx]

Thanks for your reply, Charles.

I agree with your points. I think WYSIWYG wasn't what enabled "safe" edits to be made, but it is what enabled a large number of people to be capable of making those edits.

Perhaps we also have the same two issues with programming. It's possible to make "safe" (== independent) changes to software now with effort, but it will take further language work to enable the masses (domain experts) to have that power themselves.

I'm still quite hazy about what exactly you guys are building, and I'm quite curious, since I share your interest in solving these problems. I'm eagerly awaiting more public information. :-)

[Dave]

Any chance of getting video or audio of the OOPSLA presentation?

[Magnus Christerson]

Dave,
I am not aware of any audio/video, but you can get the paper and presentation from our website.

[alpabarot]

Hi Charles,

You have a very cool blog here…loved the content.
U know there is an awesome opportunity for people like you who have ur own blogs n sites…I came across this site called Myndnet.com…it’s a platform for people to buy and sell IT related information. and everytime you sell some information you get paid for it…Good money for people like us in the IT domain. Here the link http://www.myndnet.com/login.jsp?referral=alpa83&channel=al363

Sign up is free…check it out…
You can contact me at my id here for more questions : barot.alpa@gmail.com

Cheers
Alpa

[JTD]

I have a problem with MS Word. In some documents (not all), if I am editing it, and I want to center-justify one line, and regardless of whether I put the cursor in the line or highlight the whole line, it ends up center-justifying the entire document (bad!), and I cannot un-center-justify the mess unless I control-Z and un-do the function. What gives?