eDMS Roshambo Part 3 | Updating & Repurposing Content

Continued from eDMS Roshambo Part 2: Wikis vs eDMS posted a couple months ago. Sorry for the delay.

…And now you understand my RoShamBo comparison. Wiki, according to the authors I quoted in eDMS Roshambo Part 2 beats plain desktop publishing. In fact, Stewart Mader has an excellent book out that’s on my next-to-read-list.

Wikipatterns by Stewart Mader Read more about this book…

And as we remember from my eDMS Roshambo Part 2 quote from Dan’s blog, Dan Ortega feels that with the proper corporate restraint wikis can work well within a corporation.

This is with caveats, and not all of them are limited to technology. There are significant conflicting social elements regarding wiki implementation as well which is a point that Stewart Mader and I both agree upon.

Sacha Chua from The Orange Chair discusses this dilemma in It’s the culture, not the technology:

Corporate culture isn’t something you can change in a few months. You can’t install goodwill. You can’t enable cooperation.

In short, if you work in a hostile corporate environment, wikis might not be the best method to collaborate. Then again, in such an environment there’s probably zero collaboration going on at all.

Wiki Strength: Wiki Usage Resolves Siloed Content Challenge

No more of that developed content (.doc, .pdf, .fm) shoved somewhere on the eDMS or intranet with only desktop tools to edit it with. A wiki provides a single authoring framework that all can use.

Wiki Weaknesses: Homogenizing, Updating, and Repurposing Content

The primary objection / weakness that I have of a wiki integration is in single-sourcing and repurposing the resulting content.

Bringing exported content out into XML or another form is possible in some wikis but the end product still requires some sort of editing tool such as Microsoft Word, Adobe FrameMaker, or MadCap Blaze. Now you run into some issues.

The content’s single sourcing is critical, and if it’s updated in the wiki getting the changes into the technical communicator’s source working files could become a devastating bottleneck. 

The second weakness of a wiki is in the editing tool itself. The integration of concepts such as snippets and variables doesn’t currently existi in wiki editing. 

I would also add that the snippet suggestions and many other ‘homogenizing’ methods that MadCap’s Analyzer offers allow significant time savings in structuring content. This is a capability that the wikis I’ve seen don’t have and I consider this to be a particular weakness when overall content structure is considered due to the time required to get ‘er done.

Wiki content needs to be cleaned up if it’s going to see the outside world. I think behind the firewall a wiki gives everyone something to work with but there’s still considerable work to be done prior to integrating raw text into a corporate presence.

So even with a wiki there is still a workflow requiring a tool, and usage feedback can still be examined within the published online resources.

With RoboHelp or Flare the WYSIWYG is very sophisticated, the result of both product’s design team experience with help authoring. With a better editing tool for XML Flare tends to overrule both RoboHelp and straight wiki collaboration with the MadPak suite which has that killer app Capture, which takes the image variables into consideration so graphic inclusion isn’t such a chore.