Site FeedPalimpsest has moved. Please visit our blog in its new location for the most recent posts from Scriptorium.
Palimpsest
WYSIwar?
Monday, November 17, 2008 — posted by Sarah O'Keefe
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:
Jain counterpunches:[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.
[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.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.)
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.
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.
4:00 PM Permalink |
|
<< Home
