An "Interesting" WinHelp Development

On July 1, I wrote an entry describing what WinHelp is and discussing its drawbacks, such as:

- Possible security risks from its use of macros.

- Its lack of "web-ness".

- The declining number of authoring tools that support it.

- The declining number of authors that know how to use those tools.

- The declining number of authors who know the codes in case something goes wrong in the tools.

For those companies that still do WinHelp, the projects are becoming increasingly unstable. In my experience, most WinHelp authors today follow instructions written by long-gone predecessors but don't know what's happening under the hood.

Fortunately, there's always the authoring tool vendor's tech support. It's inefficient, since the support rep rarely knows WinHelp and has to research the answer in the company's knowledge base, but you'll get an answer. Until last week...

I'm converting an old WinHelp project created using RoboHelp Classic (now RoboHelp for Word) to Flare WebHelp. Parts of the project date back to the mid-1990s so, not surprisingly, a file was corrupted. After spending an hour in the code, I called Adobe tech support to see what they had in the knowledge base. After some discussion, the support rep told me that he had found nothing!

It's risky to read too much into one episode. It might have just been sheer bad luck on the support rep's part. But it was also clear that he knew nothing about WinHelp. Why does this matter?

It matters because it means that the help-of-last-resort for WinHelp authors just got wobbly. If your tool vendor can't help, it means that any conversion from WinHelp to HTML must go flawlessly via the authoring tool because, if anything goes wrong and you can't find a consultant who knows WinHelp, you'll be stuck. To me, this is a glaring signal that it's time to start leaving WinHelp now.