The Rockley Blog – wiki’s delivery mechanisms

I’m thoroughly enjoying the new Rockley Blog at I’m so glad Steve Manning and Ann Rockley are blogging, especially about wikis.

I appreciated Steve’s post “Wikis for Documentation” especially where he says that the delivery side is the weak point still. Agreed, but I have seen pockets of improvement there and need to be blogging heartily about them.

About three years ago I was equally as unconvinced of a wikis usefulness for end-user doc. An Agile-advocating developer mentioned the idea of using wikis so that the end-user doc could stay in sync with their fast Agile iterations. Yipes I thought! Wikis did work well for convincing the developers to contribute their knowledge, though, and internally they became a useful knowledge sharing (and finding) system.

Now I’m starting to see more and more actual customer need for them. I just had a great discussion about the difference between what a customer needs and what a customer thinks he or she wants, though, so some of what’s necessary is interpreting whether a wiki can fulfill a customer need. I got a small chuckle out of the title of this blog entry – Wikify Documentum Already – but he’s talking precisely about the gains you and your customers make when documentation is in a wiki. The interesting momentum going now is whether the current large enterprise content management systems can start to see the value in a wiki output, or whether the wiki engine providers themselves are going to catch up with the full feature set available in the large enterprise systems.

But wow, I’m learning how difficult wiki maintenance and trust patterns can be while using the site to help out with their end-user doc. In some ways, wiki doc is more difficult than using the real CMS tools that we’ve become accustomed to (read: spoiled by). But I’m also learning how amazing the collaboration opportunities are when using a wiki. I’m still marveling at the communication going on in the discussion pages as well as the volunteer spirit that has come through a request on an art network.

So, what to do to get decent output for content delivery using the multiple channels that us advanced single-sourcers are already accustomed to? I’m planning to move the XO’s end-user doc towards the model of a highly customized Twiki implementation where you can get and print a PDF from the wiki. I can’t wait to learn more and I’ll blog about it as I find out. It’s a step in that direction, though, where you deliver user guides and online help and web sites tailored to the needs of specific audiences. Language translations in a highly distributed environment are going to be an important part of the project, and I’m curious about how Flossmanuals provides for that aspect. riverbend.jpg

I’ve learned that you can write a Confluence plug-in that will take DITA source and turn it into wiki text. Confluence has PDF output capability as well, so it’s another step in the right direction to get that just-in-time content delivery that a customer needs (but doesn’t know that they want.)

Putting documentation in a wiki (or any really-well-indexed web location, really) can increase findability. If you get internal comments that say “you haven’t documented this particular feature enough” and you feel the feature is sufficiently documented, examine the findability of your documentation.

Also in our user advocacy role we are learning how to listen to customers and then interpret their needs. As information acquisition continues to gather speed, we not only provide the information but should also make informed choices about delivery methods.

Examples of what a customer wants but might not know that a wiki can deliver:

  • What’s new with the product?
  • How do I interact with documentation, support, the company represented as an actual live person?
  • I want immediate information updates.
  • I want to discuss the nuances of an implementation decision.
  • I need to find others who are attempting what I am in the same type of field (insurance or banking).

What are your thoughts? Are we spoiled by our advanced delivery systems and waiting for wiki engines to catch up? Or are wiki authoring and delivery systems already giving us collaborative opportunities that are unparalleled?


  • December 14, 2007 - 12:40 pm | Permalink

    Hi Anne,
    Excellent, excellent, excellent! I’ve been reading your blog since Scott Abel had you guest blog about your response to Joann Hackos’ wiki article, and this is a great post.

    I think that wiki tools are giving us unparalleled collaborative opportunities, and the “thing” holding us up from realizing their value is ourselves. Some people are either still so caught up in the notion that enterprise software should “dictate the conditions of its use” (, or fearful of wikis based on what they’ve heard about Wikipedia, and these factors keep them from meaningfully exploring what a well managed wiki can do for things like documentation, project management, managing meetings, etc.

    Fortunately, good people like you, Steve Manning, Ann Rockley and others are writing posts that show how useful, powerful, and forward-thinking wiki use can be. Keep up the good work!


  • December 16, 2007 - 1:09 pm | Permalink

    Thanks Stewart!

    I liked the link – on of the things he said in there stuck with me, where a wiki contributor asked, “how she would know if her contributions have any value…” This measurement is an interesting shift for each of us as professional writers and also as contributors to wikis (often for free). Where does our value lie and how do we ensure our contributions have value? Wikis are turning that very measurement on its side and that might be the heart of what holds back some from adoption. I know I struggle with that very question myself on some of my projects.

    I especially appreciate your encouraging words! Just so you know, I’m ordering a copy of WikiPatterns while I do some Christmas shopping on Amazon. 😉

  • Leave a Reply