There’s no such job! – Or, How I ended up with a career in Technical Communications

I can’t spell. I really can’t. I’m terrible at it, always have been. Yet I read voraciously (it just took me three attempts to spell that one right), and I love to write. I’ve wanted to be a writer since I was seven years old, but my poor spelling was always something of a handicap, because I’m so old that when I was at school there was no such thing as spell checkers. Sure, there were dictionaries but the problem with a dictionary is that you have to at least have some basic idea of how a word is spelt to be able to get find it in the first place.
I also liked machines, cars, motorcycles, planes. I enjoyed taking them apart and finding out how they worked (OK I didn’t take planes apart, but I studied aerodynamics so I knew how they stayed up there). Early in my teens, sitting in the careers advisor’s office at school with the oil from the latest engine tear-down fresh under my finger nails, I had a discussion that went something like this:
Careers Advisor: “So what would be your ideal profession?”
Me: “Something that combined Engineering and Writing.”
Careers Advisor: “That’s not a career. There’s no such job.”

He then looked at the file on his desk, and then at my oily hands. “Your report says you have a good grasp of most subjects and can learn quickly, but you are a terrible speller.” Another look at the hands, “But clearly you like machines. Go be an engineer.”

And that was his final word, and that’s the path the school put me on.
Fast forward several years and I have a degree in Marine Engineering in my pocket and I’m working as a Junior Engineer in the British merchant marine on container ships. It wasn’t the life for me, except for one aspect.

nacontrolroom-470x352
During long boring watch rota shifts in the mainly automated engine room I would while away the time reading the tech manuals. You know the things that I’d been told didn’t exist. And my reaction was (1) That idiot careers advisor had been wrong as someone must produce these, and (2) I could do them so much better.
Despite being paid to travel the world (well the Mediterranean and North Atlantic) while staring at a deck full of containers, after a year I decided to head back to land and to University to pursue a second degree in Industrial Technology. As part of the degree course we had to spend two separate six-month periods working in industry. My first industrial-placement was at a computer company, and the second?

At some point I’d been chatting to my girlfriend (now my wife) about potential placements and she suggested I talk to her brother-in-laws, both of whom worked at British Aerospace. Over a pint in the pub later that evening someone casually mentioned that there was a department called Technical Publications at the aerospace facility nearby, and he happened to know the guy who ran it. One introduction later and the following summer I found myself at a desk writing my first piece of technical documentation – a Component Maintenance Manual for an upgrade to the engine intakes on Concorde!

CONCORDE
As for that job that didn’t exist, by my reckoning I am now in my 32nd year of working in the profession in one capacity or other.

Advertisements

Color me this…

The following are a few extracts from my latest feature cover article for INTERCOM magazine on Communicating with Color

 

My red shoes went viral on the Internet thanks to a photograph taken at the Intelligent Content Conference in Palm Springs back in February. Over the last couple of years I’ve developed a bit of an obsession with Converse sneakers, and as of today have nine pairs in different colors, usually worn to match whatever shirt or jacket I’m wearing. The red ones always seem to draw comments or, it seems, the occasional photograph.
However my interest in color goes beyond my choice of sartorial footwear, as I’ve long been interested in the use of color as a design element in communications and storytelling.
Color has always been around us, used by both man and nature as a means to communicate.  The bright plumage of a bird, or the striped fur of a Tiger are not an accident, they are an integral part of the way that the animals interact with each other and their surroundings. The same goes for the human species. We have long used color to communicate with each other and as a part of various cultural traditions. So why not use color as part of our technical communications toolbox as well?
….
Of course adding color to your technical communications deliverables isn’t as simple as just picking a few crayons from the box and coloring in between the lines. The use of color takes a lot of thought, and a new set of skills that need to be considered. In fact the color theory knowledge and experience of an individual can make a big impact.   
….
Think about the colors you see around you everyday and how they are used. Red for Stop or Danger. Green for Go etc. Your company probably already has some color standards overseen by the marketing group on how the company colors can be used. Think about how they can be incorporated in to your technical documentation. Even take a look at the colors used in the product you are writing about. How can they be used?

The full article is available in the print edition of the STC INTERCOM magazine, or on-line here.

Looking forward to the STC Summit

Next week I will be in Sacramento, CA for the 2011 STC Summit. An event I’ve been looking forward to for many months.

Although I’m not speaking this year, I’ve been more involved than ever, as both Deputy Program Manager, and Track Manager for both the Web Technology and Education and Training tracks.

This will also be the first STC Summit since the publication of my book “WIKI: Grow Your Own For Fun & Profit,” which will be available at the conference bookstore and at the XML Press booth.
If anyone would like to meet up for a chat, or get a book signed, then the best places to find me (or leave messages) will be at:
  • The STC Program booth,
  • The XML Press booth,
  • The PTC booth.
I’ll also make sure to step into some sessions and visit the expo floor on a regular basis throughout the conference.
I’ll also be posting note on both my Twitter accounts during the conference, so feel free to follow, or contact me, via @4jsgroup or @alanjporter
I’m looking forward to meeting up with old friends and colleagues, as well as meeting lots of new people for some interesting discussions on Technical Communications and Content Strategy.
I think we have put together a great program this year, and if you are attending, I hope you find it both informative and stimulating.
See you in Sacramento.

Paying the Ferryman – The cost of putting your content in someone’s hands.

As part of the research for my next book for XML Press book (Which like this blog is also entitled THE CONTENT POOL.) I was having a conversation with a couple of people at a large manufacturing company about the cost of their documentation; at the start of the conversation I was expecting to hear all about the software they used to author, manage and publish their information, or even about the cost of training and retaining skilled technical communicators. But the conversation very quickly turned to one aspect of technical publishing that most of us (and I include myself in that) often completely overlook. – The cost of actually getting the information into our customers hands.

For this company their largest publishing related cost is simply Postage.

When we talk about modern technical communications and publishing systems, processes, and technology, we tend to think about digital creation and delivery. Along with that comes an assumption that most, if not all, our customers are in some way connected to the internet. There is a lot of talk (and again I’m just as guilty as anyone) of web delivery, mobile delivery and the bright digital future we are all marching towards. Yet that is a very Anglo-American centric view of the world.

Recently someone at Facebook developed a visualization of all the various Facebook connections, and the image that appeared (below) turned out to be a startlingly accurate rendering of a map of the World. Except that large areas of that map were dark. It reinforced the message that even if we are producing information digitally, we can’t assume that if we are operating on a global scale everyone who needs access to our information has a wired connection.

So back to my earlier conversation. The company I was talking to uses XML and topic based authoring processes, along with content management tools, to efficiently single-source their documentation into many different deliverables.

But their products are literally used all over the world, including in some of the world’s most inhospitable and remote locations. Not everyone is wired, so instead they ship sets of DVDs to customers and business partners.

Depending on the product being used the DVD sets can consist of anything from 3 to 12 separate DVD discs. And they ship 15,000 such sets every month. While the cost of shipping a set of DVDs within the US may be relatively cheap, the cost of shipping on set of DVDs to to a user working in the African jungle maybe as high at several thousand dollars. As well as the actual postage there is the cost of import duties, time to fill out customs forms and get approvals, as well as the actual delivery cost. I was told of one DVD set that involves the monthly rent of a boat and boatman to delivery it along a jungle river!

The total annual postage and delivery cost of DVDs for this company is in the Millions of dollars range, and recent increases in postage rates have meant a dis-proportianate rise in that overhead.

So next time you are considering the cost of your documentation – don’t just think about the investment needed to actually create the content – think about what it takes to actually get that information into the hands of all your customers, no matter where they are located.

Are you an "Awesome Dude"?


I just spotted this message posted by one of my nieces to her FaceBook account the other day:

[name] finally has picture messaging on her Nokia N900 thanks to an awesome dude and his step by step youtube video!!

A seemingly simple message, but one that made me stop and think. I’ve written, and spoken a lot over the last year of so about the way that the digital generation access and assimilate information (a subject I’ll be revisiting at this year’s LavaCon), and also held forth on my view that as Technical Communicators we should be embracing and working with new media.

Here is a perfect example of that convergence. Rather than use the manufacturers, instructions, or look for an answer on their web-site, or on-line help, my niece turned to the internet and the wider online community.

Her answer came not from Nokia, but from some “awesome dude” on YouTube.

What are you doing to make sure that you as a technical communicator can be the next “awesome dude”?

Technical Communication As Story Telling

Over on his “I’d Rather Be Writing” blog, Tom Johnson, has taken my idea of Tech Comm as storytelling, and expanded on it an excellent post, that I highly recommend.

In particular I like these two ideas on the practicalities of applying story telling techniques to technical documentation:

THE ELEMENT OF CHANGE


In a good story, the resolution always brings about some type of change, or comes about because of change. If you listen to stories on The Moth podcast (a storytelling podcast), you’ll constantly hear this element of change near the end of each story. For a story to feel meaningful, the protagonist always changes as a result of the conflict. Without this element of change, the story feels flat.
In technical documentation, achieving that element of change is difficult. In almost all technical documentation, the reader is the protagonist, since our point of view is second person (“you”). You (the reader) have a problem. ….. Through the help topic’s steps and information, you find a solution that solves your problem. Hooray, you’re much happier and complete now. That’s the basic transformation.
And..

FOCUSING ON THE PROBLEM

A problem of some kind usually drives and gives rise to the story. But isn’t every help topic by default the answer to some problem? And aren’t users coming to the help content with a problem already in mind? Do we need to explicitly supply the problem, since it’s already apparent in the user’s mind?

Yes, your protagonist already has a problem. That problem is what is fueling his or her path through the help. But it can still be helpful to state the problem explicitly so that users can connect their problem to the solution you describe.

In many ways the examples and ideas that Tom cites, also feedback to my earlier post on Applying the 10 Commandments of Storytelling to Technical Documentation.

It’s great to see these ideas being picked up and expanded upon.