ffeathers — a technical writer’s blog

Do wikis save trees, and do we even want to save trees? Global warming, carbon-trading, green politics — where do wikis fit in, and are they even relevant?

I’ve worked in an office environment for quite a few years. Recently, I’ve started using a wiki to write, review, update and read documents and to share ideas. My desk is definitely more paper-free than ever before, largely due to the use of the wiki.

So my gut-feeling is to say, ‘Hey, wikis save trees!’ Being a tree-hugger and a wiki-hugger both, this feels like a good place to be.

But take a look at this article by Chris Anderson, which seems to prove that my good place is an illusion. Printed documents have a lower carbon footprint than online documents! So even if wikis save trees (which is debatable in itself) perhaps we don’t want to save trees. The paper industry puts them back in the ground, whereas a wiki doesn’t.

Chris Anderson’s article has a very long, heated and interesting comment trail. After reading it, I’d like to take a slightly different tack. He is concentrating on articles which are written once, and then read by many people. Websites are viewer-intensive.

How is a wiki different to a web page?

Many wikis are used for short-term collaboration rather than, or as well as, longer-term information storage. You might put an idea up on a wiki. A number of people would then review it, add their comments, and update the page. At the end of the process, an idea has been formed and is out there in the noosphere. People probably won’t go back to the wiki often to look at that particular idea. You could say the wiki is scribble-intensive.
The key thing is: In the review and refinement process, if we use a wiki then we aren’t passing around and scribbling on pieces of paper. We aren’t even exchanging long and confusing email chains which eventually force you to print them out just to keep track of who said what in reply to whom. Nor are we using Word documents, where the change-tracking is just as confusing Nor even any backs of envelopes or matchboxes.

Instead, the wiki page distills and merges all updates so that it shows the latest aggregation at any one time. And if you need to, you can go back and examine the change history to see who did what.

We’re online anyway. Given that the bad effects of the technology exist whether you use a wiki or some other form of website or computer technology, perhaps wikis are a step in the right direction.

What do you think?

Does anyone have any figures which go to prove this question either way? Maybe someone in the publishing industry has some experience of using a wiki for pre-publication drafting and review. Or perhaps there are some other industry-specific stories out there. Do you have anecdotal evidence, or even some documented statistics?

Ozzie tree shedding its bark

Here’s a tree in our garden. In early summer (that’s December on this side of the world, when I took this picture) the tree chucks all its bark on the ground. The new ’skin’ underneath is a lovely mixture of salmon pinks, oranges and greys.

The story goes that early visitors to Australia were amazed by trees like this, because they shed their bark in summer rather than their leaves in winter.

Sydney Red Gum (Angophora costata) aka smooth-barked apple.

J the TW writes on Spacebar about some wiki restructuring that she is about to undertake. Her blog post struck a strong chord with me, and probably will with a number of other wiki-huggers out there. When a wiki gets to be of a certain age, it needs some work done. In some cases, it may even need an extreme makeover. Who else has a story to tell? And should you even try to put structure in a wiki?

My wiki makeover story

Like J, I have just passed the 6-month mark at my new job. Writing in and managing a wiki is a large part of what I do. One of ‘my’ wikis needs some body sculpting. It’s been around quite a few years now, and parts of it are looking a bit tired. I’m thinking a face lift, a fair bit of liposuction, plus definitely some implants and enhancements.

The wiki in question houses the technical documentation for the Confluence software product. Yes, it’s a wiki which documents a wiki. It’s the oldest of our product documentation wiki spaces, and is updated continuously by a large number of people. It has kind of grown organically, to match the needs of a fast-growing company plus a rapidly-expanding software product. The wiki pages are updated by technical writers, support engineers, developers, sales staff and anyone else within the company who sees something that needs doing. In addition, anyone in the whole wide world can add comments to the wiki pages. These comments often contain useful information, which should ideally be incorporated into the pages at some time.

Enter the technical writer. It’s definitely within my portfolio and skill set to re-organise the documents, excise the out-of-date pages, add missing bits and sort out the structure.

Two hiccups are immediately obvious:

• Time: It’s hard to fit in a large maintenance task like this, especially when there are new features rapidly and continuously appearing and demanding to be documented.
• Sustainability: With so many different authors, the wiki will tend to revert to its current muddle soon after the restructuring task is done. (Is it ever done?) That’s entropy, man.

Should you even try to structure a wiki?

It’s a good question. It’s even a philosophical question. Isn’t a wiki meant to be an amorphous collection of pages which the reader can surf via a search engine, an index, RSS feeds and page-watches to catch the latest updates, or even just via the lucky-dip technique? Isn’t a wiki kind of like a mind map, with free-thinking links darting here, there and everywhere? You could compare a wiki to the nutrient soup which purportedly gave rise to sentient life. A wiki enthusiast might justifiably believe that we should not impose a hierarchical structure on the wiki gloop.

Well, my answer would be: ‘Yes’, wikis make excellent nutrient soup which allows ideas to bubble up to the surface and be scooped up by a passing RSS feed. But ‘Yes’, you can also add structure to allow human readers to browse in a more methodical way when that suits them. To some extent, it depends on the purpose of the wiki concerned. When the wiki contains technical and support documentation, structure is a plus.

Some examples of structure might be:

• A table of contents.
• Division of documents by audience.
• Page hierarchies, so that you can group pages which deal with the same topic.
• Headings within pages.
• Similar look and feel across the pages which deal with the same subject.
• And so on - your typical tech writer stuff.

We have some other wiki spaces with good structure. Here’s an example.

Quelling the hiccups

If your structure has some logic to it and is readily visible, then other people will tend to follow it rather than add to a spaghetti-bowl of documents. Our brains are wired to recognise patterns, and we usually like contributing to the symmetry rather than breaking it. Technical writers are trained to chunk information and to present it in ways which appeal to other humans. So all we have to do is to apply these techniques to a wiki. That takes care of the ‘sustainability‘ hiccup. Easy

The ‘time‘ problem is less easily solved…

Watch this space

I’m planning to get to work on the Confluence wiki. Probably the best thing is to tackle it in manageable pieces. I have a few tasks mapped out already. Let’s see how it goes! If J the TW beats me to it, I’d love to hear her story!