I don’t own a car. And I haven’t since I gave mine to my parents over seven years ago. That perplexes a number people I know, many of whom can’t get along without their four-wheeled metal boxes.
While I am member of a local car sharing service, most of my travel through the city is done on foot, by bicycle (I own a really nifty folding model in case you’re wondering), or by public transit. For all it’s flaws and all the complaints, Toronto’s transit system isn’t too bad. Not the best I’ve used, but not too bad.
Watching my fellow riders is an interesting exercise in observing human behaviour. I won’t go into too many details — I’ve ranted and joked about that elsewhere. Let’s just say that for the most part I don’t have a very high opinion of people who ride transit in Toronto. They seem to turn their brains off and be oblivious to their surroundings; I have several bumps and bruises to prove that!
But watching many riders is also a good case study in how people use (or don’t use) documentation.
Let me explain …
Two weeks ago, the Google Summer of Code Doc Camp was announced. I won’t go into that event in this post; you can read more about it here. Maybe you’ll get involved, too.
After the announcement hit Twitter, Shaun McCance posted an interesting tweet:
I know Shaun, and I understand where he’s coming from with that tweet. Thanks to topic-based writing and online delivery, the whole idea of books and manuals seems so twentieth century. And Shaun has been developing Mallard, a topic-oriented markup language intended primarily for the delivery of help. You can read more about Mallard here.
After reading Shaun’s tweet, I got to thinking about the idea of the book.
I view documentation as serving three main purposes:
- Helping users become familiar, and comfortable, with the hardware or software that we’re writing about.
- Teaching users advanced tips and tricks.
- As a reference for things that users may have forgotten or rarely use.
A big part of the second point is internalization. Making tasks seem like second nature to the user. This was brought home to be recently while doing some audio editing and clean up for my wife.
It’s been some time since I’ve done any audio editing, and quite a bit of time since I’ve done it regularly. That was back when Aaron and I were frequently putting out our podcast.
Last week, I joined a very interesting webcast (organized by the folks at opensource.com) on motivation by Daniel Pink, author of Drive and A Whole New Mind. Pink’s thoughts about motivation, how it’s changed, and how organizations can motivate their employees offed a lot of food for thought. You can read the tweets from the webcast, and a recap of the webcast.
During the webcast, Pink mentioned an interesting way that software development shop Atlassian motivates its employees. It does that through FedEx Days. A FedEx Day:
is time set aside for developers to work on whatever they want with a skew towards our products. We tend to run “FedEx” with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products. We have expanded it such that we set aside 1 1/2 days for the developers to complete their ideas. We start after lunch on a Thursday and work until 4pm Friday when we present what we have to everyone.
With FedEx Days, Atlassian is motivating employees to become more engaged by doing work outside of the boundaries of their jobs. It gives them a greater sense of purpose.
When I heard Pink talking about that, it sounded a lot like something done at Google called 20% time (hence the title of this post). Google encourages employees to work on personal projects 20% of the time. Those projects can be speculative, wacky, or visionary.
During Daniel Pink’s webcast, I started asking myself can this be applied to technical communication? The answer is yes and it has been done (more on this soon).
It’s just a matter of being able to set aside that time and how you use it.
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.