Foul Writer’s World

I was thinking last week about how my writing has differed from the eLearning experience of my earlier career and it got me thinking, why do we continue to do things the same way? I’ve read much about the whole Learning 2.0 movements, as well as the Web 2.0 phenomenon and I am amazed at the strides those different disciplines have made. From looking at the new 2.0 world for these particular subjects I have noticed that both terms were invented at the beginning of a new era, an alternative way of thinking and working.

So I began to think about how could documentation be moved into the 2.0 world, can it or has it already? I’m not talking about this from a technology point of view or using 2.0 technology (like wiki’s) with our 1.0 documentation. This has already been discussed by various people like Ryan’s documentation 2.0 blog post at Technically Speaking. I’m talking about this from a written/cognitive perspective. For example, should we be telling people exactly how to do what they want or should we be explaining the concepts in a hope that they understand the principles quicker and learn not to rely on the help. I would much prefer to write a simple concept driven help that will be similar for every product produced. A context sensitive help that is conceptual, where a user can read a single help page and the whole application becomes second nature. Alas, I don’t think we will ever be able to make that jump in to documentation 2.0 from this perspective, not permanently at least, because developers will continue to make difficult to use applications, user interface designers will continue to be influenced by marketing and management rather than doing what is ‘right’ for the user and it will also take organizations a long time to kick their documentation habits.

I consider the closest we have come to a documentation 2.0 solution is the embedding of Help Centers. These often incorporate instructions, tips, troubleshooting and user contributions. A good example of this would be Google’s Reader Help Center. While the help does little in describing the concepts used, what it does do is keep the help simple and relies on the easy to user interface and the common sense of the user. This sort of short focused help can only be achieved on simple to use applications. Don’t get me wrong the applications can be as complicated as you like, just as long as they are simple to use, these are two entirely different concepts that unfortunately most software developers don’t spend enough time focusing on. This can be especially difficult for documenters who work in organizations where usability, design and product management all occur between the same group of people. I’ve always believed that documentation should be part of the initial usability design, the way I’ve always thought about it is if it is easy to plan and write for, it will be easy to use. Funnily enough, just as I finish typing this post up I see a quick flash in my RSS reader of a new article by Tom over at I’d rather be writing describing the biggest failure of WordPress titled WordPress’ Biggest Mistake. Apparently that they don’t have a technical writer at all, this explains why WordPress will never be the easiest blogging platform. Talk about a funny coincidence

Does anyone else have some thoughts on which direction documentation 2.0 should head? Should it be more concepts driven, more knowledge friendly, less fact based and less procedural? Or is it just impossible to achieve at the moment?

Other related information

• The great wiki experiment
• To blog or to wiki software software development?
• Wiki based API documentation
• Questionmark joins the blogosphere and updates its wiki
• Write me a river!
• Foul Writers World Wiki
• Creating user assistance documentation in a WEB 2.0 world