A content inventory is only as good as the data in it, and content inventories often have incorrect data in them. For instance, I have seen a team trying to make content cutting decisions based on an inventory with incorrect last-modified dates in the inventory although that was not immediately obvious to the team. An even more common problem is out of date inventories. Figuring out whether the data in a content inventory is accurate can be tough (at least for large inventories), but here are some ideas for increasing their quality.
First, what are the characteristics of a high quality content inventory:
Each of the fields is correct (as of the time you need to analyze the inventory) for each content item in the inventory.
It contains one row for each piece of content in the site you are inventorying.
You have the information you need to make business decisions about your content.
In this blog post let's concentrate on the first characteristics of a high quality content inventory.
Spot check for accuracy
One of the best ways of checking for content inventory accuracy is to randomly select rows from an inventory and then look at the data to see if it looks right. Just to be clear, I really mean random, meaning that you have a spreadsheet of say 1,000 pieces of content and let the computer pick a random sample of rows (for example, see this random sampler from Add-Ins.com if you’re using Excel). By taking a random sample you are less likely to be pulled to the magnetic areas of your site and see potential problem areas. Once you have your sample, compare both across fields (for instance if the last-modified date is older than the creation date, then you have a problem) and also across content items to look for inconsistencies.
Use the right source in the first place
As always, people usually quickly fixate on a particular tool for creating inventories, but make sure you are using the right source for the data. This may mean joining together data from multiple systems.
Sometimes a quick inventory can answer immediate questions, and this makes sense. But often you need something more permanent. As with many things in life, things that start off life as temporary end up becoming permanent. So when you develop a content inventory at least consider the effective lifetime, and if it is to be short lived then clearly indicate its creation date.
Check aggregated views
In many ways the opposite of the first suggestion above, you can create summary views of your content inventory (for example topic and site Linventories). In an analysis to cut content, this will naturally occur when you are doing what-if analysis to bucket content. Other aggregated views could be histograms of creation dates, and if you see a smattering of content with far different dates than others, then that may be a place to dig around to see if the data is accurate.
Just because some tool gives you a field to include in your inventory doesn’t mean you should include it. If you discover a field is not accurate, and it isn’t essential, then drop the field.
Related to using the right source, you should attempt to automate the creation of your content inventory as much as possible, or create a mechanism to update key fields of the inventory.
Submitted by David Hobbs on 28 August 2012 - 7:48pm
As I work with more and more sites I continue to be struck with how different each site is. One difference in particular can be content froth, or what content is bubbling on the surface of the website. The content that changes frequently can include:
Some sites are very frothy, like news sites that are more like rivers with content flowing onto the site. These sites:
Are constantly producing content (or republishing content from other systems)
Probably have very low traffic to old content
Are particularly concerned about being able to produce content quickly
Need to have mechanisms for the content to appear in multiple contexts (by topic, etc)
Also, although during a transformation old content might be able to be dropped for these constantly-changing sites, the amount of froth means that continuing publishing during website transformation needs to be carefully planned
Other sites are like little inflatable pools, with a small amount of content but you can also easily make a splash in them so the whole thing is frothy:
These sites are asy to create (and probably take down).
The site visitors and the site owners can clearly see all the content.
Everyone clearly sees the purpose of the pool.
It's quite easy to move.
Perhaps the most interesting sites are more like oceans with a large amount of information in the depths that are extremely still:
These sites have lots of still content in the depths, whether or not you can clearly see it (even if there is a lot of turbulence at the surface)
This still content, even if there is a huge amount of it, can be migrated over at your leisure (even months before the "go live" date) in the event of a major website transformation.
There is a much higher probability that a large amount of the content is actually coming from other systems (that can be left as-is during a transformation).
It is difficult, if not impossible, to even get a grasp of the entirety of the site. But ideally you come up with a way to shine light into the content (see the Rethinking the Content Inventory report).
Depending on the nature of the site, there still may be a significant amount of traffic to some of the older, still content.
May have a larger amount of frothy content than a smaller news-driven site, but even with that there is still a huge amount of still content.
Monsters in the depths lurk, for instance old content or sites that people have forgotten about, that, again, may still be utilized by site visitors.
There is probably a lot of content that no one uses and can be dropped.
Large sites are big enough to have different sub-climates, for instance different sites / subsites that are quite unique.
Recently after presenting on the content handling process during a migration, a content strategist came to me and said that they thought that the old content should just be thrown out and rewritten during a migration. If you have a river or a small swimming pool of a site, then sure this might be the case. But an ocean? Probably not.
David Hobbs Consulting frequently works with organizations that are either thought leaders or the global authority on their topics of expertise. These sites must have a depth of content, much of which is evergreen content that is frequently accessed or perhaps as an institution must be made public. Furthermore, this type of content often must be written (or at least carefully vetted) by scientists or other subject matter experts. This content may be therefore be quite still, even if there is a constant stream of new blog posts and other updates. In a transformation, this evergreen content must be retained (even if it is changed to meet new goals).
In summary, consider content froth in your analysis of your site. In the event of a web presence transformation, the level of froth can be an important factor in your planning.
Submitted by David Hobbs on 14 August 2012 - 10:56am
Organizations often jump to solutions when thinking about making major changes to their website. This is frequently because they haven't first thought through the focus of their website. And the response to this shouldn't be saying that any particular discipline should be first. The point is that the first step, before diving into any particular aspect of planning, should be defining the focus of your site. This vision should clearly indicate what your goals are. Perhaps more important, the vision should clearly detail what is not going to be implemented (see Website Migration Handbook for more on vision).
The focus of your website changes should be implementable. RSG's recent "Beware user experience overreach in your website overhaul" and Gadgetopia's "Seduction by wireframe" discuss where user experience is explored before a reality check of whether implementation is possible. Defining an implementable vision does not mean coming up with a full implementation plan before defining your vision, but considering at a high level all the aspects that will have to come together to make the change. One way of looking at the implementability of your vision is to look at it as moving a weight across a distance, and should consider many perspcetives including the toolset, integration points, how the tools were implemented, how the organization manages ongoing changes, metadata, content, templates, functionality, legal needs, relationships, schedule constraints, budget, and others. But the point is to look broadly at what you'll need to do to pull off your vision to see if it's possible. Some effective ways of getting to a more implementable vision is to prioritize your goals if you have a laundry list and also to list the risks to implementing your vision.
You want to aim squarely at the intersection between your desires and the realities you face, obviously prioritizing the objectives that further your business goals. Furthermore, you only want to get to a high level design (and for example wireframes) for those elements that will be implemented in the near term, leaving room for implementation that can react to changes in the future:
Submitted by David Hobbs on 7 August 2012 - 9:35am
Many website strategies are glorious, sold as amazing improvements to get everyone on board, like promising a castle with a moat. Those involved are probably expecting unicorns, butterflies, rainbows and a steady stream of milk and honey.
But then what happens? You wind up with a tent surrounded by water.
This happens when the strategy is either unfocused or was just never possible in the first place.
If a list of desired outcomes were made, perhaps it said "water" and "protection from the wind," and the implementation team could point at these and say that the dwelling got both of those things. But it missed the core underlying need, which is perhaps protection from invasion. But, more likely, the initial strategy just wasn't thought through and a single family home would have been better in the first place.
This happens all the time, in both broad strategies and requirements gathering. In strategy definition, sometimes the vision just isn't clearly nailed down, so in our example maybe everyone is thinking something different: many are thinking about unicorns, others medeval castles, others dragons, some current day ruins, etc. In requirements definition, this can result from an overextended technical team with a weak process, not spending the time to clearly define the requirements, then taking a long time to deliver something that does not meet the client's expectations.
When it comes to travel, I tend to shoot from the hip. I've hit the road in Latin America with a bus ticket to the Mexican border and little else, and spent two years in a Chadian village starting with only a few words of the local language.
Most websites are managed in a similar way. Sometimes this results in great successes. Also, who wouldn't want to be loose and easy with websites. The possibilities on the web seem endless, so who wants to be constrained in any way?
The problem is that once you reach a certain size or have unique requirements, you just can't be so loose anymore. A few years back after having my first child, my family took a trip to Europe and we rushed around with a busy schedule (too much). Images of loading / unloading tons of luggage (required now with a child) on busy trains are seared into my mind as experiences not to be repeated.
This summer we took another European vacation, and we did more planning, including staying only at two locations, even renting an apartment for a week at one location. A bit more boring than deciding every day where to stay like many years ago? In some ways, maybe. But we had a terrific trip, with a base that the kids got to know and we saved money as well.
For me, the transition from very nimble travel to a more planned mode has been tough, but now that I see the results given my traveling party's size and complexity (random kid screaming included) I'm convinced.
But, as with websites, this really isn't about one mode of travel being the "right" one is it? If you're just out of university backpacking around Asia, then sure be spontaneous. If you're single traveling on business, then take advantage of features that might not be worth it to the backpacker (like taking a taxi ride straight from the airport to hotel, rather then a series of public transportation that might make sense when backpacking). If you're traveling with a family, then maybe a more planned approach with less stops makes sense. But the point is that there is no single "answer" to the best way to travel, like with websites.
On a website, sure some websites can be managed by a single person. A site with tens of thousands of pages needs to be managed (or transformed) differently, as does a site with hundreds of thousands of pages or more. But, it's not just page size that makes one site different than another. Just like the young backpacker and seasoned business traveler are traveling alone but with very different needs, so are websites with the same basic page count. Other elements that can add to the complexity include systems being intergrated as well as the number of subsites (take a ten question self-evaluation to get feedback now, including a customized reading list).
It's time we stop acting like all websites are the same, and giving each other one-size-fits-all (or one-tool-fits-all) advice.