---
title: "Moving Between the Agora and the Desert"
date: 2012-12-16
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2012/12/16/moving-between-the-agora-and-the-desert/
---
# Moving Between the Agora and the Desert
One concern he had in [our migration away from wikis to a help authoring tool](https://idratherbewriting.com/2012/06/11/essay-my-journey-to-and-from-wikis-why-i-adopted-wikis-why-i-veered-away-from-them-and-a-new-model-for-collaboration/) was that the content would become out of date. Employees would move on to other projects and documentation would lag without anyone taking care to update it. At least on a wiki, someone in the community could still update the content.

Six months later, I realized that the predictions were partially right.

But merely switching tools to something more browser-based, like WordPress, Mediawiki, or some other online CMS, still doesn't solve the problem, my developer friend explained. The content can become outdated no matter what tool you're using. Switching to another tool doesn't solve the underlying problem.

We can update content regardless of the tool. If you're using a help authoring tool and uploading the output to a server, or publishing using some other CMS, or editing directly in the browser, you still have to keep a listening ear to your users and update content regularly.

Wikis might make the job of staying updated a bit easier, because you can edit directly in the browser, and if content is out of date, users may try to make edits, thus making you aware of outdated material. But whether you work in an offline tool or online tool, the hard part isn't clicking a few buttons. It's taking the time to stay updated with feedback, deciding how to address the feedback, and figuring out where to add more information to your help material.

I have to confess something. I miss using Mediawiki. Using a help authoring tool feels a bit disconnected with the experience of being online. There's not a sense of a dynamic ebb and flow of edits, comments, recent changes, histories, new users, updates, linkbacks, plugins, releases, and "online-ness" like there is with Mediawiki.

But the tool isn't the culprit behind the out-of-date content. It's the hassle of updating the content.

For me, the hardest part about technical writing is making the mental shift about when documentation is done. Documentation is never complete, especially at release. Users continue to have questions, issues, feedback, problems, new scenarios, and concerns. If we follow a style of [Include It All, Filter It Afterwards](https://idratherbewriting.com/2012/12/11/podcast-include-it-all-filter-it-afterwards-interview-with-mark-baker/), we end up with an ongoing engagement with documentation, one that leads us to continue to add and add and add content to our documentation until we have tomes of information.

## Fixing the Problem Instead of Changing the Tool

I decided that rather than focus on tools (because it wasn't necessarily a tool problem), I would instead immerse myself in user feedback. I spent half a day reading threads in user forums, noting information that I could add to the help. After I gathered a long list of notes, I then set about updating my help content. I added new pages, rewrote existing pages, added known limitations, added even more known limitations, responded to forum threads with updates and other information, and so on.

After a day of this, I no longer had the sense that I was "offline" by using a help authoring tool that wasn't browser-based. Instead, it was rather refreshing to take this hustle and bustle of forum activity, information that was scattered and repeated, quoted and refuted, expanded and criticized, expounded and propounded and repounded, ad infinitum across forum posts, and then to figure out — *offline* — how to reshape the help material with the right information to address all of these threads.