Don’t Touch it!; Technical Writers Have a Sense of Humor


Article from Funny Tech Writer blog; posted on September 7, 2011.

Finally, strong evidence that technical writers have a sense of humor when they write documentation. Here is an image from instruction manual for a vacuum cleaner:

Don’t Touch

There’s a seal on the back of the cleaner that seems to fascinate peopledon’t touch it.

  1. It’s there to assist the manufacturing process.
  2. Don’t touch it – you’ll break the cleaner.
  3. It’s not meant to come off, but you can force it off if you try to turn it.
  4. If you succeed, the cleaner will stop working.

312572_10150303055209914_521479913_7741421_2130125_n

THE PEETLES: Technical Writer


This publication will cause a lot of controversy, but I’m getting used. Flaming torches and pitchforks are optional. I found this song very funny, so I wanted to share it with you all.

This song was written by Pete Zolli for his spouse’s birthday… A theme song for her and her profession. His wife is a tech writer, and he is a musician, so he gave her this song/recording/video as a birthday present.

Click on the image to see the video.

The Peetles Technical Writer

THE PEETLES: TECHNICAL WRITER

 

Technical Writer, writer, writer

__________________________

Dear Sir or Madam, you won’t read my book

it took me months to write; you won’t even look.

All you’ll ever look at is the online help,

but I’ll do my job, ‘cuz I trained to be a

technical writer, technical writer.

__________________________

I wen’t to school to be a double “E”

but I couldn’t do the trigonometry,

so I looked around for something else to do,

and I found this job and I learned to be a

technical writer, technical writer.

__________________________

Technical writer, writer, writer.

__________________________

It’s a thousand pages, give or take a few,

and they wanna release it in a week or two.

The engineers won’t give the facts I need,

but we’ll ship it out, ‘cuz I’m only just a

technical writer, technical writer.

__________________________

There’s a million changes here to document,

and a contract worker would be heaven sent,

but all the money goes to marketing.

I can’t take a break, ‘cuz I only am a

technical writer, writer , writer.

Mr. Procedure Discusses Procedures–Documenting Software (Part 1)


mrprocedure

The topic of documenting software came up in one request for my Writing Operating Procedures book. This is an important topic to all technical writers and would-be technical writers, because writing in support of software applications is a significant and growing piece of the technical writing pie. I personally have not written documentation for software spefically, but I have documented the software aspects of machines as part of operating procedures. Frankly, I find it the most tedious part of the procedure writing I have done.

In my current role, I write manuals for capital equipment that is entirely driven by software, so I have had to wrestle with exactly how best to document the software in a manner that benefits the equipment’s end user the most. So I will provide the insights I have gained, while at the same time asking readers to give their feedback, particularly those who have…

View original post 452 more words

Why name a product Flare?!


Originally posted on Mike’s MadCap blog on February 7, 2008; By Mike Hamilton

Special Note: Mike’s MadCap blog has being moved off of the WordPress servers and onto the MadCap Software servers.

Mike Hamilton

Mike Hamilton

I thought I would start out with something light but interesting. A bit of insight into the beginnings of MadCap Software.

A few people have asked about the name of our flagship product, MadCap Flare, and how it came to be named that. Well many people know about our background and our long involvement with the RoboHelp product line, and as the product manager for RoboHelp I found that a product with the name “Help” in it became extremely limiting. The plans we had for Flare were so much stronger than anything we ever did in the RoboHelp days that we definately didn’t want to limit ourselves in the same way by including the word help in the product title. But, then, what to name the new product?

Lots of ideas were bandied about, lots of brainstorming, and then it came to us. What is the international signal for, “I need help”? Why, you shoot off a Flare so that people can find you. This reference to help, or assistance, without explicitly using the word seemed too great to not use. So the product became Flare, or MadCap Flare. Unfortunately, I guess we had been watching too many episodes of Survivor or something, because nobody ever seems to get the back story without an explanation.

Now you know the story of how MadCap Flare got its name!

Shall I Use Must? Must I Use Shall?


mrprocedure

What a complete embarrassment to realize I have gone 2 1/2 months without authoring a post. Which I guess means I have to say Merry Christmas, Happy New Year 2013, Happy Asian New Year of your choice, and (for my U.S. readers), happy President’s day next Monday.

Recently, Angel Candelario featured my Writing Operating Procedures course/book, which is still available for free by contacting me at mrprocedure@gmail.com, on his fine Tech Writer News blog. This brought a (very gratifying) new rush of requests for the book (people like free, that I have learned!), which I have been more than happy to fill.

One request came from a gentleman named Johan (I don’t know what country he hails from), but in his request, he described his technical writing credentials, and he closed his request by saying:

In particular, I’d be interested to see what you have to say about the…

View original post 391 more words

Back to Basics – The 10 Golden Rules of Technical Writing


World of a Technical Writer

It was a refresher to spend a friday evening listening to Leah Guren sharing her insights acquired from a 30 year old career in Technical communication. She talked about the fundamentals that lay at the core of Technical Writing. The focus was on what process is followed, what are the right questions to be raised, how well the information is analyzed rather than any particular tools or domain. The talk was titled “The Golden Rules (Technical communication theory and application)”.

She discussed 10 Golden rules that work for all types of TC projects and provide a practical methodology. These golden rules are a result of Leah’s own experience and research.

#1. Paper is Permanent

It’s about owning what I am writing. It says “I am responsible for what I am writing”. So its important to write correctly, proof read and edit the documents properly and provide a proper structure to the…

View original post 915 more words