Hobbs On Tech -- All Blog Posts

Rethinking the Content Inventory: Topic Inventories

David Hobbs — Thu, 26 Apr 2012 21:30:28 +0000

This is the fifth blog post in a series on Rethinking the Content Inventory -- also see Exploration, Sources of Data, Site Inventories, and Layers of Content.

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).

--------

Want to read more about effective topic pages? Read the new report.

Also, Tim McGovern and I presented on how the Heritage Foundation is improving their topic pages at J. Boye Phillie in May 2012.

Unexpected Responses to Requirements

David Hobbs — Thu, 15 Mar 2012 21:41:08 +0000

At the World Bank, I was product manager for the content publishing platform for the thousand+ World Bank sites and we had a seemingly-endless list of requests from the hundreds of content contributors for improvements. The list of requests always grew more than it shrank. One time, the lead developer said he had an idea to completely change the first page people saw when they logged into the CMS. But no one had asked for this. I have to admit, I was nervous about prioritizing this change over our huge backlog of requests. In the end, we went with it. Guess what? The CMS users were thrilled. It helped both power and occassional users. And no one complained that item #428 or whatever wasn't implemented to make room for this change.

There are probably lots of lessons to glean from this little story, but the one I'd like to emphasize here is that it's ok to give an unexpected response to the "requirements" that you people may lob at the central team. Sometimes it's even ok to ignore what people are saying and instead give them what they need. They might be delighted (at least for a while!) rather than everyone complaining about request numbers. Of course, this requires finess, skill, and a bit of luck -- and you can't ignore your stakeholders in general. But when getting into the decisions of what gets implemented, listening to the deeper needs of the teams are more important than literally what everyone is saying.

----------------------

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.

Mobile Content Resolution

David Hobbs — Tue, 13 Mar 2012 16:26:32 +0000

Image resolution is obvious: you know the image needs to be smaller on a cellphone than when it's viewed in a full size desktop browser. Actually, changing image resolution meaningully isn't entirely straightforward but we'll come back to that in a bit. On the other hand, let's consider textual content. This also has a resolution in a sense: the full War and Peace text has extremely high resolution, but to say "War and Peace is about the inevitability of history" or something is much lower resolution. In this post, I'll concentrate on the ability to generate the different resolutions, and not about technologies needed to detect and serve up the content.

You don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem.

Let's start by using some images as an example. On this blog, every post has an image in two versions: a) the full size that appears in the post itself, and b) a smaller 220x120 image that is used by navigation throughout the site. Look at this example of two smaller sized images:

The microphone is simply a resize of the entire image, since the image is focused on a single, easily-recognized object. The table, however, is an entirely different crop since I wanted the text to be readible.

So these examples demonstrate two properties:

For the microphone, there is a high degree of similarity -- in other words, anyone looking at the large and small images see it's exactly the same thing.
For the table, there is a high degree of readability, which is also the case for the microphone. But one required a different cropping to accomplish it.

Now let's consider another factor: 3) relevance. In other words, is the image relevant? In the case of the table, it is necessary -- the blog post does not even make sense without that table (obviously also an accessibility problem). In other words, there has to be a way to present it, or another representation of it (perhaps just in text). On the other hand, the microphone isn't necessarily required at all -- it reenforces the theme but it is not necessary.

Before we continue on to text, note that all of this is a question of quality against the technology and your resources (sure by hand by skilled Photoshop users may result in the best resizing, but it isn't worth it at a certain scale). Obvious really, but the quality level usually seems to be backed into rather than carefully considered in advance. For small sites, including the Hobbs On Tech blog, this probably doesn't matter much. But for large and huge sites this is a more important trade-off to weigh.

For text resizing, let's start by looking at this Website Migration Handbook download page, which had unexpected consequences (to me) of long filenames:

I actually changed around the naming of the filenames to make the format of each clear in this rendering (so that "mobi" etc was at the front of the name). Although perhaps an extreme example (it was silly to have longer filenames in the first place), I think this points to another problem that I haven't seen discussed yet: until you see your content in a new context, you don't really know what its needs will be. And here's where a big difference between text and images come into play: unless you go down to extremely low resolutions, chances are that an automatically-resized image will still make some sense. But at some point earlier the text becomes meaningless (for instance if the epub, mobi, and pdf text wasn't at the front of these filenames).

All of the above examples are where the content producer also had control of the display. The problem: In general, you don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem.

Text may need to be resized in whatever field it appears, including common ones like:

Title
Filename
Short description
Full text
Metatags

Although tools like Teragram may be able to resolve some of these text resizing issues (for instance taking the full text and giving an abstract) for larger organizations, in general the resizing of text cannot be automated. Truncation is obviously easy to implement and the most common approach, but less useful (no one would accept this approach for images, just taking the first 50x50 pixels from the upper left of an image and saying the image is resized).

You Don't Know the Resolution In Advance

The problem here is that you don't know what resolution your content will be served at. Here are some things you can do as a content provider for text:

Test end-to-end on the platforms that are of particular interest to you
Put as much meaning in the front of each text field (important words first in title, more unique or important metatags first, etc).
Place relevant (especially crucial) images closer to the top of the text
For displaying the content on pages that you control, you can intelligently change the treatment of fields at different resolutions (title always appears, but full text doesn't appear on the first page of a piece of content at small resolutions)

Unfortunately there isn't really that much on the provider side that you can do. Any other suggestions?

If you are displaying other people's content, then you could at least set and publish the standards for the maximum characters, words, or other metrics that each field will display. Then providers could decide whether to tailor their feeds to you to your renderings.

Standardization and Migration Effort

David Hobbs — Thu, 16 Feb 2012 21:45:14 +0000

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.

Migrating Mass.gov: An Interview with Bill Trevor

David Hobbs — Wed, 08 Feb 2012 17:42:21 +0000

Bill Trevor was the Project Manager who led the Mass.Gov effort to replace the Web Content Management System, visual design and navigation. He is a consultant specializing in Information Architecture, Website Migration and Optimization, Project Management and Social Media Marketing. His views are his own and in no way represent the views of Mass.Gov or the Commonwealth.

You migrated 26 sites and around 700,000 content items into your new CMS, and some of the sites were previously on other platforms. How did you coordinate with all of the stakeholders? What were the initial discussions like, and how did you stay engaged throughout the process?

With any project (especially one of this size) communication is key. We held frequent stakeholder meetings at both the migration coordinator and senior management levels for each of the 26 sites. We formed a "migration liaison team" that included one representative from each site to ensure information was broadly communicated. We also leveraged a wiki so stakeholders could receive notifications if there were any updates related to the migrations.

A primary goal of the project was to maintain one platform that easily presents a single view for web users looking for information on Massachusetts government. Was that goal met? Why was a new platform needed to make that happen? How did you convince people to move to a single platform, and how much variance did you allow between websites?

Since its inception, Mass.Gov has been focused on maintaining a single face of government. The goal of this mantra is to create a state website that constituents feel comfortable navigating around, no matter the agency/department providing the information they seek. Too many state websites have a "single facing" homepage only to disperse into as many different websites as there are agencies. Mass.Gov takes the opposite approach and as far as I can tell, is doing it the best. The new Content Management System (CMS) will enable Mass.Gov to keep that guiding principle true while allowing some flexibility to content authors to slightly alter their web pages without losing that single face. Constituants want to be confident that the site they are visiting is an official state sanctioned site and Mass.Gov makes that happen. The Commonwealth of Massachusetts continues to pursue the goal of IT consolidation. Why not offer a single enterprise level CMS instead of having 160+ different systems, visual designs and site navigation structures. This website consolidation has been in the works for many years (termed Portalization) and the new CMS will allow Mass.Gov to continue the push to bring more sites onboard.

How different is the experience now for web users looking for information from Massachusetts government?

While it may have been an ambitious project, Mass.Gov saw the replacement of the CMS as an opportunity to also update the visual design (4+ years old) and the navigation schema (7+ years old). The prior versions of the Mass.Gov site templates were very rigid, narrow and leveraged the old Yahoo category navigation schema. You know, the one where you saw topics, clicked them, saw sub-topics, clicked them and so on and so forth. Mass.Gov has introduced a modern mega-drop down, in the same style of ESPN or Target, quickly exposing level 2 and 3 topics from the banner on every page. Another addition is a similarly fashioned left navigation that allows users to expand a drop down menu from the left column to get a peak at what content lies beneath that category. These features reduce "number of clicks" and help to flatten the information architecture. We put a new "modern minimalist" design on top which offers more space for agencies to showcase content along with an easy to maintain slideshow template and a wider page layout.

How did you develop content inventories, and what did you discover when you did them?

We used everything we could find. Some agencies kept good inventories of their own and we leveraged those. We also used free tools like Xenu to spider sites and export the findings into excel to obtain a comprehensive view. For better or worse, the old CMS was a very linear tool and so it was a lot of work but attainable to export the navigation structure from the old site and dump that into the new tool to build the underlying folder structure. One thing to note, most agencies saw this as such a large project to simply move their existing content/navigation into the new CMS that few took the opportunity to redo their IA. We did, however, try to get agencies to see the value in a pre-migration ROT (redundant, outdated and trivial) analysis because the less content you migrate, the less you have to QA/tweak.

What simplifications did you make the project a success?

Keeping the scope in focus and using it as the barometer for any requested change. We used our daily scrum (15 minutes) to update each team member on what we accomplished yesterday, tasks for the current day and to discuss any issues blocking progress. These meetings kept team members honest and ensured everyone was on the same page. I also cannot stress the importance of a parking lot page and Executive Sponsorship. We had great support with the upper management circles who really listened when something came up that might derail us and helped to determine an effective resolution without busting scope.

How much of the migration was automated and how much was manual?

We had really great partners from the CMS vendor (Percussion) and a rocket scientist (well he was considering becoming one) who did the automated migration. Again, we did a lot of research and heard the horror stories about how poorly content migrations ended up but I can say that the automated portion of the project *fairly* cleanly migrated 85% of the agency content. This included documents and images. There was some content that may have gotten lost in translation but the vendor did a great job translating the old to the new. It was no small feat and only caused minor delays. We knew the cleaner the content was after it migrated, the less work the agencies would need to do prior to their site going live.

How much was dropped from the old sites?

Because the old tool had a separate navigation component, Mass.Gov knew exactly what was live on the old website when we took our final content snapshot. Mass.Gov migrated every web page that was live at the time of the snapshot and the numbers of pages dropped due to issues was probably less than 2% of 400,000 pages. This was most likely due to malformation in the page code.

How did you track progress as you went forward?

We used every resource we had at our disposal! Scrum was a tremendous help. Our main tracking methods were MS Project, our Wiki and Sharepoint. We leveraged MS Project to track milestones, resources, critical path and high level project points to senior management. Our Wiki was the main communication mechanism for our stakeholders as they were able to comment, ask questions and view schedules/timelines in real time as the project evolved. Internally, we leveraged Sharepoint as a means to track issues / bugs / fixes during the configuration and implementation of the CMS.

The old saying goes something like "You have your choice of schedule, scope, and cost -- pick any two." How did you do against schedule, scope, and cost?

Scope was always a challenge but we kept focus via daily scrum meetings and constant sessions with our stakeholders. The schedule did take some hits to ensure the product was scaled appropriately and that the content was migrated as clean as possible. This did not result in a significant delay and by the time we launched the first websites on the new platform, we were within the margin of error for our original project plan we drafted some two years prior.

If you could do it over again, what would you change?

If time was not a factor (we were dealing with fiscal year funding deadlines at times) I would have preferred to have spent more time analyzing website Information Architecture. Due to the enormity of migrating to a new toolset (fear of the learning curve) we recommended that agency staff focus on QA'ing the content that migrated and getting comfortable with the CMS. I still believe that this was the right decision but some sites are now looking to overhaul their IA.

What were the biggest constraints you had, and how did you overcome them?

I think the biggest challenge is that Mass.Gov is the top level website and maintains the CMS tool but does not control the governance model used by the 26 sites. While not a bad thing, it was challenging to get agreement and consensus on some aspects. In the end, we had a very strong communication model that served us and our stakeholders well. Absent this, we might still be migrating websites.

How is Mass.gov set up for ongoing management of the site? How many sites are still on the horizon to be moved to the new platform?

Mass.Gov took great care to develop authoring documentation and posted it to the Wiki. This way, it is available 24/7 and is continually updated by the team. Gone are the days of printing out a training manual as the minute it is printed, some aspect is out-of-date. Mass.Gov is also working to make short video tutorials that authors can watch to see click by click how different content components are created. Now that the CMS is in production and the original sites have launched, the next phase has commenced and "portalization" of state entities not on the CMS platform has begun. There are several large sites outside the Mass.Gov platform and the hope is to migrate as many as are willing to leverage this enterprise CMS and join their fellow agencies in expanding the single face of government.

--------------------------

Are you a website owner with a migration success (or failure)? HobbsOnTech will be featuring interviews like this one to help provide a repository of experiences that others can draw upon. Please contact us if you would like to participate.

Focused Team Engagement and the Alternatives

David Hobbs — Mon, 06 Feb 2012 16:50:26 +0000

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.

--------------------

Pushing Continuous Website Improvements: Posting It On a Wall

David Hobbs — Tue, 06 Dec 2011 19:23:33 +0000

Pushing through ongoing changes on a website can be tough, whether it's because of inertia, other priorities, politics or other reasons. Although there is no single magic potion, one thing can help, and that's prominently posting your near-term work program (which should have short delivery cycles). Basically this would be listing out your upcoming work program, stating what you will be implementing when. This could be on your intranet, in an email newsletter, on the main CMS login screen, or some other place that all internal stakeholders could easily see.

Below are some of the advantages of boldly posting your work program on the wall.

Better engagement

As soon as you post what you plan on doing over the next few months, people are sure to provide their feedback. Since at first this feedback will probably be less coordinated than as you improve your processes, you probably will want to start with items that you are very confident in fixing and that have wide support. At any rate, you will increase engagement by clearly indicating what you plan on doing (and hence what will not be done as well).

More reasonable work program

By publicly posting the work program, everyone will hold you accountable for it. This is good all around, but specifically it will naturally force you to suggest a work program you are confident in. Also, since everyone will see the breadth of what you are doing (rather than simply the potentially-small sliver that they are concerned about), then all stakeholders will better understand why all of their requests may not be possible to resolve. See Product Managing Your CMS: Defining the Work Program for more on the inputs into your work program.

Better clarity

Also, you will need to be much more clear about exactly what it is you are saying you will do. Vagueness will burn everyone but especially the owner of the work program. People may think your "fix UI" meant far more than what you meant!

Higher confidence

Even if you end up not delivering 100%, the stakeholders will respect that you stood up to say what you were going to do, and then standing up again to update on what you did and did not accomplish. Of course, the highest confidence will be attained by consistently delivering on your promises, which then will also have the effect of less complaints on an ongoing basis.

More focus

It's easy to be vague when having distributed conversations with a wide range of stakeholders. But when you publicly state what you are doing, it will both force the person defining the work program to be more focused but also focus all the stakeholders on the near-term objectives.

This is something that can be done by event the smallest team, but is also highly relevant for large organizations.

--------------

Need help improving your website on a continuous basis? Contact David Hobbs Consulting.

Rethinking the Content Inventory: Layers of Content

David Hobbs — Fri, 11 Nov 2011 14:25:18 +0000

This is the fourth blog post in a series on Rethinking the Content Inventory -- also see Exploration, Sources of Data, Site Inventories, and Topic Inventories.

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.
Site sections. Different subsites / sites / sections may have evolved separately (also see Rethinking the Content Inventory: Site Inventories).
Scraping. Sometimes you just need to scrape content off of the page.
Template versions. If you have consistently used a tool, then you may be able to see what template version they were on.

So don't just concentrate on the pretty green layer at the surface, but dig into your content to see the layers you've accumulated over time.

-------------------------

Version 2 of the Website Migration Handbook is about to be released. Sign up to get notified with a discount code when it's available.

Migrating NationalJournal.com: An Interview with Chris Contakes

David Hobbs — Wed, 07 Sep 2011 14:47:51 +0000

Chris Contakes, CTO of the Atlantic Media Company, led the technology migration of National Journal Group from a variety of platforms to Nstein in less than a year from concept to launch October last year. National Journal Group is an online and print publisher of in-depth non-partisan news and analysis covering politics, policy, and issues in Washington. National Journal Group’s flagship publications include National Journal Magazine, National Journal Daily, and The Hotline. The business embarked on an aggressive new digital strategy in 2010 to increase reach on the free side of the site and increase utility behind the paywall for subscribers. Executing the new strategy called for a complete overhaul of the technology infrastructure delivering National Journal content. Chris and I first met at a DC Web Content Mavens event and stayed loosely in touch throughout the migration. Before the National Journal Group Chris played the role of Manager of Content Management Systems for WashingtonPost.com. Below is an edited version of a conversation we had at one of my favorite Capitol Hill restaurants, The White Tiger.

Why did you migrate to a new platform? And how deep of a redesign from the end user’s perspective was needed to meet that vision?

Our in-house platform wasn't scalable and flexible enough to meet our needs as we transformed to a digital first publication. Our aggressive plan called for a launch in the fall which gave my team less than 5 months to migrate and build the new site. We decided to execute with a solution that did a lot of great things out of the box and would flex to serve our strategy.

We needed a system that could scale for growth, be flexible to integrate with a sophisticated paywall system, be able to support multichannel publishing (web, mobile, native iPhone / iPad (download) etc.). We also designed a sophisticated reader experience for visitors on the site. For example, one of the goals of the strategy called for no "dead ends". In other words, visitors should be able to access anything they can see and not see anything they are not entitled to (do not subscribe to) on web and mobile devices. Building this type of functionality into a native iPhone app required APIs for us to surface access control rules for content requests.

Going into the migration, one of your biggest challenges was adding more refined metadata to allow advanced browsing by your subscribers. How did you approach that issue?

During the demos, we were impressed by Nstein's text mining capabilities and were planning on using it for dynamic tagging. That said, since the editorial process already included tagging to publications (for instance, four editions of Hotline per day) and major topics (like National Security), the editorial team still tags manually to these primary channels. Nstein is automatically tagging to IPTC topics and surfacing these topics via the Solr search experience. During the migration, the old taxonomy values were mapped to the new ones. We used these rules to build migration scripts for the content.

How much of the migration was automated and how much was manual?

We have 30 years of editorial content including videos, articles, and podcasts. The 600,000 articles were automatically migrated using custom scripts. There were also data-driven portions of the site such as the Almanac of American Politics. In these cases the content stayed where it was with the new templates pulling in the existing data.

How much was dropped from the old site?

Most of the content was migrated, although some editorial features didn't migrate based on strategic decisions such as were the features were performing well and staffing decisions.

What was your biggest surprise?

The complexity of the 30 year archive was a surprise, with the content developed on changing systems with different writers and web producers over time. This meant that over time content having non-standard features (like iframes). We carefully babysitted the scripts, analyzing exceptions that the scripts reported. We knew there would be holes in some pages, but our objective was to move 98% without exceptions in time for launch. We then had a spreadsheet of the exceptions that the editorial team worked through in the weeks after the launch.

How did you deal with the aggressive timeline? We first met six months before your relaunch, and at that point you were still selecting the CMS. Since the president gave an interview mentioning the aggressive schedule, you were on the hook to deliver to it.

From the top down, our organization was focused on executing the strategy that we laid out earlier in the spring. The technical, editorial, and business teams were almost completely focused on the new website, with long workdays and weekends the norm leading up to the launch. The developers knew they were working on something impressive and remained focused on a successful launch. We also used some professional services from the Nstein team to assist where we could silo off development projects for extra bandwidth. We also did have to do some things that were not ideal. For example, the aggressive schedule meant we couldn’t spend a great deal of time on workflow design in the backend with the actual users that would be using the system for publishing. We relied on a lot of quick thinking and using workflows out of the box where we could with an understanding that we would refine in the future.

--------------------------

Rethinking the Content Inventory: Site Inventories

David Hobbs — Wed, 24 Aug 2011 18:52:07 +0000

This is the third blog post in a series on Rethinking the Content Inventory -- also see Exploration and Sources of Data, Layers of Content, and Topic Inventories.

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).

----

If you are having a hard time doing this for your web presence, please contact David Hobbs Consulting.

Product managing your CMS: defining the work program

David Hobbs — Tue, 05 Jul 2011 21:14:34 +0000

Any CMS implementation with a large number of stakeholders will generate far more requests than could ever be implemented. So how do you determine what gets onto the work program and then implemented?

There are several streams where potential features could get added to the system:

User requests (either internal or external)
Stability / security
Performance / scalability
Hardware / infrastructure
Long range requirements

So even an important user request may not make it onto your near term work program if, for example, there is a severe stability issue that needs to be addressed quickly. So there is something of an air gap between the requests coming in and what winds up on the work program. This is one of the most important roles of the product manager, and the product manager needs to consider the following factors.

Backend needs

As mentioned above, key security, scalability, performance, or manageability issues may trump any other requests. Notably, these may be items that your key stakeholders may not be aware of, much less actually requesting them.

Batching

Your near-term work program needs to be consistent, meaningfully grouping changes. This is both for communications and technical reasons. From a communications perspective, if the items being addressed are consistent then everyone can quickly understand what's happenning. From a technical perspective, if you need to completely rewrite a subsystem to address and issue then it might make sense to address many of the issues with that subsystem at once.

Resource constraints

Obviously you need to have the resources to implement your work program. This is both for a raw number of hours as well as balancing key resources. For instance, if your DBA is required for many requests then you may be able to only do some DBA-limited requests at once.

Popularity

Of course, the popularity of a request is very important, but, again, not the only factor). All other factors being equal, a more popular item should be placed on the work program before others. In practice, it may make sense to delay your top-requested feature in order to address the next three (for instance if the next three could be implemented in the same effort as the first).

Note two factors that are NOT listed as factors:

a group being willing to pay for certain functionality (see the previous blog post You're Willing to Pay for That Feature? So What?)
the length of time that an issue has been discussed

In the end, the product manager must be able to justify the work progrm to the stakeholders. Although clearly more of an art than a science, the factors (and non-factors) should help in forming that solid work program.

--------------

Need help managing your CMS implementation as a product? Contact David Hobbs Consulting.

Better Topic Pages: When Topics Lists are Too Much of a Good Thing

David Hobbs — Thu, 19 May 2011 00:30:26 +0000

Far too often, teams get so excited about the possibility of automatically-driven topic pages that they wind up with an overly-complicated topic list. It seems so easy, what with the possibility of one template simply being driven by tags to generate lots of topics pages. Why can a complex topics list be a problem?

More difficult to tag well

Unless you are going to have dedicated librarians tagging your content consistently (or librarians managing the rules for doing automated tagging), the more complicated your taxonomy the more difficult it's going to be to tag well.

Less likely to be a good taxonomy

The larger your taxonomy, the less likely it's going to be consistent, correct, and not redundant.

More likely to be bureaucratic or overly-technical

Once you open the floodgates to a large taxonomy, you are far more likely to have it represent internal interests than those of your site visitor.

Harder to migrate

If you're making the topics list more complex in your target site during a migration, then you need to have a way of tagging it to this new list, and a complex list will be more complications for that migration.

As always, what the right level of complexity for your organization may be too complex or too simplified for another. After all, the whole reason for your migration may be more thorough topics pages. That said, keep in mind the downsides of a more complex taxonomy when designing your system to help ensure you don't end up with an unreasonable topics list.

Content Handling Process: Asking the Right Content Migration Questions

David Hobbs — Wed, 20 Apr 2011 17:25:31 +0000

I realized that something I've been talking a lot with clients isn't yet on the Hobbs on Tech site: the content handling process. In addition to this blog post, please also download a short pdf exploring these steps in a bit more detail, along with an example analysis to flesh this out more.

What questions are being asked at each step:

1. Sort: what am I going to do with this content?
2. Place: where is this content going?
3. Edit: does a human need to edit the content itself (not the HTML)?
4. Move / Transform: how is this content going to be moved / transformed?
5. Enhance: Do I need to enhance the content's metadata?
6. QA: Actually confirming the migration was reasonable quality

Even without a deep analysis, you can get a feel for the type of process you have before you by considering these steps and your approach. Some sites will have no sorting at all (moving all content), while for other sites this may be a significant part of the entire effort. Similarly, placing content may be obvious if you're keeping the exact site structure. So if some steps seem irrelevant, those may be areas where your migration is simpler than others. That said, all of these decisions can change during planning.

Also note that aside from the Edit step, there's room for automation at every step. But most focus is on the Move step (and usually with minimal transformation), with people thinking about how the content is going to be rammed into the new system (and hence criticisms like Web content migration: disastrous strategy). Consider automation for each step, but make sure it will lead to the quality level you need.

For more on the content handling process, including an example simple analysis, Check out the report. Related blog posts include:

-------------

Need help in planning your migation? Contact David Hobbs Consulting.

You Can't Get There From Here

David Hobbs — Tue, 08 Mar 2011 17:51:37 +0000

There are many components of a strong implementation strategy, but one key goal of an implementation strategy is simply to answer this question: "Can we get there from here?"

Problems with ungrounded strategies

Many impressive-looking website strategies (or even website designs) have almost no grounding in reality. The pressure is often to think big and be as forward-looking as possible, but no one looks good if you cannot implement it. There are many problems with an ungrounded strategy including:

By shooting higher than is possible to attain, you are far more likely to wind up with an inconsistent implementation
Higher likelihood of an orphaned site (maybe it's possible to launch the thing quickly, but not maintain it effectively)
Greater risk of total project failure
Uncomfortable internal discussions about expectations vs. reality near launch

Elements of a strong implementation strategy

Here are some of the main things that can effect whether your goals are attainable:

Focus. This is far harder than it appears, especially for large organizations. Be realistic about whether you can really focus your efforts, because that will have a dramatic impact on how attainable your goals are.
Clarity. You can be completely focused on one goal, but be unclear about exactly what you are attempting to do. Hazy thinking about problems and their solutions is also an easy way of not reaching your goals.
Ongoing support. Are you organizationally committed to maintaining the site after implementing the big changes?

The point is to weigh all the conflicting factors in aiming for a goal that is both high impact and feasible. For example, if you know you cannot focus the effort, then perhaps the level of ongoing support will be even more important and the goal should be set a bit lower. If you can be focused and are quite clear on what you want, then that goes a long way toward a more ambitious set of goals.

-------------

Need help developing or evaluating an implementation strategy? Contact David Hobbs Consulting.

Topic Pages: Fruit Can Be Different Colors

David Hobbs — Fri, 11 Feb 2011 11:56:55 +0000

Many sites are largely organized around topics (as oppossed to, say, the org chart or products). But there are plenty of nuances to having successful topics pages, from dealing with political issues (when should a new topic page be created) to functionality options (how should topics pages be managed) to the metadata concerns. If creating automated listings on topics pages, consider this:

You can only have automatically-pulled topics listings if there is a one-to-one or many-to-one relationship from your source metadata tags to your target groupings.

This probably sounds a bit too academic, so let's look at this in concrete terms. Let's consider the case where you have a bunch of articles tagged to either broccoli, apple, or orange. If you wanted to have a vegetable topic page and a fruit topic page, then this would work fine. This is because you have a one-to-one mapping from broccoli to vegetable (broccoli is always a vegetable), and a many-to-one mapping of apple and orange to fruit (both apple and orange always map to fruit and nothing else). That said, you cannot have red and green topic pages based on the existing tagging. Broccoli is always green, so if the only tags you had were to broccoli then you would be fine. But the apple tagging is the problem: an apple can be either green or red. Obviously, you could introduce a new color tag, but if you had a large number of existing pieces of content then you would have a large amount of retagging to do.

This may be obvious when looking at three tags and a handful of possible topics pages. But when looking at larger repositories and the possibility of creating topic pages with some automated pulls, consider the mappings to ensure you end up with relevant topics pages.

--------------------------

Need help setting up or fixing the processes, functionality, metadata, or other aspects of creating topics pages on your site? Contact David Hobbs Consulting.

Migration Isn't Great Training

David Hobbs — Thu, 06 Jan 2011 14:48:50 +0000

Does manually migrating into a CMS help train users? It can, but it isn't great training on it's own and in some ways can be detrimental from a training perspective as well (in particular in forming a positive impression of the tool). Note that this was explicitly left out of my previous post on making a decision to migrate manually or automatically since the training aspect really is not a slam-dunk positive in my mind. Let's start with the cons of migrating as training.

Cons

First, the cons that are listed in version one of the Web Site Migration Handbook (page 26):

Much of the migration effort, especially for a large migration, will not be done by the same people who will be using the system on an ongoing basis (so you're not training the right people anyway)
The problems of migrating are different than day-to-day, ongoing efforts
May set the expectation of very wide / distributed content entry, when on an ongoing basis a more centralized team may be better
Tool probably not ready, so users will probably get frustrated (not an ideal training situation)

What are some other disadvantages?

May not have the opportunity to train on subtle but important aspects for long term success (for instance, strong metadata tagging) -- another way of looking at this is that everyone, even those with good intentions, will have tunnel vision on the tips / tricks to ram in as much content as quickly as possible
Loss of enthusiasm for the tool based on massive repetition (even if tool is strong)
Little training on creating content from scratch, which may be a more common use case (rather than, for example, cutting and pasting)

Pros

It's not all dark and gloomy, and you certainly want to optimize the training aspects of whatever manual migration does occur. So here are some positives to training during a manual migration:

Practice cutting-and-pasting content -- depending on the environment, this may be either a common or uncommon situation on an ongoing basis
Practice creating navigation
Quick and early feedback on user interface issues
Quick and early feedback on your training program (your training documentation, processes, help screens, etc)
Ensure people have the right access to their websites earlier in the process

Will manual migration be good training for you?

If you have a small site, and you won't need to bulk up with a large number of external, temporary folks to do your manual migration, then migration will probably be a good component of your training. If your site will be able to use your CMS content contribution interface as-is, then there's more liklihood that you won't alienate people early in the process. The equation for large sites is much different, since the cons listed above will be more of a factor. That said, by all means take advantage of the training opportunity of the migration if you decide to do so manually. I just wouldn't overstate the training advantages in that case.

What are your thoughts? What pros / cons do you see? What are your experiences?

----------------------------------------------------

Need help planning your migration or training program? Contact David Hobbs Consulting.

Should you automate your migration?

David Hobbs — Wed, 05 Jan 2011 02:00:22 +0000

Automation is a worthy goal, and I'm always looking for ways to automate migration where possible. That said, obviously there's a tradeoff between automation and manual migration. For instance, if you have a site of ten pages then don't even waste your time talking about automation and buckle down to copy and paste into the new system (or just create the new content from scratch). At the same time, if you have a site with 500,000 pages that you want to keep, then you probably want to spend a lot of time talking about automation. So how do you know whether to pack up the pickup truck and move yourself, and when is it time to try a more sophisticated approach? The following should help in your decision.

Evaluating whether to automate

What are some of the factors in deciding whether to automate or not?

Commonality

How consistent is the content you will be moving in? This one can be easy to ask but difficult to answer. Much of the discussion of a migration is looking for patterns, so this isn't literally about whether 80% of the content on a current site is driven by the same template (although that helps). For example, if your current site is not in a CMS but still every page consistently uses H1, H2, strong, and em tags then you may be able to scrape out the information you need.

Structure

The structure of the content / pages on the source and target system are also crucial, since this will determine how much transformation is required (and, notably, whether people will need to edit to get there). In the example above with the content that has common usage of H1, H2, and some other tags, that commonality is useful only if it maps usefully to the target structure. For instance, if the target system is highly structured but the source system is not, even if it's common / consistent then it may not help you much in automating your migration.

Editing requirements

When considering the vision of your site after migration, you may necessarily need to modify a swath of content purely for editorial reasons. Obviously, this is a big argument for manual work, although it may just mean a modification of the process such that initial migration is done in an automated fashion but regular editorial work is done after initial technical migration (or other process changes may be needed).

Staffing

If you have a large and distributed publishing community, then even a large number of pages may be able to moved fairly quickly. That said, this does necessitate a fairly polished publishing system earlier in the process.

Raw count

Obviously, the more content you have the more likely automation will make sense. But there's one very important nuance here: it's the count of *similar* content that matters. In other words, if you have 10,000 pages but 100 groups is each managing completing different sets of 100 pages each, then it may make sense for each group to manually move their content!

Advantages of automation

Iteration

Almost by definition, automation means repeating runs of migration until you work out the kinks in your automation rules. This is completely different with the manual process, where people are much less likely to go through all the content again to make an improvement only realized later in the process.

Cost savings with consistent content

This is probably the key reason organizations look to automation. With the right level of consistency, source and target structure, and number of content items to be moved, automation can bring cost savings.

Consistency across large amount of content

Related to the point on iteration above, it's easier to have a consistent level of quality across a large amount of content, since you do not have to train a large number of users that might be treating content differently.

More likely to see patterns that can be applied on an ongoing basis

The most interesting aspect of a migration is searching for patterns, and many of these patterns can be used on an ongoing basis.

Less dependency on the publishing process being perfected

One of the key aspects of CMS acceptance is the publishing experience for content providers and site owners. With automated migration, this publishing process does not need to be as perfected before migration starts.

Advantages of manual

DIY

You can start as soon as editing tools are in place. Also, there's no need to engage with the technical team.

Budgeting

It may be easier to get the budgeting in place for manual migration than for an automated migration project, especially if you already have access to a pool of content contributors that could work on the project.

Built in editing

Especially for a smaller set of content, you can ensure that human editing of the existing content occurs during the migration (although for larger migrations getting consistent quality may be difficult).

Built in QA

If someone is staring at the content during migration, then nominally they have a chance to QA whether the migrated content looks good. Note that this means that the output templates need to be complete for a solid QA during migration. Also, this works best when the same people who are migrating the content also own the content, which may not be true.

---------------------------

Want a worksheet to help in your decision of manual vs. automated? Subscribe to Ten Weeks to a Better Migration for weekly action-oritented information and excercises to improve your migration effort.

Rethinking the Content Inventory: Sources of Data

David Hobbs — Thu, 04 Nov 2010 15:20:57 +0000

This is the second blog post in a series on Rethinking the Content Inventory -- also see Exploration and Site Inventories, Layers of Content, and Topic Inventories.

Many descriptions of content inventories seem to be focused on small sites (that can effectively be clicked through to generate a clickmap) or use a tool to quickly scrap together whatever information a tool like Xenu linksleuth can generate. But both approaches focus on only one aspect of content: how site visitors see the content! Obviously, this is a crucial element, but it misses many key aspects that might help inform whatever content decisions you are trying to make (that is the reason to do an inventory, right?). Some useful sources of data for a content inventory are:

View, or the content as views by the visitor (usually, what they see in their web browser)
Origin, or information that the source system such as a Content Management System contains, such as the number of versions a piece of content has gone through
Usage, or how the content is actually used by visitors, for instance whether anyone is actually reading the content at all
Intent, or how well the content quality (and qualities) match your site intent

View

This is probably the most obvious one, since it is mostly about the view that all of us can understand: what the content looks like in a web browser! Looking under the hood a bit can be helpful however, since the actual HTML can lend us interesting clues as well (such as the structure which lets us know if an old template is being used for a particular piece of content). Also, there are items like status codes that the server returns and many tools will report back.

The View as seen by the user is helpful, as is the HTML

Origin

So far in the discussion of View, we have glossed over an important point: content can appear in multiple places on one site, and also across multiple channels. This means that even when considering the Views as a source of content inventory data, you may wish to compare how the content appears in multiple views. But regardless this leads to another important point: the origin system is an important source of data for your content inventory, especially in multi-site and multi-channel situations.

Even in simpler cases, the origin system has a lot of useful information. In cases where there is no CMS, using file system data such as creation dates can be helpful in your analysis. In a CMS, other information such as last updated date, first creation date, original author, and topic tags could be useful.

Example information available from a CMS

Usage

How your content is being used would probably be quite useful in your content inventory. The first obvious information would be pageviews and other straightforward information you might get from analytics packages such as Google Analytics.

Example from Google Analytics

In addition,you may wish to consider the social media usage on top of the usage directly on your site, such as information from services like PostRank:

Example information from PostRank service

Intent

You could have content that is used a lot, but doesn't meet the objectives of your site. So one element to make sure you are considering is whether the content is meeting the objectives, as well as the quality level you expect from the site. As a source, this means more application of judgement than the other sources of content inventory data. Also, you may derive quality measures from the other sources (like checking which content is using old templates). Some aspects under intent to consider are: a) whether standards are being met, b) which of your core objectives the content is meeting, and c) marking content that needs careful editing.

Example intent analysis for a rabbit expert's website

Putting it together

Each of these on their own is interesting, but putting them together in your content inventory can lead to more interesting analysis. For instance, let's say you are about to conduct a content migration. With a content inventory that contains View, Origin, Usage, and Intent, you can ask questions like: What content do I have that is using the old template and never viewed? What content is being used a lot but not meeting our site vision? What content is about rabbits, authored by Joe Blow, and mentioned in social media a lot?

Don't forget to read the first blog post in this Rethinking the Content Inventory on Exploring your website.

-----

Need help getting a handle on your content, or how to decide what to do with all your content? Contact David Hobbs Consulting.

You're Willing to Pay for the Feature? So What?

David Hobbs — Tue, 19 Oct 2010 21:26:05 +0000

Once you are dealing with a big website with a large number of stakeholders, you have a challenge: how do you decide what functionality gets implemented on the site? If you run a small site, this question may seem completely ridiculous (and, if the question does seem silly then this blog post probably isn't for you). I've written before on product managing the CMS platform and website, but here I'll concentrate on one thing: why it doesn't matter if a group is willing to pay for the feature they want. This is always tough to deal with. Your internal clients will say things like "I don't understand. I have the money to pay for it, so of course you should implement this." Hopefully this blog post will help firm up you response.

So why doesn't it matter if a group is willing to pay for a feature?

1. They aren't really paying the full cost

Sure, you might estimate the total development cost correctly, but are they even paying for simple maintenance of the feature? Upgrades? More subtly, are they paying for the extra regression testing now needed for features that aren't even directly related? Or the extra troubleshooting required for even what turns out to be unrelated issues?

2. Consistency of web experience for, you know, the site visitor

Not that this always seems to matter much in internal discussions, but is this better for the site visitor? Sure, it might be a gee-whiz and exciting feature. But is it going to confuse the experience of the rest of the site? Even if conceptually you could make it consistent, will you have the time to implement it in a way that's consistent?

3. Not implemented in an extensible way

If a particular group is commissioning a new feature, chances are they are thinking about how it needs to work for their site. The cost they are willing to pay will reflect that. So then you implement something (perhaps partially under the guise that this could be a "pilot" of a new feature), and other teams want it. Well, now the cost has actually gone up since not only does the feature need to be implemented anew for the rest of the site, but the feature needs to be retrofitted into the site that initially got that feature.

4. Not implemented in a technically consistent way

If only a particular group is getting a new feature, then even the technical team will be tempted to take shortcuts to get it in as directly as possible. This may seem innocent since, hey, only this group cares about it. But actually adding any complexity to your system just adds to the frankenstein nature of your implementation. This means that as you are adding features you are just adding heft that may eventually grind your ability to add new features to a halt.

5. Limited resources anyway

Alas, you are only dealing with limited resources anyway. Maybe you can throw an external development team at the problem. But even if you are able to do that, what about the core team's coordination cost? This just means they won't be able to spend time on items that *all* groups want.

Obviously, sometimes special functionality needs to legitimately be developed. But consider the factors above before providing a new feature, and never just because a group is willing to "pay for it".

-------------------------

Need help product managing your website or CMS implementation? Contact David Hobbs Consulting.

Rethinking the Content Inventory: Exploration

David Hobbs — Fri, 10 Sep 2010 19:02:28 +0000

This is the first blog post in a series on Rethinking the Content Inventory -- also see Sources of Data, Site Inventories, Layers of Content, and Topic Inventories.

Especially for large sites, one of the reasons to do a content inventory is to understand your content. Another way of looking at it is that you want to explore your content. Often a tool like Xenu Linksleuth or OmniOutliner is used to create an inventory, and then teams are left to manually prod at the content. This prodding can be done by working in a spreadsheet (for example, filtering columns or generating graphs by mime type) or by clicking around on the site.

But what if your inventory allowed true, meandering exploration through the partially-unknown world of your content?

What needs to be in place to allow content inventory exploration:

Search for patterns within raw pages. Sure, your site might pull information from multiple systems, but you need to be able to analyze what your users are really seeing. For example, how many pages of my site use the current template?
Easily add information to the inventory. If you have a new source of data, you need to be able to add it to your inventory. For example, if you get physical store sales information that is relevant to your online product pages, then you should be able to quickly integrate that. Or you want to combine a link checker report and Google Analytics? It should be easy.
Iterate quickly. Instead of being a one-off activity, the explored content inventory needs to be able to do all of the above very quickly. For instance, if you dream up a new question about a pattern on your site (how many pages have an embed tag?), you should be able to do that quickly (this also means that re-spidering the whole site isn't acceptable for these quick tests).
Continue all of the above over a long timeperiod. Exploration isn't a quick hit activity, and neither should exploring your content be. Unless you have a small site, understanding your content is complicated. You need to try things out, think about them, and try again.
Easy to re-integrate work from multiple groups. A classic issue with inventories is having all these dreaded spreadsheets flowing around different teams and trying to keep them up to date. For example, you should be able to pass out information to multiple groups, and then they could highlight the content that needs a high level of manual reworking. This is related to #2 above, but a bit different: the point here is updating information in addition to adding new information.

Why bother this exploration rather than just looking at a simple tool's output? The biggest reason: You don't even know the questions to ask about your content when you start, so structuring and thinking about the undertaking as an exploration allows you to start earlier and take your time. In addition, this deeper understanding of the complexity and exceptions allows you to better plan your undertaking, for example a content migration. For example, nominally you many think all the pages of a subsite are using a particular template, but it would be better to check that rather than being surprised during the migration.

As with the question of how much automation to undertake in the migration, of course there is also a tradeoff here: for huge sites, this sort of analysis can probably be quite useful. For small sites, it probably isn't worth it. In between is less clear. That said, at a minimum for large sites, you can use this type of information to inform many decisions such as information architecture design and migration planning. In migrations, you can explore what rules could be used in your migration .

I'd love your thoughts in the comments below, including how you have done content inventories.

This is the first blog post in a series on Rethinking the Content Inventory -- also see the second post: Sources of Data.

-----

Need help getting a handle on your content, or how to decide what to do with all your content? Contact David Hobbs Consulting.

Hobbs On Tech -- All Blog Posts

Rethinking the Content Inventory: Topic Inventories

Unexpected Responses to Requirements

Mobile Content Resolution

You Don't Know the Resolution In Advance

Standardization and Migration Effort

Migrating Mass.gov: An Interview with Bill Trevor

You migrated 26 sites and around 700,000 content items into your new CMS, and some of the sites were previously on other platforms. How did you coordinate with all of the stakeholders? What were the initial discussions like, and how did you stay engaged throughout the process?

How different is the experience now for web users looking for information from Massachusetts government?

How did you develop content inventories, and what did you discover when you did them?

What simplifications did you make the project a success?

How much of the migration was automated and how much was manual?

How much was dropped from the old sites?

How did you track progress as you went forward?

The old saying goes something like "You have your choice of schedule, scope, and cost -- pick any two." How did you do against schedule, scope, and cost?

If you could do it over again, what would you change?

What were the biggest constraints you had, and how did you overcome them?

How is Mass.gov set up for ongoing management of the site? How many sites are still on the horizon to be moved to the new platform?

Focused Team Engagement and the Alternatives

1. Don't engage (otherwise known as "they first have to give us their requirements") — NOT recommended

2. Aimless engagement — NOT recommended

3. Focused engagement — do this!

Pushing Continuous Website Improvements: Posting It On a Wall

Better engagement

More reasonable work program

Better clarity

Higher confidence

More focus

Rethinking the Content Inventory: Layers of Content

Migrating NationalJournal.com: An Interview with Chris Contakes

Why did you migrate to a new platform? And how deep of a redesign from the end user’s perspective was needed to meet that vision?

Going into the migration, one of your biggest challenges was adding more refined metadata to allow advanced browsing by your subscribers. How did you approach that issue?

How much of the migration was automated and how much was manual?

How much was dropped from the old site?

What was your biggest surprise?

How did you deal with the aggressive timeline? We first met six months before your relaunch, and at that point you were still selecting the CMS. Since the president gave an interview mentioning the aggressive schedule, you were on the hook to deliver to it.

Rethinking the Content Inventory: Site Inventories

Product managing your CMS: defining the work program

Backend needs

Batching

Resource constraints

Popularity

Better Topic Pages: When Topics Lists are Too Much of a Good Thing

More difficult to tag well

Less likely to be a good taxonomy

More likely to be bureaucratic or overly-technical

More difficult to have consistent topic page quality

Harder to migrate

Content Handling Process: Asking the Right Content Migration Questions

You Can't Get There From Here

Problems with ungrounded strategies

Elements of a strong implementation strategy

Topic Pages: Fruit Can Be Different Colors

Migration Isn't Great Training

Cons

Pros

Will manual migration be good training for you?

Should you automate your migration?

Evaluating whether to automate

Commonality

Structure

Editing requirements

Staffing

Raw count

Advantages of automation

Iteration

Cost savings with consistent content

Consistency across large amount of content

More likely to see patterns that can be applied on an ongoing basis

Less dependency on the publishing process being perfected

Advantages of manual

DIY

Budgeting

Built in editing

Built in QA

Rethinking the Content Inventory: Sources of Data

View

Origin

Usage

Intent