Standardized Help has existed since the Windows platform was created, and even in the DOS world in little known tools like QuickHelp. Throughout the years (and versions of Windows), Help has continued to evolve, passing through several distinct stages, which are described in the next few sections.
The WinHelp format used in Windows 3.0 still exists, and can be used in the most modern Windows application. Unfortunately, it looks irredeemably garish. Help files from different authors tended to look—and act—differently.
Figure 14-1: WinHelp: a piece of living history
When Windows 95 was introduced, a new standard (often referred to as WinHelp 95) took over. WinHelp 95 files are familiar to almost any computer user, and they are still used in countless programs.
WinHelp 95 was a major improvement in the Help world. Whereas the original WinHelp forced developers to create their own contents page with hyperlinks, WinHelp 95 files use a separate contents file (with the extension .cnt) to define the standardized multilevel table of contents. WinHelp 95 really has two parts: the .cnt contents page (which also provides a standardized index and full-text search), and the .hlp help file that provides the actual topics. When a user double-clicks a topic, the table of contents disappears, and is replaced with the appropriate help window.
Figure 14-2: WinHelp 95: a facelift
The standardized table of contents was both the most significant advance and the most obvious limitation of WinHelp 95. The obvious problem is that users often need to jump back and forth between the table of contents and the topic pages before they find the content they need. This process is tedious, and it feels complicated because there can be multiple windows scattered about the desktop.
The next version of WinHelp was named HTML Help, because the source files were written in HTML markup language instead of the RTF format. HTML Help debuted with Windows 98 and also shipped with Internet Explorer 4. A common source of confusion about HTML Help is the idea that it is somehow supposed to provide help over the Web or browser-integrated help. While HTML Help depends on some components that are also used in Internet Explorer, it really has little to do with the Internet. Instead, HTML Help is an improvement to WinHelp that combines the table of contents and topic views in the same window (see Figure 14-3).
Figure 14-3: HTML Help: the industrial revolution of help
The new HTML Help view makes it dramatically easier to browse through a long, multilevel table of contents without losing your place. By dividing and subdividing information into its smallest bits, Help developers are able to put fairly lengthy, complex content in a help file. With HTML Help, developers also started to use DHTML and JavaScript text directly in their Help to create collapsible headings and other neat tricks. In some cases (for example, the Visual Studio 6 documentation and the SQL Server documentation), Microsoft refers to these help files as "books online." HTML Help files always use the .chm extension.
The next revolution to the Help world is tentatively titled MS Help 2, and it's the help engine used by Microsoft's MSDN help in Visual Studio .NET. The first Help 2 engine ships with Visual Studio .NET, but it isn't yet supported by most third-party tools, and there isn't a great deal of information about it (some basic information is available at http://helpware.net). Help 2 promises some long-awaited improvements to HTML help, like a redesigned user interface, and the ability to embed a help window in an application interface with minimum fuss. However, it also has its idiosyncrasies. For example, every Help 2 file must be registered with the Windows operating system. You can't simply copy the appropriate .HxS file to another computer.
Figure 14-4: Help 2: a new standard?
One of the exciting features with MS Help 2 is that it can plug into the Visual Studio .NET Help collection. That means that tool vendors can distribute Help with their components that will pop into the Dynamic Help window in the Visual Studio .NET IDE when the component is being used.
Microsoft provides only rudimentary tools for compiling source files to create Help systems. To have the full range of tools for designing, linking, and configuring your Help, you will probably need to turn to a third-party design tool. Creating Help is beyond the scope of this book, but there are a few starting points:
The "professional" Help design systems tend to ship with countless tools—and intimidating prices. Two leading examples are RoboHelp (http://www.ehelp.com) and ForeFrontHelpCenter (http://www.componentone.com/ffhelp/ff), although numerous other mutually incompatible design tools are available.
Some Help systems are designed from the ground up with single-sourcing in mind, with varied degrees of success. Doc-to-Help (http://www.wextech.com) attempts to integrate printed documents in Microsoft Word with Help, and WebWorks Publisher (http://www.quadralay.com) works magic with FrameMaker files—at the cost of forcing you to learn and use a proprietary language.
Numerous smaller-scale utilities assist with the compilation or some aspects of development (like creating a table of contents) but don't assume you'll use an HTML editor or other tool to write the actual content. An example of a program like this is FAR (http://www.helpware.net), which is unique in being one of the first third-party tools to introduce support for MS Help 2. You can also find many cheaper Help tools at shareware sites online.