Like them or not, wikis are becoming more and more common in various enterprises. And they’re not just a developer’s tool anymore. They’re used fairly extensively for documentation, too. The beauty of wikis is that they’re easy to use and that they’re living documents. The content on a wiki is constantly being updated and (you hope) refined.
The dynamic nature of wikis, though, can cause a few headaches when you need to baseline documentation that’s on a wiki to correspond with the release of your product. That’s the problem that we ran into at the firm at which I’m working right now.
A couple of days ago, I was trying to catch up on some online reading and went over a series of posts, titled Technical Writing in Transition, at Chris Borokowsi’s User Advocacy blog. If you haven’t read these post, you should. They’re interesting, detailed, and they get right to the point.
Often, it’s hard to put a value on documentation. As mentioned in a previous post, the value of documentation isn’t in the money that it brings in but the money that it saves. Of course, you often have to justify that value to the powers that sign your cheques. To do that, you must show a return on investment (ROI).
This blog post outlines two interesting ways in which you can attempt to measure the ROI of documentation and training.
Anyone who knows me will tell you that I’m an avid user and staunch supporter of free and Open Source software (FOSS). I could list all of the apps that I use, but that would be a lengthy blog post in itself.
There’s a lot of great FOSS software out there. But one area in which it’s lacking is professional-level help authoring tools. In 2005, Linux.com published an article titled “FOSS help authoring tools falter“. And not much seems to have changed in the intervening years.