Saturday, May 5, 2007

Responding to the comments about my May 2 post, with apologies for deviating from the low-gibberish quotient that I promised…

Re Tom’s point about formats supported by the DITA Open Source Toolkit and why WebHelp isn’t one of them - Officially, I don’t know. Unofficially, I’m pretty sure this is why…

Any authoring tool provider has to offer not only the tool itself but useful outputs as well. Without that, the tool is simply producing raw material. Converting that material to an output that can be distributed to users requires further processing, and that makes the tool less useful. So the answer is simple; make sure the tool can convert the material that it outputs to formats that can be distributed to end-users.

Every tool outputs HTML Help, for two reasons.

First, HTML Help, despite its age, is a standard. (It’s become an uncertain one and, in my experience, is in decline as people move to WebHelp, but it is still a standard.)

Second is a business issue. Tool providers can easily offer HTML Help because the “compiler,” the tool that turns the files in a project into a finished CHM, is part of a Microsoft tool called HTML Help Workshop that, I assume, Microsoft makes easy to license. And the “viewer” that runs the CHM has been built into Windows for years, so the authoring tool providers don’t have to do anything to make the CHM viewable on users’ PCs.

So all the authoring tool provider has to do is bundle HTML Help Workshop with the tool and add a few toolbar and menu options on the tool interface to launch the compiler and view the finished CHM. Easy…

(The same situation largely holds true for the older Windows Help and JavaHelp as well, which is one reason many tools offer them as well. Ignoring the fact that there are still companies using those formats, of course…)

In contrast, there’s no standard authoring engine for WebHelp. The idea of web-enabled output is the same no matter what the tool, but each tool provider has to create its own “WebHelp”. That means programming and expense. (They don’t have to worry about how to display WebHelp, however, since that’s taken care of by the browser.)

So the tool providers are in a tough position because some of their main outputs, like HTML Help, are easy to add to the tool but are in decline. The outputs that are growing in popularity, like WebHelp, require a lot more work on the providers’ parts.

On a side note, you can use DITA in any authoring tool that can import XHTML. Simply convert the DITA to XHTML and import the XHTML files into the authoring tool. The drawback is that you lose the DITA-ishness of the original files.

Re the question about Eclipse Help – I’m not that familiar with Eclipse Help yet, but it’s on my list of topics for future blog entries. In the meantime, Sarah summed it up nicely in her comment. There’s a lot of information about Eclipse Help available on Google.

Re Sarah’s comment – See above, and thanks for the feedback. As far as BBQ is concerned,
see my BBQ page and look up the BBQ Rib Ranch in Sanford, FL, where I ate at the end of April. A gem…

Re Michael’s comment – Excellent points, thanks. The one thing I’ll add, which you sort of said at the end (“no one promised us that everything would be easy”), is that the level of complexity in the approaches you describe will limit these approaches to a very small and advanced subset of help authors.

No comments: