"To launch the holographic virtual assistant module, press F1 now and move three steps to the left of your terminal."
Ok, I'm willing to admit that the above scenario is more likely to appear in a lousy science fiction novel than in the homes of actual computer users, at least in the near future.
But, help is changing.
The question is, how should help evolve so that best meets the needs of users?
The Dr. Frankenstein approach to building help
Software, like humanity, progresses in bursts. It leaps forward, stumbles back a step or two to catch its balance, and swerves sideways to adjust for environmental hazards. Often a software release is less reliable than a previous version. Sometimes a release includes features that no one really uses. But, over time, the software gradually improves as developers gather more and more information and feedback from users.
Help authors can see this need for direction and feedback by taking a look at popular user-assistance delivery models and the latest help authoring tools.
The RoboHelp Packager for Adobe AIR, for example, is betting that "help as a separate application" will continue to meet the needs of users, if the platform features are robust and user friendly. AIR help offers user-selected favorites, comments, tabbed browsing, automatic updates, and more. If the Adobe team can get enough users to install the AIR plugin, or enable AIR help to run on a server (thus negating the need for users to have the plugin), I'd be willing to bet on the future of AIR help. My initial experience with the format left me quite impressed.
However, others preach the benefits of embedded help. By placing help content within the interface, technical writers can offer assistance that is less intrusive and easily associated with the appropriate context. Hmmm... this sounds like a great idea also.
Given that embedded help and "help as a separate application" are practically opposites, how do we plan for the future and reconcile such differing approaches?
Perhaps a blended approach would work best, with embedded help serving as a front line of defense and a more-robust help system offering more detail when necessary.
But the only way to really know is to gather more feedback about how users access help. This requires time for usage data to accumulate, and...
Ubertools (and the implications thereof)
Many tools are emerging to provide the kind of feedback help authors need to best serve users.
Slick applications like the RoboHelp Server Engine and Google Analytics offer the ability to track how many users are visiting individual pages of help content.
Help topics in MS Office applications share a common element at the bottom of the text: a feedback form. Users can tell the technical writers in Redmond exactly what improvements they'd like to see in the help. With a bit of server-side scripting and a fancy HTML form, you can build such a feedback form for your help topics. (Not much to it; in fact, most of the code is freely available on the web, if you know what to look for. The scary part is what happens after the form is enabled and you prepare to read the comments!)
These and similar tools are opening the doors to direct two-way communication between users and technical writers. When this happens, help authors will have one less excuse for providing help that simply misses the point.
Now that usage data and feedback are possible, the real question becomes...
...how do we make sense of it all, and turn that data into a help format that is user friendly and allows help authors an efficient workflow?
Time will tell.
Until then, I'll continute to drool over AIR help, dabble in home-brewed ASP.NET enhancements, and listen to more Tom Waits. ("Rain Dogs" is a killer album.)
If you enjoyed this post, check out Technical writing unchained | A custom approach to building help.