Category Archives: technical communication

by Scott Nesbitt

Ranting (again) about error messages  Clip to Evernote

Frustration with bad error messages As you may or may not know, one of my pet peeves in the world of technical communication is error messages. Make that bad error messages. We’ve all seen them. Many of us have fallen victim to them. They’re frustrating, to say the least.

Case in point: over the last month or so, I’ve been selling various things on Amazon.com. More to thin out the books, DVDs, and CDs that have been piling up around my house for … well, a long time.

Things were going quite well until about two weeks ago. That’s when I got a return request. The return request wasn’t the problem. But to process the request, I have to jump through a few of Amazon’s hoops. The first step is to approve the return request. Sounds simple, doesn’t it?

Continue reading →

by Scott Nesbitt

Books, documentation, and perception  Clip to Evernote

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:

Tweet about books

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.

Continue reading →

by Scott Nesbitt

Internalization and documentation  Clip to Evernote

Practice, practice, repeat I view documentation as serving three main purposes:

  1. Helping users become familiar, and comfortable, with the hardware or software that we’re writing about.
  2. Teaching users advanced tips and tricks.
  3. 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.

Continue reading →

by Scott Nesbitt

Thoughts about 20% time and the technical communicator  Clip to Evernote

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.

Continue reading →