Must Help Pages Live Forever?

I’m pondering the 1998 article, Pages Must Live Forever (from Jakob Nielson’s Alertbox) while documenting the content aging report in MindTouch 2010 (Read the spec here, read the user guide here).

With redirects helping stave off link rot, it seems that we can fulfill the wish behind Kristina Halvorson’s plea not to allow the web become like the junk-filled planet in Wall-E. Instead of piling up old versions of pages, the links stay fresh while the content might age a bit, like a fine wine.

For help content, I can list reasons that older content might be just fine, no need to send off alarms.

  • Software that has classic features that were well documented in the first place, those pages can be static.
  • Pages that haven’t been updated but are still oft-visited I would consider to be fresh, not stale. As long as the comments don’t indicate a problem with the content, it can be considered fresh.
  • Depending on how well it’s resourced or energetic it is, your writing staff and community can only add a finite amount of content per week (or month). So the percentage of old content may be higher than the percentage of new content. That ratio is probably okay as your site ages. The mark the report sets is two years (24 months), then the content might be “old.”
  • Depending on the scope of the aging report, an older product would have older help pages. Filtering helps you tune in the grouping of pages where you might be concerned about stale pages.

Two years would be a long time in a web application’s life, but perhaps not so long for an enterprise application. As usual, the answer to “Must Help Pages Live Forever?” is “It depends.” The real question that I’m trying to answer is “When are Help Pages Stale?” I believe two years is a valid and reasonable line to draw. What do you think?


  • July 26, 2010 - 8:21 am | Permalink

    Hi Anne, spectacular to read your writing, once again. We’re about to enter a new era. Web analytics will soon make it easy to evaluate the usefulness of each published topic. Provided the #techcomm topics are on the searchable web AND that proper tracking tools are in place, writing teams will soon be able to assess whether or not a topic has outlived its usefulness. In short, if a given web-topic has NO readers over a defined period of time, it is likely that it can be safely deprecated. There are many other factors, but that (a total lack of hits) would be a key one. I actually wrote about this here, in a somewhat ominous plea for the industry to prepare:

    Anyhow, I’m so excited about what the future holds for our profession. Thanks for all you do. I finished your book and LOVED it.

  • July 26, 2010 - 8:32 am | Permalink

    We are going through the process of integrating our web app into the Google Apps Marketplace. Google had some stale content in their documentation that created hours of confusion and frustration in what should have been a simple process. I don’t know how old it was but it was certainly less than two years.

    Documentation is stale as soon as it is wrong. The documentation becomes wrong as soon as the app changes. The trick is tying the two together so that the doc team knows what needs to be updated and when.

    We have found this works very well for us:

    1. Keep articles specific and task-based. If you do this it becomes much easier to know which articles need to be updated when a change is made to the app. If you have an article titles “How to create a user” and the process for creating a user changes you know you need to change the article. If you just have one big article titled “Users” then what needs updating becomes more ambiguous.

    2. Use pictures whenever possible. A picture will almost instantly let the user know if a help article is suspect. If the picture in the help doesn’t match what they are seeing in their app there is a good chance that the article is out of date. This can save them hours of frustration in trying to implement outdated instructions.

    3. Add commenting to each help article. If your users find an article is out of date they will tell you if you make it easy for them to communicate with you.

    Pruning documentation is definitely important but I am not sure how an aging date will really be helpful. But maybe I haven’t thought of the right use case scenario.

  • July 29, 2010 - 2:20 pm | Permalink

    A hearty thanks to both of you! Greg, your example and subsequent point that “Documentation is stale as soon as it is wrong” and fast-changing apps play into that is spot on with my experiences, especially when keeping up with an Agile development team. The graph that the report offers shows content 0-3 months old, 4-6 months old, 7-12 months old, and 13-24 months old. See the image on this page: (It wasn’t ready yet when I wrote the post!) šŸ™‚ So I think it offers a great place to start your work – especially since it’s not just a measure of a cliff jumped off at 24 months, but a way to prioritize what pages may need more work sooner than others.

  • Pingback:   Weekly links roundup by Communications from DMN

  • Pingback:   Weekly links roundup by Communications from DMN

  • Pingback:   Weekly links roundup by Communications from DMN

  • Pingback: Danegeld links 16-20 August: exploring digital identities at Danegeld

  • Leave a Reply