I don’t have to tell you that topic-based writing is a very popular idea in the world of technical communication. And with good reason: it can help make writing, managing, and assembling documentation a lot easier.
But you can apply topic-based writing to work outside of our profession.
As you may or may not know, I do quite a bit of freelance writing. And sometimes, I have an idea for a non-fiction writing project, but am only able to chip away at it bit by bit? That sometimes feels like it happens a bit too often.
I also find that with projects like that, I write in bits and pieces — a few sentences or paragraphs here and there — and never get anything finished. I have chunks of writing, but can’t really pull them together.
Yes, that’s where topic-based writing comes into play. It can help you pull together all those chunks of content that you’ve been pecking out into something tangible.
Have I got your attention? Then read on.
This one comes under the banner of Getting back to basics …
For those of us who do it for a living, writing is a way of paying the bills. But writing is, first and foremost, a method of communication. It’s putting thoughts and ideas and opinions out in the wild. How you do that is as important as what you want to say. If you don’t do the job properly, you’ll quickly lose your audience and your efforts will have been wasted.
How do you do the job properly? Here are a few thoughts.
I have to admit that I find the book Writing in Bullets to be quite valuable and useful. It’s a good guide to writing concisely, and for using bullets effectively. Unfortunately, over the last few years I’ve been seeing bullets used to replace crisp, well-thought-out writing.
And that’s forced me to think about 1) how bullets should be used, 2) how bullets are used, and 3) how I use them when writing.
A warning before we begin: I’m sure that this post is going to cause a bit … well, if not controversy then a bit of contention. That’s OK. I’m used to it. Understand that my definitions and perceptions of many things are filtered through my experiences.
Enough of that. On to the post …
I’ve often said that editing is the secret to good writing. And I really do believe that. As someone who once made a precarious living as a freelance editor, I helped improve the writing of my clients with a few tweaks. Well, sometimes more than that. In some cases, a lot more than that. And as a professional technical and freelance writer, I’ve seen my own work improved at the hands of a good editor.
Editing, like writing, takes on several forms. Two of the most common are copy editing and editing for content. They are different, although not everyone understands the difference. There was a time when I didn’t!
Let’s take a closer look at what I see as the differences between these two types of editing.
Recently, I ran a FLOSS Manuals book sprint to update a manual for the Thunderbird email application. If you haven’t heard of a book sprint before, the idea is quite simple: spend anywhere from two to five days writing a manual or book from scratch. Yes, it can be done!
In this case, the sprint was to update the manual for Thunderbird. There were a number of changes to the software in the year or so since I was involved in writing the original manual. But due to a number of constraints — both personal and professional — I could only devote one day to the sprint.
Obviously, there was a bit of planning involved. I gathered together a group of participants (mostly in Toronto), found a venue, and working with the folks at Mozilla (who created Thunderbird) came up with a list of changes that needed to be made. That involved pinpointing the relevant changes and making a list.
Afterwards, I was mulling what made the sprint successful. Part of it was the planning. The process that I used was very helpful. And you can apply it to any group writing project.
Let’s take a closer look at what I did and how it worked.
Throughout my career as a technical communicator, I’ve never documented consumer software or devices. My work has always focused on enterprise applications. Even when I did write documentation for PDA software or for the Blackberry, it was in the context of the enterprise.
Which is why I’m fascinated by the documentation that comes with consumer items. Most of the time, that documentation doesn’t do anything for me. It’s not that great. Or, it just doesn’t grab my attention.
Sometimes, though, that attention isn’t just grabbed it’s held on to. Not too often, but often enough.
That happened recently, and got me thinking about some implications for technical communicators.
Curious? Then please keep reading …