In previous installments of this Rethinking the Content Inventory series we've covered inventorying content and sites. As many sites become more topic-driven, another crucial slice is by topic. So basically we take an inventory of every topic along with relevant metrics. Take this example of a site that is organized by type of bird:
Topic
Content Count
Has Description?
Pageviews last month
Supply Side
Supply Side
Demand Side
Cardinals
0
Yes
1
Robins
1000
No
100
Seagulls
2000
Yes
5,000
Starlings
1
Yes
1,000
Woodpeckers
10,000
No
20,000
Wrens
500
Yes
20
The columns in this example are the topic name, the number of content items tagged to that topic, whether or not the topic has a contextual description for visitors, and how many pageviews there have been on the topic page in the lst month. In this example, we could use this topic inventory to make a variety of useful observations:
A lot of content is published (and categorized) to the woodpecker subject, and has relatively high pageviews to show it. That said, we are missing an opportunity with such an important topic (for this site) in not providing the context of a description for the topic page.
Cardinals as a topic should probably be dropped.
More should be published on Starlings, since there are high page views based on only one piece of content.
Studying the topic inventory is interesting because:
This can affect publishing schedules, pushing editorial teams to publish to keep quality high.
Provide feedback on what topics are most interesting to readers (other more sophisticated measures can be brought to bear such as how "evergreen" the content on that topic is).
Topics pages in particular can erode quickly in quality, and this gives a mechanism to monitor them.
In a migration, topics pages can sometimes be like "ghost" pages, assumed out of migration discussions since they will be "automatic." That said, there are for example opportunities to cut underperforming topics just like unneeded content during a migration.
As discussed in Sources of Data, one key to an inventory is to use the sources of data that are required to get the information needed for an inventory. In this case, we'll cover information from the Origin (the CMS) and Usage (How content is used by visitors).
Submitted by David Hobbs on 16 February 2012 - 5:45pm
The level of standardization you have as well as the level you want has a direct impact on your migration effort.
For example if your content is currently inconsistent, and you don't care about consistency after your transformation, then the migration is easy. For example, if your data tables each are presented entirely different on each page but you don't care, then migrating is easy. On the other hand, of course if you have high consistency now and want high consistency after the transformation then that is easy, even if you want transformations along the way. The hard part (and it is often worth it!) is when you currently have inconsistency but want to have a more standard approach going forward.
This also has an impact on your inventory effort as well, since if you don't care about the resulting consistency then the inventory may not need to be as accurate for your planning.
Of course, there are many nuances to all this (and the Easy/Hard designation is oversimplified), but hopefully this will help your planning in broad strokes.
---------------
So what does standardization mean? Clients of David Hobbs Consulting dive into the many dimensions of standardization when planning website transformations. Contact us.
Submitted by David Hobbs on 6 February 2012 - 12:50pm
Any website needs focus to achieve ongoing quality, and keeping this focus is a way of avoiding the redesign-forget-redesign cycle. Once you have a sizeable website, you have many voices (for example the owners of different subsites or sections) competing for changes to the website and underlying CMS. You need a way of product managing the implementation, so that you have a productive way of getting feedback. Without this, you could wind up with an unsustainable website, catering to the whims of the loudest stakeholders.
Organizations are tempted to take one of two approaches that get them trapped in a maze:
1. Don't engage (otherwise known as "they first have to give us their requirements") — NOT recommended
The CYA method of the central web team saying "first they have to give us their requirements" is an almost sure sign that there isn't engagement or focus. More sophisticated stakeholders may "win" in this environment, but this will also mean that items without an organization-wide priority will probably be implemented. On the face of it, this does seem like a reasonable approach because after all the central team needs to know the requirements, and who better to provide them than the team needing the requirement? But this overlooks the fact that individual teams probably have many non-web responsibilities, different groups don't know what other groups are up to, and also they do not understand the technical impacts of different requirements (see Developers, Don't Miss The Opportunity). Note that this is related to the approach of doing what stakeholders can pay for, which probably is not good for the organization overall (see You're Willing to Pay for the Feature? So What?).
2. Aimless engagement — NOT recommended
So if we're going to have a more active relationship between teams, then of course you want to go out and talk to stakeholders. But one thing to avoid is having this become aimless engagement, without specific goals and context. This problem can be made even worse if this is a big-bang, one-time engagement rather than setting things up for ongoing engagement. Some problems with aimless engagement are:
Wasted energy on details that will longer be a problem in the future. Stakeholders naturally talk about the thorns they bump against in their day-to-day use of their systems. But assuming you are trying to fundamentall change the way the system works, many of these issues may be irrelevant in the new system.
Poor expectations-setting about the future. Unless the context is specifically set, stakeholders will expect that the issues they raise will be resolved. And, as mentioned in the above bullet point, some issues may not even be relevant in the new system. Beyond that, you may wind up with the anchor of a long laundry list of issues, rather than a focused exploration of underlying required capabilities.
Lost educational opportunity. Engagement should always be a two-way street, and one area in particular that we should focus on is educating the stakeholders (after all, they are educating the core team about their needs). For instance, if you are talking about moving away from Dreamweaver to a CMS, then the current site owners will need to be educated about a CMS.
Instead, I would propose the following approach:
3. Focused engagement — do this!
For focused engagement to work, the following must be in place:
Overall objectives set and understood by all.
Iterative / responsive / ongoing.
Process understood (this does not mean heavyweight).
Everyone has input, and can see the status of their requests.
--------------------
I'll be writing more about defining requirements and also improving engagement with internal teams. In the meantime, you can download this new report: Better Engagement for Ongoing Website Improvements.
The older your site, the more layers of content you have. This is similar to the layers of rock you see when driving through the mountains that have been blasted through for the highway. Some layers may be harder and others softer. On the editorial side, perhaps you had different writing style, editorial focus, editorial standards and general quality under different editors. On the technical side, perhaps ten years ago you were using tables for your formatting, then one division started using Flash extensively, and another group was frustrated by the controls in the CMS so used javascript to rewrite the pages. This information is probably important for your content inventory.
Some of the reasons to capture this:
Cutting content, either as a one-time or ongoing basis. The strata of content may be a key factor in your decisions.
Website transformation or migration. Any time your content needs to change to enable a transformation on your website, you need to understand what the transformation needs will be, and the different layers of content probably need to be transformed differently. To use a simple example, if a whole site section that was created five years ago is heavily Flash-based, then the transformation there may need to beg entirely different than for another layer.
Generally determining the quality. You may want to analyze your quality over time, perhaps even testing the impact of different approaches to content over time.
Before continuing on to ways of figuring out the layers, I wanted to point out why layers in particular is important rather than why you might just do counts of various aspects you want to test (these 10% have Flash, these 25% use tables for layout, etc). The primary reason is that it allows you to better look for patterns (for example, all the pages in this section use Flash and tables). Another reason to group by layers is that these are probably a way that internal stakeholders can wrap their heads around and make solid decisions.
Also, notice in the graphic above that if you look at the side you see slightly different layers than when you look from the front. So naturally what layers you see also depend on how you slice through your site. You may miss some important layers.
Figuring out your layers will depend on the specifics of your web presence, but here are some ways of figuring out layers:
Age. This one is relatively easy to get (although getting the originally-posted date can be a challenge), and, if you're going to slice on just one metric then this is a good one to start with.
Editor. Different editors may have dictated different content quality and focus.
Systems. From a technical perspecitive, the system (or original system if it's already been migrated once) can have a huge impact on the underlying technical content quality.
Content inventories are often considered just long lists of content. In fact, the top Google.com search result on "content inventory" is still the 2002 Adaptive Path article calling them "a mind-numbingly detailed odyssey"). But sites now are often getting way too complex (and big) to plod through every entry.
Many web presences have multiple sites or perhaps subsites or major sections. A multinational consumer product company has sites per country and / or product. Advocacy organizations may have a site per initiative, and news sites will also be broken down into primary sections like Sports.
So instead of a mind-numbing list, your content inventory could be grouped to come up with site inventories like this:
Subsite
Pages
New Template
Popularity
Percentage of pages using most recent corporate-approved Dreamweaver template
Percentage of pages that have received less than five pageviews in the last month
Sports
5000
100%
50%
Celebrity
1000
90%
50%
Europe
1000
90%
90%
World
2000
10%
90%
Politics
3000
50%
50%
Weather
6000
100%
10%
You'll notice that this type of report tells you a lot of information that probably would not be obvious when poking around a laundry list content inventory. For example, you see:
Which sites have a high percentage of unpopular content that are also small and on an old template -- potentially the entire subsite could be dropped for example
Which sites are completely using your newest template -- these could potentially be the first to migrate in a migration project
What sites are large and in the new template but with a lot of unpopular content -- these may be ripe for a new publishing strategy
Part of the point of the site inventory is that it is combining information from multiple sources (the above example table lists some possibilities but there are many more). Obviously, you could look at your analytics to just see the total page views for a site, or even the % of pages on a site that have under a threshold of pageviews per month. But it gets much more interesting when you combine the information, especially when you are considering phasing changes to your site. For example, you could migrate all sites that are 100% in the new template first, then in the next phase move those that have 90%+ in the new template.
A site inventory view into your content inventory of course isn't the only view you need to take. You need to look specifically at high-value content, and may need to slice and dice the results in different ways (such as by content type). But for complex rollout planning or other broad analysis, especially for very large sites which an organization doesn't have a solid handle on, site inventories can help drive decisions.
Note that the site inventory can just be derived from a larger content inventory. For example, if your content inventory has less than a million items, then you can use Excel pivot to aggregate the information (and other tools could be used for larger sets).
