I decided to overdose on wikis today, and there were three sessions that gave me that fix. I was able to get some interesting perspectives on wikis and how they’re being used.

Wikis are wonderful?

That’s what Alan Porter of WebWorks believes. WebWorks is using wikis both internally and externally, and Porter explained some of the reasons why. They’re easy to use, and make communication and the spread of information easier and more efficient.

Much of what Porter discussed in his session mirrored what Stewart Mader wrote in WikiPatterns. Still, it was refreshing to hear another perspective and to listen to someone actually putting the concepts into practice.

Porter highlighted what went well with WebWorks’ roll out of four wikis, and he also highlighted some of the things that the company could have done better, including:

• They needed to better define the basic structure of the wiki
• WebWorks made the mistake of designing for the company’s process, and not for the culture of the company

Porter, like Stewart Mader, pointed out that a company needs a person to champion the wiki and who is passionate about maintaining it. Luckily, WebWorks has a couple of those.

The site wiki.webworks.com was created to make interaction between customers, support, and development easier and utside normal support channels. Not only does the site allow for customer-to-customer iteraction, but also enables the company to post just-in-time documentation.

Porter also discussed one interesting project that WebWorks is undertaking: converting all of the company’s user documentation to wiki format. Everything is being authored in Structured FrameMaker with DITA and the wiki will be populated using ePublisher. The company is also working on DITA-wiki roundtripping using their own tool, but that’s still under development.

Growing wiki use

Stewart Mader, author of WikiPatterns and a passionate wiki evangelist, discussed using a wiki to increase collaboration and effectiveness in an enterprise.

Using personal anecdotes, Mader discussed how people can use a wiki to dive into material that exists, work with it, and expand upon it. Mader found that communiactions and materials often aren’t in sync. It shortens and streamlines the review cycle, and decreases conflict within a group.

Mader said wikis give collaboration context — you’re making changes based on the context of what someone wrote or edited, and not in a pristine copy of a file. This decreases misunderstandings, and increases communication. You’re not working in isolation but everything is out in the open (in the wiki comments/revision history).

The key message was that a wiki helps move a project forward through that collaboration and communication. Wikis put the emphasis on content and not design.

Mader reiterated the key points in his book:

• Spaces
• Barnraising
• Better meetings
• Onboarding
• Sharing
• Security

Need to consider all of those factors to ensure a successful wiki implementation.

The biggest leap is to move from relying on email to using a wiki. Mader offered a good example: one company made financial information available on an internal wiki. The information is there, and anyone can access it and generate a report when needed. Email is the weak link.

In a documentation project, Mader suggested writing about a feature or function while it’s being developed. This puts the information in context and keeps it fresh. Writing becomes part of the development flow and isn’t rushed to meet a deadline. You get better, more complete documentation.

Wikis, as Mader continually emphasized, can streamline projects and decrease (or eliminate) repeated work. Nothing is done in parallel, everyone knows what everyone is working on. It’s all on the wiki.

He also emphasized that wikis can be used for just about anything in an enterprise: documentation, reording meeting agendas, maintaining a knowledge base, collecting and spreading tacit knowledge, getting new employees up and running quickly, project landing pages, and more.

Wiki roundtripping

Finally, Anne Gentle and Stewart Mader (no, he doesn’t slow down!) talked about talked about moving from wiki to print via DITA. It’s (relatively) easy to go from DITA to wiki, but going the other way is a tad more difficult.

They explained that a wiki is an excellent complement to DITA or structured authoring. Gentle discussed IBM’s RedBooks, which are written by consultants. Right now, IBM gives the consultants a crash course in FrameMaker and then cuts them loose to write the RedBooks. A better way, Gentle and Mader said, is to let them write in a wiki and then pull that content into an publishing tool.

Wikis are a perfect vehicle for user assistance — companies like Sun, Intel, and eBay use them for:

• Giving customers quick access to documentation
• Presenting customer use cases and case studies
• Lower support costs

Something both Mader and Gentle stressed was that you need to build the community first, then build the wiki. Then, you can generate the help content. From there, users can access the content and also interact with each other on the wiki.

Gentle and Lisa Dyer of Lombardi talked about the solution that Lombardi uses to publish the company’s documentation to a wiki. It’s elegant, although it only works with Confluence at the moment.

Mader talked about data portability, and mentioned how DITA can help facilitate this. A DITA topic equates to an article on a wiki, and (as Gentle said earlier in the presentation) DITA maps enable you to better reuse content and offer you more flexibility.

Mader also said something that still sticks with me: the tool is not important. It’s the content. He and Gentle stressed that you need to build a community around a product. The best way to do that is with a wiki. And, it appears, DITA might be the best way to do that.

Related posts:

1. DocTrain West 2009 – Day Three
2. DocTrain West 2008 recap
3. DocTrain West 2008 day 3: keynotes, wikis, and interviews