What Does HTML-Based Help Look Like? Take Your Choice 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(tm), 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 March 1998 issue. For permission to reprint this article, contact the Managing Editor.

So you've decided to try out this HTML-based help stuff, or at least dip your toes in the water to see what the temperature is like. And perhaps you're thinking, "I know what WinHelp files look like. I've done those. Does moving to HTML-based help mean that my help systems are going to look different from WinHelp? What should my HTML-based help system look like?" It is this final question that we're going to tackle in this article. What's the "standard" model? Though you might expect the question to have a fairly simple answer-"Oh, it looks like this. Here's a picture of it."-this isn't the case. The "standard" HTML-based help model currently depends to a certain extent upon whether you've chosen your "side" in the browser wars. Have you decided to go the Microsoft route or some other? For example: You might go with the tripane model (see Figures 1 , 2, and 3) to provide your customers with the standard model that Microsoft has been using with its more recent applications (e.g., Internet Explorer 4.0) and is likely to use as the help model for its operating system (Windows 98? NT 5.0) and application software. In fact, if rumors are valid, JavaHelp, Sun's help solution, will be using a model that is similar to the tripane window (more on that later). You might also decide to go with what I call the scripted help model. NetHelp (see Figure 4) is the most well-known example of this model, which combines heavy JavaScripting (primarily to create smaller windows) with standard HTML. The third model that I'll be talking about in this article is the website model (see Figure 5). In this model, the help system opens in the browser and takes up the entire screen. It typically uses frames, tables, and other standard HTML techniques to set up the page. Let's look at the interfaces and design implications of each of these models. The tripane window Microsoft has developed the tripane window as a standard model for its own help systems and as the default model produced by HTML Help. It is called the tripane window because it does, in fact, have three panes--that is, three areas of the window that can be controlled separately. Those panes are the button bar (at the top), which contains the Back, Forward, Options, and other buttons the navigational pane (on the left), which contains the table of contents, index, and search tabs (controlled by the HTML Help ActiveX control) the topic pane (on the right), in which the content appears when opened from one of the navigational systems or through context-sensitivity. Figure 1: The tripane window, in its full state, displays both the navigational system and the topic area in the same window. Figure 2: To get around the real estate issue, users can click the Hide button to see only the button bar and the topic pane. (This design is much more like Windows help.) Remember: While this model isn't the only interface you can produce with HTML Help, it is the one Microsoft is currently using for its own help systems. The tripane model tackles some of the usability problems of WinHelp 4.0, which uses a dialog box (called the Help Topics dialog box) for its main navigational system. One of the big problems with the WinHelp 4.0 interface is that you can't have, say, the Index tab of the Help Topics dialog box open at the same time as the topic. As a result, you can't just click through similar keywords in the index to see the content of the associated index. The tripane window, on the other hand, is designed so that the user can select an entry in the index (or table of contents or search) and immediately see the associated topic in the same window. Then, if necessary, the user can continue to skim through the index to see additional topics. While the tripane window does help the user in the sense just described, the tripane design introduces another design problem, that of screen real estate. The tripane window is simply larger than the small help windows that we are accustomed to creating, especially since the influence of Microsoft's "minimalist model." The navigational pane and topic pane, when opened together, are twice the size of many help windows we're currently building and cover more of the software than we may be comfortable with. To get around the real estate problem, Microsoft added some functionality-controlled by the Hide/Show button-to the tripane window. If you click the Hide button, the navigational system is removed from the tripane window so that only the button bar and topic pane are visible. To get the navigational pane back, the user just clicks the Show button. From the results of its own usability studies, Microsoft representatives have stated that users seem to like this design. Although Sun and Oracle have developed their own user interfaces, those interfaces appear to be spin-offs of the tripane design and other online documentation influences. For example, the following model shows one of the very early prototypes for Sun's JavaHelp. Figure 3: This figure shows a very early prototype of Sun's JavaHelp system. The basic design is very similar to the tripane window but without the Hide/Show capabilities. This prototype is quite similar to the tripane window, though as first shown it did not (and may still not) have the Hide/Show capabilities. You can create the tripane window with Microsoft's HTML Help Workshop (a free download from http://www.microsoft.com/workshop/author/htmlhelp/) or with the most recent version of your help authoring tool. Those tools will more than likely support JavaHelp and perhaps Oracle Help for Java at some point as well. The scripted HTML window The tripane window-and all spin-off designs-require the user to install software components on the user's machine in addition to the browser (which is required for any HTML-based help system). That software may be created with Visual Basic, C++, Java, whatever-for some authors it simply doesn't matter. They don't want to have to deploy and support more than their own system and don't want to have to send, manage, and install additional software components. On the other hand, they do want to develop WinHelp-like topics that reside in a small window so they need more than a standard browser. For these users, the scripted help model has become a good alternative. Using Java-Scripting (or some other HTML scripting language), the author or some helpful developer creates a scripted window for topics. JavaScripted windows display more slowly than software-controlled windows and don't offer as much control over window size, location, and navigation. However, compared to the full-screen browser, this strategy does at least create a smaller space that isn't as likely to interfere with the user's ability to see the application software. The most well-known of the scripted help windows is the NetHelp-based system for Navigator 4.0/Communicator (see Figure 4). This window uses a five-frame design. The navigation control frame (top left) contains scripted controls which change the "view" to the table of contents or index, and open the Find window The document navigation frame (top right) contains a series of graphics that allow the user to open any of the main documents in the help system The index or table of contents frame (left side, below the navigational control frame) lists the table of contents entries or keywords The content frame (right side) displays the topics in the document as selected from the document navigation frame Another navigation frame (bottom left) contains the browsing, printing, and exiting buttons are placed Figure 4: The Navigator 4.0/Communicator help system is an example of the scripted help window, which uses JavaScripting to control the window. The NetHelp system uses the latest version of JavaScript, which currently is supported only by Navigator 4.0. This limits its usefulness in a cross-browser situation, but makes it a fine alternative if your users are using the latest version of Navigator (especially since the browser is now free). Like the tripane window, the standard window size that NetHelp creates is a little large. In addition, it has no "on top" state, so it falls behind the current window if you choose to use the software when the help window is open. You can create the scripted help window with whatever HTML editor you're using, although you do need to understand JavaScript. To create the NetHelp implementation of this model, you should download the NetHelp 2.0 SDK from http://search.netscape.com/eng/help/home/home.htm). Using a help authoring tool won't help you, since the tool vendors don't currently support NetHelp 2.0. The website model If you haven't yet surfed the web, go take a look, and you'll see lots of examples of the website model, which pretty much means "create whatever you want, and have fun doing it!" On the web, you'll see lots of examples of the website model. Like the scripted help window, the website model (see Figure 5) uses standard HTML without additional software components to avoid the deployment and support issues of using software that isn't part of the browser. Figure 5: The website model allows the help to take up the entire browser window rather than attempting to manage the window size. Although I call this model the website model, this doesn't mean that it has to be placed on the Internet or an intranet. Figure 5, for example, shows the help system for an HTML authoring tool, which resides on your local hard drive. However, the website model doesn't necessarily require scripting. In fact, authors may decide to limit the amount of scripting they do or "dumb down" the scripting to very basic scripts. For example, you may be creating a help system that you're putting on your public website and don't want to use JavaScripting since many corporate firewalls don't allow scripted pages to be viewed. In this implementation, the help system takes up the entire screen. What you put within that screen is up to you (and as you see from the web, can vary widely), but three basic formats are common. The original "fill up the screen" approach has admittedly become less common but is certainly out there, especially on pages for academic or organizational use (presumably to support less capable browsers) The frame "shell approach" has a table of contents in the left frame, sectional or browsing navigation in the top frame, and pages "poured" into the right content frame The table approach, for more highly structured pages, often uses columns, small chunks of information, and very tight, precise designs An obvious problem with the website model, at least for software documentors, is that it covers the software you're describing. As a result, the user can't use the software and the help at the same time. This may make this design more useful for online documentation, rather than help. As with the scripted help window, you can create these designs with a bit of HTML-knowhow (required for every one of these designs, by the way) and your favorite HTML editor. So is it different from WinHelp? WinHelp is certainly the help designer's launching point for considering which model to use, and it should be. WinHelp is what we know now, even though it is certainly crucial to learn about HTML-based information. You can create an HTML-based help system that works very similarly to WinHelp. Using HTML Help and the tripane model will get you closer to this goal than any of the other help systems but may limit you to an Internet Explorer world. Be sure to experiment with the other models. Each of them has its place, and I suspect, as you begin to develop more HTML-based information, you'll find yourself using each of the models to create different kinds of information. It's a world worth knowing, and one worth experimenting with. Don't be afraid to try something you haven't tried before. In fact, I'm willing to bet you'll gain as much by testing yourself as you do by testing the technology.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Posted June 5, 1998 (dls)