As well as my full-time job, in my spare time I also design and build websites. It’s something which fits well with my skillset as a technical communicator, and allows me an insight into the world of development as well and has mirrored my career every step of the way.

The first company I worked for sent me on a training course to learn how to create web pages and, since then (13 years ago), I’ve continued to follow the trends and techniques involved. I’ve been through using tables for layout, to the introduction of frames, the launch of Internet Explorer and the first release of CSS.

The parallels between the theories of technical communications and those of web design are very similar, the key aim is to keep the audience in mind at all times. The way you structure and present the information is also important, as is a sense of usability of the content itself.

I’ve been lucky enough to have a fairly constant stream of web design work, largely by word of mouth, and have just finished chatting with another potential client. Part of my approach is to ask to have a questionnaire filled in, largely to help me understand the requirements for the website, as well as to have something to focus the initial conversations around.

Two of those questions are:

1. Who will be using your website? What is the intended/current audience?
2. Does your current website meet the needs of your audience? If not, why not?

Which, as I’m sure many of you will already have realised, is exactly the kind of questions we, as technical communicators, should be asking ourselves on a regular basis.

Apologies for the silence, as ever life is making posting to this blog a ‘challenge’. I’ve not forgotten about it, and I will get back to more regular posting soon. I’ve a few posts almost completed that I’d love some feedback on, not to mention a few outstanding questions that have been asked in the comments to answer.

So, as the sign says, I’ll be back.

Using Author-it to produce Word documents is easy. The tricky bit is distributing them.

Without running any post publishing macros, the Word document that is generated will be using linked images. So everytime you need to distribute the document you’ll also need to remember to include the images as well.

I frequently forget this, hence why I’m posting this, so, if all else fails, I can at least search my own blog to find the solution. If you look at a document with linked images, you’ll see that the filesize for the document is quite small, and there will be a number of images in the same folder (although this works fine if your images are linked from another folder).

UPDATE: You can also do this automatically after publishing using an afterPublish Word macro, the Author-it Knowledge Centre has the details, thanks to Derek Tomes for pointing it out. Read on for the manual method.

You can quickly and easily convert linked images to embedded images in Word 2007. Here’s how:

1. With your Word document open, click the Office button*, top-left of the window.
2. Select Prepare > Edit Links to Files.
3. Select and highlight the images you want to convert from the list.
4. Select the option to Save picture in document.
5. Click the Break Link button.
6. Click Yes to confirm.

The links are removed, and the images are now embedded in your Word document. A quick check of the filesize of the Word document should show a marked increase and you can now distribute the Word document, and the Word document only, safe in the knowledge that the images are embedded.

Last year I read the book Made to Stick, in which the phrase “The Curse of Knowledge” makes an appearance. The authors of the book will be delighted to know that the phrase stuck in my head and I can be heard applying it in all sorts of scenarios.

The principle is quite simple:

Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listeners’ state of mind.
Made to Stick

For example, during the course of an average week I will have several conversations with people who have a lot more knowledge of a specific thing than I do. Typically these will be software developers who have an in-depth knowledge of computers, how they work and most specifically how they thingmajig they are currently building works. There is a lot of presumed knowledge in these discussions, some rightly (I do know the principles of object-oriented programming) and some wrongly.

And, of course, I do exactly the same when talking to others. Everyone does it, it’s human nature. Where it really starts to hurt is when the Curse descends upon your technical writing.

I’ve fallen into this trap myself, and we do try and peer review our output to make sure a non-expert is looking at the documentation (non-expert in the specific area but still within ‘target audience’ boundaries of knowledge) and, largely, that’s the best you can expect to do with the typical resource and timescale limitations we all worked within.

There is another aspect to technical writing which falls prey to this Curse. There is sometimes a level of disassociation at play as we focus in on word usage and the grammar of what we write, rather than trying to use our information as a user would. It’s a fine distinction but using the software and documenting it is not the same as using the document to use the software.