Pilot

Topic Pages: Fruit Can Be Different Colors

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.

Rules for Content Migration: Panning for Gold

Moving content into a new CMS comes with many caveats (for example, is it even a good idea, and migrating to a CMS is far more than just moving content). However you slice it, moving to a new system is an important time to think about your content. Specifically, what content should move? Kristina Halvorson's Content Strategy for the Web lists two reasons to have content: a) it supports a key business objective and/or b) supports a user (or customer) in completing a task. So the Compelling Vision is important here (as always!). It's not just about what can be moved in, but filtering out the gold nuggets from the muck (see The Web Diet for more overall ideas on shedding bulk from your site).

OK, so how do you decide what to move? The most straightfoward method is to have a spreadsheet of content, basically an audit of your current content, and then line-by-line decide what moves over. This can work for smaller pools of content, but what if you have 10,000, 100,000, or more pieces of content? Even with a hundreds of pieces of content this can start being a bit unwieldy.

Having rules (like different types of sieves to leave behind the useful tidbits) for content migration are more helpful than one-off decisions for the following reasons:

Apply in the system on ongoing basis

Why go through the effort of your migration only to have the content go stale immediately? If you decide that press releases older then four years old should be dropped during the migration, then do you really want seven year old releases kicking around your system two years after launch. Similarly, if you decide that pages that are regulation-driven and over one year old should be reviewed, then don't you want that in your new system? Of course, there's a whole other area of governance around actually being able to enforce these rules on an ongoing basis, but perhaps during migration planning is a good time to discuss this.

Better justify drops

In a simple (no beauracracy) environment, justification is not really relevant. For instance, if I want to remove a page from this blog, I don't have to argue with anyone about it. But if you are operating in a large organization, you could wind up in endless discussions going nowhere by reviewing content items on a case-by-case basis (or, perhaps worse, just decide to throw everything into the new CMS again). That said, if you are dropping a piece of content because of a rule (any content of any type that has not been viewed more than ten times in the last year will be archived), it's much harder to argue with (of course, you would probably also need to come up with some sort of very tight exception policy).

More easily to agree first and then everyone do work separately

Related to the above comment, if you agree on the rules first, then you apply those rules and everyone can get cracking on whatever they have to do on the content. For example, if a rule states that a page needs to be updated because it mentions a particular highly negative incident, then the someone can start updating it rather than spending time talking about whether it needs to be updated. Related to this, having some rules in place would better fit into a web operations management framework so that existing teams could make high-impact decisions rather than the impossible task of getting mired in infinite details.

More easily identify disposition

Let's say you have a spreadsheet of 50,000 pieces of content. How do you start? You could just start at the top and work your way down, but how efficient will that be? If you have a rule like any content not updated in the last 8 years gets put into an archive site regardless of any other factors, then you can (assuming you have reliable dates) apply that rule and start working through the content in chunks like that. Note that the process of defining the rules probably means that you need to deep dive into your audit, but the point is that with rules in mind you will quickly see patterns that you can apply to quickly identify the disposition for different content.

Better move content

By looking for patterns, some commonalities may be relevant to deciding how to move content. For example, you may notice that content over a certain age used an old HTML template you forgot about, but that could be scraped easily. Or you may realize that your old working papers can just be moved in as-is rather than needing any manipulation.

Explain to end users if appropriate

If you have these rules in place, then it may in some cases be relevant to your end users. For example, if certain types of content go into an archive after a certain period, you can indicate this to your users. This also gives you a means for public feedback on your decisions.

Reapply rules once you realize you don't have the resources

While going through this process, hopefully you can also take some wild guesses at the effort it will take to deal with different types of content. If working in your content audit spreadsheet, you could always have a running table of the total editing effort. If the effort is high, then you can re-evaluate assumptions, change quality levels, and many other options. One option is to migrate in less. If you have applied rules, then you can tweak the rules and then see the impact on the projected effort. If you went in and did your analysis in a piecemeal manner, then you would now need to go through and have all those negotiations again about what's moving and not.

Hopefully this has convinced you to at least consider defining meaningful rules for defining your content migration. Please share your thoughts or experiences in the comments below.

Confusing Your Pilot / Beta Users Before Full Site Migration

Your visitor winds up at a piloted section of your site, but the first link they click on goes right back to the old site. That would be a bit like playing a maze game where you suddenly roll into a hole and aren't playing in the game any more (but didn't know the rules or that you were playing a game). How do you deal with that and other linking issues when piloting a site? (Also see background on what/why to conduct pilots before full site migrations or all articles on pilots)

Web Site Visitor Confusion

What are some of the ways that pilot can be confusing for your site visitors? Here are some problems and suggestions for improvement:

Not Knowing Where the Pilot Begins and Ends

One of the keys to deciding what to pilot is choosing whether the site visitors will clearly understand where the pilot starts and ends. So before talking about any technical or implementation details, the selection should just make sense. For instance, if you have a clothing site then a possible piloted site would be the women's clothing store. This might make good sense to your set of users. Note that one of the reasons that you might be undertaking a new site is to consolidate different systems, so you may be piloting a new site that contains content from multiple sites. See the example diagram below, where some content from two subsites is being piloted in one site. Using the clothing example again, this could be where there are currently two separate sites that include all of your clothing, and you are eventually merging to one. You could pilot a women's site that will include content from both of the existing sites. At any rate, the key is that, even before considering the technical implementations, the site user should understand what is piloted and what is part of the old site.

Not Knowing When Leaving the Pilot Site

In addition, there are some ways you can implement the system to make it more obvious for the user whether they are on the piloted or existing site, including:

• Indicating when leaving the piloted site. You may wish to implement a standard intermediate page that the user sees before leaving your piloted site (see #3 in the diagram below). At least that way the user has the opportunity to back up if they want to stay on the piloted site.
• Clearly branding the piloted site. You also want to make sure that visually the piloted site is quite different from the existing site.

To Beta or In-Place Pilot

One question will be whether to just plain replace an existing subsite or to do a Beta that users can optionally try out. One advantage of a Beta is that you can have one entry point (the Beta home page) where you can explain to your users what the Beta is, including what the advantages of the new site will be (see #1 in the diagram below). If launching a subsite in place, then you also need to be ready for deep linking to your site. This can also be an advantage so you can do a live pilot of your rewriting rules, but a disadvantage is not being able to explain the new site as easily.

Unnecessary Linking to "Old" Site

If you blindly cut and paste content, you'll have a whole lot of links going straight back to your old site (like the ball dropping in the whole in the game above). This is because you probably will have hard links to your old site within the content. Some links will need to point to the existing site and others to the new site, depending on if the target content is moved into the pilot as well. If you are doing an in-place pilot instead of a Beta, then the old links should continue to work but you still may prefer to get the links "right" anyway (for example, if you want to use managed links that some CMSes offer).

As an example of unnecessary linking, let's say you have two pages B and C that will be piloted. If you just move the content without changing the links, you'll wind up on the old site when click from page B on the new site. Obviously you want to make sure to link from the piloted B page to the piloted C page (see #2 in the diagram below).

Example Linkages in a Pilot, when using a Beta