Empower Authors with WYSIWYG

WYSIOO = Absence of WYSIWYG – If you don’t get what you see, and get something else, it is WYSIOO – what you saw was just one of the options – may God bless you! Now that final output has been published, it looks ugly. WYSIOO by definition adds uncertainty about the final form of output and hence, creates ground for surprises in the publishing stage. Surprises are never good in a production environment. You don’t want to send the content back to authors and ask them to re-write the content because their authoring tool was not WYSIWYG and final output does not look good.

Sarah O’Keefe writes about WYSIWYG vs. WYSIOO and “how in … authoring environment, it may be impossible to provide a WYSIWYG view.” In my view, in 99 % of environments, a WYSIWYG tool exists or can easily be made available to the authors. Most enterprises, small or large, publish to either of the following formats – Print, PDF, HTML Help, WebHelp, FlashHelp, Oracle Help, JavaHelp, WinHelp, Adobe AIR and so on. An integrated toolset like Adobe Technical Communication Suite provides a WYSIWYG view in all these formats.

  1. You can author structured (XML, DITA) or unstructured content in FrameMaker for print and PDF WYSIWYG and publish through RoboHelp for online help formats – with a WYSIWYG view
  2. Content is always synchronized between different output formats (no out of sync)
  3. With support for conditional text and filtering based on attributes, authors can preview all the possible output options (multiple output options – dynamic publishing).
  4. You can connect to a CMS or a source control system to work in a distributed environment.
  5. You can view the aggregated content in a FrameMaker book or in a RoboHelp project (modular authoring environment)

Even for the example Sarah mentions – “a website that allows different users to choose the look and feel of the document instead of accepting the formatting choices that the website developer made”, it is very much possible to give a preview to the website developer. Have a staging server where authors can connect and see the output in different views. In fact, it is almost mandatory to provide a preview – for any good web site, Quality Assurance demands that a testing team verifies all the possible layouts and ensure that user experience is good.

That said, there is still 1 % chance that we can come up with an authoring environment, where a WYSIWYG view is absolutely not possible. If a view is not possible, how is publishing possible? Well, the creators of that environment will need to figure out an answer for that.

I believe in the maxim – “the proof of the pudding is in the eating” – you don’t really know that your dessert has come out right until you taste it. If an author is creating the content, why don’t we give them the tools to view the final output. Empower the author with the same tool and the same template that you have created to publish the content. Don’t restrict the WYSIWYG view to only one output format – for example, print or PDF. Give the right tools to view content in all formats you publish in and this will prevent an excessive focus on one format at the authoring stage.