One of the questions publishers in government departments are asking us a lot at the moment is "Can I embed [insert name of web app here] on GOV.UK?"
In the spirit of "publish, don't send" this blog post sets out our answer.
The good news (and tl;dr version) is that we are planning to make sure departments can continue to meet the user needs that they have met - up to now - by embedding widgets, apps and badges on their sites. But we almost certainly won't be meeting those needs by allowing publishers to embed 3rd party code freely on the main GOV.UK platform.
Read on to find out why, and what we'll be doing instead.
What's this all about?
Like practically all website owners, in recent years most government departments have made extensive use of third party web tools to host or curate content outside their own publishing systems.
That's tools like YouTube and Flickr to host and share video and images, Storify and CoveritLive to curate or create event coverage, Google Maps and Google Charts to display data in visually engaging ways…and many others besides.
Often, departments then take free embed code from those providers to place content or widgets back into pages on their own site, augmenting the capability of their publishing tools.
It's not a marginal activity, but part of the daily digital operation of most government departments. So it's hardly surprising that publishers in departments are keen to know whether and how we plan to support this kind of thing for corporate publishing on GOV.UK.
What's the user need?
As with everything else, our approach is to start with a solid understanding of user needs.
The web services used by departments - including by us here in GDS - are many and varied. Some are destinations in themselves and good places to reach people, like the big social networks Facebook, Twitter and LinkedIn. Some are utilities like Scribd (for documents), CoveritLive (for live blogging), SlideShare (for presentations) and SoundCloud (for audio files). Some are a bit of both, providing both a hosting service and a social hangout, for example YouTube, Flickr and Pinterest.
It follows that the user needs are also many and varied - running the gamut from "I want to see the places this policy announcement relates to on a map" to "I want to listen to an audio summary of Foreign Office news on my way to work".
Occasionally, there isn't a clear user need beyond the publisher's desire for something visually impressive. Round the GDS office we've got a name for this - "blog bling". I've been of guilty of this kind of thing myself in my time at BIS and DCLG.
For GOV.UK we want to look at each need in turn, ensure it's something users genuinely need, and go about meeting that need in the best way possible.
What determines the best way ?
There are many things to consider to determine "the best way possible".
Here are some considerations that seem to us to be particularly relevant here:
- quality and convenience of the user experience
- how it looks and functions on different browsers, including on mobiles and tablets
- what the public record looks like in a decade's time
- impact on users' privacy
- impact on the availability and integrity on GOV.UK as a whole
Taking these considerations into account, sometimes a simple link to a third party service is the best way to meet the user need (eg linking to a Facebook page or a podcast on iTunes).
But wherever there is a clear and frequent user need which is best met from within the pages of GOV.UK, we will look to meet that need either using GOV.UK's publishing tools or using a (technically) separate blogs platform, which be available alongside GOV.UK by late April.
Meeting the need on GOV.UK
For the most common and compelling needs, we intend over time to provide functionality within the main GOV.UK platform.
It is likely that we may continue to encourage the use of 3rd party web apps to help curate and host content, but we will not be using the embed code provided by these services on the main GOV.UK domain.
Here's some of the reasons why not:
- The user experience of embedded services is often poor, displaying content in a small viewing area when a full page view would often be more useable. The user experience tends to be especially poor on mobile - few if any of these services use responsive design and many drain battery power. Often the services require a particular plugin (eg Flash or Silverlight) that not all devices support. Very often, embedded services are completely inaccessible for users of assistive technology.
To avoid all these drawbacks and more, and better to meet users' needs, we will provide alternative ways of achieving these objectives without relying on embed code on the main GOV.UK platform.
We've done this already with YouTube. Since GOV.UK's launch (in fact, since its beta) departments have been able to embed YouTube videos into the site by pasting a link to the video into their content and using a simple markdown command, which GOV.UK then renders using a fully accessible media player. Here's an example.
The next thing we will tackle is maps. This sketch below illustrates our likely approach. There's material for a whole post about this alone, but in summary, we're going to provide a way to import geographic data that departments create using online mapping tools like Google Maps and output it as a static image for displaying on GOV.UK, from which end users can then download the data in their preferred format or view the map in their preferred online service. It's an approach which places open data front and centre, removes reliance on proprietary services and gives more choice to the user.
After delivering our solution for maps, we expect to turn our attention to the need to aggregate and curate news, and social media conversations and reactions around announcements, currently met by embedding Storify and similar tools. To ensure this valuable content is not lost to posterity and to provide a better user experience, our current thinking is that we will pull the curated content into GOV.UK using Storify-like tools. This next sketch gives an idea of what that might look like. We'll be doing some thinking about a design approach to reflecting these reactions on GOV.UK in the coming months.
Meeting the need with blogs
We also want innovation to flourish, and for departments to be able to exploit opportunities from new web apps that might come along.
We are in the process of setting up a blogs platform with partners dxw and expect the first GOV.UK blogs to go live by late April. From a user's perspective, GOV.UK blogs will feel like an add-on to the Inside Government section of GOV.UK - but in terms of infrastructure they will be entirely separate.
For that reason, we intend to be a little more permissive about the use of 3rd party services within blog posts.
For instance, there is a very clear need for users who are unable to attend a public event to be able to follow real-time coverage in the form of a live blog. CoveritLive is probably the best way to achieve this, at least in the short term. So we intend to support that in GOV.UK's blogs from early on.
We don't yet know exactly what other services we will support on the blog and by when. It won't be a free-for-all, but we're working with dxw to design a process that will allow us to add support for new embedded services within blog posts, giving proportionate rigour to quality and security, and starting with the ones that are most frequently used by departments right now.
Looking beyond GOV.UK
And of course, it almost goes without saying that often the best way to meet users' needs is not to use GOV.UK at all. The whole internet is our canvas.
We expect and encourage departments to continue to do lots of their user engagement on the social networks where their users spend their time and to continue to run their own cost-effective platforms for online consultations and conversations like http://dementiachallenge.dh.gov.uk and http://www.redtapechallenge.cabinetoffice.gov.uk.
In other words, never underestimate the value of a simple hyperlink to meet the user's need from within GOV.UK.
As ever, we welcome your feedback.