Guest post by Larry Kunz.

Two years ago I hadn’t heard of content curation, and you probably hadn’t either. Now it’s everywhere. The steam of content is turning into a flood. (Brett Swanson calls it the exaflood.)

As a technical communicator, if you’re not already assimilating content from all across the organization—as well as from your customers—you soon will be. In fact, your customers won’t wait to be invited to the party.

This subject fascinates me, and I like to read everything I can about it. I’m noticing something: as the flood of content increases, the flood of content about content curation is increasing too. Blog posts. Slide decks. Webinars. All with their attendant tweets, RSS feeds, and email notifications.

I’m not alone. As I was preparing this piece, I ran across an article in which Ian Greenleigh wrote that he has trouble handling all of the “shiny” new stuff being written about content curation. Like Greenleigh, I have a column in TweetDeck labeled #curation. Unlike Greenleigh, I don’t have ADD—but I still find it devilishly hard to keep up with everything.

› Continue reading…

Guest post by Kristi Leach.

So, You Need a Book about Usability

A while back, I asked Karen Bachmann, a usability expert in our STC chapter, to recommend some books for our tech comm department. I was looking for a place to start with the topic. Without hesitation, she told me everyone should read Steve Krug’s Don’t Make Me Think.

So, I ordered both Krug’s books: Don’t Make Me Think and Rocket Surgery Made Easy. Rocket Surgery is an expansion on his explanation of how to do simple, cheap usability testing. It comes with great check lists and sample scripts that you can download, along with a free chapter of the book and recommendations on equipment.

Once I had read Don’t Make Me Think, I wanted to send recommendations to our developers. That seemed like an overwhelming undertaking, so instead, after reading Rocket Surgery, I decided to implement a testing schedule for our documentation, with the long-term goal of getting to test our products.

› Continue reading…

I knew from the email subject line that I wasn’t going to like what was in the message.

The subject contained the name of an application, then two frightening words: “help sheets.”

I’ve found that outside the tech comm profession, people tend to throw around terms like “help” and “tips” without really thinking about what they mean. That’s why I felt a bit of dread as I opened this particular email.

The Rogue Documents

Looking for feedback, the product manager had forwarded two Word documents from an instructor who teaches this particular application as part of a week-long training for office staff. The instructor had documented a couple of end-to-end processes that weren’t strung together like that in the help.

Let’s just say that these documents weren’t done by a professional tech writer. I didn’t even get down to giving feedback on a content level; a subject-matter expert did some of that. Instead, I was concerned that by giving these documents to the class members, we were providing an inconsistent and less-than-professional experience.

I was also concerned because these documents’ pages were numbered 35 through 41. So what else was there that we didn’t know about? How much effort was being duplicated? Since it’s my full-time job to create such materials, I would have preferred if the instructors let us know about the need and asked me to fill it. Frankly, it felt a bit threatening, as if I thought my job was in danger. I considered this “rogue,” or unofficial, documentation.

The Idea

I ignored this email until the next day. Then, however, I decided to change my stance. I realized this was an opportunity, not a slap in the face.

› Continue reading…

Guest post by Peggy Harvey.

In today’s world of technology changing in the blink of an eye, ongoing professional development isn’t an option for technical communicators, it’s a requirement. Over the past decade the field of technical communication has grown and gained more respect as a legitimate profession, and the complexities of the job and skill base required of technical communicators have also increased. Some of what’s new we can learn on the job—if we have a job—but sometimes we need to obtain the skills to stay vital in other ways.

When it comes to professional development in tech comm there are a lot of options. If you’re gainfully employed, enjoying what you do, and just need to brush up on the latest tool, then probably just a training seminar or a short online class is all you need. But if you’re not employed, or employed in a different capacity than you’d like to be, then you might want to consider a bigger educational commitment to make yourself more marketable as a technical communicator in today’s world.

In 2008 I stepped out of the working world to go back to school to earn my master’s degree in technical communication. While I’d started my career as a technical writer in a software development environment, I’d changed roles along the way, and by 2008 I was wondering how I’d gotten on the train I was on and, more importantly, how I could get off of it. I decided earning an advanced degree was the right decision for me, so in January, 2009, I took the plunge and started graduate school as a full-time student.

› Continue reading…

One day I spent much of my time with a person who was new to a desktop application I work on. I provided documentation for the application, but this particular person—I’ll call her Ann—tends to doubt her ability to learn. So I was happy to work with Ann one-on-one to help her learn the steps of a procedure she would use at least weekly (and that she knows well at this point, I’m happy to report).

As we talked, Ann decided to open a new Word document to work in. I watched as she went into her file system and located a document with the file name “blank page.docx.” She double-clicked it to begin a new document.

I was somewhat surprised and even a little amused.

› Continue reading…