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 use of JavaScript, images and iframes from third party sites can be used to set cookies that we won't be able to control or document, as well as to harvest cookies set by GOV.UK. By allowing this we would flout the law and ICO guidance and enable third parties the potential to track users across parts of the government web estate.
- By embedding third party code in GOV.UK we also tie our integrity to that service. If the service is compromised in an attack, shut down, changed without notice or taken over by a new provider we could be left with broken functionality, or missing or inappropriate content on GOV.UK. Similarly if third-party JavaScript is badly written or allows users to embed badly formed HTML or CSS into the page then that could break the display of GOV.UK.
- 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.
Images by Paul Downey (available on popular third party web app Flickr.)
13 comments
Comment by SEMfuze posted on
The reactions diagram is pretty cool.
Comment by Paul Downey posted on
All our code, apart from infrastructure and some sensitive projects, is open source and on GitHub: http://alphagov.github.com/ and our approach for coding in the open is explained in the service manual: https://www.gov.uk/service-manual/making-software/open-source.html
Comment by Rowan posted on
Excellent, thanks Paul! Will check that out
Comment by Rowan posted on
Your approach is admirable, but for a site like ours (Transport Scotland) we only have a small team and a very limited budget to spend on enhancements. Do you have any plans to share your coding or platforms with other public sector webmasters?
Comment by Tim Blackwell posted on
Will you have an internal URL shortening service? Or better, a unique, short non-repudiable identifier for each document published on .gov.uk, ideally supporting versioning and compound documents. Perhaps you have such things already?
Comment by Paul Downey posted on
We have in some cases created a 'friendly URL' (FURL) for popular pages, e.g. https://gov.uk/dft" . Non-repudiation has a number of different meanings, but as the post outlines, our principles dictate we have to identify a clear user-need before building something new, I suspect many of these feature are answered by GOV.UK having stable, quotable URLs, with redirects when they change.
Comment by What the federal budget illustrates about social media in government posted on
[...] policies. (NOBODY in Canada’s government would write a blog post and title it “Widgets, badges and blog bling.” Trust [...]
Comment by kriscoverdale posted on
"By embedding third party code in GOV.UK we also tie our integrity to that service. If the service is compromised in an attack, shut down, changed without notice or taken over by a new provider we could be left with broken functionality, or missing or inappropriate content on GOV.UK."
Surely your integrity is tied to that service from the decision to "use of 3rd party web apps to help curate and host content". If YouTube was shutdown, the video will be unavailable, regardless of how you choose to embed it?
Comment by Paul Downey posted on
YouTube is one of the few cases where GOV.UK hosts content on a third-party site, otherwise the data behind the content will be hosted on GOV.UK with links out to view that data elsewhere on The Web, as with the mapping example.
Comment by Andy Mabbett posted on
Google Maps? Why not OpenStreetMap?
Comment by Paul Downey posted on
Andy
the approach for mapping isn't tied to Google Maps, rather illustrates using one of a number of services to build mapping data, with a static image which links to the data in an number of different formats and links to the map in a number of different services including OSM.
However my sketch does use KML as an example open format, mainly because it supports points, shapes and HTML.
Paul
Comment by Gavin Bell (@zzgavin) posted on
This all looks like a sensible approach to supporting a wide range of providers and allowing the information to persist beyond the life of a commercial API or company. Can you comment on any progress that GDS have made with a matching policy for badging GOV.UK out onto other sites?
thanks Gavin
Comment by Paul Downey posted on
I've an example for publishing a slideshow, actually a single page with full-bleed images, which has a link for embedding in other pages. We should definitely enable similar extensions for maps and other content: http://www.flickr.com/photos/psd/8387483176