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.
Unless you’ve been living in a cave over the last couple of years, you’ve no doubt realized that the the ideas and concepts of Web 2.0 (I hate that term, don’t you?) have leached into the world of documentation. Online help and manuals still exist, but they’re now supplemented product blogs, wikis, and user-generated documentation in forums and on the wikis.
All of this seems like a great boon to the technical communicator. Once the documentation for a release has been finalized and locked down (as a help system or a PDF, for example), wikis and forums and blogs and podcasts can be used for updates and errata, as well as to present real-world scenarios, troubleshooting tips, and any other information that might not fit comfortably in the mainline documentation.
A number of companies of many sizes have thriving user communities and developer/product blogs — two good examples of this are MySQL and Splunk. Of course, the users of and contributors to this type of documentation are usually quite tech- and Web-savvy.
It’s no secret that I’ve been eagerly awaiting the release of MadCap Blaze for … well, for a long time now. It looks like the release will be happening sooner rather than later — sometime in March or April.
Last week, my colleague Keith Soltys took part in an online demonstration of Blaze. Keith’s written a lengthy and detailed blog post about the demo. If you’re wondering about whether to take in a demo, or if you aren’t able to, then Keith’s write-up is definitely worth a read.