Because I don’t jump all over the latest trends and tools in the tech comm world, I sometimes get labeled as old school or as a dinosaur. And that’s one of the nicer things that’s said about me …
It’s not that I’m afraid of technology or of change. That just bad thinking, pure and simple. But I do take a measured approach to just about everything. Simply because a new tool or technique promises to make my job easier, to write documentation by itself, to make me more charming, and brew me a perfect cup of green tea doesn’t mean I’m going to swallow those promises whole. I like to investigate. And, for the most part, those promises have fallen short. Sometimes far short.
Take, for example, screencasts. I like screencasts. I’ve used them. I’ve recorded them. I’ve written about them in this space (use the search box in the top right if you don’t believe me). But, like anything else, screencasts have their strengths and their limitations.
Anyone who writes for a living has been hit by writer’s block, or something like it, at one time or another. That includes technical writers, too.
What do I mean by writer’s block? A mental log jam. Acertain mental paralysis that stops us from putting words on the page, from developing effective procedures and diagrams and overview information. It’s frustrating and can be worse than annoying.
Over the years, I’ve had a few bouts of writers block in one form of another. Thankfully, each of those bouts weren’t incredibly bad but they were enough to put a dent in my productivity and to jeopardize a deadline or three.
I’ve tried a number of things over the years to get around writer’s block. Some worked. Most didn’t.
Last weekend, I was in Cincinnati, Ohio for the Open Help Conference. Organized by Shaun McCance, it was a three-day event bringing together people who work on open source or community-based documentation and support.
The conference lived up to its aim to be a cross between traditional conferences and open discussion and participation sessions. The atmosphere was informal, but the participants were serious about the subject matter and (I think) they had a lot of fun.
While there were just under 30 participants, the diversity of that group was something to behold. You had people involved in professional Open Source (there was a large contingent from Mozilla, for example), contributors to various Open Source projects, and a couple of non-Open Source technical writers.
And they came from all over: the United States, Canada, Europe, and Australia. That diversity gave the presentations and discussions quite a bit of depth.
Here’s a quick recap of what happened at the conference.
To be honest, I’ve liked Google’s documentation for some time now. Not only does it seem to try to conform to the 5 Cs (clear, complete, consistent, concise, correct), it’s laid out in a simple, readable form. There aren’t too many frills, and those frills aren’t always in your face.
Over the last little while, I’ve been taking another look at Google’s documentation. Mainly because of the work I was doing and supervising on the FLOSS Manual for the Chromium Web browser. And, partly, because of a comment by Ivan Walsh on a recent post in this space.
So, at Ivan’s (non) suggestion, I took another peek at the documentation for Google Chrome. Now, more than ever, seem to be following some principles/ideas that Aaron and I have been espousing (and taking heat for in TC circles) for a few years. Not that we’re taking credit for anything that Google’s tech writing team has done …