Listening to Paul Mueller now, talking about using wikis for user assistance.
Some interesting ideas early. Notes that not all users are online, some prefer docs or "traditional" help. Also noted that communites can be good, but kind of a "wild west" (my term), there users have to look through many posts to find answers, and responses that interate over potential solutions.
The benefit of a wiki is it's collaboration on one common solution.
Wikis can also create a collaborative environment with tech support, who would previously opy content from help and put in KBs. Then, when a new release came out, verifying that duplicated content might by bypassed because of no time. But you need a community here, both ecgternal *and* internal, including tech support and members of the engineering staff (well, in addition to you, of course, because technical communication is properly an engineering discipline too).
Paul says that our jobs will be less about delivering content, but about delivering a structure for content. Users work with us as partners to extend and enhance that knowledge.
They used the ePublisher platform, by Quadralay.
Delivering different media (help, online, etc.), so have to decide what information goes where. Wiki will be "latest and greatest" content. If you don't go to wiki, and look at local content, you have what was known at the latest release.
Wikis do have weak areas. Out of the box, wikis don't have navigation. Content appearance can be less polished. verified and "extended" content is difficult to tell apart.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment