The information in this blogpost may now be out of date. See the current GOV.UK content and publishing guidance.
GDS held the second content clinic on 24 March, which 24 departmental and agency editors came to. Here are answers to the questions submitted that we didn’t get around to answering in the clinic, like ‘detailed guide vs a guidance publication: what’s the difference?’
Attachment titles on publication pages
The style guide says the title, summary and detail on the HTML publication landing page must be in GOV.UK style. The attachment title should be the same as the actual title of the document, in case people search for it. The best result is to work with the publication author to make the document as plain English as possible, including the title.
Hyphens or slashes in dates
Don’t use hyphens or slashes, use ‘to’ instead, for example ‘March to October 2011’. Slashes and hyphens are difficult for search engines to scan and irritating for people using a screen reader because it might read them out. When you need to compare 2 years and ‘to’ isn’t suitable (for example ‘2008 to 2009 to 2011 to 2012’), write ‘financial year ending April 2009 to financial year ending April 2010’.
HTML publications: preview and fact check
At the moment you can’t preview before publishing or send for fact check. We want to introduce this in future, but for now take a screenshot of the draft version, or build in Preview and paste your code into Production.
Attachments: how to find the page that holds them
For attachments on publication pages, type ‘site:www.gov.uk “name of attachment”’ into a search engine and the referring page will appear in search results. This also works for attachments in content items without a landing page. For example typing ‘site:www.gov.uk “Letter about forthcoming changes to planning fees (10 September 2013)”’ will give this result on Google:
The first entry is the attachment and the second is the detailed guide it can be found on. We’re currently working on replacing this detailed guide with a collection as a guide isn’t the correct format.
Footnotes and legal language
Don’t use footnotes on documents. They’re designed for reference in print, not web pages. Always consider the user need first. If the information in the footnotes is important, include it in the body text. If it’s not, leave it out. As for legal language, explain the law in plain English so that everyone can understand it, not just lawyers.
Corporate style in HTML publications
Right now we don’t edit HTML publications for style, because many are online versions of documents already in print, particularly in transition. In future, we want all content that’s written for HTML pages (for example departmental corporate reports) to be in style.
Detailed guide vs guidance publication
Detailed guides and publications have different roles. Detailed guides answer a specific user need for detailed information – usually ending in a user action, for example with government. The audience generally has a specialist or professional interest. If your content is telling someone what to do or how to do something in the form of a manual, handbook or statutory guidance, it should probably be a publication, subtype ‘guidance’.
Collections of detailed guides: how to create them
You create a collection of detailed guides in the same way you make 1 with documents – search for the title or slug and add it to the documents tab. But consider the user need and if the content is in the right format. Improve the user journey by linking and tagging, and consider if mainstream browse categories may be appropriate.
A collections page is for related documents, it’s not a navigation page for links. We shouldn’t create navigation pages for non-specialist content, because 75% of the traffic comes from search engines. Here’s a blog post on how to make a collection.
Accents on GOV.UK
You can use accents on GOV.UK, for example, ê and â. The quickest and easiest way is to copy and paste from a list of accents.
Archived pages: double redirects
The example given was an archived page which was redirected to a page that was then unpublished, requiring a second redirect. While it’s possible to do a double redirect, it creates a poor experience for users. It’s better to redirect from the original URL straight to the live page.
