TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Looking at the WIKI entry for EPSS, I see a desire to focus on specific tasks, and be able to provide procedures for each task a user could need for a given application or set of applications. I tend to think that's not even possible... It's like documenting a language by providing an example for every possible sentence. For initial exposure you need to learn specific didactic procedures -- sort of like an initial phrase book. But there's a point where you need to learn the grammar and vocabulary.
But there are good ways to aid tasks. You should look at walk-through documentation. Drupal has a walkthrough module, and I believe there are companies out there that provide software to create these. The idea is that you choose a procedure, and the GUI displays flags (tags??? balloons???) that show where to do each step, and give whatever explanations you want.Â
In our product we use progressive disclosure... Tooltips, content on the GUI surface, overlays you can invoke for each panel of the GUI, and full online doc. I'm a big fan of keeping content as close to the GUI as possible, and giving the user avenues to take that gradually lead away from the GUI as the content becomes more abstract/conceptual.Â
Our help system performs dynamics in the client, at the last minute. So we can get information about the state of the user (role, for example) or the product (execute API calls), and modify the docs accordingly. We haven't had a chance to experiment fully with this -- I imagine that we could look at the product and provide in-depth descriptions of the current state -- not just WHAT the state is, but WHY. But that's a question of time to experiment. Another thing we can do is merge remote documentation. As our product begins to incorporate remote components, the docs can sit with those components and be merged if you are a user with access to the given component. And we can also merge content from remote sites like our social web... Search can include hits from the forum, and if I wanted to I could incorporate content from forum posts.
I think content delivery is on a threshold of change. The network is becoming much more dynamic than ever before, and doc delivery has to keep apace. So you're doing the right thing by asking about this and looking for possibilities beyond the usual.Â
BTW, the age-old response... "What do your customers USE for docs?" isn't quite appropriate. The question is, what do your customers need in order to future-proof their experience with docs? If they already had it in their hands, then it would probably not be appropriate for the next wave of technology. My opinion, anyway...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
