I have little recollection of how I decided to become a technical writer. I’m not even sure how I found out that technical writing was a thing people did. I followed some roommates from college to Atlanta from Connecticut in the fall of 1993. I was a pretty good writer and I had always been a “computer nerd.” Today that might conjure up visions of Red Bull fueled hackathons. When I was growing up it meant reading operating system manuals. For fun.
Tag: Manuals
Paul Clifton is a Ph.D. student in Digital Media at the Georgia Institute of Technology. He has been an on and off technical writer with Shoap Technical Services since 2007 and is currently working in interaction and user experience design at Intel.
Recently, I helped my friend update his resume. I’d helped him make a brand new one a few years before, and it had been an extremely painful process, so when he asked me to help update it, I nearly just said no. To my surprise, the draft he sent me proved that he had been paying attention when I had originally explained the rules for making a good resume, why they were the rules, and why following them mattered. His grammar and spelling still weren’t very good, but grammar and spelling are the easy part. Clearly communicating complex information by meeting the expectations of the reader is the hard part, and I was happy to see that he had pretty well taken care of that.
“Waterfall is dead, long live Agile,” many voices cry, heralding a transition in the software industry from heavyweight engineering efforts to an almost sports-like scrimmage. Waterfall didn’tkeep up, they complain. Projects turned into congested pipelines and out of desperation to reclaim fluidity, the entire cycle broke down into an environment of iterative re-development that gave birth to Agile. Increasingly, developers collaborate in short sprints to rapidly address evolving concerns rather than as construction crews working from blueprints. What does this new era mean for technical writing as part of software development? More specifically, what is expected of an Agile Technical Writer?
Categories
eBooks
At some point, you’ve probably developed documentation to attract clients, educate customers, or provide instruction on the products or services you offer. Considering the effort put into creating the material, as well as the pool of expertise behind it, you might think about re-working some of your content to produce a general release eBook.
In a recent issue of the Shoap Technical Reader, I commented on my reaction to a usability test in which I had participated (“Why Technical Writers Are So Weird”). The test was for one of our writer’s web UI development classes. He created an application to create a response to an RFP. His observations can be found here: http://superawesomegood.com/2012/03/31/searchers-and-scrollers/.
You may have heard the term “gamification” floating around and wondered, “What is that?” The answer: Gamification is the new buzz word representing the idea of incorporating gaming concepts and techniques into non-game activities in order to drive a desired behavior. Marketing campaigns can use game mechanics to drive customers to their websites, sales agents can participate in games to drive competition and increase sales, and in our industry, documentation and training groups can build game-like training materials to fully engage the learner.
I used to take Microsoft Paint for granted. I saw it every once in a while in the Accessories folder when I was looking for the Calculator or Notepad but never really used it. Then I starting using screen capture programs at work to take screenshots for user guides, manuals, online helps, etc. When I was on my personal computer, I had no idea how to take a screenshot without a fancy program, and then I finally remembered Paint. Since then, I’ve used it for screenshots, creating and editing pictures/photos, and testing.
We’ve recently been approached by two different companies about writing requirements. The first, a small company, wanted to develop a dashboard to replace a third-party application it was using. The owner, who had most of the information in his head regarding what the new dashboard should look like, what it should do, etc., suggested we send one of our writers to his location to study the existing dashboard, spend a little time with him and some of his key people to learn more about the functionality the dashboard needed to support, and “capture” this information so he could give the requirements to a developer or offshore the project.
When you are a company dealing with your customers’ most valuable personal information, you need them to trust you. One easy way to do this is to have your documentation flawless (or close to it). Also, performing a test run with a small group of people before releasing it to the masses is a good idea. The group of people should be 3rd party users who can find the mistakes you can’t find (since you’ve read and reread the form 40 times and never want to see it again).
Categories
Reading Images
There is an unfortunate trend towards using more images and icons and using fewer written instructions (I like to say “words”). Personally, I don’t think it’s obvious what every icon actually is and what it means, especially when I’m in a hurry to do something.