The infinite monkey theorem states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare. As such, it stands to reason that two monkeys would be able to produce the same volume of output, but are unlikely to write exactly the same thing. Add in a few more monkeys to the equation and suddenly you have lots of content, none of which really relates to anything else.

I’ll stop with the monkey metaphor before I insult anyone.

Consistency is an important part of communication, even at the simplest level of having a common terminology, using the same words consistently throughout a document helps the reader learn. Take this idea up a level, from a single document to a number of documents and maintaining the same terminology across all documents can further help re-enforce the messaging and aid learning, and should give the reader a level of comfort that the entire set of information has been thought of, and delivered, as a cohesive set.

Move up the stack one more time and you start to look around at surrounding areas of information, outside of product documentation, produced by a different department and it’s here that consistency starts to suffer.

Typically Technical Communications teams will spend some time developing their own Style Guide (however loose), and agree a basic set of terminology, also known as the Product Glossary. Having been involved with creating a Product Glossary in the past, it’s interesting that other areas of the company see it as being a ‘documentation thing’, until such times as you get them to sit down and help you compose entries for it.

I know that the information produced by my team will be consistent and is written in a similar enough style that it won’t ‘jar’ the reader. In other words, it doesn’t matter who wrote the information, it is all part of one larger set of documentation, with a similar tone, voice and style.

Aiming the information at the correct audience is a key part of deciding what the three attributes of tone, voice and style, should be, and it’s at this point that I find other departments starting to struggle. Without a clear idea of the audience, and with their own perception of what the message (the terminology) needs to be, there is a tendency to wander off message, and produce a document which, whilst perfectly good in isolation, doesn’t seem to fit into the overall set of product information.

So what type of information is this? Well it varies, and can be tracked through the customer (or company) journey and their interactions with your company and product. Broadly speaking there are four levels, all of which need to be talking to the correct audience, and ideally should be providing the same message in a consistent manner.

1. First up there is an introduction, a high level chat about our product and what it can do. This is typically a mix of marketing brochures, website collateral, and sales presentations.
2. The next level of interaction delves a little deeper into the business benefits and key selling points of the product, and can start to touch on product features and capabilities.
3. After that, there is a need to provide a level of technical information, outlining the architecture and fundamental design of your product, detail the full set of capabilities, and provide reassurance around any potential implementation issues that may arise.
4. And then we get to product documentation, training material, and ongoing support and maintenance information.

Four levels of information, all of which should be saying the same thing about the product, regardless of what message that is.

It would be wrong to say that each level is unique, as each interaction your company has with a customer will vary, but largely speaking the four levels allow anyone who is creating information to better understand their audience. Add in a Product Glossary to ensure terminology is consistent, and a strong product message and there is no reason why any of the content being produced cannot be consistent.

Mapping these levels to the amount of content available at each level gives us the following:

Of course this is a very simplistic model, but as a starting point, it at least provides the mechanism for anyone about to create new content to pause and consider the audience. So whilst you could add in several levels, and several different mappings of document types, I think it’s better to leave things a little open to question as that helps bring a better understanding of why the content is being produced in the first place.

I first introduced this model to my current company several months ago, and we are currently revisiting this to make sure it is still a good fit to our needs. The next step for me is beefing up our Product Glossary, and then we can get on with the thornier issue of document management, an intrinsic part of having a Content Strategy for your company.

I have been remiss at writing new content for this blog, and whilst this topic isn’t one that I said I’d post about (those posts are coming, I promise), it’s something I was discussing yesterday and so is at the forefront of my mind.

Like many people I still use pen and paper when taking notes, and regardless of the type of meeting I stick with three basic categories.

1. [] Actions either for me or my team to do. Includes things that need done immediately or things which it would be good to do in the future.
2. ? Questions on things I want to learn more about, which relate to my team. Whilst these may also be actions (typically they involve asking people questions) I differentiate them because, until I’ve asked the question, I don’t know enough to decide on whether there is anything to be done (caveat: if it is a burning issue, I’ll like put this against both categories ? [] ).
3. I Information which covers all sorts of things from useful URLs, to quotes, to product names and so on.

I also “style” my notes, with the appropriate shorthand symbol first, then a gap, then the text for that item. Keeping that consistent makes it very easy to scan down my notes to process them.

[] email report to Fred
[] speak to Tina about next phase of work
? what is the cognitive learning project, who is running it?
[] write a blog post on the Information Strategy Pyramid
I stats for last week 103 open, 74 closed

Processing the notes, again, depends on the type of note.

For actions as, unless they can be done straight away (I think that is a GTD methodology thing? If it takes 1 minute to do it, and 1 minute to write it up and put it in a list, then you are better just doing it), they are transcribed into an online task manager application I use called Remember the Milk. It has a very nice iPhone app which makes it easy to “take my list” with me at all times.

Questions are simply a matter of being asked. That may drive further actions or information which are captured accordingly.

Anything I’ve noted down as information is either processed electronically, if it’s something online I’ll visit it and either bookmark it in my del.icio.us account, add it to my list on Instapaper (again, which has an excellent iPhone app), or grab it and store for later in Evernote (again, a useful iPhone app helps).

Whilst all of that seems like a lot of work, it’s very maintainable, and I spend less than 20 mins a day processing my notes. However it helps me keep on top of several different streams of work, and so far it hasn’t let me down. I’ve been using the shorthand symbols for a long time now, but obviously the electronic processing of these things is new.

So, what about you? How do you take notes? Are you a mindmapper? A random scribbler? Or do you, like one lady who attend a presentation I did a few years ago, do you draw out the subject and the notes in one go?

Last night, around 3am, I woke up. I lay there in bed wondering why I’d woken up and as my mind started to churn I realised I was very very awake.

In flooded four things I’ve been thinking about for some time, all of which are related but I couldn’t quite make the connection. Last night I cracked it. Maybe.

I’m still thinking it through but here are the four items in question:

1. Single sourcing our documentation – and recent discussions with other areas of the company who could benefit from the same approach.
2. Company Information Strategy – a simple pyramid based model that allows everyone creating content to ‘map’ their audience appropriately and which should start to help with consistency of terminology and messaging.
3. Document Management – there have been some murmurings about this from a few people and it’s likely to fall into my lap.
4. Requirements gathering – we’ve recently rolled out a new process which should lead to better requirements for each project build.

All of these are tied together, and if planned properly can feed off each other. Naturally there is quite a lot involved with all of the above and I’ll be revisiting items one and two in the coming weeks.

Ohh and I’ve still to pull together a slide deck on “selling our services”, which involves all of the above and more. Once it’s ready, I’ll share it here.

Exciting times ahead.

I have no idea what our users want.

I do know they want information, and I know they want that information to be kept up to date as our product evolves and as far as those basic needs are concerned, I’m happy that we are meeting them. Beyond that I admit I’m not really that sure.

Over the past couple of years we have plugged a lot of gaps and improved the documentation provided in key areas all whilst keeping up with new features being added to the product. We’ve moved to Author-it to give us the advantages of re-use and multi-format publishing and on the whole we’ve built a good reputation within the company.

So it’s time to take stock and look at the next area we need to improve and to do that we need to know what our users want.

On the one hand we are lucky in that we have access to a small number of them, and if we can arrange the time we can sit down with them and ask them direct questions. However there is a large portion of our audience that isn’t available to us and who we also need to converse with.

Rather than try and start up a conversation from cold, I’m thinking it would be a good idea to ask them to complete a short survey, the results of which we can discuss when appropriate.

But what to ask? In the past I’ve tried to get users to score the documentation on a number of criteria (who easy it was to find the information, if it answered their questions and so on) but that doesn’t really give much scope to start a conversation.

So I’ve been looking about for some examples and to my delight have found many. I’ll probably be picking and choosing questions from the following, but I thought I’d list them here in case anyone else finds them useful:

• Apple Logic Studio
• Solaris Developer Documentation
• Drupal Documentation Survey
• User Documentation Survey 2009

I’d also urge you all to take part in the last one, it’s relevant to us all.

Have you run user surveys? I’d love to hear your stories, successful or otherwise.

As we approach the end of our migration from FrameMaker 7 to Author-it, I’m going to try and pull together some lessons learned, some tips, and useful links that I’ve found along the way. I’m not claiming to be an expert (I’ll leave that to Rhonda Bracey and Char James Tanny, amongst others!) but, as they say, a problem shared is a problem that you might just find via a Google search… or something like that…

Pre-empting this, I thought I’d open things up to anyone who might have any questions about the process we’ve gone through. So, if you want to know my thoughts on migrating content (how NOT to do it, perhaps?) or anything specific to Author-it then leave me a comment.

Over to you!

When I get to the bottom
I go back to the top of the slide
Where I stop and turn
and I go for a ride
Till I get to the bottom and I see you again!!!!

Ever get that feeling that you’ve been here before?

I write this blog post with haste as I’m halfway through the penultimate week of a particularly arduous project. Not only are we releasing a new version of the product, but we are completing the first major stage of our move to Author-it.

Overall the migration has been pretty painless. There are still some Word templates issues to work around and getting to grips with Variants has still to be tackled, but overall we are pretty happy with our choice. The only major gripe we have is partly our (ok, MY) own fault, and it’s here that I’ll offer the most valuable tip I can.

If you are migrating legacy content to Author-it (we were moving from Structured FrameMaker), make sure you thoroughly test and check the import settings. Time constraints had me rush this stage and we ended up paying for it, spending far too long cleaning up rogue topics than we had planned. Every cloud has a silver lining though, and it does mean that the documentation is now far more consistently written and styled than it had been. However, going through some 5000 odd topics by hand wasn’t the greatest use of our time!

Soon we will be looking to how we can leverage the output to provide better access to information, feeding into the developer community website we have already built, and improving how we deliver information alongwith our product set.

For the former we have taken some inspiration from the presentation by Rachel Potts and Brian Harris (Red Gate Software) at last years UA Conference, titled Delivering Help in a Support Portal. For our implementation the Publications team will take the lead, and it’ll be interesting to see where it takes us. Web 2.0, anyone?

We will also be looking to provide better online help by introducing Keystone Topics, as suggested by Matthew Ellison. Author-it should make these topics, which are the first topics the user lands on when they start the online help and which provide sensible links to common information (rather than just providing repurposed user manuals), very easy to build.

Two of the team will be in Cardiff for the conference this year so it’ll be interesting to see what we learn there and how we can really start to leverage Author-it in more and more powerful ways. I’m definitely keen to start innovating what we do and, in a few weeks time, we won’t have any further barriers to stop us.

The other day one of our genius developers (I think his official ranking is Jedi Knight) asked me why we don’t provide the product documentation on a Wiki. I answered him stating that it was because I wasn’t allowed. That’s not strictly true.

My answer should have been that, quite simply, I’ve failed to provide a good enough reason to my boss (and my bosses boss) as to why that may be a good thing.

And the reason I’ve failed to do that?

Because I’m still not 100% convinced that it is a good solution for our product.

What is more likely is that, if we do decide to embrace Wikis (we haven’t managed blogs yet, but that’s another issue) we take a split approach and offer a knowledge base style information centre (something like the Author-it Knowledge Center) and host a Wiki as a way of capturing and sharing what I refer to as ‘grey information’.

It’s this latter set of information which, whilst it has always existed, has never really had a place to live until the internet came along. These days all it takes is a quick internet search and you’ll find masses of information, all generated by the users. Some of it is useful, hints and tips, ways to workaround product limitations, and clever uses that were never thought of by the manufacturer.

To me, that user created content is where Wikis hold their true power and finding the balance between that content, and the content provided by my team is still something I’ve to get my head around. Ultimately the argument (business case) for investing in the creation, maintenance and policing of a Wiki needs to be focussed on how much value we will gain (ROI).

On that basis it shouldn’t be a hard business case to put together, the tricky bit is making it such a compelling argument that it moves to (close to) the top of the list, and that will require a lot more discussion around why embracing Wikis, and blogs, will stand us in better stead in the future.