An essential part of a software technical writer’s toolkit is a screen capture program. This article is an excellent review of some of the most popular screen capture tools available for Windows. The focus is on commercial screen capture software. There are, however, a handful of good free applications too. One of our current favourites is FastStone Capture.
We have to disagree with the author referring to a screen capture tool’s lack of image editing capabilities as being a weakness. For us, screen capture software does a specific job. It doesn’t need to be anything else. If we need to edit an image, we’ll pull it into a program that’s designed for image editing.
Technical writers often walk a tightrope. Our job is to make the complex simple, or at the very least simpler. Many times, though, technical writers (either inadvertently or not) make things too simple. This, in turn, does their audience a disservice.
Here is an interesting article on the difference between dumbing something down and making it easy to understand. It was written with Web developers in mind, but the article is also a good read for technical writers.
Yes, we’ve decided to take the leap and produce a weekly podcast aimed at technical communicators and the people who employ them. The first edition of the podcast will be available on December 4, 2006.
Watch this space in the coming days for more information.
Writing the documentation for a software development kit (SDK) has been described as “technical writing on the edge.” To do a good job, you need a knowledge of one or more programming languages and the writing skills to communicate the use of those languages effectively. We’ve written a few SDK guides and can attest to the challenges involved in preparing them.
But writing SDK docs isn’t an impossible chore. This article breaks the process down to 10 easy-to-follow steps. The article is short, but offers a lot of excellent advice. You won’t become a master SDK writer simply by reading this article, but by following the advice you’ll get off to a good start or become a better one.
Technical writers go by a lot of different names nowadays. Many us of like to be called “technical communicators.” Whenever someone asks us what a technical communicator does, our facetious answer is “We write the manuals that no one reads.” The serious answer, though, is that technical writer communicate information vital to someone’s proper use of software, hardware, device, or gadget.
But there’s more to it than that. And this article offers one of the better explanations that I’ve read of what a technical communicator is and does.
If you’re a technical writer, then chances are that you have to create online help. And that’s where the fun begins. You need to choose the tool that’s right for your purposes, which can be a tough task.
This article (and its follow-ups: here and here) offer a nice overview of the available help authoring tools out there. You get the major pros and cons of a number of applications, from the big guns — like Flare, RoboHelp, and AuthorIT — to lesser-known tools — like ReWorx and HelpNDoc.