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.
One mantra that we continually chant is “Write tightly. Write tightly.” Tight writing and proper streamlining not only makes documentation easy to read, it can help make it more usable.
If you’re interested in making your writing tighter, read this article. It contains several useful tips on how to effectively edit your work. Once you internalize this information, you’ll find that you will automatically apply the principles.
Do you find yourself scratching your head when you run into software error messages? And, as a technical writer, do you want to do your bit to make those messages more meaningful? Read this article for some great tips on crafting meaningful and effective error messages.