In my last post, I offered a quick example of how to spot misbehaving content. Analytics are a great tool for showing you the suspects, but it takes a bit of work to pick the really bad content out of the line-up.  To overload the metaphor yet further, this becomes a prime time forensic drama, complete with whizzy lab equipment, and an avuncular serial killer if the content in question has no known purpose.

Typically, you'll start with a content inventory (or audit, or whatever) to tell you what you have. Then the analytics give you the warning signs, then you have to read stuff in detail, and think about how it relates to other content, business goals, user needs, house styles, and of course if it's at all well-written.

Since one of the things we're trying to do here is reduce the time spent creating, maintaining, and generally chasing after the specious claptrap that passes for so much web content, this isn't ideal.

Here at Red Gate, we've just launched the Schema Compare for Oracle early access program. It's a brand spanking new tool; so we've got a fresh start with the content.

One of the things that's quite exciting about the project is just how involved various parts of the business have been. We're normally pretty good at this, to be fair. But with Schema Compare for Oracle (I wish we could have found a shorter name) as well as close involvement from product management and support, our brand manager has been more or less part of the development team. Technical authors have been part of the development team at Red Gate for a while now. When that started, it made a huge difference. From where I'm sitting (surrounded by developers, testers, and UX) this feels like the next step.

We've been able to work together on content, so we've had an idea of what we need, why we need it, and how we'll know if it works. The traditional boundary between the "product" end of our website as owned by marketing, and the "supportcentre" end as owned by technical communications has become deliciously fuzzy, with both of us offering expertise to ensure the content is as good as it can be.

In fact, we've been quite explicit about this. We're doing it backwards - content inventory first.

Of course, it isn't actually backwards. Spending a week trawling through web pages just to work out what you've actually got on your site is the backward part.  We'd rather track what we do, as we do it. So come the release of say, version 12, we'll still be able to point to any piece of content, and tell you what it's for, how we expect to know if it's any good at it.

It's nothing flash, just a table:

It's a bit rough and vague, I'll admit, and the proof of value will only come from actually making measurements and curating accordingly, but it feels like a heck of a start.

There's a conspicuous missing column, too: "is it any good?". It's really too early for that.

The early access release has been out in the wild for only a few days now. The numbers are looking cautiously promising, but it would be easy to get specious. Viewing the product page generally leads to downloads, and it looks like people are reading the help and walkthrough content. At this stage, it's harder to know how useful they're finding those, but we're getting relatively few gripes about the things those pages cover. Again, I can't claim any causal relationship there. We know more or less what we're looking for, and we'll evaluate the content once it's been out there a bit longer.

There's an editable version of this on our internal wiki. I'm hoping it gets updated, and that we continue to find it useful. It may well be that this isn't the best way to track our content. I can certainly see it being unwieldy. After all, the SQL Compare content inventory is already a 40 row spreadsheet, and probably about half done.

I freely admit, I'm making a lot of this up as I go along. Any tips?