---
title: "Wikis and the Holy Grail of Content Independence"
date: 2009-11-02
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2009/11/02/wikis-and-the-holy-grail-of-content-independence/
---
# Wikis and the Holy Grail of Content Independence
And yet, I regularly need to update the help after the application is released. For example, in the previous project [I was writing about](https://idratherbewriting.com/2009/10/29/a-few-surprises-in-using-a-wiki-for-documentation/), the Local Unit Calendar, after release I learned about a bug in production. I received a couple of questions from a user, and the answers weren't in the help. I had an error in the section about changing calendar color. And I needed to add some more instruction in another section.

When I explain to system engineers that I need a server for my help that I can update on the fly, they always ask why. Why can't I just include my help content in the application? However I explain it, the reasoning always comes off sounding like an excuse for not being able to finish my work on time for release.

And yet, I sometimes don't find out about an application until two weeks before the application goes live and needs documentation. Although I need to create video tutorials, the interface isn't frozen until the application goes into hardening and becomes a potential release candidate.

If the materials need to be translated, the Translation department requires at least a month of turnaround time. If the content will be printed and sent out to users, I may have to get the content approved from a department that ensures message consistency.

If subject matter experts don't take time to carefully review the material and video scripts before release, there's a good chance the help will contain some inaccuracies. Project managers and quality assurance engineers rarely have time to review help material the week before a release. If I don't submit the help content to peers for a style review, there's a possibility that typos or inappropriate formatting will also sneak through.

In short, there's a host of reasons why the documentation might need to be updated after the application is released. If I could access the help content and continue to add and adjust it at any time, independent of application releases, it makes documentation less of a time crunch the night before (for example, to finish the video tutorials for the calendar app., I stayed up until 5 a.m. the night before).

The concept of having control over your help content, to update it at any time, is what I'm calling *content independence*. Establishing content independence in your publishing environment may be a battle that can take years. For example, at a previous job, it took five years to finally convince architecture that we needed and deserved our own independent folder on a production server.