WYSIwar?

Sarah O'Keefe / Opinion5 Comments

Recently, there is a dispute brewing over the relative merits of WYSIWYG and WYSIOO (What You See Is One Option).

In the WYSIWYG corner, we have Vivek Jain, Group Product Manager, Technical Communication products, of Adobe. He recently posted this:

WYSIWYG (What you see is what you get) is the hallmark of a good authoring and publishing tool. Publishing process is the last stage of any technical communication project. Having a WYSIWYG tool, whether you are authoring for Print, PDF or HTML, enables you to preview the expected output as you develop the content and reduces surprises in the end. Surprises during the publishing stage are often the reason for project delays and nightmare for all project members.

And in the WYSIOO corner, we have Sean Wheller with an excellent overview of the argument for XML, which includes a discussion of WYSIOO and WYSIWYG:

[The WYSIWYG] approach is not possible with XML since it was designed to describe data and to focus on what data is, not how data will be displayed or formatted. Authors composing texts stored in XML must use a “ Structured Editor.” This means the editor is focused on two tasks: text composition and valid markup thereof. Since formatting information cannot be saved inside the XML file, the best an editor can do is render temporary formatting and layout for the duration of the editing session. What authors see during the editing session is “One Option ” of what they may get in the final product, WYSIOO.

WYSIOO and WYSIWYG are opposite ends of the same stick. The two end-points cannot be brought together without breaking the stick. Try as you may, if you do manage to bring these polarities together you will find that you have violated the fundamental laws of one or both of these paradigms.

Jain counterpunches:

[W]hile authoring XML documents in FrameMaker, the styles are applied through a template. […] You can replace your […] template at any time during authoring or publishing.

I have often found the argument about WYSIOO (What you see is one option) very hard to understand. If you are publishing for two channels, you can use two templates to preview the final output (WYSIWYG view for two channels). In any case, you need these two templates for publishing, why not share these templates with the authors.

[…] If you can get WYSIWYG for both print and HTML and synchronized content, isn’t WYSIOO an argument in favor of poor authoring experience.

And this is where I join the fray and attempt to provide some additional perspective. WYSIWYG has been the norm for around 20 years as part of the desktop publishing paradigm. Desktop publishing became the dominant paradigm for lots of fun reasons that I won’t get into here. (Wikipedia has the scoop, as usual.)

Today, the entire publishing industry is in the throes of a shift from desktop publishing to structured authoring. Our Structured Authoring and XML white paper has all the gory details. When you start focusing on document structure rather than on page (or screen) presentation, your priorities change.

Dismissing WYSIOO as simply a “poor authoring experience” is too simplistic. In a collaborative, distributed, modular authoring environment, it may be impossible to provide a WYSIWYG view because each end user might see a different version of a document. A simple example would be a web site that allows different users to choose the look and feel of the document instead of accepting the formatting choices that the web site developer made. For print, the final pagination of a document would depend on which modules are assembled for the document, and if the end user has the ability to choose which content to include, the author can’t predict where the page breaks will fall in the document.

Finally, there is the question of the author’s mindset. If you author in an environment that shows you a WYSIWYG print representation of your final document (as in FrameMaker), would that cause you to focus more on printed deliverables rather than considering all the possible destinations for your content, such as print and PDF (which could be different!), HTML, CHM, Eclipse help, and so on?

We are moving away from providing static deliverables, such as HTML pages or PDF files. Instead, readers may be able to control presentation, change fonts, aggregate content, and assemble their own deliverables. In this environment, we need WYSIOO.

PS I’d really like to know who coined WYSIOO. The earliest reference I’ve found is 2004.

About the Author

Sarah O'Keefe

Twitter

Content strategy consultant and founder of Scriptorium Publishing. Bilingual English-German, voracious reader, water sports, knitting, and college basketball (go Blue Devils!). Aversions to raw tomatoes, eggplant, and checked baggage.

5 Comments on “WYSIwar?”

  1. I see the “what you get folks” eventually losing this argument. The downside of the WYSIWYG is that your content is locked within its formatting and crafted for a singular purpose. You can create additional templates, but you cannot foresee all future uses of the material. If you needed to reuse your already published content and deliver it to a completely different medium (say for the next computer/phone/jukebox fusion), you would have to unpack it from what you got in order to get something new.
    WYSIOO gives your content the most mobility and the room to evolve and be reused over time. For an author, the appearance shouldn’t matter. implies the same meaning as seeing the text in big bold letters at the top of the screen, it’s just not as pretty.

  2. I agree with the ‘mindset argument’, but you cannot enforce such a paradigm shift.
    I believe in the merits of Structured FrameMaker by allowing authors to work in a reliable printing environment (there is still no option for user to change the paper width in case they don’t like the layout!). At the same time, working with the structure (view) will gradually change their mind to concentrate on content instead of formatting.

  3. WYSIWYG — how very 90’s 😉
    We can’t anticipate the way our topics will be reused/used in future. And we want to get our authors to focus on the content, not formatting. So, WYSIOO for us makes much more sense. We can always do a quick extract to proof a specific deliverable type.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.