News & Views Feature Article
|
What
Is Embedded Help? A Simple Idea, Really News & Views Feature Article |
|
By Cheryl Lockett Zubak Cheryl Lockett Zubak is president of Work Write, Inc., a consulting firm that specializes in the design and development of user assistance for the Windows and web platforms. A senior member of the Philadelphia Metro chapter, Cheryl is a charter member of the Microsoft HTML Help MVP program, and was voted "All Time, All Around Help Guru" and "Best Teacher or Instructor" at the 1999 Help Authors Choice Awards. Originally published in News & Views September 1999 issue. Copyright 1999 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor. |
Embedded help is user assistance that is part of the real estate and functioning of the user interface of a software application, rather than a separate window that floats (often to our dismay) above, and sometimes behind, a software application. It’s help that is designed as software. Not as an afterthought. Not as part of a separate development effort. But as part of the same development, indeed part of the same code, as the software application itself. Simple, right? Like most technology issues in the web age, the idea may seem simple—I might even argue that it’s crucial—but the implementation and design issues that surround it are less so. But we’ll come back to this after we take a little deeper look at what embedded help is. That right embedded help pane What most people think of as embedded help is a help pane that takes up the right side of the application window. It has many of the same attributes as a nonembedded window—for example, it may have a table of contents and familiar types of navigational mechanisms—but unlike traditional help it has a fixed place in the interface. Perhaps the most well-known recent example of this design is the help for Microsoft Money 99 (see Figure 1).  Figure 1: Help for Microsoft Money 99 depicted in right window A help system like this makes use of what I call stationary embedding—help that is intended to create an always available space from which the user can seek help, and which documents the interface as the user is looking at it, even before the user has performed any significant actions. The Money 99 help system opens in an embedded window on the right side of the application window. The Money team chose to customize this window to match the rest of the Money interface. In addition to a custom toolbar, table of contents, and index, the help system also uses the Microsoft natural language query engine instead of a full-text search. While the result doesn’t look much like the standard tripane window that we see in, say, the Windows 98 help system, the Windows 98 and Money help systems both use HTML Help technology for the content. Now back to the right pane issue. Because a right help pane like the one we see in Money 99 has become one of the most recognized embedded help designs, it has come to represent embedded help entirely in the minds of many help authors. This is ironically the case, since the Microsoft Money interface is full of embedded help, and only a small portion of it resides in that right help pane. If you look again at Figure 1, you’ll see that much of the interface uses help text that orients the user to the interface and adds to the user’s understanding of the subject matter of the application (domain knowledge). The most obvious of these is the Q&A on the left. But open a dialog box and you’ll see more: instructions, tips, option descriptions, and so forth (see Figure 2).  Figure 2: Help instructions embedded in a dialog box Stationary embedded help, like the user assistance we see throughout the Money interface, is great for creating what I call "hands off help design": that is, help that doesn’t require the user to constantly resize and move the help window so they can use the help and the software at the same time. Since the help is designed as part of the interface, the programmer and help author have already resolved these issues for the user. Help embedded in process Providing help as a visible part of the interface isn’t the only way of providing embedded help. Some help is embedded into a process—that is, it is evoked when the user takes a particular action or, in some cases, fails to take an action. A familiar example is backing up your checkbook with Quicken. When you choose to back up, a message box briefly sets the context of the process, tells you to place a diskette in the drive, and recommends that you alternate between two diskettes in case of a problem with the media (see Figure 3).  Figure 3: Help instructions embedded in a message Process embedded help, as I call this type of embedding, is also useful for walking the user through a process. An often-cited example of this in performance support circles is Microsoft Publisher, a desktop publishing system for the home user. Publisher uses a wizard-like interface to guide the user through the process of creating a document (see Figure 4).  Figure 4: Help embedded in a wizard provides user feedback As the user moves through the wizard, the document is updated so that the user gets immediate feedback at each step. The user can also depart from the wizard and just dive into the document at any point. From a design standpoint, it’s important to point out that help embedded into a process doesn’t need to be in that stationary right help pane we saw with Microsoft Money. Instead, it can be evoked much like any context-sensitive topic: what’s important is that it opens and updates as the user goes through a process in the software. In fact, it may even guide rather than follow the user through a process. On the other hand, it’s possible to provide process-embedded help in a stationary window. Imagine, for example, providing a right-hand help pane in which the content updates when the user moves from function to function in the application. (This could, of course, become distracting, so the user needs to be able to close the help window). Microsoft Publisher, by the way, also has a nicely designed stationary embedded window that has some similarities to Money’s help system. Embedded help that instructs Embedded help may also be primarily intended to instruct the user. The goal of instructional embedding is to teach the user about the interface or add to the user’s domain knowledge. As a result, it should be something that the user can control (e.g., turn it on/off or change the level of instruction) to avoid irritation. Like process embedding, instructional embedding may be built into processes, although it may be an option that the user explicitly chooses. As an embedded system, however, it should be evoked by the software, not just opened at the user’s request. Suppose, for example, that you’re a new help author who’s working on creating a help system, and you open a page that has a lot of text in it in your help authoring tool. Suppose when you do so, the authoring tool opens a design tip like the one in Figure 5.  Figure 5: Help embedded as instructions This design tip informs you about issues of topic length in online help systems, asks you whether or not you want to see this design tip again, and then offers to assist you with modifying the file (e.g., by creating a new HTML file where you can revise the text). You might argue that the intent of instructional embedding is very much like computer-based training. I’d agree: it’s very granular, highly contextual computer-based training that’s evoked when the user performs actions that may require advice or correction.
The goal of embedded assistance is to drive assistance into the application, and, in fact, to design the application so that it offers assistance when, where, and in the manner it’s needed. The degree to which embedded help drives assistance into the interface can vary significantly: by changing the interface itself, by providing information at the point of need, and by offering information—whether requested or not—that assists a user in learning, troubleshooting, and other situations. Because of these goals, embedded help is an aspect of performance support (EPSS). The examples we’ve looked at in this article show embedded help that looks, in most cases, quite similar to the online help you may already be creating. The difference—and this is crucial—is that embedded help is a planned aspect of software development. The help is physically combined with the software, because it is the software and because it is evoked from the software. Since embedded help is software, and it’s capable of performing both simple and complex actions, an embedded help system won’t necessarily result in opening some sort of help topic. For example, imagine choosing a procedure from an index or table of contents to start the initial software action for a process (e.g., opening a dialog box) or perhaps having a "character" guide you to the right place in the software to begin a task, while giving you the option of both beginning the process and learning about it. These may both be examples of embedded assistance. In fact, some of the more advanced types of embedded help that we don’t cover in this article actually open software, not textual help, when the user needs it. Figure 6 shows an example from KeyTools, a freeware set of utilities developed by my partner, Ralph Walden, and me. In this example, the user has compiled an HTML Help system, found an error, and clicked on a description of the error. At the bottom of the description is a button that says Fix It. When the user clicks this button, the software repairs the error condition for the user. (This, by the way, is called agent embedding.)  Figure 6: Agent embedded help Is embedded help difficult? Yes! Developing embedded help systems is more difficult than creating a traditional help system. But among the reasons for the difficulty is a learning curve: it’s new to us and we don’t have as many examples of it as we’d like. Practical-minded people that we are, help authors need to see design examples, and we need code examples that show how it’s implemented as part of the software to share with our programming staffs. For design ideas, we can look to examples like those I’ve discussed in the article as well as to the performance support community, who have been working on embedded assistance for some time. Code examples and tools are harder to come by, but you’ll find the beginnings of a list at http://www.helpmatters.com/tools/ etools1.htm. Embedded help is also difficult because it requires help authors and software developers to form new working relationships. Help authors who want to develop embedded help systems need to become part of the development team from the beginning of the product design. In some organizations, this is already a trend. In others, it will require you to break ground with development teams and work out new processes for working together on software development. If it gives you any hope, I remember writing about many of the same difficulties when context-sensitivity was first introduced. Although it’s more than a decade later, context-sensitivity is now something that we take for granted, both in terms of our expectation that development teams will endorse it and in our understanding of how it should be done. Finally, developing embedded help is more difficult, but also more crucial to developing good user assistance, because it requires close examination of who the user is and what he or she is doing when using your product. Developing embedded assistance requires you not just to acknowledge this fact, but to act upon it. Of course, this has always been a critical and difficult challenge of our work. Selected sites to visit
|
Return to . . .
[News & Views] [STC-PMC
Home] [STC Home Page]
Last updated: October 10, 1999 (psw)