Is Help sufficiently different from other forms of documentation that it should warrant a specialised DITA? Specialisation tends to be vertical (industry-specific) rather than horizontal (domain-specific). Single-sourcing makes a lot of sense if the Help is viewed as one possible output. A Help specialisation might make single-sourcing of manuals, Web and Help content difficult, although it might make the production of a suite of Help systems easier.

Read more

On a mailing list, I once read a comment to the effect that DITA was not suitable for Help, as it didn't provide support for popups. This comment rang a bell with me. When Microsoft released HTML Help (in 1995, I think), one of the first criticisms was that it didn't support rich text popups like good old WinHelp did. True, it did not, and its support for plain text popups was ungainly. Over time, the popup problem was solved by DHTML.

Read more

In thinking about what a standalone (as in "not embedded UA")  Help system generated from DITA source should look like, and what features it might have, Eclipse Help keeps cropping up. If a tech writer currently wants to generate an Eclipse Help system for distribution with a locally-installed application, the technical hurdles are quite high. It might not be an issue if the application is Eclipse-based, but it otherwise requires quite some overhead.

Read more

I have been giving some thought to the ways in which Help may be invoked by a software application. The ways I could think of were:

Read more

When a DITA information set is transformed into a book, the deliverable is a self-contained. Its navigation devices (page numbers, TOC, index, cross-references) are constructed from the DITA source. Likewise, when a compiled Help deliverable is created, the navigation is constructed. However, a compiled Help file is typically read in a viewing program that allows full text searching; that form of navigation is provided by the viewing engine, and is not derived from the DITA source.

Read more