B Y   N E I L    P E R L I N
Boston Chapter

This column previously appeared in Accelepoint, from Clear Point Consultants.

The previous column introduced the problem of formats and tools with confusingly similar names (Are WebHelp and Web help different formats or just a typo?). If the HTML that forms a Web site isn't compiled, what's "compiled HTML" and how does it differ from "uncompiled HTML Help"?

Mistakes may be embarrassing, but they can lead you to pick the wrong format or tool. Or use the right tool the wrong way. Or hire the wrong people. You can avoid such problems by making sure that you and your clients clearly understand the distinctions between different formats and tools. The previous column covered the primary formats and tools: HTML Help, third-party formats like WebHelp and InterHelp, and Java-based formats like JavaHelp and Oracle Help. In this column, I'll touch on the web, introduce some new and potentially confusing markup languages, discuss some misconceptions about help authoring tools, and present two new help "models" - embedding and user assistance.

Over time, "help" has come to be interpreted as "assistance in using an application" and is usually provided as Windows Help or HTML Help. But there's no reason why "help" can't refer to assistance with any task and why it can't be presented in any medium, such as a Web site as in Figure 1. Although it is not help in the traditional sense, this site certainly provides assistance to people who are confused or under pressure.

Then, consider Figure 2. This Web site is still far from traditional help, but it does provide assistance - "help" - in trip planning.

Distributing "help" this way offers two major benefits:

• Platform and browser independence. "Help" in this format runs on any platform and browser (within reason). It has none of the configuration requirements that complicate the distribution of Microsoft's HTML Help.
  
  
• Network friendliness. "Help" in this format is a Web site, and is free of the server-based distribution problems that currently affect HTML Help.

The drawback? Since no one wants online help, we can assume that no one views it until necessary - when they're under pressure to find an answer and get back to work. But users first have to learn how to use the help site. And, because each Web site is designed differently, each site has its own learning curve. It's like saying that you have to learn Pig-Latin to use help file 1 and Greek to use help file 2. If the learning curve is too steep, it's easier to ignore the help and simply yell over to the next cubicle. This is what makes third-party formats like WebHelp and InterHelp useful; they blend the freedom of the web with the navigational consistency of HTML Help.

This isn't to say that a Web site can't deliver help. It simply means that the site must be easily and quickly navigable by users who are under pressure, and can't be designed with the creativity of a typical Web site.

The last two years have seen a proliferation of new and proposed markup languages. Many are at the initial W3C submission stage or niche oriented and little known so far. But some, usually for either e-commerce or the wireless web, are trickling into everyday conversation. They include:

• Compact HTML - A subset of HTML for information appliances. It's an initial W3C submission.
  
  
• XHTML - Extensible HTML, the new version of HTML which is now an XML application.
  
  
• HDML - Handheld Device Markup Language, the original markup language for coding web pages for wireless access. HDML has been transformed by XML into WML, Wireless Markup Language. The danger of HDML is having your listener think you said "HTML". Spell it out - "HD 'as in Dog' ML".
  
  
• WML - Wireless Markup Language, the current markup language standard for the wireless web under WAP (the Wireless Application Protocol).
  
  
• PML - Peanut Markup Language, a markup language developed by Peanut Press of Maynard, MA, for coding material, usually books, for display on Palms, IBM WorkPads, and (recently) CE-based PDAs.
  
  
• CE Help - Microsoft's 1997 entry in the information appliance market. Windows CE is effectively a "light" version of Windows 95 and runs on handhelds, other information appliances, and industrial process controls like conveyor systems. CE never really took off, and Microsoft is due to announce a new version in late April. But CE Help is still out there. It's based on standard HTML with one proprietary tag. (Note that CE may be replaced by Pocket PC and by Microsoft Reader, a new viewing format for eBooks running on handhelds (in 2000) and on desktops and laptops (planned for 2001).)

Another source of confusion arises when people mix the names of the authoring tools with the names of the output formats that those tools produce. RoboHelp, ForeHelp, Doc-To-Help, and other such products are help authoring tools (sometimes called "HATs"), not output formats.

In other words, you don't create and distribute RoboHelp. Instead, you use RoboHelp Classic or ForeHelp to create Windows Help. You can use them to create other output formats also, such as JavaHelp, CE Help, and "WebHelp/InterHelp", but Windows Help is the primary output. Similarly, you use RoboHelp HTML and ForeHelp HTML to create Microsoft HTML Help as the primary output format.

The fact that developers confuse HAT names with the output formats is an indicator of just how deeply the Hats have penetrated the market. The confusion may have no effect other than to make you feel silly, but it can cause trouble - "I just finished creating RoboHelp HTML. How do I convert it to HTML Help?"

A second issue with the Hats is that the shift in the underlying code from RTF to HTML blurs the distinction between the Hats and other authoring tools. All the Hats provide an HTML editor, but many developers don't like them because of their WYSIWYG display problems. (Someone suggested replacing WYSIWYG with WYSIOP - "What You See Is One Possibility".)

Because of the WYSIWYG problems, you might want to use another, "true" HTML editor like Front Page or Homesite to create your topics and import them into RoboHelp HTML, ForeHelp, and so forth, only as the final step to add the control files and compile them. This approach works, but adds to your learning curve because you're now learning two tools rather than a single HAT. Also, be on the lookout for unexpected problems, such as a HAT's rewriting the Javascript inserted by an HTML editor.

With the move to markup languages and a web-like style of help, two new help models are emerging - user assistance and embedding.

User assistance is the least well-defined, which also means it offers the most creative latitude. The idea is that user assistance goes beyond help to encompass anything that offers assistance to the user. The Web sites in Figure 1 and 2 are good examples. For another example, consider the problem faced by your power company's repair staff. If a transformer goes out, a lineman climbs to the top of the pole to check things out, climbs down the pole and into the truck to refer to the manual, then back up the pole to fix the problem. Imagine having the entire manual online as a Web site accessible by a user from a desktop PC and by the lineman via a PDA or cell phone while on top of the pole, without climbing down to the truck. You can see another, more available, example in some of Microsoft's home user software, such as Picture It!, shown in Figure 3.

The "user assistance" is the left pane, which describes how to add a text label to a graphic. Unlike typical applications, which present the fields in a standard dialog box with a help button, the dialog box and help are effectively combined here.

Although this approach is an alternative to traditional help screens, it can't entirely replace them. You still need a way to present concepts, or to present tasks from a user assistance pane in a reference format. There are many ways to do this, but the simplest and most battle-tested method at this point is traditional Windows Help, which even Microsoft uses as shown in Figure 4.

Figure 4 - Traditional help in support of "user assistance" in a consumer application

By breaking the help standard that's evolved since the introduction of Windows Help, user assistance offers the flexibility of presenting information in whatever format is the most appropriate. However, this can also be a drawback for two reasons:

1. We have to determine what that format is.
2. Users might have to learn how to use the new help format, as happened with early WinHelp when help authors had to include a "Help on Help" section in their files.

We assume that today's users don't need guidance, but that may not be true.

The second model is embedding. Embedding help is designed as part of the interface, as in Figure 3, rather than just dropped on top of the interface, as in Figure 4. Money 2000 and some applications in Microsoft's Home line use embedding. The benefit is that the help can be tightly integrated into an application visually and functionally. The drawback is that embedding represents the cutting edge of today's help development and, as in the early days of context-sensitivity, there are no tools and little experience on the parts of either help developers or programmers. In other words, it's still unknown territory. But, like context-sensitivity, it's too useful an idea not to develop and I expect embedding to be a mainstream model within the next few years.

Neil Perlin has twenty-one years experience in technical writing, with fifteen in training, consulting, and development for various types of online documentation including WinHelp, HTML Help, and some now known only in legend. Neil writes about online documentation and is a popular speaker before the STC and other professional groups. Neil provides training, consulting, and development for online documentation through Hyper/Word Services of Tewksbury, MA. You can reach him at nperlin@concentric.net or www.hyperword.com.

Copyright © 2000 Neil Perlin submitted to the STC for use in Hyperviews:Online.