For my first 6 months as a contractor at Government Digital Service I worked on the transition tools team as a front-end developer, designer and user researcher. We were building the tools needed to transition 800 government department and agency websites to GOV.UK. All 24 ministerial departments had already been migrated. In October 2013, transition was in full swing and it was a complex process.
URLs - links and Web addresses - are the ‘strands’ in the Web metaphor. When URLs change, the strands break.
All government content is moving to GOV.UK, the old sites are being retired. That’s the potential for a lot of broken links. Across 800 websites there are over 1 million unique URLs. Government has lots of links in the wild; on websites, but also in letters, on mugs, in ads and on TV. Users will continue to click and type these URLs, expecting to reach the content they need. Those old URLs must continue to meet that need. Government needed a way to manage these URLs.
Every old URL has a mapping from old to new. These are managed in a rails app named Transition.
An old URL can:
- be redirected to a GOV.UK page
- be archived
Redirects are served with a
301 status code, a permanent redirect. For example, this page on the old Environment Agency was for checking your flood risk:
It redirects to the equivalent content on GOV.UK:
Not all roads lead to GOV.UK. Archives are for content that doesn’t meet a user need. Content without a need isn’t transitioned to GOV.UK. These old URLs display a notice and a link to a version of the page on the National Archives.
They’re served with a
410 status code. 410 means “Gone”:
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent.
From the first prototype to the live application we conducted frequent user research sessions with our government users. Research asked users to perform tasks and probed their understanding of the process. These sessions led to iterative changes in the application, changes that were tested again with further research, either validating our patterns or challenging our assumptions.
An early version of the application used 410, 404 and 301 for mappings. Research showed that users didn’t know what these codes meant, or worse, interpreted them wrongly. Rather than explaining the codes we replaced references to them with “Redirect” and “Archive”, terms users knew already, titling them with “Type” rather than code.
Managing thousands of mappings is a daunting task. Editing them one by one was very obviously not ideal, creating bulk editing tools was a big deal.
Research highlighted that:
- many similar paths get redirected to the same GOV.UK page
- many similar paths get archived
- sites without a clear URL structure were harder to manage
- users needed to group paths to manage them
- groups used for paths would be dependent on website and organisation
- it was hard to know which paths were most important
- it was unclear which paths had already been checked or edited
On a list of mappings we added a way of selecting a range (one by one, or by shift-clicking a range) using a familiar pattern found in web email clients. That set of mappings could then be redirected, archived or tagged. It tested well.
To group paths we added filtering and tagging. Organisations were free to create groups of mappings with whatever tags they liked. Tag autocomplete encouraged users to select tags their organisation had already used while tags themselves were hyphenated and lowercased to eliminate a lot of inadvertent variation. This follows my design principle of “Making it hard to do things badly”.
To indicate which paths had most importance we added hit counts, in a column that could be sorted.
The default mapping was “Archive”, but it wasn’t clear whether a mapping was set to archive through choice or by default. A third pseudo-state was introduced, it behaved exactly like an archive but had the type “Unresolved”, this made it clear which URLs were being archived by default or still required a decision.
After transition it’s important to check on the performance of mappings. It’s possible that mappings were missed (they were imported from web logs), or mistakes were made – an archive with a real user need.
The transition application provides analytics for all old websites, showing which URLs are being hit and what proportion of them are archives, redirects or errors; an error being a 404 page that has no corresponding mapping.
David Mann outlined the process on the transition blog. High traffic to redirects is what’s expected, but many errors would suggest many missing mappings, and high traffic to an archive might indicate a user need that’s been missed.
Based on research findings, we made it easy to:
- create a mapping from an error
- edit any mapping from analytics
- know whether changes had already been made to fix a mapping