The information in this blogpost may now be out of date. See the current GOV.UK content and publishing guidance.
A few weeks back we made a change so that it's mandatory to have at least one attached file or HTML version available on a publication page.
We did this because it's important that we provide a consistent user experience for publications.
What is a publication?
The publication format on GOV.UK is conceived as the end point for accessing a stand-alone, self-contained document - something which is reached via the website as opposed to being part of the website. The document itself is a date-stamped, issued information product - something portable, packaged, intended for distribution. Usually there is some ceremony about its release. Often there are bibliographic reference numbers.
The function of a publication cover page on GOV.UK is to provide meta-information about the document. It is the permanent, canonical URI for accessing and referring to the document (as opposed to the attachments themselves, which might be numerous, may get replaced, can accumulate in number over time, or offer multiple file formats representing the same document).
At the other end of the spectrum, there are things which are less obvious fits for the format, like maps, forms, circulars and newsletters, posters and similar marketing material, and correspondence with ministers and officials (like decision letters). These still fit the definition, albeit less clearly.
In the middle of that scale sit things like transparency data and responses to FOI questions. These have more in common with publications than, say, any of the announcement formats in that they are things which are released, issued, made available - more often than not in a document format.
What's not a publication?
Outside of the scope of the publication format on GOV.UK fall things like:
- slides, agendas, minutes and meeting papers (these are not publications and should instead be attached to the governance group, policy team, policy advisory group or policy detail pages that the meetings relate to)
- macro-enabled spreadsheet templates, calculators and tools (these are usually not publications and should instead be attached to the policy detail pages they relate to)
- videos (just like images, these are not publications and should be embedded into the news stories, case studies, policies or policy detail pages they relate to - or indeed into the HTML version of a publication that they help illustrate)
What the change means for you
Now that it's mandatory to attach a file or add an HTML version to a publication, this kind of thing can no longer happen:
In other words, you should never (and now cannot) put the content of the publication itself into the "Detail" ("body") part of the publication cover page.
Here's what the GOV.UK style guide says the "body" field is for on the publication cover page:
The body of a publication page is used to provide a summary of the publication in plain, neutral language – to reassure the user that it is (or isn’t) what they’re looking for. Include what the publication is about and its purpose. Publications often outlive governments so keep the language politically neutral.
Include links to related publications but use series to group them if more than a few.
Good example: ‘These reports describe the effect of government proposals to reduce the amount of money spent on legal aid. The aim of the reforms is to make sure legal aid is still available for support and representation in cases where it is justified."
There are 3 known problems with the current implementation, which we will deal with in future sprints:
1. I acknowledge that, in the case of very short FOI questions and answers like the screenshot above, it feels a bit like overkill to have to click through to a separate HTML document to view the content. We'll be looking at FOI as a special case for future iteration. Until then, putting the actual content into the HTML version is the right thing to do and a more appropriate use of the format than crowbarring it into the wrong fields.
2. We will need to migrate the legacy publications that have content in the wrong fields into HTML versions.
3. The inconsistent labelling of the field in admin ("body") and the heading on the frontend ("Details") is confusing both on publications and consultations. We'l sort that out when we can.
Those are the problems we know about. There may be other problems we don't know about, so please don't hesitate to point them out.