Tools and Techniques
Online Help Today
By Neil Perlin
Editorís Note: This is Part 1 of a two-part series. Part 2, which will appear in the July/August issue of the Broadside, will summarize "true" Web help, the state of the development tools, and major trends.
Online help is changing rapidly, dramatically, and often confusingly, making it difficult to choose formats, standards, and tools. This articleís goal is to make these choices easier by describing the status of online help today and noting some of its major trends.
Very Brief History of the Online Help Industry
In 1990, the industry was small and chaotic. Tools like SmarText, Window Book, Views, and Guide vied for a few applications in a tiny pool of market awareness. The appearance of Microsoftís Windows Help (WinHelp) 3.1 changed this. By 1993, WinHelp was the major standard, more applications were appearing as the Windows market expanded, old tools were disappearing, and todayís tools (RoboHelp and Doc-To-Help) had begun to appear.
WinHelp continued its dominance, with WinHelp 4 in 1995 and HTML Help in 1997. (HTML Help was very different from WinHelp under the hood, but its interface and feature set were similar.) But in 1998, two events began to break the WinHelp modelís dominance and create the industry that we see today:
- The Department of Justice suit against Microsoft delayed the bundling of Internet Explorer (IE) with Windows. That meant help developers couldnít be sure whether users had IE, which made developers reluctant to use HTML Help because it needs IE for rendering. Companies that might have naturally migrated from WinHelp to HTML Help suddenly had to examine other alternatives.
- The Webís growth began a move away from the Microsoft-centricity of WinHelp and HTML Help.
For various reasons, many companies stayed with the Microsoft formats. But other companies took the opportunity to evaluate a range of new choices.
HTML Help replaced WinHelp in 1997, and the WinHelp team was reassigned to other projects a few years later. Yet WinHelp lives. Joe Welinske, president of WinWriters, noted in his opening speech at the 2002 WinWriters conference that about 45 percent of the market still supports WinHelp 4 and about 6 percent still supports WinHelp 3.1. Though WinHelp is a dead format, it's well known, largely bulletproofed, and should work under versions of Windows for years to come.
In many cases, HTML Help is the natural next step after WinHelp. It has a similar interface and feature set, but it is built on an open standardHTML. Microsoft used HTML Help as the basis of its help systems from Windows 98 on, and HTML Help 1.X is the core of Windows XP and Office XP. However, HTML Help has several drawbacks.
- Users need 32-bit Windows. This is not an issue for companies in a pure Microsoft market, but it is for companies that need to support Unix and/or the Mac as well.
- Users need IE 3.02+. Again, this is not an issue for companies in a pure Microsoft market, but it is for companies that need to support other browsers. IE doesnít have to be the userís default browser, but it does have to be on the userís PC.
These two requirements limited HTML Helpís market so the first release included a variant that ran on non-IE, non-Windows machines. However, legal and technical issues led Microsoft to drop its support for this variant. This lead to the development of the Help Authoring Tool-based formats, described below.
HTML Help is based on a pre-Web model in which software is running locally (on the userís hard disk). Itís less effective in server-based environments, because the entire HTML Help file has to download to the client PC before a desired help topic opens. This was acceptable for small help files, but not today when files are reaching multimegabyte sizes.
HTML Help also has two surprising problems:
- A confusing name. People often hear "HTML Help" and think of a helpful Web page rather than a help format. When discussing HTML Help with a client, ensure that everybody understands what it is.
- Unfamiliarity. Few users get training on how to use a help system. Those who do often quickly forget what they learned. And no one runs a help system just for practice. The result is that people typically donít know how to use the help when they most need it. (Interestingly, browser-based help eases this problem. Because a browser is at least minimally familiar to anyone with Web access, users may still not understand all parts of the help system but they do understand its basic operation. This reduces the fear for many new users and gets them up to speed faster.)
Platform- and Browser-Independent Help Formats
HTML Helpís configuration requirements gave rise to other formats that fall into two categories: Help Authoring Tool-based and vendor-based.
These formats were created by individual Help Authoring Tool (HAT) vendors in response to Microsoftís decision to drop its support for the non-Windows, non-IE version of HTML Help. Each major HAT vendor had its own version, such as eHelpís WebHelp and ForeHelpís InterHelp. These formats were basically a combination of a Web site and a help system, offering the platform and browser flexibility of a Web site with the interface consistency of HTML Help. In other words, developers got something that looked similar to HTML Help but without its platform and browser requirements, and that could run from a server in ways that HTML Help could not. Figure 1 shows an HTML Help screen. Figure 2 shows the same content converted to WebHelp.
||Figure 1: An HTML Help system screen (from eHelp).
||Figure 2: An HTML Help screen converted to eHelpís WebHelp.
The formats look similar, but note the toolbar. In Figure 1, itís the HTML Help toolbar. In Figure 2, itís the IE toolbar. The difference seems minor, but the format in Figure 1 requires 32-bit Windows, IE 3.02 or higher, and local operation. Web Help, in Figure 2, will run on any platform and any browser (within reason) and will run on a server. Itís a huge difference.
Note that eHelpís WebHelp has a terminology problem. Just as people hear "HTML Help" and think "Web site", so too do they hear "WebHelp" and think "Web Help." If you plan to use eHelpís WebHelp format, ensure that the client understands what it is.
The Java Helps
Sunís JavaHelp (http://java.sun.com/products/javahelp) and Oracleís Oracle Help for Java (http://www.oracle.com) compete with both HTML Help and the HAT-based formats. JavaHelp and Oracle Help were initially created to compete with HTML Help by offering an escape from Microsoft-centricity, because material in these formats runs on any platform or browser with a Java Virtual Machine (JVM), which meant almost any platform or browser. In a sense, these formats defined the market niche into which the HAT-based formats moved.
The Java helps should have been major competitors to HTML Help, but have actually had limited success. People who need cross-platform/cross-browser functionality have tended to adopt eHelpís WebHelp or the now defunct ForeHelpís InterHelp instead. There are several reasons for this:
- The Java-based help seems slow. Many users find this off-putting.
- Many help developers are unfamiliar with Java and face a steep learning curve to get comfortable with it. (Even some groups within Sun and Oracle use WebHelp instead of their own help formats.)
- Sun and Oracle donít offer their own authoring tools, relying instead on the HATs. (The alternative is hand-coding, which almost no one does anymore.) This leaves Sun and Oracle dependent on the HAT vendors, whose strategies may conflict with those of Sun and Oracle. For example, eHelp appears to be emphasizing its proprietary WebHelp format at the expense of JavaHelp and Oracle Help.
- There hasnít been a strong PR effort by Sun and Oracle to evangelize their formats.
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. Neil can be reached at or http://www.hyperword.com.