When a freshman/sophmore in college–Wichita Falls, Tx’s MidWestern State University–I was doing terrible in math and science, but was taking sophmore English classes. I’d managed to CLEP out of tons of hours, something I was quite proud about at the time.

One of my sophmore level classes was Technical Writing. Obviously, that technical writing class had a profound impact on my work. Now, I point back to that one class as giving me the tools and framework for becoming a technical writer.

In my search for introductory wiki information, I ran across Tom Johnson’s TechWriter Voices Podcast. It featured a podcast on wikis and technical writers, which combines two of my passions (I’m subscribing!). I really liked the podcast and listening to the technical writer being interviewed. The title of the podcast is Wikis Are Coming: An In-Depth Exploration of Using Wikis in Documentation — Interview with Katriel Reichman (Israel). Well worth listening to.

Some of my notes on the podcast:

Some of the benefits of wikis for technical writers:

• Getting the benefit multiple experts rather than just rely on certified technical writer
• Tech writers can’t make frequent updates in the documentation; this is addressed easily by wikis.
• With a rapidly evolving product, wikis make it easier to keep up. For example, Google Gmail is rapidly changing. The technical writer gets it going but then it’s important to use a wiki to update the content.

Some potential problems or obstacles:

• Issue of control
• Tech writers have to give up control of their document
• How many people are going to be involved. Wikis play off when you have several players. When you have only one person, a wiki doesn’t pay [I DISAGREE]
• Wiki has to be accessible.
• Wiki is good for reference information, less good process/task/heavy graphic oriented information. Not good if people don’t have access to the wiki

What about user contributions? What about bad grammar and editing?

• Two models. People expect content as is. When in a business environment, people want content to be edited. You have to distinguish between intense editing. Focus is on editing for clarity.

Is documentation ever finished when you have a wiki?

• Are products ever fixed? Even in a classic documentation cycle, the user guide is updated as the product is. So in any case, we’re updating content. Are we updating content and putting the tech writer at the center, and only the tech writer can do this job, or do we open it up and then let the tech writer follow changes the people make? The tech writer follows either the product changes, or in a wiki situation, the changes people make. [NICE DISTINCTION]
• Users don’t complain about wikis.
• Most people today get their information today from sources that aren’t top-down, hierarchical model.

Any way to export content into Word for printing? Or are you stuck with the online format?

• Wikis are oriented to the online format. There are some plug-ins that can turn a wiki entry into a printable version.
• Working on a DokuWiki plug-in.

What do you recommend as a good wiki tool and what do you use?

• A good site to go to is http://wikimatrix.org and if you go there, you can see other tools compared to DokuWiki.
• His preference is Dokuwiki. wiki.splitbrain.org
• Another good wiki is MediaWiki. Not the best wiki but popular and has lots of plug-ins [I LIKE PMWIKI.ORG]
• Host it internally or a site?
• View comparison between DokuWiki and PMWiki

• No good reason to install SharePoint when you can get good wiki functionality for free. We’re a Microsoft shop, says some CEOs, and we only run Sharepoint, then you can’t do it, then I say go with Sharepoint, you don’t want to spit in the wind [HILARIOUS].

How do you convince higher-ups?

• Convince management that wikis are going to deliver a better product for them, implementation time will be reduced.
• It’s going to cost management less.
• He mentions that a product developer can make an update to the wiki himself, then the technical writer can come along later and clean it up a bit.
• If in the content mgmt business, show them what other businesses are doing and how they’re using wikis.

Will wikis replace the technical writer? Valid fear or not?

• Is it a real threat?
• Do I gain anything by ignoring it?
• WIkis are coming and being adopted. Wikis are a logical next step. They’re coming. As a tech writer, I can seize that opportunity or let it hit me from behind. My company didn’t use to have a formal training program for new customers, but now they’re doing it. A smart technical writer will try to get training into their purview. It may take 2 years, but a good writer will try to channel this.
• A good wiki needs management, needs a template. If I just provide an unstructured wiki, I’m not going to get good content. I want a technical writer to think about design of a wiki, as well as provide editing of the content. If I’m in a wiki, and not info is being re-used, how can I facilitate or enable that? A wiki creates an opportunity for a technical writer to do more, not less.