A Review of RoboHelp Office 2002
Part 1 • Part 2 • Part 3 • Part 4
By Matthew Ellison
Although, on the face of it, this appears to be one of the least "high-tech" (or lowest-tech) aspects of the new product, it must have been one that posed great challenges for the developers. They have done a good job. What this means is that it is now possible to produce your WebHelp navigation files (TOC, index, and full-text search) in plain HTML that conforms strictly to W3C's Version 4 recommendation—without any ActiveX, Java, DHTML, JavaScript, or anything else that could cause potential problems within even the most security conscious corporate environment.
It also means that the user can successfully utilize the Help system with virtually any commercial browser from recent history—even Netscape Gold works perfectly well with it. You have the option when you generate your WebHelp system to set RoboHelp to degrade gracefully to this version of the navigation, based on the end-user's browser. Alternatively, you can choose to generate your WebHelp system in this format for all users.
The expandable table of contents is implemented by a collection of inter-linked HTML pages, each of which represents the TOC expanded at a different section. This works perfectly well. The only drawback is that you are unable to expand different parts of the TOC simultaneously.
The full-text search has a rather strange and potentially confusing interface. To find all topics containing the word "bird" in eHelp's Africa Help system, you have to start by selecting "B" as the first letter of the word in the list letters in the figure below:
Then you have to narrow down the possible words by selecting "BI" from the list of letter combinations below:
RoboHelp then scrolls down an index of all words in the Help system to the appropriate location as follows:
The numbers after the word "bird" represent each of the different pages that contain this word, but offer no clue as to the title (or content) of the page.
There is something that I don't understand about eHelp's implementation of this Pure HTML Output feature: I would have expected that if I chose this option then my content pages (as well as the navigation files) would have been represented in pure HTML. However, this is not the case. Any DHTML effects and popups (including See Also) that you have within your Help are not affected by selecting Pure HTML Output. What this means is that even by selecting this option, your topic pages still contain significant amounts of JavaScript code.
It's nice to see a Help authoring tool finally addressing the issue of Section 508 Compliance. Section 508 is part of the Rehabilitation Act requiring Federal agencies to make IT systems accessible to people with disabilities. RoboHelp HTML 2002 provides an option enabling you to generate WebHelp output that is Section 508 compliant. Unfortunately, the Section 508 compliant output is not supported within the Netscape browsers.
The effect of selecting the Section 508 Compliance option is to:
- Automatically assign "alt" text (alternative text) to all the images within the navigation pane (including TOC books, TOC/Search/Index tabs, and navigation buttons)
- Automatically assign "alt" text to design-time controls (ALinks and Related Topics)
- Assign "titles" to navigation frames, which are readable by assistive software such as speech browsers
- Generate tables and forms to comply with assistive technologies
The benefits of eHelp's switch from sitemap format to XML format may not necessarily be obvious to you as Help author. However, it makes a lot of sense—with XML becoming the de facto standard for structuring information of this type, and with Microsoft abandoning the sitemap format in favor of XML in future versions of its own Help format (Microsoft Help 2.0).
There are also practical benefits. The XML-based navigation files are smaller and faster to download than their sitemap equivalents, which reduces the delay when the user first opens up a WebHelp system over a web connection.
One of the drawbacks of an uncompiled Help format such as WebHelp, as compared to WinHelp or HTML Help, has been the lack of a standard API (Application Programming Interface). An API is a ready-made piece of code that enables programmers to link parts of their application to your Help topics. eHelp has gone some way to improving this situation by providing a set of "support files" for programmers working in Visual Basic, C++, Java applets, or JavaScript. These provide functions for calling individual WebHelp topics by Topic ID or by Map ID, thus saving the programmer from entering the necessary code.
One small gripe here: When you are generating a WebHelp system and using one of the eHelp-supplied Skins, you have the option to include a link in each of your topics to the navigation pane. This link is shown only when a topic is displayed context-sensitively without the WebHelp frameset, and it's a very neat way of allowing users to move from a context-sensitive topic into the rest of the Help system. However, RoboHelp does not allow you to specify the wording of the link—"Show" is the default. "Show" may not mean very much to many users, so I'd like to be able to change it to "Show Navigation" or even "Show More Help" instead.
I will continue this article with Part 4, where I discuss the online Help for RoboHelp Office 2002, mention a couple of small glitches that I have encountered, and summarize my experience of working with the new version.
| 
