Hobbs On Tech -- All Blog Posts

The Metadata Sweet Spot

hobbs — Fri, 26 Feb 2010 14:33:54 +0000

The road to metadata quality hell is paved with good intentions. Spellbound by the possibilities a complex taxonomy (or just seeming like an interesting mental exercise in its own right), the team gets to work on a detailed taxonomy that could cover all the future needs of sophisticated searching / browsing. You have a problem when the complexity of your taxonomy outpaces functionality the site visitor sees. So if you have a five level deep taxonomy but your site visitors only ever see the first level, then chances are that only the top level is accurately tagged. Since the content contributors won't see any difference / gain, then why would they spend the extra time required?

Match automated functionality to taxonomy complexity

The metadata sweet spot is where the taxonomy complexity matches the automated functionality on your site. So for example the hobbsontech.com site is all tagged to the five stages of CMS migration, and this tagging is used throughout the site (on the home page, as tags with every blog post, etc). So the complexity matches the functionality, and I am compelled to tag correctly. In addition to the functionality, the match must also be in the pain level of bad tagging. So for example I originally structured this site differently so old posts do not have very useful metatadata. Since the pain level is relatively low, I haven't yet cleaned that old metadata (note also that this is a problem with free metadata tags without a large number of contributors). So if you bury some metadata-driven functionality that none of the content contributors care about, then the quality will also be low.

So what to do about this? Carefully consider any additional metadata complexity before adding it to your system. If at all possible, consider a way of increasing the visibility of the metadata through automated functionality on your site. The most direct way would be prominent functionality that the site visitor would see/use (and both the site visitor and content owners / site editors care about). Relying on administrative functionality (for example, ranking groups based on how much content is tagged to their detailed topic without showing this to site visitors) only would be more dangerous since it might encourage people to game the system.

For other related metadata posts, see:

As always on this blog, this post is most relevant for larger sites. Is your site large? Answer four questions to get a quick gauge.

Combating Your Biases: Achieving Site Success

hobbs — Fri, 12 Feb 2010 19:39:14 +0000

We naturally all have a bias of how we approach improving our web sites (Information Architects through an IA lens, programmers from a technical perspective, etc), but we should all occassionally be looking broadly at what is required for success of your web site. I would also advocate that someone (the product manager) should always be looking broadly at site success.

As always, I advocate starting with the vision of what you are attempting to do. This could be your vision for an upcoming site revamp/migration, or your long-term vision.

After you define your vision, you can then help to combat you and your team's biases by:

List out the various factors that will lead to meeting your vision.
Evaluating where you are, right now, against those factors.
Roughly determining how strong you need to be in each area.
Concentrate on the deltas, in particular those that have a wide gap.

So instead of diving into one particular area with a tactical view of your problems (for instance, a deep engagment improving the graphic design of a site), you can concentrate on those that will derive the most value. Also, hopefully this will focus discussions so that you are always going to just enough complexity that will meet your needs.

One way of representing this would be in a graph, highlighting a) the "ultimate" / maximum maturity / most complexity / most impressive / most Amazon-like / fantasy, b) current level, and c) the level required for your vision. See the example below, which highlights those areas where you are meeting/exceeding the capabilities toward your vision (in green) and those that require work (in red). In this example, your design level is exceeding what's required toward your goal (which would be good, but on the other hand might be an area where you could spend less). The widest gap in the example is around setting a shared vision, so perhaps should receive the most attention.

Shock and Awe or Tightly Focused Requirements

hobbs — Mon, 08 Feb 2010 18:06:59 +0000

Most written requirements / use cases are limp, not getting to the essence of the goals (see Where's the juice in your requirements?). Why does this happen? Often, since tough decisions are not being made.

Requirements should be focused and targeted to meet your goals. Since it is probably more painful to make changes later in the process (for instance, after implementation has started), making the tough decisions needed for focused requirements should be a priority.

Of course, some readers may argue that traditional written requirements are less effective than a more iterative, generative agile approach. I also like the iterative approach, and in fact it can aid in decision-making (for example, since working code is something that all stakeholders can respond to during the process). That said, sometimes requirements written in advance are needed, for example when selecting a Content Management System.

Some Types of Unfocused Requirements

These are some of the types of requirements documents I've seen that show a lack of decision making:

Shock and Awe

Some requirements documents obscure the real purpose of a system since they are so "impressive". These may inspire comments like "Wow, that requirements document is 100 pages and I barely understand any of it! That must have taken a lot of work! You're so smart!". The main problem here is that if stakeholders cannot understand the requirements, then there cannot be true agreement on them. Although these may impress some, they still probably lack much strength since it's hard to see the point.

Listless

Ambling requirements are also common, and these often result from requirements being gathered rather than analyzed and synthesized. Ambling requirements may contain flashes of important requirements, but are buried along with unimportant requirements or even inconsistent requirements. Listless requirements may also be too detailed in places.

Overly Generic

Some requirements documents read like "car must have a driving wheel and four wheels" rather than "sports car primarily used to race on a racetrack on the weekends". One is certainly a fact but doesn't help in, for example, selecting a car. The second one shows a bit more of the flavor of the true requirement.

One requirements documents can have both of the problems listed above, but they can all be helped by better decision-making.

How to Tell if Your Requirements Are Unfocused and What to Do About It

How to know if you haven't made the decisions you need:

You resist efforts to prioritize your requirements.
You are excited about a possible capability, but have not written the related requirements since the relevant decisions haven't been made.
An outsider reads the requirements and does not understand overall what you are trying to accomplish.

How to make the decisions you need:

Define a compelling vision. In other words, big picture what are you trying to accomplish?
Make sure the requirements are synthesizing. People do not always know what they want, so everyone's input on the requirements should be synthesized into a coherent whole. A good way to see if the requirements are coherent is to ask someone uninvolved (but aware of the general area you are writing requirements for) understands them quickly.
Even though it is hard, prioritize your requirements. Many resist the concept of prioritizing requirements, since a requirement is a "must have". Of course you don't always get everything you want, but, moreover, you want to make sure that your highest-priority requirements are easy and straightforward in your implementation. Perhaps a lower-level requirement could be satisfied with a bit of a hack.
Consider the purpose of your requirements. If you are selecting a CMS, then really the only requirements that matter are those that will differentiate one product from another (based on your objectives). If you are handing off development in bulk to another team, then the requirements need to be more exhaustive. The general point is to concentrate on the requirements that matter for your current task at hand.

Confusing Your Pilot / Beta Users Before Full Site Migration

hobbs — Tue, 22 Dec 2009 14:02:08 +0000

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

Pilot What? Deciding What Subsite to Pilot Before Full Site Implementation or CMS Migration

hobbs — Thu, 10 Dec 2009 19:06:40 +0000

Migrations can easily grind to a halt. By methodically launching a subsite as a pilot, and giving time to react to issues, you can partially mitigate against that risk. For more information on pilots, see The Pilot in a Site Redesign or Migration: A How-to Checklist, CMS Proof of Concept, Pilot, Migration, and How to Migrate Content into a CMS. Just to re-iterate one important point, it's not a pilot if you don't plan for a) time for real users to use the piloted subsite, and b) time to fix issues before moving on to subsequent subsites (see more).

How do you select what subsite to pilot?

The pilot needs to launch an actual subsite, but which one? There are two key factors:

Ensure the subsite will meet the objectives of the pilot
How easily the subsite can be teased out of the rest of the site

Before diving into some of these details, note that if you have a very large suite of sites that you will be implementing or migration then you may be more likely to launch a site as your pilot (rather than a subsite).

Ensure the subsite meets the objectives of the pilot

You may be tempted to pilot whatever is easy, but that would not really help you much as a pilot since you probably would not learn much of importance. One of the most important things to keep in mind is your pilot needs to test how well your compelling vision for the site will be met, so that you can quickly correct course if your vision is not being met. Including the compelling vision, the subsite you select should meet the objectives of a pilot:

Test key aspects of your compelling vision
Test virtually all aspects of the eventual migration:
- Automated migration
- Manual migration/editing/entry
- Deployment (making the site "live")
- Integration with other systems
- url rewriting
Feedback, with the intention of making changes prior to migration
- From actual web site visitors
- From the core redesign team (inevitably, the more "real" the system gets, the team will see more issues and uncover more miscommunications)
Estimate effort levels, which requires:
- representative content types (again, not just the "easy" ones)
- not just your super stars doing any manual migration, but a representation of actual users

Many subsites will probably be ruled out by the list. For instance, a subsite that just has one content type and only a few users would not work because a) you won't be getting a good estimate of the effort for moving all content types, and b) you might not get good feedback. Note that you may not be able to accomplish all of these objectives, but by thinking about them you can better choose a site and plan your pilot. On the objective of estimating effort levels, you will also need to establish a method of tracking people's effort (such as using some sort of automated reporting, or even a spreadsheet).

How easily can the subsite be teased out from the rest of the site

Broadly speaking, there are two ways of launching a pilot: a) replacing an existing subsite entirely, or b) as a stand-alone beta site (with a prominent link such as "Try the PuppyWeb Beta!"). Some advantages of replacing a site "in place" are that you are doing a deeper test, with all of your current users on a richer set of functionality. For instance, you can test url rewriting directly to see if your old links will still work (if that's what you are attempting). A stand-alone beta is easier to take down in case of emergency, and also is easier to extricate from the rest of the site. So which approach you take depends on your particular objectives and constraints.

Regardless, you will almost certainly have to think through linkages between the site that you are piloting and the rest of the site. A major factor in deciding on what subsite you pilot may be how easy it is to decouple / couple from the site. One helpful set to defining this is to draw a high-level architectural diagram, highlighting the interrelationships between systems and subsites. These are some of the factors to consider in how the piloted subsite will relate to the existing subsites:

Internal references between content within the subsite under consideration
References between your existing site and this subsite
Other linkages with organization-wide services and reporting, such as site-wide search, site-wide RSS feeds, and site-wide statistics.
References to the subsite from outside you site entirely (for example, Google references)
How identifiable the subsite will be to site visitors (will the delineation between piloted and "old" subsites be clear to the visitor?)

If a subsite already "stands alone", then it may be easier to migrate that. If an objective of your new overall site is better integration, then you may be able to highlight that in the pilot (by pulling content from both the "old" stand-alone site and content elsewhere).

Size Matters: Your Web Site Redesign or Migration

hobbs — Mon, 30 Nov 2009 14:43:55 +0000

Redesigning your site or migrating to a new CMS? The size of your site matters in how you plan for it. Do you have a complex site? Answer these four questions (don't worry if you don't know the exact numbers):

(push "click to edit")

Obviously, the calculator above is not comprehensive, but hopefully it gets to the how complex, broadly speaking, your site is. The questions attempt to use fairly objective measures. If the calculator shows your site as simple but you know that you have underlying complexities that the questions do not capture, then of course take that into account. For example, this does not cover extensive content re-use, which is a bit less objective to add in a simple calculator (re-use means different things to different people) but important to complexity.

A quick note: if your site is simple, then congratulations! This is something to be proud of, since you have a site that is relatively easy to manage and maintain at a high quality. That said, obviously some sites just are more complex than others, so if your site is complex then that is entirely valid as well. The point of this article is to point out that the complexity of your site should drive how you plan and run the migration. See The Web Diet for ideas on how to slim down your site.

Why Site Complexity Matters

The complexity of a site is often implied in discussions, but this can obscure core requirements. For example, the majority of CMS discussions are probably of the Joomla vs. Wordpress (or pick your other favorite) variety. Big picture, this is appropriate since most sites are simple. If your site is simple (like this Hobbs On Tech web site is), then by all means launch into these discussions. Or just pick the system that all your friends are using. That said, if you have a complex site, then you probably need to consider other platforms and also use a more rigorous CMS selection process. If over the weekend for a personal site you were talking about Drupal vs. Joomla, then you may be tempted to apply that same discussion to your company's site with hundreds of thousands of pieces of content in multiple languages. The discussion / approach will need to be different for a complex sites.

Similarly, the complexity of your site impacts your implementation approach. If you have a complex site, then a rigorous process is key. For a simple site, perhaps no real process is needed at all.

Process for the Complex, Large Site

Implementing a complex site requires the most planning and coordination. There are just more moving parts and relationships to manage. For example, widely communicating a compelling vision is key for a complex site, since there are more people to communicate with, coordinate, and set expectations with. Similarly, clearly planning (and, again communicating the plan) is essential since the project is naturally more risky. Aside from the obvious reason of there being more to design, any ambiguities can quickly explode into major issues. For example, if you do not define core functionality clearly (let's say how content is re-used), then it can be implemented differently by different developers for various sections of the site. This ends up being even more complexity to manage, and an albatross that can weigh down future enhancements. Also, management items such as defining the metrics to track migration are even more important since there are more people to align. The complex, large site should consider following all the steps in this interactive checklist.

Process for the Simple Site

Assuming it fits with the vision, one of the keys of a simple site is to make sure it stays simple. This may be as simple as just being very diligent about the simplicity, or, for slightly larger sites, putting some sort of process in place about how changes are made to the site. In general, the simple site can concentrate on the why and what of the site, and not the how (see more about the why, what, and how of implementations). That's the reason so much discussion is about what the site should look like (for example, designing the look of a site) and much less on how to implement. So a simple site still needs to define the design, functionality, and IA (although perhaps not as deeply), but probably does not need to define the metrics to track a migration or have a pilot (or communicate progress during the migration). Also, automation in the migration is much less important.

Process for the Medium-sized site

Deciding how to plan for a medium-sized site implementation is probably the least obvious. Obviously, the *why* (vision) and *what* (IA, design, functionality) has to be defined. The *how* is the most interesting. If you are attempting a bold new direction for your site (rather than more superficial changes), then you may need to follow all the items on this checklist. In particular, a change in direction may mean that a pilot is particularly important. The breadth of functionality / relationships will also drive whether defining metrics to track the migration is important (if your site has a lot of pages but no other complexity, then a simple tracking of pages may be sufficient). A major consideration is how many internal stakeholders you have, which will impact how carefully you have to communicate / train. This, along with how much is to be migrated, will also impact how much attention needs to be paid to the estimation of staff resources required.

How to Migrate Content into a CMS

hobbs — Fri, 13 Nov 2009 02:33:18 +0000

You're staring at a seemingly insurmountable pile of content that needs to be moved. For whatever reason, you are moving to a new content management system. How are you going to migrate this stuff? A natural conclusion is that you'll have to manually review, edit, and move content. That is understandably intimidating and would probably take a huge amount of time and effort. Moreover, especially for a large site, a manual approach has many other issues including lower quality due to inconsistency in decisions that the various editors make. Furthermore, even if you are going to be doing a lot of manual work, you should still look at the problem as a whole and break down the steps rather than just dealing with each piece of content in isolation.

So how can we turn this mess of content into something that is easier to deal with? In the following steps:

Divide the problem into manageable pieces
Take time to pilot and estimate
Re-assess based on your pilot, and migrate

Step 1. Divide content into manageable pieces: type, cut, automate

The first step is to break up your content into types. You may be lucky and your content is already neatly arranged or easy to identify. Or you may have work to be done to figure out your content types. You will need to do content analysis anyway to move into your CMS, so the first step in in the process is categorizing your content by type. To use a container ship analogy, instead of looking at the shipyard full of containers as a whole, start looking at each type of container separately.

The reason to break your content into types? You'll need to do that for a variety of reasons such as defining the metadata (which will help enable site behaviors) as well as define the editorial requirements on an ongoing basis. For the purposes of planning your migration, breaking into types will help you decide what to cut. You may feel that your press releases over five years old don't need to be moved, or the encyclopedia you tried that didn't work can be deleted.

One of the main take-away points here is that you want to define the rules for cutting content. For smaller sets of content, this may not be needed and evaluating / identifying from spreadsheets listing all content may work. But hopefully you'll be able to define rules that will allow you to not even have to take a second look at those that were cut. Defining rules may allow you to just cut wide swaths of content that isn't contributing value to your site. Some other ways of deciding to cut could include web analytics (cut anything that hasn't received page views in the last month), site section (not just the encyclopedia entries, but the whole encyclopedia site), metadata that already exists (the topic "parcheesi" doesn't interest anyone, so delete anything tagged to it in the current system), or even contributor/source (perhaps everything that intern entered three years ago can be safely deleted).

Next, you want to decide what you can automate. You've already decided what will be migrated, so now you need to decide what's going to be automatically moved. Automating isn't an either/or proposition, and in general you want to automate as much as possible. Again, the idea here is to define the rules about what will be automatically migrated and what will not. This will be useful in helping you estimate your effort and help prioritize. The biggest issue on what can be automatically migrated and not is the structure and "regularity" of the content. If you had a bunch of content that was already in a CMS, only referred to a common CSS stylesheet, was only in standard HTML, already had high quality metadata, and all the relationships between content was clearly defined, then you could migrate that easily. That's because in that example it's structured and regular. Chances are, your content is more interesting and varied (and hopefully less interesting once in the new system), so you will need to look at samples of your content and try to determine how regular and structured it is. If you can see patterns (which can be more art than science to find), then you hopefully can automate the migration of some portion of some/all content types.

After Step 1 of typing, and then finding rules for cutting and automating, you will have a more useful inventory of your content, with numbers like this:

Content Type	Original Count	Percent Cut	Percent Automated	Manual Count	Automated Count
Press Release	20,000	50%	50%	5,000	5,000
Article	100,000	20%	90%	8,000	72,000

Step 2. Take time to pilot and estimate

At this point you have some big numbers based on educated guesses, but you could still be wildly off on how many can be automated. At this point, take this one step further and try to estimate how long it will take to do the manual migration and automated migration. You might say that the press releases just need a small amount of manual massaging, so each one will take an hour on average. But perhaps those articles that you want to manually touch require actual rewriting, so will be four hours each. Using the numbers from the table above, this would mean the manual migration of the press releases is 5,000 * 1 hour = 5,000 hours and the effort for the articles would be 8,000 * 4 hours = 32,000 hours. This probably is more manual effort than you're willing to take, so you probably would cycle through Step 1 to see what other assumptions you might be able to change (for instance quality).

Let's say after your do your further analysis, you think a larger percentage of your content can be automatically migrated. Well, until the rubber hits the road, you won't really know if those assumptions are true. At this point, you should pilot an actual migration of a section of the site. Then you can actually see how much can be migrated and, by doing a sampling, you can discover how good the migration quality is (and potentially cycle through iterations to improve quality).

Step 3. Re-assess based on your pilot, and migrate

After the pilot it complete, it's time to re-assess where you're at. Did the automation yield the quality you were expecting? Are there ways of improving the quality through the automation rules? Are you going to need to jettison more content, or lesson the quality? You may decide that you need to do manual QA on a certain sampling of the automation on some content types, to confirm that the quality is working out over a large batch of content (this may also vary based on content type). See Why estimate? I'm not getting more resources for this site migration.

In sum, this is the overall process of migrating content:

After you have done the pilot and re-assessed, you should:

Have a good estimate of the effort it will take
Get a flavor for the types of issues you will be encountering
Have a way of breaking down the problem for the actual migration.

Also see the previous entry on ensuring quality during migration.

Be Careful!

This article jumps straight in the middle of migration planning, and assumes you've already taken care of other important planning, including:

Defining a compelling vision
Considered your content strategy
You have already conducted a proof of concept on your CMS
You aren't considering this a one-shot deal, but are looking at how to steward this content and the site over time

Remember that a migration is almost never just about content, but you need to consider relationships, teams, and tools.

A final note: you may feel a bit of a deer in headlights with the issue of whether something can be automated or not. I've heard some interesting excuses from systems integrators / development shops about why something cannot be automated, which may sound like valid reasons to you. Hopefully by conducting your pilots and estimates, you will have compelling reasons to automate as much as possible. As mentioned above, it can be a bit more art than science in seeing patterns and being able to apply them, and it certainly should go beyond throwing a tool like HTMLtidy at the problem.

Some People to Watch for Site Implementation Success

hobbs — Fri, 06 Nov 2009 20:51:48 +0000

This blog concentrates on web site implementation success, and I try to take a holistic view of that. Of course, we all have our biases, and my technical background probably comes through pretty strongly at times. That said, my primary concern is making sure that web sites get implemented well. In order to do so, I get inspiration from folks in various disciplines. For this blog post, I thought I would concentrate on some people in specialties that probably do not get enough focus:

Content Strategy: Kristina Halvorson (@khalvorson) of Brain Traffic and Jeff Macintyre (@jeffmacintyre) of Predicate are folks to watch on content strategy, which Kristina defines as "the practice of planning for content creation, delivery, and governance" (from the Content Strategy knol). Check out Kristina's book Content Strategy for the Web.
Product management: Scott Sehlhorst (@sehlhorst) writes the insightful Tyner Blain blog about product management in general, which I think is an area that does not get enough attention for web site management. Some recent favorite posts of mine are Product Manage Your Website and Modeling User Competency.
Design, with a focus of successful ongoing management: Paul Boag (@boagworld) comes at the problem of running large sites from a designer's background. See the Boagworld blog as well as the Website Owner's Manual. A recent favorite post is 10 Problems Your Content Management System Will Not Solve And How To Overcome Them.
Web Operations Management: Lisa Welchman (@lwelchman) of WelchmanPierpoint defined Web Operations Management, which "takes Web management out of the arena of daily management, mini-projects, and silo'd technology implementations and moves it into the more mature operations arena".

Of course, I missed many others in the above and related fields, but I wanted to highlight some of the key related fields and some of the folks behind them.

Are there others we should be watching when trying to implement successful web sites?

Priorities for Successful Web Site / CMS Implementation

hobbs — Tue, 03 Nov 2009 01:58:59 +0000

Tools get too much focus. I guess it's natural, and I also fall for the allure of a good tool discussion. But we should get a bit real on our spotlight on tools, and concentrate on what it takes to successfully implement or migrate a web site. I've written about how to migrate before, but not tried to describe the success factors in priority order. So what are the keys, in priority order, of a successful implementation?

Let's take the example of photography. Go to photography forums, and the discussions are about cameras, just like most of the discussions around web sites are tools ("Do you prefer Drupal or Joomla?"), or maybe the end result ("I love the new CNN redesign"). In photography, successful photos probably rely on something like the following, in priority order: 1) vision of the photographer, 2) timing and lighting, 3) format (medium format digital, 35mm digital, mobile phone camera), 4) support (tripod, steady hands, holding camera out the window of a moving car), 5) lens, and somewhere way far down in the list is the actual camera. Of course, it's not as much fun or sexy to talk about it this way, but the first items in the list are more important. Give an excellent photographer a pinhole camera with perfect pre-dawn glow, and you'll wind up with a better photo than a two year old in harsh noon lighting with the "best" camera on the planet.

So, what are the keys to a successful web site then? Here's my stab at the answer, in priority order:

1. Vision

Before implementing a site, you need a strong, widely communicated vision of why you are going through the effort. Otherwise, your whole endeavor could be misguided or just lack the direction needed to keep the whole project moving forward.

2. Support (the "tripod")

Can you actually implement and then maintain this thing? Do you have the governance, processes, and teams in place? During and in preparation for the migration, you need to train the relevant teams. Are you following a sound process for your implementation?

3. Product Management (the "lens")

You might have the vision and staff in place, but in practice during implementation (and on an ongoing basis), there are lots of seemingly-small details that need to be worked through that affect the overall quality. Note that this is not only about project management of delivering to originally-defined scope, but the continuous tweaks that need to be determined as the project goes forward. For an infrastructure product like a CMS, the tool must also be managed architecturally to ensure it is sustainable. Strong product management also means being able to clearly define the essential requirements, and concentrating on defining your requirements will also naturally help you in selecting your technology as well. See more on product management.

4. Class of tool (the "format")

You aren't going to build Amazon.com on Wordpress. If you need to build a website in the next hour, you're not going to build a new infrastructure from scratch but might use Drupal. More important than the specific tool is probably making sure you're in the right ballpark with the type of tool you are using.

5. The exact tool (the "camera")

I would suggest that the exact tool is not as important as the items above. That said, if you have strong product management clearly defining what needs to happen to meet the vision (and the processes to make this happen), then you'll more likely wind up with a strong tool. Another point: in the choice of whether to change tools or not, it's probably more important to first make sure you expend effort in the higher-priority areas. Of course, any of the above issues could derail a project, but I would argue that you can recover from the "wrong" tool if you are at least using the right class of tool. But you can't recover from a poor vision and improper support.

What do you think the priorities are for implementing a successful web site?

CMS Proof of Concept, Pilot, Migration

hobbs — Thu, 29 Oct 2009 11:48:37 +0000

Oftentimes, a Content Management System selection is part of a large-scale site migration or redesign. When a new CMS is involved, you will want to make sure to put the CMS through a proof of concept, which should be part of your CMS selection process. A migration or redesign should include these three steps if you are using a new CMS. This table highlights the differences between a proof of concept, pilot, and full migration:

	1) Proof of Concept	2) Pilot	3) Full Migration
Purpose	Determine suitability of tool(s)	Discover and fix issues that arise during fairly real if partial implementation	Move off of old platform and onto new
Choose another tool at end of stage	Possibly	No	No
Only prod a bit at the tool or just watch vendor demos	No	No	No
“Real” content contributors use	Maybe	Yes	Yes
Site visitors use	No	Yes	Yes
Migrate in full section of site (content, templates, functionality, etc)	No	Yes	No (implement all needed for launch)
Implement key use cases	Yes (concentrating on functionality)	Yes (for end-to-end capabilities)	No (implement all needed for launch)
Concentrate on functionality that could break	Yes	Yes	No
Concentrate on the “bulk” that needs to move in	No	No	Yes
Concentrate on load	No (unless a key issue that could drop a tool)	Yes	Yes
After stage, possibly quickly scrap development to start from scratch	Yes	Yes	No
Estimate user effort	No	Yes	No

Web Site Migration, Implementation, or Redesign in Five Steps

hobbs — Sat, 17 Oct 2009 21:27:36 +0000

I've been doing a lot of thinking about migrating Content Management Systems recently, with some of this thinking up on the Hobbs On Tech blog. In talking with practitioners, I realize that much of what I've been writing actually isn't CMS-specific and isn't migration-specific but probably relevant to large content technology implementations, whether it is an initial implementation, redesign, or migration to a new system. That said, in this article, I'll continue to concentrate on CMS migration, trying to bring together an approach to migration in a coherent whole. In fact, I have started to write an e-book on CMS migration, so would appreciate you pointing out any areas that should be covered to be useful in a migration handbook.

A strong process for a CMS migration doesn't just look at one dimension (for example, just design), but looks at the relationships, team, tools, and pages that truly make a large site happen. The first section of this article covers these, and then the steps of a migration are covered:

It's not just the design, or just the content, or just technology....

Sometimes, a site redesign really is just that, meaning some templates or CSS changes and that's it. Or it really is just migrating content into a new system. Let's face it: that's rare, except for small or relatively new sites.

One way of looking at this is that the Compelling Vision defines why you are doing the redesign/migration, the pages define what you want, the relationships are a blend of what you want and how you will accomplish it, and the people and tools are all about how you will accomplish it.

Below I'll start with things that might not get planned for (at least sufficiently) during a migration effort. All of the components are related (for instance, good metadata probably means good training for people), but it's probably a good idea to isolate each of these to make sure they are covered.

Relationships

By relationships here I mean metadata, structured content, links, and integration with other systems (for example social media and public repositories of information, but also your partner sites) -- basically how your content lives in the site and world. These things aren't plug-and-play in any system, because they are always unique to your organization. For metadata, there is defining the metadata, setting up the tools to support your metadata, training on metadata (both how to use the tool and how to tag effectively), and possibly writing guides on how to use metadata. The reason that metadata and other relationships are becoming more and more important is that your content is appearing automatically in more contexts, both on your site (slicing and dicing by topic for example) as well as off your site. Designing for these relationships is more subtle than may be obvious (for instance, false precision and taxonomy mappings). The point here is that you need to plan for all of these relationships so that you do not box yourself into an implementation that cannot allow the functionality you need.

Team

Your site visitors need to be considered in a redesign (see Jakob Neilson's Fresh vs. Familiar: How Aggressively to Redesign), but here I concentrate on other important people: the team that will implement and maintain your new system. There are two parts to making sure your team will be ready: a) having the right people (and availability of those people), and b) communicating /training these folks. See Staffing a Team for Large Web Site Migration and Training During CMS Migration for more.

Tools

Many casual conversations about technology amount to name-dropping ("I just installed FlamingoDogCMS at home last night, and it's much better than the system we use"). People have strong opinions about technology, but hopefully you can steer toward substantive requirements that drive your technology (see Where's the juice in your requirements?). In the case of strongly content-driven sites, you need someone who has experience to help steer clear of potential issues in these technologies specifically (for example around automatic pulls and content re-use). See Should I Stay or Should I Go for more details on the configuration, templates, and special functionality that you should make sure to plan for.

Pages

The Page receives perhaps the most attention, since it is in everyone's face and also very concrete to discuss. User interface, information architecture, content strategy and design are discussed in detail elsewhere. These are all crucial aspects and need to be defined for your project, but please make sure to dig into enough details to figure out how to deliver the desired pages.

Also, note that even the technical migration isn't just about content/pages (see Why It's Hard to Migrate Content).

Migration in Five Steps

Note that I didn't say five easy steps :-). That said, projects may focus on just certain phases (especially ignoring the pilot or maintenance), so listing out generic steps below may help in deciding whether you have addressed them sufficiently for your particular project.

1. Vision

You need a reason for going through the effort of a migration or redesign. The implementation probably will not be easy, so you need to define a compelling vision to align everyone and also remind everyone why you are doing this in the first place (see Compelling Vision for a Large CMS Migration). Read more on Vision.

2. Plan

Your plan needs to consider all four components listed above, along with the next steps in the process: the pilot, implementation, and maintenance. Part of the planning is defining exactly what you are attempting to implement, but also more about how it will be accomplished. Obviously you will encounter unexpected issues, but hopefully the planning will help reduce those -- furthermore, by clearly planning you may be able to articulate what you are *not* doing as well (think about putting your web site on a diet). Read more on Planning.

3. Pilot

The objective of a pilot is to better estimate how long the actual implementation will take, enhance buy-in, and give you time to tweak the system before proceeding to implementation. For more information, see The Pilot in a Site Redesign or Migration: A How-to Checklist. Read more on Piloting.

4. Implement

At some point, someone declares "enough is enough, it's time to migrate". Sometimes you're ready, but usually it's just time to take the plunge. Hopefully you've been able to plan, pilot, and appropriately scope the project. In staffing a migration, you will want two particular roles filled for the actual implementation: project management to track through and push the implementation, as well as product management to maintain overall quality (and also to keep scope under control when issues arise). Note that during implementation the process for dealing with enhancement requests is crucial so that you don't end up building an unsustainable beast (see Be Ready: Initiating CMS Migration as well as CMS Implementation: Product or Project Manager?). You will also want to insure quality during migration, and decide how to track progress during migration (hint: it's not just about pages). Read more on Implementation.

5. Maintain

Maintenance isn't part of the migration per se, but the migration would be a failure in my opinion if the implemented system cannot be maintained. What are some of the reasons that a site can't be maintained:

Insufficient ongoing training
Insufficient standards or buy-in around standards resulting in immediate degradation of coherence of site (see more on standards and web governance overall at WelchmanPierpoint). On the flip side, this can also occur if the technology is so rigid that people break out of the system to do everyday changes (see Standardization and Large Web Sites).
Insufficient or inappropriate staffing levels (See migration staffing suggestions).
No product management of the web site or CMS driving the web, so the toolset itself becomes difficult to maintain.
Insufficient helpdesk support (see this little note on responding to urgent user issues)

The migration plan needs to pull all this together

Do you have someone on your team who is committed to looking at all aspects, or are they really in one of the slivers above? If working with a systems integrator, are they looking at how to get to delivery or setting everything up for ongoing success of your site?

A typical (but not ideal) project might go something like this (in the graphic, darker boxes mean more emphasis: for instance, a typical project might have no visioning of the impact on people):

The information architecture and design gets the most attention (with probably less attention on the content) in visioning and planning. Or, this could be flipped and if the technical team is running the show then the planning around the technology might get a lot of attention with little attention to IA/design.
If there is a pilot at all, it probably focuses shallowly at a technical level rather than a comprehensive pilot. Or, there is a pilot but not enough time to react and make changes based on the findings from the pilot.
Implementation just has to get done, but if all the components weren't planned, then items get jettisoned during implementation. The people impacts are probably only minimally considered (with everyone left wondering how their job will be impacted).
Maintenance?

The point is that you want to be looking at your migration as a coherent whole rather than isolating one component or attempting to skip steps.

Please follow up with any comments including what you think is important to success in a migration or any particularly thorny issues you'd like more writing on. Please either put comments directly on the blog post or through Twitter at @jdavidhobbs.

The Pilot in a Site Redesign or Migration: A How-to Checklist

hobbs — Thu, 08 Oct 2009 18:42:06 +0000

If you're going to do a large web site redesign or migration, you are probably already planning on conducting a pilot. One natural approach is basically to consider the first site/section you migrate as the pilot, but not take the time to respond to issues uncovered during the migration (which would reduce acceptance of the project). There are other easy traps to fall into, so what does it take to do a strong pilot?

1. Flex Important Muscles

A web site isn't just a pile of pages, but includes content, tools, configuration, relationships, account management, reporting, people and processes (see description). So you should not consider your pilot just a test of some pages, any of which on your site could be piloted as well as any other. What is to piloted or not piloted is a key decision, and may or may not mean piloting lots of pages. The steps to decide should be:

Define the compelling vision for your redesign,
Decide which components of your site are key to your vision,
Pilot the highest-risk or most important items.

Note that this usually does not mean piloting the easiest pages, or just trying to plow through a lot of pages to show progress (see more on tracking progress).

Since on of the purposes of a pilot is to discover issues as early as possible, so you can either reset expectations or put in more resources, you want to pilot the parts that are most important to your effort. Otherwise, you will think your pilot was a success only to have a train wreck later.

2. Launch Actual, Live Site

The best pilot will be one that results in a site that real-live web site visitors can actually use. Not only will you get feedback from the most important stakeholders of your site, but many other production-only issues will be more obvious. Examples will be load/caching issues, url redirection, and usage of your site that you were unaware of. But, even more important: you will be forced to work through all the issues to launch a site, rather than just having a couple people publish a few pages and declare the pilot complete.

3. Reserve Time to Respond to Issues

If you have a schedule that goes straight from pilot to mass migration, then the pilot won't be of much use since you won't have time to respond to issues you uncover. You need a step where you regroup and respond to issues found during the pilot.

Ideally, you will have the time to:

Define with key stakeholders what needs to be changed/fixed before the full redesign or migration occurs
Implement all those items that were agreed-upon with stakeholders prior to the full-blown migration

What the Pilot Will Do

The successful pilot should then allow you to:

Better estimate how long the actual migration or redesign will happen (see "why estimate")
Tweak the system, approach, expectations, and training
Enhance buy-in
Avoid some major roadblocks

Should I Stay or Should I Go? Corporate Site Migration, Redesign, or Both?

hobbs — Sat, 26 Sep 2009 15:32:06 +0000

So you want big changes on your site. Should you stick with your current system to accomplish this, perhaps doing a simple redesign, or is it time to migrate to another system? This is such an important decision, but easy to just fall into one of two camps: "our tool stinks and a new one would solve our problems" or "we couldn't possibly move." So how do you go about making the decision? Two steps can help you decide:

Inventory what you already have (and not just a content inventory).
Rationally review the situation for each item in your inventory, and then decide if the advantages/costs of staying outweigh the pros/resources of migrating or not.

What is a site?

What – exactly – is a site? If we're talking about whether to move or not, what are we talking about moving anyway? First, the obvious two parts of any site:

Content, which is either managed or unmanaged.
Tools, which could include anything from a highly automated CMS implementation, to someone using a text editor and ftp client.

You will also have some/all of these:

Configuration
- Templates that drive how pages are consistently generated (chances are, these are not implemented in a way that's a simple copy-and-paste). For example, on the Hobbs On Tech blog, all the blog entries are generated from the same template of the CMS, but moving the templates to another system would not be 15 minutes of work.
- Special functionality, including how search is configured or how page urls are handled.
- Platform / implementation architecture. You may or may not have a platform that helps, behind the scenes, in ensuring quality of your site.
Relationships
- Metadata. Metadata is becoming more and more important to driving how pages work, and an important element of any decision of how to modify a site.
- Structured content. You may have something like a "book" content that has chapters, or some other content that has components that are highly related. Regardless of the technology, the relationship between the components (for example chapters and books) would have to be maintained in a migration, or might be very difficult to maintain in your existing system.
- Links. Links within your current site and with partners need to be carefully considered, so that you don't break links or inadvertently end up with duplicate content in a redesign or migration.
- Integration with other existing systems, both to and from. This can include generic interfaces such as RSS and XML, as well as highly customized interfaces internally or with partners.
Account management
Reporting
- Self-inspection, including how many content items are in the repository and ability to easily find and edit content.
- Analytics, including passing key metadata to analytics packages / services.
People and Processes (not the "account" above, but real live people used to supporting and trained on your system)
- Publishing interfaces, including workflow.
- Existing training and support programs.

Obviously the different components could be sliced and diced differently, and complex sites will probably have other concerns. That said, the basic message is to consider all aspects of your existing (and desired) site when deciding whether to migrate to a new system or not.

The Inventory

To do an effective inventory, you will first need to define your compelling vision of what you want your site to be. After you have that, for each of the components of your site (using the above list as a start), rate each according to the following:

For the completely as-is case, with no changes, how well is the current site supporting the Compelling Vision? Perhaps you leave the effort baselined as 0 for this case. Obviously, one of the items you may be after is reducing the ongoing cost of running the site, which perhaps you can capture in the People and Processes section (or you may decide to create a separate sheet to decide analyze the ongoing costs).
Another possibility may be to tweak the current system toward satisfying the Compelling Vision. In this case, rate both how close each component will be to meeting the vision, and also how much effort it will take to get there.
Repeat the ratings of how close the system would be to where you want, along with how difficult it will be to get there.

Even if you just spend an hour on this exercise, hopefully you will have a clearer picture of your situation. Here's an example spreadsheet (with 5 being the best/difficult, and 0 being the worst/easiest that's been started for a hypothetical site:

The Decision

This will almost certainly be iterative. For example, you may look at your original analysis and decide that maybe there is an easier way to improve the metadata in your current system toward your strategic goals. Or after going through the exercise once, you may realize that there would be content repercussions that you didn't anticipate until you thought through the analytics requirements. At any rate, to help you make a decision you can see how difficult each possible approach would be, and weight that against how strong you anticipate the end solution to be. In addition, you will have some documentation of how you came to your decision. You can also use this sheet as a reality check when you conduct a pilot of your approach. For example, if you see that modifying the templates in your current system during pilot is far harder than you anticipated, you can revise your estimates and perhaps re-evaluate your initial decision.

You may also be interested in these blog posts:

Staffing a Team for Large Web Site Migration

hobbs — Mon, 14 Sep 2009 21:44:10 +0000

How do you staff a large web site migration? In this blog post I'll review some of the roles needed in a migration. Remember, much of these suggestions are for a relatively large migration (and some of these roles may be ridiculous for small migrations). Also, there are many elements to planning a migration (see checklist), but I'll focus on staffing here. Note that the compelling vision is particularly important when talking about staffing, to make sure that you're aligning and motivating everyone.

Balancing Complexity and People

First, let's revisit the fact that there really is an interplay between the complexity (along with size) and the people required for the migration. This may seem obvious, but you often have a choice between putting your web site on a diet and the general resources needed. The focus of this blog post is on people, so just keep in mind that if some of these roles seem ridiculous then perhaps you just need to confirm that the complexity you are attempting is possible with the people you have on hand (as opposed to, as the diagram at right is showing, having more complexity than can be supported by the team).

Roles You'll Need

Here I'll concentrate on the staffing required for the migration itself, rather than the overall web team required for continuing to run the web as an ongoing undertaking (the migration is just a step in the long life of your web site). In general the migration will be a burst of effort, where people are brought in temporarily, but it is essential to keep the team needed for the ongoing support as well.

Also, I'll assume that the content strategists, information architects, (graphic) designers, taxonomist, system architects, and other people involved in the definition of the project have already defined what needs to be defined. Of course, they will still need to be available for issues that arise during the migration, but I'll assume that the overall structure has already been defined and it's time to get migrating. The policies and standards should have also been defined by the policies and standards teams so that the migration will occur consistently.

Note that the roles below are roles and not necessarily individuals. In other words, you might have one person playing multiple roles depending on the size of your migration. In addition, some of the roles below might not even be necessary for your migration.

Internal CMS Product Manager

You'll need someone to be managing the configuration / implementation of your CMS, and I would argue that you should have someone "internal" doing this (rather than, for example, you systems integrator). This product manager works with the various teams to ensure a high quality implementation and defines the product. One of the most tangible and high profile tasks they'll undertake is owning the feature request process. The best source for more information on this is this article on Internal CMS Product Management.

Liaisons and Coordinators

For very large projects, coordinating across large organizations, you need to think about how two-way communications will occur between the core infrastructure implementation team and the various units within your organization. For example, if you run a worldwide corporation, then there may be five different regions to work with and hundreds of users of the CMS. Obviously you're not going to have all the stake holders communicating directly with the developers. In a large organization, you could consider a model like this:

This type of model may seem (and be) overkill for your particular organization, but when you start having a hundred-plus people who will be involved in the migration, you may need:

Liaisons on the technical team, who know the technology and can hand-hold the business users on how to get the system to do what they need it to do. Also, they can help work with the business users to understand any special requirements they may have.
The business liaisons help prioritize all the requests and general issues that their business users are having in order to make sure that the most important items are getting taken care of.

Content Specialists

A site migration / revamp is usually an important time to improve the content. There's a good chance it is also necessary. For example, if you never had topics-based pages and are adding them now, then you'll probably need new content. Here I'll just list the different roles:

Content Publishers. These are the folks that do the initial migration of content from the old system to the new (if it is not automated), and, depending on the tools and what you are trying to accomplish, doing HTML modifications/transformations or tagging. This role in particular may need to burst during the migration.
Editors / Writers. Some content may largely be cut and pasted, in a fairly mechanical fashion. Other content needs to be written. Obviously, you need access to writers/editors for the web to do this work.
Subject Matter Experts. During the migration, depending on what you are trying to accomplish, you will need access to your content subject matter experts. If your site is about the nuances of tax law, then you'll need access to your tax law experts.

Other roles

Some other roles need less description, although they are no less important. You should make sure to reflect on whether you need these roles in your migration:

Project Manager. Although the CMS Product Manager may play this role, you may need to have a separate person looking specifically at keeping the project moving forward according to schedule and budget.
Developers. Who exactly you need depends on what you're trying to accomplish and the tool you have, but you'll need developers (whether in-house or outsourced) for configuration/implementation of large sites.
Help Desk. Unless the business liaisons can handle the various issues the CMS users raise, you will need to involve your helpdesk. The helpdesk may end up passing a large volume of the requests to the liaisons at the beginning until the patterns of requests are understood (and the helpdesk has the knowledge needed).
Trainers. All the users need to be trained on how to use their system (for their particular task).
Executive Sponsor. Someone high up in the food chain sponsoring the migration. In particular, they need to articulate the compelling vision of the migration.

Which do you need?

I've put a little spreadsheet together to help you keep track of which roles you already have, which you need, and which you won't need:

As always, I appreciate any comments you might have.

Where's the juice in your requirements?

hobbs — Mon, 14 Sep 2009 16:30:28 +0000

Requirements are difficult. I should say good requirements are hard to put together. One thing to look for in requirements, instead of a shopping list, is the juice in requirements. Sure you may need a bag of oranges, but what you're really after is orange juice. Of course, you also need a knife, juicer, pitcher, glasses, and to know how to make orange juice. But really, orange juice on it's own really isn't that interesting a requirement since pretty much anyone can make orange juice. So ideally you want to dig deeper and define more clearly what kind of juice you are attempting (perhaps mint orange juice made at your table?).

Many requirements are written as if each item on a requirements list is a magic pill, where if you just take, for example, one pill of "orange" you'll wind up with juice.

Let's step back and start with a shopping list.

The Shopping List

Many requirements I see look something like a shopping list (not that difficult to put together):

eggs
lemons
butter
flour

If you were handed this, would you know what's for dinner? It could be:

sauce
lemon butter
bars
cookies
muffins

It reminds me of the question you get on the plane: "would you like beef or chicken" when you have no idea how it's prepared. So in the list above, you can be pretty certain that you'll be eating something lemony, but you don't know if it's going to be sweet, savory, an accompaniment, or the main course.

Actually, you don't really know if it's going to be lemony. Perhaps lemons may be needed but you're not sure. Also, you may be using ingredients already in your pantry or refrigerator (perhaps lemon fried chicken?). Or the lemons could just be used to keep your apples from turning brown after you cut them. Or you could only be using the lemons to make lemonade. Someone in the house may have just said "I think we're low on butter" with no specific purpose in mind.

The Objective

What if you were handed a sheet that said "We're having your favorite tonight: lemon pancakes! To make the pancakes we need sweet butter, large organic eggs, those small lemons at the back of the store, and flour"? That's a bit more motivating, and something that everyone can understand and line up behind ("Junior, if you don't run over and get lemons we're not having lemon pancakes tonight").

Unstated Requirements, Important Details, Technique and Your Skills

So you get home, and find that you're the one making dinner. All you have is the objective (lemon pancakes) and the ingredients from the shopping list. No one gave you a recipe. And frankly you don't know your way around this kitchen. You look on the internet and find a recipe for lemon pancakes, but it calls for refined sugar which you're avoiding. Come to think of it you just remembered that your daughter is pushing you all to eat organic, and you got regular flour. Thinking that perhaps you can get away with the non-organic flour, you look around, and then see a recipe that uses honey rather than refined sugar. It looks like this recipe is actually harder to make, since they say honey browns really quickly. You vaguely remember that the stove runs hot, or is it cold? I'd probably burn regular pancakes! A sifter? Where's a sifter? Do we have a sifter? We have baking soda but not powder.

Let's just make ramen noodles.

How did this happen? The shopping list was certainly correct: you did need lemons, butter, eggs, and flour. But even the list wasn't specific enough (for example, you needed organic flour). Also, there was a lot of implied/assumed stuff that was actually really very important to making the dinner. This included technique, unstated requirements, and your skills.

Does this kind of thing happen in large systems development? Yes. Someone thinks you should make lemon pancakes, no one knows that's what you're making, and you wind up with ramen noodles. The objective (compelling vision) should be clear to everyone, and the important details should be worked out. In large systems development, a useful way to do this is use cases since they are more easily understood by a wider group of people. Also, it helps pull things together to illustrate the point of the requirements. Is there juice in your requirements?

Ensuring Quality During Site Migration

hobbs — Fri, 11 Sep 2009 18:39:04 +0000

A previous blog post covered some of the types of metrics to track progress in a migration. This blog post explores ensuring that quality is acceptable during the migration.

A Naturally Iterative Process

Whether you have a high degree of human intervention or not, you will be following a iterative process like the one illustrated below. Basically, you'll have a stream of content/sites/functionality/etc that you are migrating. As you migrate, you are checking the progress by some means or another. The worst case would be the internal team not checking at all but then getting feedback from actual site visitors after launching a part of your site. Even in that case, you will find mistakes and know what needs to be fixed in the next round.

Let's look at these steps. For illustration in this blog post, the concentration will be on quality of content, although of course the drive to progress on other migration metrics needs to be high quality as well.

The Stream

You have a choice in how to phase your project, and you should ground your phasing in moving toward your compelling site vision. By keeping the above process in mind, you can further optimize what you start migrating. Probably the largest issue you want to avoid is re-processing any content twice (that's the "re-apply as needed" box in the graph above), which is covered below in Short and Focused Iterations.

Apply Rules

The next step is to actually migrate content. Since you want this process to be as streamlined as possible, I list this simply as Apply Rules in the process. The key about rules is that, if defined correctly, you can have more consistent treatment (and results) of your content.

In an entirely manual process, you would hopefully have some sort of written checklist/process for those using the tools to migrate the content. The process might be something like: "a) indicate in site inventory that you are working on the page, b) turn into XHTML, c) add descriptive image descriptions, etc". At any rate, some rules would be followed during the actual migration.

In a more automated environment, the rules would be embedded in the scripts/tools used for migration. Note that not all scripts are created the same, and you should challenge your system integrator to creating scripts or configuring tools that can do things like scrape pages that might not be totally regular. Some questions to ask your system integrator include: a) will you be scraping pages, b) will links/images/documents be "managed" when migrated, c) how will references (links, documents, images, etc) be handled such they are consistent, and d) how is acceptable quality determined (see the next section for more)?

Find Mistakes

If you are applying rules to your migration, why a separate step in the process to check your work? One reason is simply that mistakes are found pretty much without anyone explicitly doing anything, so it's important to know what to do when mistakes are found (the following steps in the process). For example, you may have done a careful job migrating some content, only to have site visitors find issues with the content after it has already launched. Aside from the situation where mistakes are found "too late", some reasons to explicitly search for mistakes are: a) a different "pair of eyes" (whether a person or a separate script) can help find issues not found in the first go-around, b) it's often easier or lower-risk to check for errors (if automated) than to ensure correct migration, c) correcting mistakes earlier rather than later is more efficient (especially to avoid doing anything over), and d) you may not have the resources / backing to do specific testing later.

What to check when looking for mistakes? Although simply having people eyeball the content, a checklist would be helpful to make sure key elements are being checked. Note that the checks ideally cover what people, automated scripts, and the system has generated. Some example items to check: completeness (for instance, when checking a page as opposed to a piece of content, making sure that all parts of the page are fully formed vs. "no records found" errors), your standards / style guide, consistent layout (old, large tables not blowing out pages for example), persistent issues, and unnecessary code stripped out and only your styles used (so that it's not just about how the content looks now, but that when you change your CSS the look will change as well). Note that some of these tests are checking the content in various contexts and not just the content alone (since it may be far easier to discover content problems by looking at the pages that are to pull the content).

For a large migration, you probably will not be able to manually check every page. For any page, you have the choice of whether and how to check for mistakes, which broadly speaking fits into three possibilities:

Manually checking
Automatically checking
Not checking

The decision on which of the three paths to take can be done by a variety of ways, including: by content type, by size of page/content, complexity of page, and importance to the compelling vision for your migration. If blocks of the content is highly regular, and manual checking seems to indicate that the migration works well for this content type, then automatic checks probably makes sense. For archival information formatting and small irregularities may not matter, not even checking it may be acceptable.

Change Rules

Whether it is checklists or automated scripts, the rules should be changed so that either the issue doesn't come up again (preferable) or at least there is an easy (hopefully automated) way to check. An unacceptable process is that mistakes from automated scripts are simply siphoned off into a bucket of items that need to be dealt with manually. Not only is this inefficient, but if you let that bucket of problem pages grow, you could inadvertently be blinding yourself to a major underlying issue that cannot be dealt with one by one.

Re-Apply As Needed

This is a key point. You could appear to be migrating along swimmingly, and then find an issue fairly late in the process. Do you go back and re-apply the new rules to the old content? Obviously you want to avoid either the impact or occurrence in the first place. To limit the impact, you could implement things in a way that it's easy to re-run automated scripts on content for tweaks. To limit the occurrence, short and focused iterations might help.

Short and Focused Iterations

There is no way to anticipate the issues you will encounter during the migration, but, especially since you want to avoid having to repeat any steps (a la "Re-Apply As Needed" above), short and focused iterations can help. By short and focused I mean:

Trying to define what is acceptable quality up front
Migrating a small amount of easy as well as very difficult content, representing as much as possible the full breadth of the type of content that will be moved
Implement as much functionality (see other examples) as possible, to better expose issues earlier rather than later (see Why It's Difficult to Migrate)
Check as thoroughly as possible as early as possible

The above list of suggestions concentrates on initial steps of the migration. Further into the migration, a key point is to make sure you understand the issues (meaning, you know what happened and how to fix it) you are encountering as early as possible, attempting to make sure that there are no deeper systemic issues.

Training During CMS Migration

hobbs — Fri, 11 Sep 2009 01:36:14 +0000

So you have a bright shiny CMS configured, and you're ready for your internal users to begin hands-on CMS work. Do you just let the CMS vendor give their standard training and leave it at that? No. Training on the generic mechanics of the tool is important, but your site/organization is unique and needs specific training. Also, the out of the box training may cover items that actually are not important to your organization, adding unnecessary bulk to the training.

So, what do you need to train on?

This may sound obvious, but your training should focus on what your team needs to know in order to manage their content and/or sites. For example, if you look at Team Experience, Your Tools, and Your Web Standards, then you should train at the intersection of these items: training only on what the team needs to know, based on your use cases. For example, if a key group of users is going to be publishing content but not managing sites, navigation, etc, then this user group should ideally be trained only on how to do that task. Additionally, hopefully the tools and team experience further clarify what needs to be taught. After all, if your tool is enforcing some standards, then, aside from explaining why the enforcement is happening, training does not need to dive into those details. While ramping up for migration, you may consider training just on what the users need to do during the migration, which may be less than what they need to know for ongoing maintenance (this way, you don't confuse everyone with details they'll probably forget anyway, and then you can train on more specifics when they're about to use the new knowledge).

The following are some of the elements that should be considered for training.

The Mechanics of the CMS

It's true that the CMS users need to be able use your CMS, so they do have to be trained on these details. Assuming you've defined major use cases for your site (right?), you could concentrate your training on the use cases for the users you are training. If possible, hand out a cheat sheet so that your users will be able to conduct their business once they forget all the details (and hopefully they don't have to resort to the manual every time). At any rate, the user should only be taught what they need to complete their job, and in the context of the tasks that they complete. Also, this presupposes that the CMS has been configured in a way that facilitates the key use cases.

Writing for the Web and Basic HTML

Your users may already know basic HTML and how to write for the web, but often one of the objectives of a CMS migration is to decentralize publishing so you may have new folks. Yes, of course your new CMS has a phenomenal WYSIWYG editor (or so it appears -- I've never met a web-based editor I didn't end up not liking, hence me writing this blog post with a "fat client"), and hopefully you've been able to embed many of your standards in the editor (like the users can select styles but not fonts). That said, there are still some elements of good HTML that everyone should understand and be trained on. Also, if your CMS copies and pastes from Word, then you'll definitely need specific training on that (for instance, to indicate what to expect in the cutting and pasting). At any rate, depending on your users, the tool and how it was configured, and what you are accomplishing, you may need to teach some basics about writing for the web and basic HTML.

Your Web Site Standards

The tool will not be able to enforce all of your web site standards (although ideally standards are enforced as deeply in the system as possible). There will probably be some contention about the need for standards, so some background on that should be explained in the training. Aside from this important aspect, it's important to focus on the standards that the tool cannot enforce. Some will be items like writing for the web, covered above, but you may have other standards that need further training.

Tagging

Chances are, one of the reasons you are using a CMS is to re-use content. Also, sloppy tagging has such a major impact (and is so easy to happen) that training here is essential. The items that need to be covered are:

Why tagging is important. An explanation (and hopefully "live" examples) of how tagging impacts where content appears, and how it affects search.
How to use the tool to tag. Hopefully the tool doesn't hinder tagging.
Rules (and rules of thumb) of how to tag. Do you tag to force content on certain pages, or only because it's actually about the topic or other attribute? How many values should be selected? What are the rules around the different values?

Of course, this depends on who is doing the tagging, and if you are going to have dedicated people tagging or if you will be doing automated tagging.

Workflow and Publishing Process

Some of the team may still be used to directly ftping files (or even using a lightweight CMS at home), but at any rate systems work (or are configured) differently so this is probably an essential part of the training. Obviously the workflow (clearly stating what the role is of everyone being trained) needs to be covered, but also items like caching need to be understood as these can mean frequent calls to the helpdesk if everyone doesn't know how it works.

Site-specific or Group-specific Information

This last point is easy to overlook but important for large complexes of sites. Different sites driven off the same platform might have slightly different flavors, requiring particular rules for each site. For example, the home page of major sites might be largely custom-managed, and hence needs consistency at the site or group level. Large sites should consider having their own style guide, and train one-on-one with new staff to the group in order to make sure the organization-wide training meshes with the realities of the group.

Tracking Web Site Migration Progress

hobbs — Thu, 10 Sep 2009 20:46:28 +0000

Before undertaking your large site migration, you should define how you will track progress. As mentioned in a previous post, you'll want to be moving toward a compelling vision of your site. As such, you probably do not want to be tracking only the page count that's been migrated (aside from inaccurately tracking your progress, your overall quality may be better by reducing as much content as possible). One possible approach is to track a variety of dimensions, which would result in status graphs like this:

In this example, 90% of the pages are in the system, 50% of the templates are done, 30% of the major functionality is complete, 20% of the sites are complete, and 10% of the integration with other key systems is complete. This is probably a very dangerous situation, threatening major reworking of the pages that have already been migrated (since, for example, once diving into the sites and functionality you may realize you need different metadata). It probably doesn't make sense to have the percentage complete of each of these progressing in lockstep, but by tracking things in this way you can highlight issues. Also, you more clearly see how much work you have left. In the case above, if you were only looking at the percentage of pages complete, you would think you were almost done. That said, the graph above clearly indicates that is not the case.

So what are some of the dimensions you will want to track?

Pages or Content Items

Depending on your site and objectives, you may want to be counting pages or content items. In a site with significant content re-use, tracking content items (along with sites/templates) will make more sense. Remember again that objective isn't to ram a lot of content in place, but only meaningful data (see my previous Web Diet blog post). In addition to pages or content counts, another item to potentially track is content types.

Sites

If you're only migrating one site, then obviously this isn't a metric to track during migration. That said, if you are migrating multiple sites that are driven off of the same platform, then it probably does make sense. Tracking when sites are actually launched is probably the most useful (rather than when they are "ready" to be launched), so that you are actually confirming that it works out in the wild (search traffic comes to your site, you don't hear about major issues from users, etc).

Templates

The look and feel usually receives a lot of attention, so tracking when templates are implemented would be compelling to a wide range of stakeholders. In addition to the look and feel, the template's functionality should be complete before a template is declared Done. For example, if there are auto-pulls for a template, then the template is not complete unless the auto-pulls are complete.

Integration

Large sites will usually integrate with a variety of existing systems, especially internal systems but also external systems. These may be largely independent of many of the other factors you are tracking, except for data/content format and common taxonomies. Also, since working with other teams can take a long lead time, tracking these and putting the focus on early collaboration is important.

Functions

Your site objectives might include new functionality, and, depending on the complexity, these can take a while to implement (including the need for iteration as you explore what really needs to be implemented). Functionality could include things like quizzes, maps, contact form, calculators, data manipulation tools, special search tools, and conference/event management.

Languages

If your site will have multiple languages, then you may want to be tracking certain functionality (it's not just about being Unicode-enabled!) but also tracking when different languages are fully complete. This will include translations, and you'll need to define how complete different languages need to be.

Channels

Sites are expected to share content in multiple streams / channels, and this may be an important aspect of what you are trying to accomplish in the new site. Example channels could be, in addition to your web site(s): email alerts, Newsletters, APIs, RSS, and other sites (like Swivel for data). Getting the channels right has similarities with the integration points, but in general channels are more generic. Aside from making sure the data is compatible with multiple channels, you'll need to have your database layer well implemented and also define the mechanisms that the content can be accessed (which will include defining the url structure for accessing these different tools).

These are just some examples of metrics to track during a migration, but hopefully give concrete enough cases to help think through what makes sense for your site.

I hope to cover in a future blog post how to actually go about confirming how far you are on each of the metrics you track, since self-reporting is not desirable. In addition, by defining how you will measure in advance, you may avoid issues in the first place since the system will be designed to satisfy those metrics.

As always, I would appreciate any comments.

Hardest or Easiest? Move toward the compelling vision

hobbs — Wed, 09 Sep 2009 20:34:48 +0000

Have you had a large site migration discussion where someone said something like this?

We'll just start with the easy stuff first

I would argue that, perhaps after a very initial laugh test of an easy use case, in general you should jump straight to testing/piloting/migrating the compelling vision (see description) of your web site (and of course also in your CMS selection as well). Chances are, this means iterating on some tough details rather than plowing through lots of easy work .

Why Easy first?

So what are some of the reasons that project teams give for migrating in easy sites first?

Need to show results (project's already over budget, late, etc)
Need to get momentum (if we don't get people bought into this soon, this project's never going to happen)
Learn from easy cases (let's take baby steps)

Also, another reason is probably that everyone is just a bit overwhelmed by the volume of a large site migration, although integration, functionality, automatic pulls, multi-site management, or multilingual issues may actually be bigger issues.

Issues with Easy First

Efficiency

Ideally, you only want to touch content once during the migration. If you concentrate on just getting in the simple pages / content / sites, then you may overlook some transformation of the pages necessary for more sophisticated functionality. This might include tagging needs, or structuring pages and content in a way that enables your desired functionality. In general it would be less efficient to come back to the content to correct those issues after already touching each piece of content once.

Buy-In

If you start by implementing easy but low-impact sites or content, then stakeholders may become frustrated that they're hearing trumpeting about progress but no changes that matter to them. If you have got everyone bought into a compelling vision, then to facilitate buy-in you should be trying to show this vision rather than hand-waving.

Wrong Focus, Missing the Vision

If you are concentrating on moving pages, then you'll move in pages. If you are tracking progress with metrics based on number of pages, then the focus will be even stronger. So you may not be looking at functionality, metadata, consistency, etc, that might be key to your vision. Although it may be possible to "undo" mistakes made, it may be politically extremely difficult to go back to retrofit the original vision in the site if everyone's focus has been on getting content into the system.

Metadata Quality

You are probably expecting the CMS to do some automated pulls of content, that will require accurate and complete metadata. If you do not implement the functionality that will expose the tagging (either directly by displaying it on the site or implicitly by pushing it to particular pages), then it will be very easy to not worry about whether the metadata is good when it is being migrated (by hand or automatically). Even more troublesome, you may discover that your metadata model was not sufficient, which would be better to discover earlier rather than later.

Train Wrecks at "End" of Project

By doing the difficult functionality earlier in the process, you're less likely to have the project come to a halt toward the projected end of the project. Running into issues earlier gives you more time to react to them, and also you have invested more effort already. An iterative approach, toward your vision for the site, would be more effective than putting off the more difficult items until later.

Tracking Error

If you're starting with simple stuff first, it's easy to make unrealistic extrapolations. For example, let's say you have 500,000 pages to migrate, and you have migrated 300,000 pages already. You may be tempted to extrapolate with something like the graph at the right. Since it took 3 months to get 300,000 done, it will only take 2 more months to get the last 200,000, right? As discussed above, you may actually be obscuring major issues, which may grind the process to a halt and actually require going back and touching the content that was already migrated.

How to Phase with the Compelling Vision in Mind

Let's say your web site vision is to be the "Authoritative source of mental illness information available via a variety of channels (web, RSS, API), different types (raw data, analysis), and selectable by topic pulling from a variety of back-end systems."

If you are going from the authoritative source you envision, you might start by: a) designing the metadata carefully, b) define how automatic pulls will work, and c) defining standards around the content so that it can be used effectively by multiple channels. Then you might migrate in content that is re-used a lot (or first just pull from one of the back-end systems that's already in place). You might also start by negotiating with the owners of the various back-end systems to determine when they can all meet the same standards for metadata, content-reuse, etc. For the functionality of the site, it probably would make sense to implement a little bit of support for all the functionality you were after, so you might: ensure your system drives a bit of web, RSS, API etc for a single content type first. In addition, it would make sense to start with strong content types first rather than allowing a generic content type for most content.

The near-term result may be a small amount of content, but the highest-value (as the authoritative source) information available on some key pages and via RSS. This would be in contrast to a rush to implement "easy" / high volume, with lots of pages/content but little value.

Content Re-Use: Roles, Consistency, and Standards

hobbs — Tue, 08 Sep 2009 14:43:36 +0000

Content re-use is important for many sites, but the implementation for large sites is more subtle than it may initially appear (some issues). In order to implement content re-use successfully, you must consider:

The exact functionality of the automatic pulls (it isn't just flipping a switch)
Metadata quality (not just defining the taxonomy and hoping for the best)
Who can do what

In this blog post, I'll explore the third item: roles in content re-use for large sites. These are some of the roles relevant to content re-use:

Content Contributor
Metator
Page Owner
Template / block Designer
Developers, including DB, Platform, and Site Developers

Why Roles Matter

For the end user's sake, you want your site to be consistent. For the ego of site owners, they may specifically want inconsistency. By consistency here, I mean look and feel as well as consistency in the way content is aggregated. For example, if one section of your site has Current Events that are two years old, another that only lists content in the future, and the RSS feed lists events that aren't even published, then it will be confusing for the user (sounds "out there", but I've seen this occur!). By enforcing what different groups (from database developer to content contributor) can do, you can control these types of issues. Ideally, you enforce as many of your site standards as far back on the left of the graph as possible.

Content Contributor

You could have the most beautiful design and CSS in the world, but then the content contributor could set text to a font that's not in your standard (can your users set font, or just CSS styles)? This is an easy example, but not as crucial as other standards such as the length of titles (longer titles may gum up content appearing in smaller blocks) and tagging. The impact here is setting the relevant standards, training on the standards, and enforcing the standard as much as possible in the content entry interface.

Metator

Who will be responsible for the overall quality of the tagging, key to content re-use? You could have someone dedicated to tagging (a metator), train the content contributors to do it, or have a librarian defining rules for automatic tagging. At any rate, who gets to do what tagging is a key decision. There is no free lunch here, so whichever way you go will require resources. For example, if you do automatic tagging then you do need someone to effectively train the tool (and then decide whether you remove the right of the content contributor to tag).

Page Owner

Since we're talking about content re-use, the difference between a page and piece of content is important. A good example would be this article: you might be reading this in a feed reader, on the HobbsOnTech home page, or on it's own dedicated page (it's permalink). And you could be seeing a link to this piece of content in a variety of places (for example, the See All Articles page which is automated). So the content is re-used on a variety of pages.

The content contributor is considered above, but there may be page owners as well. For example, there could be an owner of the home page that determines what content shows in the top block of the page; in this case, the owner would be playing the role of an editor. Again, this is the editor of a page pulling content and not the content in the first place. You need to define what the page owner can and cannot do. For example, can the page owner chose what appears in all blocks? If they can, is it pre-filtered for them (for example, if the topic of their page is Cycling, can they even choose something that's not tagged to Cycling)?

Developers

For a large site, you will have developers of different skill levels and experience with your environment. Instead of lumping all developers into one group, I would propose considering database / platform developers separately from site developers. This distinction probably only makes sense for large sites, but in that case it's important to at least consider.

Database Developer

For starters, there usually is not a separate role for the database developer. Perhaps only one person can change the schema, but anyone can write whatever query they want to get to the data. Of course, for small sites this is probably desirable, but for large sites (especially with high turnover amongst developers), this can result in fairly major issues. An example would be that if a "published" flag needs to be checked by anyone querying the database; in this case, a new developer could easily create an RSS feed that exposes draft content. A more robust solution would be to have a layer/API implemented by a database developer that is the only way that a site developer can get at the data. So, for example, this would mean that new site developer can't even get at draft content.

Platform Developer

Much of the platform will already be built into the CMS that you use, but inevitably you will make changes to the platform. By platform, I mean the core driving code of the site. For instance, I would consider the basic site-wide page template to be part of the platform. Ideally, much of the functionality of content re-use will be built into the platform, so that it's not done over by the page template or block developers (leading to inefficiency and possibly inconsistency).

Site Developer

The site developer implements the various page templates and re-usable blocks of pages (this is assuming you have multiple sites running off the same platform). A lot of the rubber-hitting-the-road happens here, but hopefully the platform and database access has been defined in a way to make it easier to develop consistency. As with all the developers, the site developer needs to make sure to embed as many of the site standards right into the page template/blocks. The site developer will also be developing what components the page owner can modify.

Layers and Enforcement

One way of looking at these roles is through the lens of the layers of people involved in creating a page on a web site:

The DB and Platform developers set up the system for the site developers and content contributors
The site developer defines the templates that page owners then use for their particular pages
The content contributor publishes the content, possibly with a metator to ensure the tagging is correct
All this together renders a successful page

A key point is that ideally you would have your site standards enforced as deep in the system (as far to the left of the top track as possible in the diagram) as possible. Some examples:

The DB developer has hopefully created a layer such that no one else can even get at draft content.
The platform developer sets up a platform-wide basic template such that key elements cannot be overriden by a particular site developer.
The site developer creates a page such that only appropriate parameters can be set by the page owner (a topic page owner, for example, cannot include pages that are not tagged to the topic

It may be that for some sites different roles make more sense, but the general point is that for content re-use to work, you need to carefully consider the roles of who can do what. Also, you want to implement standards as deep in the system as possible.

Hobbs On Tech -- All Blog Posts

The Metadata Sweet Spot

Match automated functionality to taxonomy complexity

Combating Your Biases: Achieving Site Success

Shock and Awe or Tightly Focused Requirements

Some Types of Unfocused Requirements

Shock and Awe

Listless

Overly Generic

How to Tell if Your Requirements Are Unfocused and What to Do About It

Confusing Your Pilot / Beta Users Before Full Site Migration

Web Site Visitor Confusion

Not Knowing Where the Pilot Begins and Ends

Not Knowing When Leaving the Pilot Site

To Beta or In-Place Pilot

Unnecessary Linking to "Old" Site

Pilot What? Deciding What Subsite to Pilot Before Full Site Implementation or CMS Migration

How do you select what subsite to pilot?

Ensure the subsite meets the objectives of the pilot

How easily can the subsite be teased out from the rest of the site

Size Matters: Your Web Site Redesign or Migration

Why Site Complexity Matters

Process for the Complex, Large Site

Process for the Simple Site

Process for the Medium-sized site

How to Migrate Content into a CMS

Step 1. Divide content into manageable pieces: type, cut, automate

Step 2. Take time to pilot and estimate

Step 3. Re-assess based on your pilot, and migrate

Be Careful!

Some People to Watch for Site Implementation Success

Priorities for Successful Web Site / CMS Implementation

1. Vision

2. Support (the "tripod")

3. Product Management (the "lens")

4. Class of tool (the "format")

5. The exact tool (the "camera")

CMS Proof of Concept, Pilot, Migration

Web Site Migration, Implementation, or Redesign in Five Steps

It's not just the design, or just the content, or just technology....

Relationships

Team

Tools

Pages

Migration in Five Steps

1. Vision

2. Plan

3. Pilot

4. Implement

5. Maintain

The migration plan needs to pull all this together

The Pilot in a Site Redesign or Migration: A How-to Checklist

1. Flex Important Muscles

2. Launch Actual, Live Site

3. Reserve Time to Respond to Issues

What the Pilot Will Do

Should I Stay or Should I Go? Corporate Site Migration, Redesign, or Both?

What is a site?

The Inventory

The Decision

Related posts

Staffing a Team for Large Web Site Migration

Balancing Complexity and People

Roles You'll Need

Internal CMS Product Manager

Liaisons and Coordinators

Content Specialists

Other roles

Which do you need?

Where's the juice in your requirements?

The Shopping List

The Objective

Unstated Requirements, Important Details, Technique and Your Skills

Ensuring Quality During Site Migration

A Naturally Iterative Process

The Stream

Apply Rules

Find Mistakes

Change Rules

Re-Apply As Needed