Web Services

Content Migration: What’s Underneath?

Over the past 5 years in web services, we have been consumed by the huge activity of migrating content from the old website (using the t4 content management system) to the new one (using Drupal). Literally tens of thousands of pages have been migrated in that time. It has seemed endless at times, but finally there is light at the end of the tunnel with the last handful of websites expected to be migrated by the end of March.

It’s the kind of work that often goes unnoticed or even taken for granted, and it would be easy to assume that it could be automated in some way. However, it’s very much a manual task. Saying it’s just copy and paste, even if it really does the task a disservice. The reality is that the team’s content specialists interact with different parts of the business to understand their goals and user needs, audit their existing content, review the data, and identify how it could be mapped into our new content model.

Questions, questions…

Since content is intended for migration, we tend to ask ourselves the same questions.

What is this?

‘What’ is something, it is very important and useful in the content world. « What » alludes to purpose and function. If someone can identify, at a glance, the purpose of a content item, then it helps them decide whether to invest time in reading. As we define the purpose and structure of content, we begin to see commonalities and patterns that help us organize content effectively and efficiently.

“What is” something also helps us decide where it should be featured in the user journey and tagged in different ways to maximize its visibility and findability.

For who is it?

It’s on the website so it must be for someone, right? Unfortunately, not always. A content item may have had a clear user need in the past, but that need may no longer exist, or perhaps it is now being met in other ways. When dealing with content on a legacy system built over the years, content that once had a definite audience is left to languish, forgotten and overlooked as brilliant new content takes its place. In a content migration project, it is our responsibility to make it clear that user needs still exist.

Is it accurate?

The risk is that old content will get in the way of new content, bloat site search and, worst of all, provide inaccurate and outdated information. Frustrating for users and potentially a major business risk (particularly related to policy and compliance content).

Inevitably, a lot of old, redundant, and inaccurate content is unearthed during the content migration process – yes, we found a lot of it!

Is it legible and understandable?

During a typical content migration project, we will always look for ways to make the content more readable. Take, for example, titles. Headers are good on the web. Headings help our brains process and scan a page quickly. More people should use the titles. Consider the following titles:

  • Learn how to deal with difficult relationships
  • Difficult relationships and how to deal with them

At first glance, isn’t there much difference? Maybe not, but when the user is presented with a text-heavy page broken up into multiple headers, we should take opportunities to lessen the cognitive load of processing so much information. As people scan information from left to right, it’s best to front-load the terms that are most likely to be helpful to them. If they’re looking for information about ‘difficult relationships’, make sure these words are at the beginning of the relevant headings rather than at the end. You will literally save them time by front loading keywords.

How will anyone find it?

The more traditional way of finding something on a university website required the user to have some understanding of organizational structure (to navigate a hierarchy of pages). This is a pretty big assumption, especially for external users who may not know anything about us.

While we’ve migrated content, it’s true that we’ve created pages that reflect our organizational structure, but our goal isn’t to isolate content within these groups. Instead, we will take steps to optimize the content to ensure it can be presented in different ways that maximize its visibility. Examples of this would be ensuring that keywords are in the title of a page (so that Google can easily recognize it) or tagging it with appropriate categories so that someone can narrow down a list of results when searching our website.

An example of the different ways users navigate to information is visits to salary scales for the academic and support staff page.

  • There have been nearly 34,000 visits to this page in the last year.
  • 2,800 visits came via the HR or Payroll pages.
  • 1,200 visits were directed to the page via our website search.
  • 22,000 visits came directly from a search engine.

Clearly, Google is the go-to method for finding this information for many users in this case.

In the case of the salary scales page for academic and support staff, it also helps that we’ve spent a significant amount of time ensuring it’s readable and usable on mobile and desktop devices. (See Claire’s blog post from last year).

Observations on 4 years of content migration

Never again!

Of course, we’d rather wait a significant amount of time before migrating an entire university again – or ideally never! Who knows what the future holds, but one way to ensure this isn’t such an onerous task again is to improve content maintenance. Yes, that means deleting things regularly (gasp!), but also taking the time to check our content and ensure the information is up-to-date, accurate, and fit for purpose. A smaller website with quality content will always provide a better experience than a sprawling website where users have to navigate through crappy content to find the useful stuff.

An intranet would help

The lack of a corporate intranet meant that the website had to fulfill a dual function of providing content for internal and external users. This was true on the old website and is still true, to some extent, on the new one. The potential downside of this is that inward-facing content interrupts the user journey of key external audiences such as prospective students. To mitigate this, and where appropriate, we have encouraged departments and services to use SharePoint for documents intended for current staff and students.

We have a PDF addiction

Much of the migration project involved moving content from hundreds of PDFs and publishing them as HTML pages. PDFs are more difficult to use for someone with accessibility needs, such as not being able to change the background color. The scale of this task has sometimes meant taking a pragmatic approach, eg long multi-page documents designed to be printed are often still published as PDFs. However, where possible, short documents have been published as HTML content.

There are steps we can take to make PDFs more accessible, but it often depends on how well best practices were followed in the original source document (usually Word documents). There is a huge opportunity to train staff in creating accessible documents but for now this is beyond our remit. In the meantime, we’ve created some guides on this topic that might be helpful:

Creating accessible documents

Publication of PDF on the University website

Talk to us!

So, as we rush into late March and bid a not-too-teary goodbye to the old website, we hope you’ll notice the benefits of the new one. The team here at Web Services has done an incredible job. Nothing is perfect of course and there are always improvements to be made. That’s why we welcome your feedback on any aspect of the website. It is only through user engagement, external or internal, that it will continue to lead the industry.

Photo credit: maggiwhiston at Unsplash