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.
Do more with less. That seems to be a popular mantra of modern business. When Aaron and I toiled at The Company That Shall Not Be Named, we were incredibly constrained by a number factors. As mentioned in a previous post, the documentation department was part of the sales organization. We were expected to make money, but since we didn’t our budget was tiny. To say the least.
Be like an empty cup. That sounds like something out of a martial arts melodrama. Which is probably where I lifted that nugget. Regardless of how hokey it sounds, it’s good advice in any career. And especially in technical writing.
If you’ve ever printed a Web page or a portion of an online document (don’t deny it, we all have), you’ve probably noticed that in many cases along with the text you get other superfluous page elements like navigation and ads. They can take up a lot of space, and cause the text on a page to wrap badly.
It doesn’t have to be this way, though. Cascading Style Sheets (CSS, which enable you to change the look and feel of Web content) also enable you to style documents for printing. Using CSS, you can change the layout of a Web page and leave out any content — like navigation or even graphics.
Doing this is pretty easy. The following are good introductory guides on how to work with CSS for printing:
Even if you use an authoring tool that automatically generates printer-friendly CSS, the content of these articles is useful if you ever need to modify the CSS code.