In previous installments of this Rethinking the Content Inventory series we've covered inventorying content and sites. As many sites become more topic-driven, another crucial slice is by topic. So basically we take an inventory of every topic along with relevant metrics. Take this example of a site that is organized by type of bird:
Topic
Content Count
Has Description?
Pageviews last month
Supply Side
Supply Side
Demand Side
Cardinals
0
Yes
1
Robins
1000
No
100
Seagulls
2000
Yes
5,000
Starlings
1
Yes
1,000
Woodpeckers
10,000
No
20,000
Wrens
500
Yes
20
The columns in this example are the topic name, the number of content items tagged to that topic, whether or not the topic has a contextual description for visitors, and how many pageviews there have been on the topic page in the lst month. In this example, we could use this topic inventory to make a variety of useful observations:
A lot of content is published (and categorized) to the woodpecker subject, and has relatively high pageviews to show it. That said, we are missing an opportunity with such an important topic (for this site) in not providing the context of a description for the topic page.
Cardinals as a topic should probably be dropped.
More should be published on Starlings, since there are high page views based on only one piece of content.
Studying the topic inventory is interesting because:
This can affect publishing schedules, pushing editorial teams to publish to keep quality high.
Provide feedback on what topics are most interesting to readers (other more sophisticated measures can be brought to bear such as how "evergreen" the content on that topic is).
Topics pages in particular can erode quickly in quality, and this gives a mechanism to monitor them.
In a migration, topics pages can sometimes be like "ghost" pages, assumed out of migration discussions since they will be "automatic." That said, there are for example opportunities to cut underperforming topics just like unneeded content during a migration.
As discussed in Sources of Data, one key to an inventory is to use the sources of data that are required to get the information needed for an inventory. In this case, we'll cover information from the Origin (the CMS) and Usage (How content is used by visitors).
Submitted by David Hobbs on 15 March 2012 - 5:41pm
At the World Bank, I was product manager for the content publishing platform for the thousand+ World Bank sites and we had a seemingly-endless list of requests from the hundreds of content contributors for improvements. The list of requests always grew more than it shrank. One time, the lead developer said he had an idea to completely change the first page people saw when they logged into the CMS. But no one had asked for this. I have to admit, I was nervous about prioritizing this change over our huge backlog of requests. In the end, we went with it. Guess what? The CMS users were thrilled. It helped both power and occassional users. And no one complained that item #428 or whatever wasn't implemented to make room for this change.
There are probably lots of lessons to glean from this little story, but the one I'd like to emphasize here is that it's ok to give an unexpected response to the "requirements" that you people may lob at the central team. Sometimes it's even ok to ignore what people are saying and instead give them what they need. They might be delighted (at least for a while!) rather than everyone complaining about request numbers. Of course, this requires finess, skill, and a bit of luck -- and you can't ignore your stakeholders in general. But when getting into the decisions of what gets implemented, listening to the deeper needs of the teams are more important than literally what everyone is saying.
----------------------
I'll be writing more about defining requirements and also improving engagement with internal teams. In the meantime, you can download this new report: Better Engagement for Ongoing Website Improvements.
Submitted by David Hobbs on 13 March 2012 - 12:26pm
Image resolution is obvious: you know the image needs to be smaller on a cellphone than when it's viewed in a full size desktop browser. Actually, changing image resolution meaningully isn't entirely straightforward but we'll come back to that in a bit. On the other hand, let's consider textual content. This also has a resolution in a sense: the full War and Peace text has extremely high resolution, but to say "War and Peace is about the inevitability of history" or something is much lower resolution. In this post, I'll concentrate on the ability to generate the different resolutions, and not about technologies needed to detect and serve up the content.
You don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem.
Let's start by using some images as an example. On this blog, every post has an image in two versions: a) the full size that appears in the post itself, and b) a smaller 220x120 image that is used by navigation throughout the site. Look at this example of two smaller sized images:
The microphone is simply a resize of the entire image, since the image is focused on a single, easily-recognized object. The table, however, is an entirely different crop since I wanted the text to be readible.
So these examples demonstrate two properties:
For the microphone, there is a high degree of similarity -- in other words, anyone looking at the large and small images see it's exactly the same thing.
For the table, there is a high degree of readability, which is also the case for the microphone. But one required a different cropping to accomplish it.
Now let's consider another factor: 3) relevance. In other words, is the image relevant? In the case of the table, it is necessary -- the blog post does not even make sense without that table (obviously also an accessibility problem). In other words, there has to be a way to present it, or another representation of it (perhaps just in text). On the other hand, the microphone isn't necessarily required at all -- it reenforces the theme but it is not necessary.
Before we continue on to text, note that all of this is a question of quality against the technology and your resources (sure by hand by skilled Photoshop users may result in the best resizing, but it isn't worth it at a certain scale). Obvious really, but the quality level usually seems to be backed into rather than carefully considered in advance. For small sites, including the Hobbs On Tech blog, this probably doesn't matter much. But for large and huge sites this is a more important trade-off to weigh.
For text resizing, let's start by looking at this Website Migration Handbook download page, which had unexpected consequences (to me) of long filenames:
I actually changed around the naming of the filenames to make the format of each clear in this rendering (so that "mobi" etc was at the front of the name). Although perhaps an extreme example (it was silly to have longer filenames in the first place), I think this points to another problem that I haven't seen discussed yet: until you see your content in a new context, you don't really know what its needs will be. And here's where a big difference between text and images come into play: unless you go down to extremely low resolutions, chances are that an automatically-resized image will still make some sense. But at some point earlier the text becomes meaningless (for instance if the epub, mobi, and pdf text wasn't at the front of these filenames).
All of the above examples are where the content producer also had control of the display. The problem: In general, you don't know what resolution your content will be served at. For images, this is a minor problem. For text, it's a bigger problem.
Text may need to be resized in whatever field it appears, including common ones like:
Title
Filename
Short description
Full text
Metatags
Although tools like Teragram may be able to resolve some of these text resizing issues (for instance taking the full text and giving an abstract) for larger organizations, in general the resizing of text cannot be automated. Truncation is obviously easy to implement and the most common approach, but less useful (no one would accept this approach for images, just taking the first 50x50 pixels from the upper left of an image and saying the image is resized).
You Don't Know the Resolution In Advance
The problem here is that you don't know what resolution your content will be served at. Here are some things you can do as a content provider for text:
Test end-to-end on the platforms that are of particular interest to you
Put as much meaning in the front of each text field (important words first in title, more unique or important metatags first, etc).
Place relevant (especially crucial) images closer to the top of the text
For displaying the content on pages that you control, you can intelligently change the treatment of fields at different resolutions (title always appears, but full text doesn't appear on the first page of a piece of content at small resolutions)
Unfortunately there isn't really that much on the provider side that you can do. Any other suggestions?
If you are displaying other people's content, then you could at least set and publish the standards for the maximum characters, words, or other metrics that each field will display. Then providers could decide whether to tailor their feeds to you to your renderings.
Submitted by David Hobbs on 16 February 2012 - 5:45pm
The level of standardization you have as well as the level you want has a direct impact on your migration effort.
For example if your content is currently inconsistent, and you don't care about consistency after your transformation, then the migration is easy. For example, if your data tables each are presented entirely different on each page but you don't care, then migrating is easy. On the other hand, of course if you have high consistency now and want high consistency after the transformation then that is easy, even if you want transformations along the way. The hard part (and it is often worth it!) is when you currently have inconsistency but want to have a more standard approach going forward.
This also has an impact on your inventory effort as well, since if you don't care about the resulting consistency then the inventory may not need to be as accurate for your planning.
Of course, there are many nuances to all this (and the Easy/Hard designation is oversimplified), but hopefully this will help your planning in broad strokes.
---------------
So what does standardization mean? Clients of David Hobbs Consulting dive into the many dimensions of standardization when planning website transformations. Contact us.
Submitted by David Hobbs on 8 February 2012 - 1:42pm
Bill Trevor was the Project Manager who led the Mass.Gov effort to replace the Web Content Management System, visual design and navigation. He is a consultant specializing in Information Architecture, Website Migration and Optimization, Project Management and Social Media Marketing. His views are his own and in no way represent the views of Mass.Gov or the Commonwealth.
You migrated 26 sites and around 700,000 content items into your new CMS, and some of the sites were previously on other platforms. How did you coordinate with all of the stakeholders? What were the initial discussions like, and how did you stay engaged throughout the process?
With any project (especially one of this size) communication is key. We held frequent stakeholder meetings at both the migration coordinator and senior management levels for each of the 26 sites. We formed a "migration liaison team" that included one representative from each site to ensure information was broadly communicated. We also leveraged a wiki so stakeholders could receive notifications if there were any updates related to the migrations.
A primary goal of the project was to maintain one platform that easily presents a single view for web users looking for information on Massachusetts government. Was that goal met? Why was a new platform needed to make that happen? How did you convince people to move to a single platform, and how much variance did you allow between websites?
Since its inception, Mass.Gov has been focused on maintaining a single face of government. The goal of this mantra is to create a state website that constituents feel comfortable navigating around, no matter the agency/department providing the information they seek. Too many state websites have a "single facing" homepage only to disperse into as many different websites as there are agencies. Mass.Gov takes the opposite approach and as far as I can tell, is doing it the best. The new Content Management System (CMS) will enable Mass.Gov to keep that guiding principle true while allowing some flexibility to content authors to slightly alter their web pages without losing that single face. Constituants want to be confident that the site they are visiting is an official state sanctioned site and Mass.Gov makes that happen. The Commonwealth of Massachusetts continues to pursue the goal of IT consolidation. Why not offer a single enterprise level CMS instead of having 160+ different systems, visual designs and site navigation structures. This website consolidation has been in the works for many years (termed Portalization) and the new CMS will allow Mass.Gov to continue the push to bring more sites onboard.
How different is the experience now for web users looking for information from Massachusetts government?
While it may have been an ambitious project, Mass.Gov saw the replacement of the CMS as an opportunity to also update the visual design (4+ years old) and the navigation schema (7+ years old). The prior versions of the Mass.Gov site templates were very rigid, narrow and leveraged the old Yahoo category navigation schema. You know, the one where you saw topics, clicked them, saw sub-topics, clicked them and so on and so forth. Mass.Gov has introduced a modern mega-drop down, in the same style of ESPN or Target, quickly exposing level 2 and 3 topics from the banner on every page. Another addition is a similarly fashioned left navigation that allows users to expand a drop down menu from the left column to get a peak at what content lies beneath that category. These features reduce "number of clicks" and help to flatten the information architecture. We put a new "modern minimalist" design on top which offers more space for agencies to showcase content along with an easy to maintain slideshow template and a wider page layout.
How did you develop content inventories, and what did you discover when you did them?
We used everything we could find. Some agencies kept good inventories of their own and we leveraged those. We also used free tools like Xenu to spider sites and export the findings into excel to obtain a comprehensive view. For better or worse, the old CMS was a very linear tool and so it was a lot of work but attainable to export the navigation structure from the old site and dump that into the new tool to build the underlying folder structure. One thing to note, most agencies saw this as such a large project to simply move their existing content/navigation into the new CMS that few took the opportunity to redo their IA. We did, however, try to get agencies to see the value in a pre-migration ROT (redundant, outdated and trivial) analysis because the less content you migrate, the less you have to QA/tweak.
What simplifications did you make the project a success?
Keeping the scope in focus and using it as the barometer for any requested change. We used our daily scrum (15 minutes) to update each team member on what we accomplished yesterday, tasks for the current day and to discuss any issues blocking progress. These meetings kept team members honest and ensured everyone was on the same page. I also cannot stress the importance of a parking lot page and Executive Sponsorship. We had great support with the upper management circles who really listened when something came up that might derail us and helped to determine an effective resolution without busting scope.
How much of the migration was automated and how much was manual?
We had really great partners from the CMS vendor (Percussion) and a rocket scientist (well he was considering becoming one) who did the automated migration. Again, we did a lot of research and heard the horror stories about how poorly content migrations ended up but I can say that the automated portion of the project *fairly* cleanly migrated 85% of the agency content. This included documents and images. There was some content that may have gotten lost in translation but the vendor did a great job translating the old to the new. It was no small feat and only caused minor delays. We knew the cleaner the content was after it migrated, the less work the agencies would need to do prior to their site going live.
How much was dropped from the old sites?
Because the old tool had a separate navigation component, Mass.Gov knew exactly what was live on the old website when we took our final content snapshot. Mass.Gov migrated every web page that was live at the time of the snapshot and the numbers of pages dropped due to issues was probably less than 2% of 400,000 pages. This was most likely due to malformation in the page code.
How did you track progress as you went forward?
We used every resource we had at our disposal! Scrum was a tremendous help. Our main tracking methods were MS Project, our Wiki and Sharepoint. We leveraged MS Project to track milestones, resources, critical path and high level project points to senior management. Our Wiki was the main communication mechanism for our stakeholders as they were able to comment, ask questions and view schedules/timelines in real time as the project evolved. Internally, we leveraged Sharepoint as a means to track issues / bugs / fixes during the configuration and implementation of the CMS.
The old saying goes something like "You have your choice of schedule, scope, and cost -- pick any two." How did you do against schedule, scope, and cost?
Scope was always a challenge but we kept focus via daily scrum meetings and constant sessions with our stakeholders. The schedule did take some hits to ensure the product was scaled appropriately and that the content was migrated as clean as possible. This did not result in a significant delay and by the time we launched the first websites on the new platform, we were within the margin of error for our original project plan we drafted some two years prior.
If you could do it over again, what would you change?
If time was not a factor (we were dealing with fiscal year funding deadlines at times) I would have preferred to have spent more time analyzing website Information Architecture. Due to the enormity of migrating to a new toolset (fear of the learning curve) we recommended that agency staff focus on QA'ing the content that migrated and getting comfortable with the CMS. I still believe that this was the right decision but some sites are now looking to overhaul their IA.
What were the biggest constraints you had, and how did you overcome them?
I think the biggest challenge is that Mass.Gov is the top level website and maintains the CMS tool but does not control the governance model used by the 26 sites. While not a bad thing, it was challenging to get agreement and consensus on some aspects. In the end, we had a very strong communication model that served us and our stakeholders well. Absent this, we might still be migrating websites.
How is Mass.gov set up for ongoing management of the site? How many sites are still on the horizon to be moved to the new platform?
Mass.Gov took great care to develop authoring documentation and posted it to the Wiki. This way, it is available 24/7 and is continually updated by the team. Gone are the days of printing out a training manual as the minute it is printed, some aspect is out-of-date. Mass.Gov is also working to make short video tutorials that authors can watch to see click by click how different content components are created. Now that the CMS is in production and the original sites have launched, the next phase has commenced and "portalization" of state entities not on the CMS platform has begun. There are several large sites outside the Mass.Gov platform and the hope is to migrate as many as are willing to leverage this enterprise CMS and join their fellow agencies in expanding the single face of government.
--------------------------
Are you a website owner with a migration success (or failure)? HobbsOnTech will be featuring interviews like this one to help provide a repository of experiences that others can draw upon. Please contact us if you would like to participate.
