Recently, a friend forwarded me an interesting blog post. It’s from popular blog on language learning, and the post in question examines the paralysis that comes from demanding perfection from one’s self. Admittedly, I have no interest in the subject matter of that blog, but the post intrigued me.
Why? The thrust of that blog post also applies to documentation.
Most technical communicators I know take pride in their work. They want the documentation that they write to be as complete as possible. They want it to be as good as possible. Maybe a little bit more. They’re aiming for perfection.
Some people see perfection as a laudable goal. I don’t. The problem is that perfection can be a mind killer. Perfection is a trap. Perfection isn’t a good goal. Why? You’ll never achieve it.
There’s definitely a lot of talk about the mobile universe in our profession. More and more technical communicators are coming to realize that the devices that we carry in our hands and in our bags are becoming a platform on which to deliver information and documentation.
The question, though, is how best to do that?
Recently, I had a rambling conversation with a friend of mine. He’s not a technical writer (or a writer of any stripe), but portions of our conversations often turn to technical communication. I enjoy the occasional talks I have with people outside of our profession. It gives me a fresh perspective on what I do, and for whom I’m doing it.
Our discussion turned to how best to deliver documentation on a mobile device. Now understand that my friend is a mobile junkie. He lives his personal and professional lives on his phone and portable media player. In fact, it’s been a while since I’ve seen him touch a computer.
Anyway, he said that documentation might best be delivered using an app. I thought about that for a few seconds, then had to politely disagree.
No matter what we say or think, documentation is rarely (if ever) complete. Even after a document has been signed off, there’s often some small change, some amendment, some addition or deletion.
I can still remember when updating a document after it had been published was a chore, to say the least. That was in the days when just about everyone printed manuals. To do an update, you had to either go through another print run or send out an addendum. Or you had to make an updated PDF or help file available for download.
The situation now is a lot better. For the most part, anyway. More on this soon.
But let’s think about software for a moment. Updating software is fairly easy. In many cases, you don’t have to download an update or patch — it’s automatically pushed to you. If you’re dealing with a Web application, updates are done behind the scenes.
Maybe documentation can take a cue from the development world and issue updates to documentation in the same was as updates to software.