In a talk at the TCANZ conference in New Zealand in September, Rob Houser explained that Microsoft's approach to user assistance separated UA into "primary" and "secondary". Primary UA is information users don't need to ask for. Secondary UA requires the user to interact before the information will appear. So screen titles, labels, wizard tasks, and other UX devices that help the user understand how to use the application form primary UA.

Read more

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