Technical Communication

WYSIWYG,WYSIOO,FrameMaker,RoboHelp,Technical Communication Suite

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 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 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.", it is very much possible to give a preview to the web site 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 a 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.

Posted by at 1:38 PM | Permalink | Comments (0)

Online Help,RoboHelp,Adobe AIR,TEKOM

Today, HTML Help and WebHelp are the two most popular help formats. The main difference between the two formats arises because of the viewer associated with each of the formats. HTML Help relies on CHM Viewer which is available on Windows OS and WebHelp relies on the browser which is today available for different operating systems. Since there is no way to control the functionality of the browser or CHM viewer, help authors are limited in terms of what they can offer by these two formats. In my opinion, Adobe AIR enables authors to overcome these limitations.  With Adobe AIR, you have an ability to build and customize your own viewer. With a built-in browser and support for SWF and PDF, Adobe AIR provides one of the best end-user experience.  Adobe AIR is designed with web in mind and provides a seamless online and offline experience. 

There are two other important web 2.0 trends worth mentioning here-

Participation of community in building and enhancing the content - Online Help is not a static document anymore and as products mature, knowledge available with end user community often exceeds the documented functionality. The information available in the product documentation is no longer the most comprehensive source of information for most users. Shorter product cycles and increasing importance of emerging markets (more languages to translate the content in) has resulted in a trend towards minimalist documentation. A large number of companies are now taking advantage of community participation. For example, LiveDocs (Adobe) already enables end users to comment on the content, a logical first step towards enabling community to author content.  

According to a survey of 600 technical communicators conducted between July-Oct 2008 (source: Adobe Systems), 60% of all technical communicators agreed with the following statement - "I want my end users to comment on the technical content and make these comments visible to everyone". A strong inclination to open up technical content to end user scrutiny is a very interesting development.

Compelling End User Experience
The most important goal for technical communication departments is "Delivering Best End User Experience", selected by 41% of all respondents (Source: Adobe Systems, July-Oct 2008). It was a surprise to me that cost and efficiency ranked lower than end user experience.  Does it mark an end to minimalism and focus back on effectiveness of documentation, probably, too early to say !!

I presented at TEKOM on a related topic.  To access the presentation, please click below -

Posted by at 11:54 AM | Permalink | Comments (0)

Online Help,RoboHelp,Adobe AIR,Web 2.0,commenting,rich media,Packager

Online Help is not a static document anymore and as products mature, knowledge available with end user community often exceeds the documented functionality. The information available in the product documentation is no longer the most comprehensive source of information for most users. Shorter product cycles and increasing importance of emerging markets (more languages to translate the content in) has resulted in a trend towards minimalist documentation. A large number of companies are now taking advantage of community participation. For example, LiveDocs (Adobe) already enables end users to comment on the content, a logical first step towards enabling community to author content.

According to a survey of 600+ technical communicators over the last three months conducted by us, 60% of all respondents agreed with the following statement - "I want my end users to comment on the technical content and make these comments visible to everyone". A strong inclination to open up technical content to end user scrutiny is a very interesting development.  When we released RoboHelp Packager for Adobe AIR early this year, commenting on help content was a clear focus area.  If you have not seen it action, you can download it for FREE from Adobe site.

Posted by at 8:45 PM | Permalink | Comments (0)

Technical Communication,FrameMaker,RoboHelp,Adobe Technical Communication Suite

WYSISYG (What you see if 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. 

In XML or HTML environments, style and content are separate.  For example, while authoring XML documents in FrameMaker, the styles are applied through a template.  Similarly, in RoboHelp, while authoring HTML content, formatting information is provided by a CSS.  Both the tools provide an ability to choose different authoring and publishing templates. You can replace your CSS or template at any time during authoring or publishing. 

I have often found the argument about WYSIWOO (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. 

With Adobe Technical Communication Suite, you can live link FrameMaker files (structured or unstructured) in RoboHelp project.  That is content authored in FrameMaker is always updated in RoboHelp.  You therefore get WYSIWYG not just for print but also for web output. If you can get WYSIWYG for both print and HTML and synchronized content, isn't WYSIWOO an argument in favor of poor authoring experience. 

Posted by at 10:38 AM | Permalink | Comments (0)