Should You Move to HTML-Based Help? It Depends . . . News & Views Feature Article

by Cheryl Lockett Zubak Copyright © 1997 Cheryl Lockett Zubak. Cheryl Lockett Zubak is a senior member of the STC Philadelphia Metro Chapter and president of Work Write™, a consulting firm that specializes in developing hypertext-based user assistance from WinHelp to the Web. She is coauthor of Designing Windows 95 Help: A Guide to Creating Online Documents (Que, 1996) and Developing HTML Help: A Design Strategy Guide (O'Reilly, 1998). Her email is cheri@workwrite.com. Originally published in News & Views January, 1998 issue. For permission to reprint this article, contact the Managing Editor.

Let me begin by answering my own question: yes, but perhaps not quite yet. Moving to HTML-based help is in most cases both inevitable and full of promise, but much of its promise is still ahead of us--dependent upon the vendors who are creating HTML-based help engines (and those now include Microsoft, Netscape, Oracle, and Sun) to actually deliver full working systems, upon the needs and Web-connectedness of your audience, and upon the types of user assistance you plan to deliver. In other words, when and how you move to HTML depends upon what you want to do with your online documents and when you want to do it. In this article, I'd like to take a look at what you'll gain by moving to HTML-based help, as well as what compromises you may need to make. First, some terminology What does HTML-based help mean? At the heart of it, this term simply means that you will no longer create the content of your help system using Rich Text Format (RTF), which is required by Windows help (WinHelp). Instead you will create that information with Hypertext Markup Language (HTML). You may still be using the same authoring tool that you've always used to create Windows help, but you'll need to get a more recent version of that authoring tool--one that supports HTML. Another aspect of HTML-based help is that it uses a new compiler--or help engine--as we'll refer to it in this article. This help engine has been upgraded to handle HTML-based information (and all of the new features that Microsoft and other engine developers have decided will come along with this file format). In fact, that help engine may not even be created by Microsoft. And that, my friends, has become the crux of one of the biggest issues behind moving to HTML-based help. Which engine do you choose? And are any of them even ready for prime time yet? The status of help engines Currently, you can choose from these HTML-based help engines: Standard HTML. This is actually the file format behind the content in any of the HTML-based help systems. It's called "standard HTML" because it is, in fact, standardized by an organization called the World Wide Web Consortium (W3C). Some people choose to use standard HTML rather than one of the other HTML-based help systems because (a) they're tired of being flayed by the developers of those systems and (b) they believe that using standard HTML on its own, without the software requirements of the other systems, is the only way to remain cross-browser and cross-platform. But more on that later. Microsoft's HTML Help. Currently in release 1.0 (version 1.1 is due out before the end of the year), this is Microsoft's replacement for Windows help (WinHelp) and MediaView, a programmer's software development kit for developing custom multimedia titles. HTML Help uses standard HTML for textual content but provides other features through a special software interface, which is supported by either ActiveX or Java technology. Netscape's NetHelp. This help engine is Netscape's answer to providing help for Navigator-based applications--that is, HTML-based software applications that run inside Navigator (or Communicator, Netscape's suite of browser products). NetHelp uses standard HTML for content and extensive JavaScripting to manage the windows and navigational systems. NetHelp is currently in release 2.0. Sun's JavaHelp. Currently in the specification stage, JavaHelp is Sun's bid to provide a help system that is based on 100% pure Java. Sun intends for this system to be used as the help system for applications created with JDK, the Sun development environment for developing Java applications. A public specification for JavaHelp is expected by the end of the year. Oracle's Oracle Help. This system, which is also Java-based, is intended for developing help systems for Oracle-based applications. The goals of the system are to provide an easy conversion from WinHelp or HTML Help and to support a client-server environment. The help system you choose depends a great deal on the programming environment used to develop your organization's products and the operating system you're supporting. The problem is that the way toward making this choice is muddled, as we'll see later in this article. In addition, the features that have been promised for each of the help engines have not yet been delivered-if the help engine is even completed. For example, Sun's JavaHelp is still in the specification stage, and both Oracle and Netscape are waiting to see what Sun will deliver, since both may alter their development plans to adopt JavaHelp. System requirements As with WinHelp, the HTML-based help systems require you to provide hard disk space for the content, any additional software components you use, and the components of the display engine. In this area, we face three problems. First, it's very likely that the size of our HTML-based help systems will eventually be larger than WinHelp systems. In part, this is because HTML-based information is generally more robust than WinHelp and some of us will take advantage of this fact. In addition, depending upon which HTML-based help system you choose, you may or may not get a compiled help system--that is, a help system in which all of the many topics and graphics that make of the content have been placed together in a single, often compressed file. Standard HTML and NetHelp, for example, don't support compiling. HTML Help does provide this feature. Oracle Help and JavaHelp are expected to eventually support compiling. But without compilation, our HTML-based help systems are likely to be significantly larger than our WinHelp systems. The third problem is the need for a browser. All of these help systems require a browser to be on the user's machine in order to render the HTML. This means that you may need to ship the browser if the user doesn't already have one, and browsers aren't exactly small. The minimum installation of Internet Explorer 4.0, for example, takes up about 30 MB. Quite a difference from the 300K of winhlp32.exe, the WinHelp 4.0 "browser"! Features we lose (for now) In the long run, you will certainly be able to do more with HTML-based information than you can with WinHelp. However, HTML-based help doesn't yet support every feature that Windows help has traditionally provided. A big issue, for example, is providing popups, which are not supported by standard HTML. You can create something like a popup through HTML-supported scripting (e.g., JavaScript), but a scripted window doesn't act like a popup. The user has to know how to close it, for example, and it opens more slowly than a WinHelp popup. HTML Help is currently the only one of the HTML-based help engines to provide a special popup window. However, these popups have much more limited functionality than WinHelp popups. For example, they don't support graphics, links, even typographical information applied to selected text. Another large issue is window handling. While you can create secondary windows with most of the help engines, you don't have the same degree of control over setting size and position as you had with Windows help--yet. I suspect this will change as the authoring tools catch up with the changes in the help engine technology and as we see new releases of the help engine technology in the spring. The need for speed It will be a long time before a browser opens as quickly as WinHelp does--if ever. It may be true that users will eventually become accustomed to the slower display of HTML-based applications and information. And it could be that, as often happens with new technology, it will take more, even newer technology and faster computers to really speed things up. There's not a lot we can do at the moment to speed up browsers. The best we can do is make sure our HTML pages open quickly. That means learning as much as we can about how HTML works and keeping up with new technologies, such as Dynamic HTML, which are intended to speed the display of complex pages. Updated information Spend some time with the help systems for Internet Explorer 4.0 or The Communicator and you'll notice that both help systems have some integration with the Microsoft or Netscape websites. Just drop down the Help menu to take a look. Providing up-to-date, dynamic information is one of the great aspects of the Web. As soon as you complete an updated file, you can put it on your website, send an email to your users to let them know that it's there, and let them download it. This is a far cry from what we have to do to get an updated help system to users today-typically, we must wait for the next software release since it's too expensive to distribute new files just to update the help system. User connectivity Users don't have to be connected to the Web to take advantage of HTML-based information, although they do have to have a browser on their machines. The question is: are users really going to support your installing a browser (remember that potential 30 MB of lost hard disk space) if they aren't using that browser for something more than help? While Web connectivity isn't required, it's also true that without a Web connection, some of the capabilities of Web-based information won't apply. For example, you won't be able to surf to a company website to download a software patch or the latest version of the help system. And if you decide to use a form to get feedback from the user, you won't be able to retrieve that information easily. Extensible, interactive information One of the problems with Windows help was always that you could only do so much before being stonewalled by its lack of more advanced capabilities. Multimedia doesn't play gracefully when placed inside a WinHelp window, for example. And changing the way navigation works requires you to embed a navigational system within the content of the help system, since you can't easily revise the way the WinHelp software works. Thankfully, a robust cottage industry has supported Windows help, creating Dynamic Link Libraries (DLLs) and other software components to buttress the capabilities of WinHelp. HTML is quite a different story. You can do anything with HTML-based information that you can do with a Web page. And the industry developing HTML-based information is incredibly diverse and robust. You have only to open your favorite computer magazine to see the latest Web technologies--everything from ActiveX controls and Java applets to database backends to multimedia support. You name it, the Web has it, and you can use it in HTML-based help. One of the benefits of the capabilities and extensibility of HTML is that you can more easily create interactive information. Built into HTML, for example, is the ability to create forms-to capture user information, ask questions and get responses, and so forth. Or you can add a software component like Shockwave to display sophisticated multimedia inside your help system. Cross-platform support Standard HTML is often touted as a cross-platform file format. Since HTML-based help uses HTML for content, you would think that it is also cross-platform. However, right now, this isn't necessarily the case. First, since HTML-based help requires a browser, you must be certain that your favorite browser is available on every platform on which you want to provide help. Even this doesn't mean you'll be able to use the help for your application. For example, Netscape Navigator is available on a large number of platforms, but NetHelp is really only intended for help in a Navigator-based application. Since many of the help engines have a software component, you need to evaluate whether this component will inhibit your using the help system on certain platforms. For example, HTML Help relies extensively on ActiveX technology, which is currently limited to Windows. (Microsoft is working to provide the ActiveX framework on Macintosh and UNIX.) While you can use a Java-based version of the ActiveX technology, this version lacks some of the more interesting functionality of the ActiveX version. JavaHelp and Oracle Help are created with Java, a programming language that is supposed to be cross platform. I've heard so many heated discussions among programmer friends over the last year that I can honestly tell you that I have no idea whether Java is indeed a cross-platform solution. But at least one side of the fence says that it's supposed to be. Cross-browser support Even with standard HTML, cross-browser support isn't a given. First of all, "standard" HTML isn't always quite as standard as you would think. Certainly, W3C has published a set of standard HTML tags, but that doesn't mean that Netscape and Microsoft always implement these tags in the same way. Try creating tables and frames that work in both browsers and you'll see what I mean. Netscape claims that you'll be able to run NetHelp in Internet Explorer--once IE supports the latest version of JavaScript. Microsoft counters that you'll be able to run the ActiveX version of HTML Help in Netscape--once Communicator supports ActiveX. Oracle says that you can plug in any browser into Oracle Help--but you have to use an Oracle database backend. Sun also says JavaHelp, once it is available, will support any browser--though it will ship the Sun-Netscape browser with the produ ct. In other words, the only cross-browser HTML-based help is standard HTML that doesn't push the envelope. So what to do? If it sounds like you'll face a lot of "challenges" when moving to HTML-based help, you may be absolutely certain not only that you will but also that I've only touched on a few of them. On the other hand, I also believe that it will all be worth doing. Anything that allows us to create better online help systems--and I do believe this will be the eventual result of HTML--based information-has got to be good for all of us. Keep in mind that you still do not have to move to HTML-based help right now, unless your company has explicitly directed you otherwise. The help engines aren't yet quite ready for prime time, but they're getting there. You can afford to wait; WinHelp isn't going away. In fact, it continues to be the standard help system for providing Windows-based help systems (and sibling help systems on Mac and UNIX), even at Microsoft. But do get ready. Do learn HTML. Do go to conferences like those sponsored by WinWriters and Help University to learn about the help technologies and to see what those who are implementing HTML-based help are doing. And do try out the help engines using your authoring tool of choice. And what do you do if you must create HTML-based help now? Work with what you have, which may not be entirely together but can still do the job. Punt. Then step back and wait a moment, take a deep breath, and push forward again. Act kind of like the Web itself. and be sure to grin. ;-)

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page] s
Posted February 1, 1998 (rst)