The EPSS Movement -- What It Means to You
News & Views Feature Article
|
|
Electronic Performance Support Systems The EPSS Movement -- What It Means to You News & Views Feature Article |
|
by Craig Marion
Copyright © 1998 Craig Marion. Craig Marion manages documentation and usability for Strohl Systems in King of Prussia. His web site, the Software Design Smorgasbord (WR20), features a version of this article with hot links and is the platform through which he plans to continue to explore the challenge raised in this article. Browse by if you're interested. Craig can be reached at cmarion@chesco.com.
Originally published in News & Views May 1998 issue.
For permission to reprint this article, contact the Managing Editor.
|
Performance support is anything that helps workers perform tasks. In the software industry, three types of performance support have become institutionalized: training, documentation, and help desks. These three institutions arose because so much software is so difficult to use. It requires lots of training, documentation, and phone calls to specialists. A movement that's acquired the awkward name of Electronic Performance Support Systems (EPSS) has developed a vision of the next stage of software development that challenges this software and these institutions. EPSSs are sets of tools that effectively automate training, documentation, and phone support; integrate this automation into applications; and provide support that's faster, cheaper, and more effective than the traditional methods. EPSS proponents argue that training is forgotten, documentation is ignored, and help desks are unnecessarily expensive. Develop an EPSS instead, they encourage, and the whole organization profits. In this article--in addition to explaining what EPSSs are and pointing out where you can learn more about them--I'd like to clarify a challenge that the EPSS movement poses to the field of technical communication in general and to the specialization of information design in particular. In situations where the scenarios I allude to in the conclusion take place, our individual responses to this challenge may have a bearing on both our jobs and our job prospects.
Deconstructing EPSSs How is this magic performed? By clarifying and simplifying tasks, creating interfaces that are clear and obvious, and providing various support tools and granularized information--often in redundant formats to suit varying learning styles and preferences. Key phrases that recur in an EPSS context are "just in time," "just enough," and "at point of need." And it's all integrated into an interface that reflects workers' own understanding of their work and the language they're accustomed to using. This past February there was a discussion on the epss.com! forum on whether the EPSS approach is, or should be, methodologically unique (web reference--WR11). There was no consensus. Nor is there consensus on what the components of an EPSS are. Gloria Gery analyzed ten examples of EPSSs in her seminal portrait of the field (1991). Since then, a number of similar analyses have been put online. Bill Miller's "A System Design Model for an EPSS" (WR12) and the performance support system that Comware built for Martin Marietta Energy Systems (WR13) are both good illustrations. An early and often cited deconstruction (Carr, 1992) presented four basic components of an EPSS:
At this end of the decade, there seems to be no consensus on the components of an EPSS. A focus on the concept by a mainline computer journal last year presented a number of differing examples (CACM, 1997). Yet there remains an element of commonality in the various approaches. To this end, I find the model presented by Bill Miller instructive. In his article, "EPSS: Expanding the Perspective" (WR15), Miller describes an EPSS as software that improves performance by
I find it useful to consider the elements of an EPSS in a manner similar to Miller's. We might say that an EPSS has three dimensions. The first is the base software interface. The second is a layer of add-ons that enables users to perform more complex tasks--that cannot be represented intuitively in the base interface--quickly and easily. And the third is a parallel layer of add-ons that organizes work (domain) knowledge and best practices, modularizes them appropriately, and integrates them with the performance of tasks. I think it's useful to label these three dimensions
Performance Support is scaffolding on top of the base user interface that helps workers use the software. Online help qualifies, but in the context of EPSS the term generally refers to more automated assistance. Microsoft's wizards and Show Me help are good examples. Wizards structure a path through a task by giving users clear choices on successive panels. Show Me help doesn't list steps; it demonstrates tasks. It walks you through making menu selections, brings up windows and dialog boxes, and illustrates appropriate choices. Performance support assistance in completing software tasks sometimes, but not always, enables workers to get their essential work done. Consider the work of a clerk using software to check a guest into or out of a hotel. If performance support assistance is provided, it guides the clerk through the use of the software and completion of the work at the same time, because the two are coextensive. But consider the task of writing a letter. Assistance on how to do formatting would be performance support. But what if a company decides that its workers need assistance on what to put into the letter? This is beyond the realm of using the software tool--of performance support--and calls for something more. Knowledge Support is that something more. Knowledge Support deals with assistance in performing knowledge-based work. It incorporates domain knowledge. Ideally, it's integrated with both the base interface and performance support. TurboTax provides a good example. On its Help display, a tab called Program Help provides performance support. Other tabs, beginning with Tax Help, provide knowledge support. EPSS strives to make knowledge support more automated--and interactive--too. Popular vehicles are expert systems and decision support systems. Multimedia, such as video explanation clips that come with the deluxe editions of Quicken and TurboTax, and developments using the web present many opportunities for knowledge support.
The challenge to information design We're at a juncture now where the bar is about to be raised again. Gloria Gery's classification of three types of information support illuminates how.
It used to be enough to organize information within books--external to the work flow. Then we modularized this information, hyperlinked it, made it visual and interactive, and built online help systems. This made it more quickly accessible. But it's still largely extrinsic: it has to be sought outside the normal work flow, and many users don't seek it. The challenge now is how to make the information we deal with intrinsic to the work flow. The problem is, we don't have models for this. The book model, whatever its virtues, places information external to the work flow. The WinHelp model gives us an easy way to make information extrinsic, but doesn't help us much beyond this. Both of these models--however well organized, formatted, chunked, and hyperlinked--are document-centric. The challenge that EPSS raises for information design is: what are the models for integrating information into the user interface? How do we make information intrinsic? One thoughtful analysis that addresses this challenge directly has been made by online help expert Cheryl Lockett Zubak. In a presentation on "Embedded Help" (WR16) she gave at the 44th STC Conference in Toronto last year--and has updated and will present at the 45th conference in Anaheim this month--Zubak classifies three approaches to embedding help into the user interface. Stationary embedded help is designed as a visible part of the user interface. It works pretty much the same way as standard WinHelp, but it's more easily accessible. Microsoft Works 4.0 help is one example. Bill Miller's Interactive Guide (WR17) is another (Figure 1).
Process embedded help is driven by the objects and processes in the application. It can be context-sensitive help that is updated automatically, or bubble help explaining commands as you explore them, or help buttons built into steps. Often it's granular and integrated into the interface. The combined help and wizard in Microsoft Picture It! (WR18) is a one example. Bill Miller's Interactive Guide (Figure 2) is another example of this as well.
Context embedded help is tightly integrated with your actions and often interprets the help you need based on them. Microsoft's Office Assistant is one example. Another is a coach that a team I'm currently working on has recently developed (Figure 3). It accompanies workers through a product and provides both performance and knowledge support. This coach also provides navigation support through a complex software product and keeps track of users' accomplishments.
These models are not exclusive. Zubak contends that the best embedded help uses all three, and that some types can be embedded in others. Her typology provides a strong beginning towards understanding how information can be made intrinsic. The larger challenge to information design, however, is to take a broader view of information and examine all forms of user assistance. How do we analyze and catalog the integration of performance and knowledge support into user interfaces? How do we determine what works and what doesn't? And what principles and guidelines can be extrapolated to assist technical communicators in integrating user assistance more effectively?
Conclusion As this perception reaches the mainstream it will have organizational consequences. On the one hand, it will be used as a justification for cost (i.e., job) cutting. On the other, it will promote the breakdown of silos, engender new cooperation, and result in teams capable of creating better, more usable software. What can we, as technical communicators, do to prepare ourselves? Mary Deaton, another online help expert, seems to me to have a good answer. I want Help developers to become performance analysts. I want user assistance for any product, mass market or otherwise, to look and feel like part of the application and like each other. I never again want to see an online piece of user assistance that is not intimately linked to every other piece of user assistance for that product. Let's stop fixating on one tool (i.e., Help - C.M.) and fixate, instead, on what the people who use products need to succeed. (WR19) The point is, as the online world morphs onto the web, many of us are going to be involved with, and challenged to create, integrated approaches to user assistance. The more proactive among us may want to learn more about EPSS. It's been scouting and blazing the way for a decade.
Print references
Web references |
Return to . . .
[News & Views] [STC-PMC
Home] [STC Home Page]
Posted June 5, 1998 (dls)
