The “what” in “what you see is what you get” is not always “formatting”.
Authors need WYSIWYG (What You See is What You Get) displays to work effectively. This is basic ergonomics. If you can’t see the thing you are supposed to be creating, you will have a hard time creating it well.
But while authors always need WYSIWYG displays, the “what” that they need to see is not the same thing in every case. There can be several different values for the “what” in WYSIWYG.
The term WYSIWYG was coined to describe the displays of word processing and desktop publishing programs. In this case, the “what” was the formatting of the printed document. (At the time we were talking strictly about printing on paper. The “what” you saw on screen was the “what” that was going to appear on paper — more or less.)
This was a big step forward, but the step forward was not enabling people to do typesetting with computers. Doing typesetting with computers had been possible for a long time using a language called TeX, which is still used in some places today. But TeX, has never been widely used because while you can specify formatting with great precision in TeX, you can’t see the formatting that you are specifying as you work. You can only see it afterward when you run the file through the TeX program to create formatted output.
Make a mistake in your TeX markup, and your output may be garbled in ways that make it hard to find your error, and finding and fixing errors can be fiddly and tedious. Desktop publishing was a big step forward because it allowed people to see the formatting they were creating as they created it.
But formatting is not always the “what” in WYSIWYG. In Learning Python, Mark Lutz describes the syntax of the of the Python programming language as WYSIWYG.
Python is a WYSIWYG language — what you see is what you get — because the way code looks is the way it runs, regardless of who coded it.
Lutz, Mark (2013-06-12). Learning Python (p. 326). O’Reilly Media. Kindle Edition.
What he means in this case is that with Python, unlike most other programming languages, the indentation of the source code always shows the logical structure of the program. If formatted poorly, the indentation of code in a C or Java program can be completely misleading as to the actual structure of the code. Lutz provides this example:
if (x) if (y) statement1; else statement2;
Here the formatting of the code makes it appear as if the else statement belong to the first if statement, but it doesn’t. It actually belongs to the second if statement. The structure you see is not the structure you get. In Python, such confusion cannot occur. Lutz’ Python example looks like this:
if x: if y: statement1 else: statement2
In this case, the else does belong to the first if, as it appears. If it were indented under the second if, like this:
if x: if y: statement1 else: statement2
then the else would belong to the second if statement
In Python, the indentation of the source code determines the structure of the program, and thus the logical structure you see in the source is the actual structure you get in the program. Thus Lutz chooses the term WYSIWYG to describe the language. But in this usage of WYSIWYG, the “what” is not formatting, but structure.
In content engineering there are multiple possible “whats” you might want from a WYSIWYG display. Desktop publishing is based on the premise that the author is also the designer, the typesetter, and the prepress person, so the “what” is formatting. We can be more explicit about this by substituting the word “formatting” for the word “what” in the acronym: FYSIFYG (the Formatting You See Is the Formatting You Get). The desktop publishing approach requires a FYSIFYG display.
Before the days of desktop publishing, when authors were only required to worry about the text, and did not have to wear a dozen other hats, they got by with pens or with typewriters. Both these tools had a TYSITYG display: the Text You See Is the Text You Get.
Today, however, the increasing demand for malleable and repurposable content means neither TYSITYG not FYSIFYG will suffice. We need more than just the text, and something other than text plus formatting. We need structure. What we need to create structured content, therefore, is a SYSISUG display: the Structure You See Is the Structure You Get. Creating such a display, alas, has not been easy.
It might seem like a raw XML file is a SYSISUG display, because all the structure is there in the XML tags. Many XML editors that let you switch to a view of the raw XML will call this “the structure view”. The problem is, while the structure is there, it is not in the least easy to view. There is way too much syntactic noise in an XML file for the reader to easily discern the structure it expresses, as this chunk of the DocBook source for my book shows:
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="chapter.linkrichly"> <title>EPPO Topics Link Richly</title> <indexterm><primary>Weinberger, David</primary><secondary>on linking</secondary> </indexterm> <blockquote> <attribution>David Weinberger, <citetitle pubwork="book">Too big to know</citetitle> <biblioref linkend="TooBigToKnow"/></attribution> <para><indexterm class="startofrange" xml:id="idx.linking-1"><primary>linking</primary></indexterm>Links are the visible manifestation of the author giving up any claim to completeness or even sufficiency; links invite the reader to browse the network in which the work is enmeshed, an acknowledgement that thinking is something that we do together.</para> </blockquote>
Just as the syntax of a formatted poorly C of Java program can obscure the program structure, so the syntax of an XML file can, and usually does, obscure the structure of the content. (Careful indenting of the XML can help, but there is so much syntactic noise in an XML file that it can still be difficult to read.)
This is exactly what Lutz is talking about in describing Python as WYSIWYG in comparison to C and Java. In C and Java, the structure is all there, but it may be expressed in a way that can be hard to see. And if you can’t easily discern the structure inherent in the code you are reading, it is not really a SYSISYG display, because while the structure is there, you can’t actually “see” it at a glance. You have to parse it out carefully from the syntax, and that does not make for effective authoring.
Another alternative that XML editors sometimes offer is a tree or grid view. Here is the same passage in grid view. Here the structure itself is quite explicit, but the text whose structure it expresses is no longer easy to read. You can see the structure, but not the thing the structure applies to, which is pretty much the same thing as not seeing it at all. While the grid view of an XML editor can be useful for many purposes, it isn’t a good place to author content. The tree view of XML is not SYSISYG.
Most XML editors also offer a formatted view (often called, “author view”, or something similar). This view looks superficially like the FYSIFYG display of a desktop publishing program. There are two problems with this view, however. First, though it looks like it, it is not really a FYSIFYG view because there is no guarantee that the formatting the writer sees on screen will be the formatting that the reader sees on whatever device the use to eventually view the content.
Below is the author view of the same passage from my book, using the editor’s default authoring style sheet for DocBook. As you can see, much of the structure expressed in the XML and visible in the grid view is invisible here. This is not a SYSISYG view of the content.
Some of the structure does show through here, though. The index elements are partially visible and the big quotation marks set off the block quote. This is necessary, otherwise the author would have no idea they were there (and might delete them unwittingly) but it means that this is not a FYSIFYG view either. Nor is it a TYSITYG view, since those same elements are not part of the actual text of the book.
So if the “what” in this supposedly WYSIWYG view of an XML document isn’t formatting, and it isn’t text, and it isn’t structure, what is it? Unless someone can suggest some other value of “what” that applies, we have to conclude that this view is not WYSIWYG in any meaningful sense.
And that’s a big problem, because it means that none of the common views offered by a typical structured editors is actually a WYSIWYG view. In particular, since structure is what we care about in structured writing, none of the views is actually a SYSISYG view. In short, we are asking authors to create structure without providing them with an authoring view in which they can actually see the structure they are supposed to be creating.
If anyone was wondering why XML can be such a hard sell to authors, this is one of the biggest reasons. Authors need a WYSIWYG display. The “what” can be different in different cases, but whatever it is, text, formatting, structure, or something else, they need to see it in order to be sure that they will get it. They need an interface that is TYSITYG, FYSIFYG, or SYSIFYG, or xYSIxYG according to the task at hand.
How to provide an effective SYSISYG (and therefore appropriately WYSIWYG) view to the author is perhaps the single most pressing problem in structure authoring. The failure to provide one is perhaps the biggest thing holding back wider adoption of structured authoring methods. We are not likely to move structured writing beyond a small cadre of highly trained full time authors until we solve this problem.
Python provides a SYSISYG view of programming code, but it does it by creating a whole new syntax. That is something that can be done for content too. Markdown and reStructured Text both provide an alternate syntax for HTML documents, as does wiki markup. All of these provide a workable SYSISYG syntax for HTML web pages.
But none of these provide the generality and extensibility of structure that XML provides. And in most cases, structured authoring applications require more structure, and more specific structure, than HTML provides (even for people writing solely for the Web). As long as we are in the XML world, we are going to have to look elsewhere for our SYSISYG view.
One place we can look is a place that SYSISYG views are commonly found in every day life: forms. The forms you fill out all the time, from an order form, to a registration form, to your annual tax form, are all structured views. Any of these functions could also be performed by a narrative view. You could order, or register, or report your earnings and deductions by writing a letter. Chances are, though, that if we relied on that system lots of people would forget to include important information, and people receiving the letters would have to put a lot of time and effort into getting the required information out of letters that put the information in a different order or called it by different names.
For these applications to work smoothly, we need a structure to guide the authors to supply complete information using agreed terms, and to make it easy for the recipients to get the information out. To get this structure, we need to provide the authors with a SYSISYG view, and we do this using forms.
Forms can provide a SYSISYG interface for a variety of content creation tasks. I have been developing forms-based authoring interfaces for many years. Fortunately, advances in tools are making it easier to create such an interface. For instance, here is a recording of a webinar I did with George Bina of SyncroSoft (makers of the oXygen XML Editor) on the case for forms-based authoring.
Forms-based authoring is probably not the whole answer to achieving effective SYSISYG authoring, but it is a big step in the right direction, and something that is available to use today.
The quest for a better SYSISYG interface for content authoring must continue, however.