Tips to Help You Raise the Standard
of Your WinHelp Documents
News & Views Feature Article
|
|
WinHelp by Design:
Tips to Help You Raise the Standard of Your WinHelp Documents News & Views Feature Article |
|
by Cheryl Lockett Zubak, President
Originally published in News & Views March, 1996 issue.
Copyright 1996 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.
|
To many document publishers, saying "WinHelp" and "design" in the same breath is a bit of an oxymoron (and to some, even sacrilegious). WinHelp is just a viewer, after all. It's for help systems. It's not as if it's a real tool. Everyone who has Windows has it. I mean, it's free. Good points. WinHelp is familiar to any Windows user, and it doesn't cost a penny to distribute it. No environment allows you to create Windows help more easily. (And the problem was...?) It's also true that WinHelp can be a "challenging" authoring environment. We simply can't do everything in WinHelp that we might want to do with our online documents (at least, not elegantly). No problem. We should just get out one of our many other authoring tools to create those more complex online documents. You all have Authorware, don't you? Or Quest? Director? And Java? And you do know at least a little bit about programming, right? Yeah, right. Despite the movement of many authors toward multimedia, computer-based training, and Web publishing, some of us are still, well, stuck with WinHelp. And increasingly, we're creating more than help with WinHelp--everything from newsletters to tutorials. Can't we, like our multimedia and CBT colleagues, do fun and interesting things? Can't we make our WinHelp documents more appealing to look at? And easier to navigate? Can't we do something to get users to look at and use them? Sure we can. Let's talk about how. Don't blindly follow the Microsoft modelThere's nothing really wrong with the online help and documentation models that Microsoft has developed (especially in Windows 95), except that everyone copies them, which means your Microsoft-mimicked document looks pretty much like everyone else's. While you don't want to be different just for the sake of being different, Microsoft's help is not the "end all" of help development. The Microsoft model is a strong one, but it's certainly not the only way of developing a WinHelp document. Even if you work in a Microsoft shop and are being strong-armed into "Do exactly what Microsoft does or else," you can use the Microsoft underlying model, even some of its look and feel, to create a well-designed WinHelp document without doing "exactly what Microsoft does." For example, in the Windows 3.1 world, you might want to include an examples and demos topic. However, you might also want to think about how useful those examples and demos topics are in Microsoft Office. It might be you'll want to offer a little more in-depth content. Or, if you're developing Windows 95 documents, you could work with your programmers to create wizards that users can select from the Contents tab of the Help Topics dialog box. But you also might want to rethink whether the Office 95 tactic of running wizards unannounced is such a good idea. You might want to tell the user what's going to happen before it does. My advice is to look at the Microsoft model closely, determine what's good and not so good about it for your applications, take the good and leave the rest behind. In other words, do your own thing, but consider other models, like Microsoft's, when doing it. Develop a visual model for your contentIf you could paint a picture of your document, what would it look like? What kind of metaphor would you use to express it? What colors would you use? Suppose, for example, you were creating an employee directory for your department--a reference for new employees. The Contents topic (Windows 3.1) or main navigational topic (Windows 95) doesn't have to be the typical list of the high-level topics in the WinHelp document. Instead, it could be a map of employee cubicles. When you click a cubicle in this map, a popup window could display a photograph, the person's name, title, and extension. If you can persuade your boss to hire a computer artist, you could use "illustration art" to convey the theme of the document, or, in the case of a help system, the software it describes. Figure 1, for example, shows the Contents topic for Hypertext Development Kit 3.0, the upcoming version of this Windows Help authoring tool. Since the tool itself allows you to add all kinds of features to your WinHelp documents, the idea of two help authors guiding text, graphics, multimedia, and so forth into a help topic is an appropriate one. (The characters you see on this graphic, by the way, are carried through the art for the help system and the user's guide.) For those of us who don't have a computer illustrator at our disposal, the visual model can be more simple than this. It could be a series of icons that represent the content of the document, such as you might find in Quicken help. For example, Quicken uses a graphical "How To" icon for procedural documents. All icons appear in the top right corner of the topic, next to the topic title. Creating a visual model is hard work. It requires that we remove ourselves from the way we think of the traditional WinHelp document (conservative, corporate, text-heavy). It also requires that we play, experiment, and seriously consider the merit of our more "off-the-wall" ideas. Ironically, this kind of play is very difficult for many of us. Create logical linking pathsLinking is the easiest part of creating a WinHelp document, right? I mean, you just see a related subject mentioned in the topic and link to that topic. What could be easier? Unfortunately, because we often do consider linking--that is, creating jumps and popups--to be a relatively easy process, we often fail to create logical learning paths in our documents. In fact, many WinHelp documents simply contain too many links. In addition, the links are often created without planning. As I just described, we create the links after or while creating the content, rather than systematically planning the links before implementing them. Here are a couple of ideas to keep in mind about linking. First, use the seven-plus-or-minus-two rule. This rule states that people can typically remember seven-plus-or-minus-two new things at a time. A topic with somewhere between five (or fewer) and nine links meets this criteria. The fewer links the better, however. The person who can only remember five things, for example, is likely to be a little overwhelmed when encountering a topic with nine links. As a guideline, any time you have two or more related links in a topic, gather them in a bulleted list. For many users, lists are more accessible than paragraphs, so skimming through links in a list will seem less overwhelming than seeing them in content. Another idea to keep in mind about links is that when you place them in a document, you're basically inviting the reader to leave the current topic. If you're creating a learning-oriented WinHelp document, as a result, you really need to think about when, where, and why you place the links. It might be that you'll want to "withhold" links by allowing access to them from a single place (for example, through a Related Topics button, as in the Windows 95 desktop help). At the very least, you'll want to make sure that every link in a topic directly contributes to helping the user to learn about that topic. Make context-sensitivity workThe most important thing to remember about navigation--that is, helping the user to move around and locate information in the document--is that users don't want to move around, especially in a help system. They're typically focused on "get in, get out." For this reason, the most important navigational path that you can develop is context-sensitivity--a direct path from the software to the appropriate information in the help system. If you do a good job with audience analysis, task analysis, and context mapping, all the user has to do to "navigate" to the right content is to press F1. However, interpreting context isn't all that easy, especially when users aren't currently in the "right" context for the help they need. If you're lost in the software and just wandering around, for example, the context point from which you're opening help isn't likely to be the right one for what you want to know. The onus for creating useful context-sensitivity is placed resoundingly on the WinHelp author. It isn't enough to do the rote work of relating topics to objects in the software. It's very important to understand what users need to see when they press F1. Typically, users want to do something, so they need to see step-by-step procedures. They may also be frustrated by some sort of a problem, so troubleshooting information is important. Field descriptions may be important, but they're most important at the field level (for example, the Windows 95 What's This? help). When a user asks for help on a topic, that person probably doesn't want to read about the fields in a dialog box. That person wants to know what to do. Create custom navigational systems (when it makes sense)Sometimes it just isn't enough to offer the navigational choices of WinHelp's built-in systems (such as Contents and Search in Windows 3.1 or Help Topics, Index, and Find in Windows 95). These navigational systems are directed toward global content (the entire help document), rather than in-context information. Sometimes your content requires the user to be able to quickly go to the information they're looking at right now. You can link to the information, of course, but what if you find patterns in the types of in-context information users are likely to look for? In these cases, it's a good idea to consider creating custom navigational systems (see figures 2 and 3 for examples). Custom navigation can be within the content (like the buttons in figures 2 and 3) or on the button bar. Some WinHelp authors even build iconic toolbars, such as you would see in software, to help users navigate among topics.
Relate windows to contentIn a WinHelp document, there's a fairly direct relationship between the type of topic (reference, task, example, or demonstration) and the window in which it appears. An example window, for instance, should always appear in the same place in relationship to the window it opens from. It should also always look the same way. For example, if you use an icon to represent an example in the main content, it's not a bad idea to repeat that icon in the example window--perhaps next to the title of the example topic. If this example window appears just slightly overlapping and to the right of the main window, it should always appear there. Figure 3 shows the layout of a window in an electronic newsletter. The first page of a regular column (Just Between You and Me) always has a column title at the top, a picture to the left, and a series of buttons at the bottom. The Go To button always opens a small window with a list of the sections in the content. The user can click the section he or she wants to read, or just click the Next button to go to the first section. The most important idea here is consistency. Visually and functionally, the windows should always work in the same way. Related to this, content with a particular meaning should always appear in the same type of window. Beyond WinHelpAs technical communicators, we understand that the time invariably comes when we need to put away the tools we know so well and start again with new technologies. Many of us have moved into multimedia and computer-based training for these reasons. But we also know that the tools we should have and those we have to use are often many a budget-cycle apart. My point is this: you needn't feel "stuck" with WinHelp. There's still plenty of opportunity for us to learn about online documentation by using WinHelp, skills that have less to do with the technology than with how we approach online documentation design. Design is something you create; and while a comparatively low-end tool like WinHelp can make authoring more difficult, technology should not affect the beautiful and usable online documents you can create in your minds. Transferring these ideas to your computer just means parting with a little time, sweat, and brain power. Where we get that is, of course, another story.
|
Return to . . .
[News & Views]
[STC-PMC Home]
[STC Home Page]
Last updated: November 8, 1996 (rst)
