Tools and Techniques

"True" Web Help

By Neil Perlin

As help becomes increasingly Web-like, a group has emerged in the help development community to argue for replacing help-authoring tools (HATs) with true Web-authoring tools, primarily Dreamweaver. This movement has grown for over a year and signifies another major break from the WinHelp/HAT standard. Some of the arguments:

Why move to Dreamweaver?

• HATs create messy code and custom files that other authoring tools may have trouble handling. The code created by Dreamweaver tends to be open and more programmatically "clean." This may be an important consideration if you plan to do large-scale single-sourcing in the future using XSLT, because this technology will have trouble with messy or nonstandard code.
  
  
• HATs sometimes rewrite Javascripts, corrupting them in the process. This only seems to happen at an advanced coding level, but it is still a concern. The obvious problem is that your functions may not do what you expect and, if a HAT is altering them automatically, you may not be able to do anything about it.
  
  
• HATs were not designed for multideveloper projects. Developers have used homebrew methodologies for years to get around this, but it is a case of getting around the tools rather than being aided by them. The HATs are starting to recognize and deal with this issue, most recently with eHelp's introduction of WebHelp Enterprise in RoboHelp 2002. Enterprise programmatically allows multiple developers to create separate modules of a larger project and merge those modules on the server at publication time.

Why stay with a HAT?

Tools like Dreamweaver are complex. Many Dreamweaver-based development groups suggest having an in-house techie, something that smaller companies may not find feasible. The HATs are limited but simpler, and offer a largely all-in-one development environment for people whose focus is content creation rather than coding.

The Dreamweaver approach seems to lead developers to abandon a table of contents and index in favor of full-text search. This approach puts a Webbish slant on the presentation of online information. However, the standard table of contents and index are often appropriate and should not be abandoned just because of a move to a new format. HATs are designed to help developers create standard navigational features such as tables of contents and indexes. Developers can then include those features and leave their use up to the users.

All modern Web development tools claim to be WYSIWYG, but the best that you can realistically hope for is WYSIAWYG (What You See Is Almost What You Get—thanks to John Garison). This is most likely a draw between the HATs on the one hand and Dreamweaver on the other.

The Development Tools

The last few years have seen major changes in the HAT market. Various tools have come and gone, but the status of the major tools is as follows:

eHelp's RoboHelp (http://www.ehelp.com), now up to version 2002, has solidified its position as the market leader. (eHelp changed its name from Blue Sky Software.). One of the biggest changes in RoboHelp is the emergence of the Enterprise module, which offers natural language recognition, usage logging and report generation, and multimodule project merging. This latter feature appears to be a move by eHelp to meet competition from Dreamweaver in the help authoring market.

The HAT market pioneer, Wextech (http://www.wextech.com), sold Doc-To-Help to ComponentOne (http://www.componentone.com), which has rewritten and rereleased it. Wextech itself has left the HAT market to focus on speech recognition via its AnswerWorks product.

Forefront, formerly number two in the market after eHelp, sold ForeHelp to ComponentOne and closed in January. Some of the ForeHelp technology, including its cross-platform, cross-browser InterHelp format that competed with eHelp's WebHelp, will supposedly be integrated into a later version of Doc-To-Help. The rest of ForeHelp will disappear.

The Dreamweaver approach is supported by help templates from Deva (http://www.devahelp.com), which let developers add the interface and some of the navigational features that are associated with traditional help.

Trends

Where is the industry going? The drift away from the WinHelp "model" continues. Different vendors, even different Microsoft groups, use different help styles, and you'll find still more styles used in Web-based applications. Many companies still use the WinHelp model because of its simplicity and predictability, but that is no longer a given.

Three interrelated trends have appeared:

• The proliferation of new devices, especially handhelds such as PDAs and Web-enabled cell phones. If you have to support these devices in addition to traditional help formats, then single-sourcing is in your future.
  
  
• The type and degree of single-sourcing that you will do depends in part on how you define single-sourcing in the first place. For example, if you create hard copy using Framemaker and convert to HTML using WebWorks Publisher, you are single-sourcing now. You're just not doing it according to the currently hot definition via XML.
  
  
• The era of proprietary formats and development systems is ending. Companies will continue to create and use them for years, but as HTML spreads and XML grows more common, proprietary formats are increasingly becoming technical dead ends with declining support resources. In other words, it will be easy to find a writer who knows HTML, but almost impossible to find one who knows a proprietary format and system.

One issue remains undefined at this time: In early 2001, Microsoft announced that Help 2.0, the next release of HTML Help, would appear in 2002. In February 2002, Microsoft announced a limited release via Visual Studio .NET but warned that the general release had been delayed until 2003 at the earliest, apparently to align it with .NET. There will be a temptation to make jokes about Microsoft's release schedule, but that schedule now appears to be driven by larger strategic issues.

Summary

The good old single-standard days are gone. We now have a variety of options for presenting online help, and the problem is to avoid picking the coolest option in favor of the most effective one. For 45 percent of the market, WinHelp is that choice. Yet, in the long run, WinHelp is a dead end. In order to move beyond it and react to continuing technical changes, help developers are going to have to do two things:

• Keep up with changing technologies on an ongoing basis.
  
  
• Create and work to standards. Too often, nonstandard development has been seen as an expression of individual creativity. But, as help systems get larger, as tools become increasingly automated, and as cross-format conversion starts to become more common, breaking the rules will simply cause trouble.

In short, we're continuing to turn into quasi-programmers.

Neil Perlin has 23 years experience in technical communication, with 17 in training, consulting, and development for various types of online documentation and tools including WinHelp, HTML Help, CE Help, JavaHelp, RoboHelp, and some now known only in legend. Neil writes about online documentation and speaks frequently before the STC and other professional groups. He is a senior member of the Boston chapter of the STC. Neil also started and runs the Beyond the Bleeding Edge substem at the STC's annual conferences. He provides training, consulting, and development for various forms of online material, XML, and the mobile wireless Web through Hyper/Word Services of Tewksbury, MA. He can be reached at nperlin@concentric.net or http://www.hyperword.com.