The other day one of our genius developers (I think his official ranking is Jedi Knight) asked me why we don’t provide the product documentation on a Wiki. I answered him stating that it was because I wasn’t allowed. That’s not strictly true.
My answer should have been that, quite simply, I’ve failed to provide a good enough reason to my boss (and my bosses boss) as to why that may be a good thing.
And the reason I’ve failed to do that?
Because I’m still not 100% convinced that it is a good solution for our product.
What is more likely is that, if we do decide to embrace Wikis (we haven’t managed blogs yet, but that’s another issue) we take a split approach and offer a knowledge base style information centre (something like the Author-it Knowledge Center) and host a Wiki as a way of capturing and sharing what I refer to as ‘grey information’.
It’s this latter set of information which, whilst it has always existed, has never really had a place to live until the internet came along. These days all it takes is a quick internet search and you’ll find masses of information, all generated by the users. Some of it is useful, hints and tips, ways to workaround product limitations, and clever uses that were never thought of by the manufacturer.
To me, that user created content is where Wikis hold their true power and finding the balance between that content, and the content provided by my team is still something I’ve to get my head around. Ultimately the argument (business case) for investing in the creation, maintenance and policing of a Wiki needs to be focussed on how much value we will gain (ROI).
On that basis it shouldn’t be a hard business case to put together, the tricky bit is making it such a compelling argument that it moves to (close to) the top of the list, and that will require a lot more discussion around why embracing Wikis, and blogs, will stand us in better stead in the future.
The editor in me dislikes wikis for technical content. Obviously wikipedia is an amazing success, but I think that has to do mostly with enabling the behind-the-scenes discussion.
But for whatever reason, people are comfortable with the wiki interface.
If I was putting together a documentation team, I would definitely argue for personal be devoted to online/interactive media. That person would spend a large portion of his or her time maintaining a wiki when demand is there.
What is crucial in my mind is that wikis must be edited/maintained. And like you note, businesswise, this requires resources.
Maintaining a wiki and maintaining a blog (or forum) are clearly different tasks because the wiki can stand as documentation (or a part of it), while a blog/forum requires more user-oriented, a.k.a customer support, interaction. So I would make it a priority to explain to management the differences between the two.
I like the idea of a wiki (Confluence ideally) but our products are for the packaging sector and it seems that many of our readers do not have internet access at work. I also can’t get my head around how to integrate one with our Authorit workflow.
Just as well really because we have no budget or resources for it.
J
For the last 2.5 years, I worked with a conglomerate of scientific institutions. The developers wanted us to scrap our traditional manuals and online help and put all of our documentation on a wiki. For many reasons mentioned here (e.g., resources, management, maintenance), we never made the transition.
The problem was that the wiki advocates didn’t perceive moving our documentation to a wiki as a significant change. In their view, we would simply post the docs on the wiki and point links to them. No one understood that we would need to fund and staff a full-fledged project to plan the design and architecture of the wiki, develop a strategy for converting content from FrameMaker and ePublisher, and maintain the wiki. (Yes, despite the “build it and they will come” belief, someone has to take the lead.)
I have attended a number of presentations on wiki docs and have talked with people who have made true strides in implementing them. I have also participated in a FLOSS Manuals project and have experienced how the organization extended a TWiki for publishing. My impression is that the most successful projects required dedicated software developers to enhance the effort with customized programming. So there’s yet another resource layer.
I have a couple of posts on this subject:
http://www.vanarsdall-infodesign.com/2009/03/11/words-to-wiki/
and
http://www.vanarsdall-infodesign.com/2009/03/27/words-to-wiki-part-2/
Cheers,
Eddie
I think it’s sad that Technical Writers aren’t up to snuff on this excellent technology. Whenever the word Wiki gets mentioned, someone immediately pipes in with Wikipedia as a prime example of a wiki, but I don’t think that’s accurate. A Wiki can be made as secure or as simple to update as the developer wishes. Editing capability can be extended to as many or as few people as necessary and access can be made secure, with logins, if required. Behind the firewall, anything is possible with a Wiki. It is a documentation nirvana.
Just because it’s a wiki, doesn’t mean you don’t control the content. We provide our online help via MediaWiki, and it’s set up as read-only for everyone, except contributors. It works very well for us.