This is Me in Grade Two…

ThisIsMeinGradeTwo

(Originally published 22 April 2007, am republishing…well…have to get back into blogging. Throwback Thursday is as a good excuse as any!)

Mrs. Halleberg was my grade two teacher. On parent’s night, each student had to make up an individual star made of construction paper. Mrs. Halleberg would then write adjectives to describe her students and put them up on the bulletin board in the hallway. She wrote ‘Chatterbox’ on mine and ‘Motor Mouth’ on my friend Lorraine’s. I guess your individual development really doesn’t change much after your first five years–hence, thirty years later I am nick-named Princess Donkey.

I’ve kept this character sketch that a fellow classmate wrote of me in Mrs. Halleberg’s grade two class.

The great thing is: thirty years later, I still have friends from Grade 2: Lorraine and Michelle.  Lorraine is my first close long-time friend to have a baby (Baby Betty). Michelle lives in or around Wakefield and is studying to become a nurse. We had another friend, Winnie Wong. I don’t know where she is now though. I think Lorraine says she is in Toronto.

I did, however, say hello to my former classmate who wrote my character sketch this year when I was home at Christmas. I found out that he and wife were living just up the road from my parents. They’ve had a baby too. I had three weeks to kill in Whitehorse this year and them up–out of the blue–and asked if they wanted to go skiiing. I didn’t think they would remember me–but they did. I told them that I had this character sketch that he had written about me–and that I am positively horrified that in grade two, my hobbies included doing chores around the house.

A very Sedaris Christmas

This is a special repost for Lindsey and Jillian who had never heard of the Saint Nicholas Day. This post was originally published on 15 December 2009.

David Sedaris is one of my absolute favourite authors. I have all of his books. I read, and re-read them from time to time. He makes me laugh out loud. He’s also a contributor on one of my favourite radio programs, This American Life.

If you have a few minutes, this is one of my favourite Christmas stories from a cultural perspective.

Happy Father’s Day to My Dad

Here is something I published for my Dad in 2008. I think it is still relevant and I shall cheat a bit and post it again.

Happy Father’s Day Dad. See you next week!!

XO

J

~~~~~~~~~~~~~~~~~~~~~~~~

It’s a little late in coming today, I know. AND I have absolutely no excuse. None what-so-ever (that the blog entry is late). But here it is…a blog entry for my Dad.

Boating down Miles Canyon

And now, I am just going to take this moment to tell the world I love my Dad. We had our ups and downs and for awhile in the late 1990s, and we weren’t talking. But we figured it out. And we are talking now. And we actually have a pretty good relationship. He’s a real person. That’s what I like so much about my Dad. He’s real. He doesn’t pretend to be someone he’s not. He doesn’t apologize for who he is. He just is.

One summer when I was home for my parent’s 40th wedding anniversary, we were talking about what (and maybe who) people believe in. And he stood at the kitchen counter and looked over at me and said: “Jennie. Know what I believe in?”

He motioned outside at Golden Horn Mountain. “I believe in those rocks.”

He motioned out another window, “I believe in those trees.”

He motioned out to the back yard, “I believe in your mother’s garden.”

That’s one of my favourite quotes from my Dad. “I believe in those rocks. I believe in those trees. I believe in your mother’s garden.”

Dad and me

I think his quote means that his beliefs are more tangible than most. He believes in what he knows exists. He knows that the mountain will be there tomorrow. It’s going to be a mountain tomorrow, standing as tall and firm and as steadfast as it’s ever been. He isn’t expecting that the mountain will be anything more than a mountain tomorrow. And the mountain is not expecting him to be anything more than he is today. Can you have a more healthy relationship?

The same with the trees. Respect the trees and they will respect you.

My mother’s garden. Now. I know how much they both work on my mother’s garden–so I don’t just think that the garden just belongs to my Mum. As much as they attend to and nourish that garden, it nourishes and attends to them back. In the brief growing season in the Yukon, they will harvest enough vegetables to get them through the summer and a good part of the winter.

So here’s what my Dad has taught me:

Believe in what you know exists. Believe in yourself. Know where your roots are and what you believe in. Be firm, strong, and steadfast in your beliefs. Don’t pretend to be somebody you’re not and don’t apologize for who you are. Have respect for others but don’t forget to respect yourself. And, give as much as you want to receive.

Oh. And laugh hard along the way.

Laugh hard the way

Click here for all the blog entries about my Dad.

What do you do with a doily?

A few days ago, my friend writes to me:

“WTF do I do with a doily?

I was given a crocheted doily, and so I gracefully accepted it with thanks. That was a few years ago. Now, I’m doing a big purge. And, I’m wondering who the hell wants a doily? Who buys these things? Who uses them? Why were paper ones invented? And, when?

I can’t even sell this doily on ebay – there’s one up there for .99 cents + free shipping, and people aren’t buying.

Any suggestions for what to do with a doily? Apart from donating it to charity?

I googled “doily history” and struggled to keep myself awake. Even the history of the doily is BOOOOORRRRINGGGGG!!!!”

I wrote back:

“Ha ha ha ha ha….

I inherited TWO doilies from my grandmother. I don’t know what to do with them either. I just keep putting them in my sock drawer because I am afraid to throw them away–because they were my grandmother’s.

I am with you though: WTF do you do with a doily?”

Today she wrote back. Apparently her husband is turning 50 this year. She was wondering if he would choose between regular fitness classes or fitness classes for those 50+. Or when he would consider asking for a senior’s discount. (I don’t imagine this conversation was going well). But she tried to flatter him by saying he would “would lead hearts to flutter amongst the blue-haired set”–which then led her think of a solution for her doily:

“So, I now have an idea–albeit inappropriate. So, if you’re feeling prudish – don’t read further.

Doily use: Pasty in role playing sex games
Required: 1 doily and 1 blue-haired old lady wig

Whisper, “I’m wearing nothing but a doily”

Snort!

What do YOU do with a doily?

On technical writing

This post is for Dave over at WhatHeSaid.ca and YukonDude.com, because he asked.

I learned technical writing at Nortel Networks where I wrote customer information manuals for the DMS-100, the Passport 7K, and other documents for engineering teams (like AMA billing requirements and ISUP technical specifications).  The most important lessons I learned were:

  • Know the product
  • Know your audience
  • Organize your information
  • Know the English language

First, while I have your attention, I would just like to say that I think many (almost too many) organizations underestimate the value of documentation. Other than the product itself, documentation is the only part of the product a customer sees. It makes an impression–not only on your customers, but on your customer support team, your product test groups, any new employee, your marketing department, product management, and I’m sure there are more that I’m not thinking of right now.

I will refer to my first technical writing contract at Nortel as anecdotal evidence. Helen Borodalyuk hired me to address XXX line items in the product information suite for DMS-100 switch for NTT (a telecommunications service provider in Japan). They judged the quality of the code and the quality of the product based on the quality of the documentation. Something I still tend to do. I guess first impressions are lasting impressions.

Regardless, everybody benefits from having accurate, succinct, and complete documentation. I believe good product documentation makes a company scalable. Leading technology companies (Google, for example) also make great multimedia content. In today’s world, I believe good documentation is more than a PDF.

Anyway, I’ll get off my soapbox. Without further ado, here are a few more words on my lessons learned as a technical writer.

KNOW YOUR PRODUCT
Use your product you are documenting. Learn it inside out (engineering perspective) and document it from the outside in (user perspective). For example, if you were writing the procedures to install a telecommunications networking product. Find out how the product is shipped. Take it out of its packaging. Start putting it together. What do you do first? What do you next? What do you do after that? Document every step along the way.

Basically, learn by doing. Systematically document every action. Teach your user how to use the product. Determine what tasks they need to do to make the product work. Describe the task and document the procedures.

KNOW YOUR AUDIENCE

The purpose of technical writing is to teach your audience something about the product. Imagine your audience has a grade 8 level education.

If you have an audience who doesn’t speak English (or the language you are writing in), imagine that they might need a dictionary to translate or define words. Use Simplified English writing rules (below).

Know the main tasks of your audience. Know if they are marketing users or maintenance users. Know if they are technicians or trainers. Know exactly who your primary audience is. Write your documents as if you were talking directly to them.

ORGANIZE YOUR INFORMATION
There is a whole discipline around organizing information. Information architecture. Information design. The buzz word in the late 90s was “information mapping”. Whatever it is now, just know that you have to organize your information to present it in digestible pieces to your reader. My personal philosophy is: “Write so they don’t have to read what you have written.” I think that is a direct quote from Robert Horn. But basically, readers of user guides and manuals have a specific task in mind when they are looking at your information. Present your information so it makes it really easy for a reader to find exactly what they are looking for.

There is a lot of value in information architecture (done correctly). A valuable architect would be able to define the required information about the product for all audience types and be able to build a information framework (architecture, library, whatever you are going to call it). The right publishing system (and person) could dynamically produce predefined information depending the audience and their requirements. For example, you can use product descriptions in marketing collateral and in hardware guides. One piece of content: two audiences. I actually have an information model I developed specifically for telecommunications equipment. But I believe it would work for many products.

Also, do you know how a reader digests information? I have this formula: one third audio (or text), one third visual (pictures, diagrams), one third practical (engagement, procedures, and practical examples). Any one person prefers any two of those formats. If you present your information in all three formats, you will reach a greater audience AND a greater part of your audience will retain what you have documented. Use graphics or other media whenever and where ever possible.

That formula also translates to finding information on the web. On the internet, this world of accessible information, there is a rule: four clicks and the user should find the information they are looking for. The four-click rule also translates to product information suites and to user interface design regardless of the platform (computer software, mobile devices).

KNOW THE ENGLISH LANGUAGE

You are not a creative writer. You are a technical writer. There is a difference. Being a technical writer is a lot like being a journalist. Investigative reporting–actually. You are researching, investigating, interviewing, putting facts (systems, software, solutions) holistically together, and presenting digestible information.

One of my most powerful tool for technical writing is simplified English. According to Wikipedia: Simplified English is a subset of English grammatical rules that was developed by the aerospace industry and is now officially known as ASD-STE100 Simplified Technical English (STE).

Keep the simplified writing rules (below) in mind for every sentence you write. Check. Recheck. And check again.

SIMPLIFIED ENGLISH WRITING RULES AS I REMEMBER THEM

  • Only use words that are in a dictionary and can be translated
  • Use active voice
  • Use present tense
  • Create sentences with 21 words or less
  • Create simple sentences: one noun, one verb
  • Create short, visual paragraphs
  • Use parallel lists
  • Use positive statements
  • Be gender neutral
  • Avoid conditional tenses (could, should, would)
  • Avoid slang and jargon
  • Avoid gerunds at the beginning of sentences
  • Create procedures with 10 primary steps or less

If you wanted to start somewhere with this Simplified English style, definitely check out  that standard. ASD-STE100 Simplified Technical English (STE). It takes practice and a good editor to become proficient. But it is definitely worth it.

Did that help you Dave? Was that the type of info you were looking for?  If  I didn’t bore you too much, here are a few more thoughts.

PROCEDURES
Procedures achieve tasks. Figure out what tasks your audience needs to achieve. Perform the tasks yourself. What do you do first? What do you do next? What do you do after that? What makes the most sense — from the user’s perspective?

Ideally, tasks shouldn’t be longer than 10 primary steps. Write sequential steps as separate sentences. Use a primary step to state the action. Use sub steps to describe specifically how to achieve the action.

Test your procedures. Ideally, have someone test them for you.

REFERENCE GUIDES

Reference documents provide dictionary-type information on any user-provisioned variable in the system. My formula for documenting reference manuals was:

  • Name the parameter.
  • Define the parameter. Where is it? What does it do? Why is it configurable? If it’s an operational parameter, why is it there?
  • List the possible values in the parameter. Define each value. Document the purpose of the value and it’s effect on any other parameters in system. Describe the dependencies?

(If anything, documenting a reference guide is the single most exhaustive technical writing task I have ever done. But, in the end, I knew the system inside and out. 🙂

EDITORS

If you can afford one, editors are invaluable. Find a good one. Work with them. You will become a better writer.

STYLE GUIDES

If you can’t afford an editor AND if there is more than one writer for the product, agree on a style guide so you don’t have to argue about init caps in titles or what to do with a semi-colon. (My advice…ditch the semi colon. Use a period and a new sentence. You get 21 more words. :-). My bible has been the Chicago Manual of Style. It’s a complete and widely used reference for style. Sun Microsystems also put out a good style guide called: Read Me First.

MY BOOKSHELF

My bookshelf includes the following titles. I refer to them incessantly:

Anyway. That’s what I have today. If I think of anything else, I’ll let you know.

~~~~~~~~~~~~~~~~~~~~~~~

PS: I didn’t just work at Nortel. You can view an online version of my resume at 9068Creative.com.