Inside Inside Government

Please use the support form!

With 24 depts and 31 other orgs now live on the site, it won’t surprise you to hear that we get a lot of support requests, questions and suggestions.

It’s not sustainable to deal with these requests directly by phone and email, especially with the hundreds of ALBs soon to join the site.

From now on, if you call or email us directly about something that the support form is intended to deal with, we will ask you to resubmit it via the form.

Sorry if this feels cold and bureaucratic. That’s not the intention. It’s so we can help you better. As it stands, lots of important things are being missed because they are lost in busy people’s inboxes, and we need to be able to see the trends in the kinds of things people are asking about frequently. The appropriate team members get alerted when support requests come in, and we are trialling an SLA for response times for different types of request.

The form is here: https://www.gov.uk/support/internal (internal to government only)

You should use it for all of the following things:

• telling us about new user needs
• requesting new features
• reporting bugs or issues
• requesting analytics reports
• requesting short URLs (guidance coming soon on this)
• requesting redirects
• general feedback

Basically, anything which you think requires an action on our part should be raised through that form.

Should you need to escalate or chase progress on a support ticket (*only* once the expected resolution time has elapsed), you can do that by emailing Jenni Moss. Jenni is the single point of contact at GDS for this purpose.

Please use multi-lingual publishing features for translated content

In February we added features that enable you to publish translated editions of documents (how to do this is explained in http://inside-inside-gov.tumblr.com/post/44215691162/worldwide and http://inside-inside-gov.tumblr.com/post/45412650932/ability-to-translate-into-welsh).

Our implementation of multi-lingual publishing provides effective visual cues to users, paths for search engines and workflows for publishers. But recently we’ve come across instances where publishers have overlooked these features when publishing translated content.

When translation features are not used, it introduces a number of problems that can only be undone by unpublishing the content and starting again from scratch:

• using English language ‘templates’ for non-English content means users and the web might well regard the page as no better than gibberish
• users who find the English or translated documents aren’t notified that alternative language versions are available
• no locale is provided in the url to verify the language (e.g. .es for Spanish or .cy for Welsh) 
• translated content is not indexed properly in search
• it means unnecessary steps for publishers when creating the document(s)
• it puts the responsibility on you (rather than the app) when making updates to remember that there are parallel documents that also need to be located and updated 

This mainly concerns FCO and Wales Office at the moment, but I raise it here because other orgs have expressed an interest in beginning to publish translated editions of documents.

Imminent stories on our backlog will expand on the translation features by allowing translation of additional format types (eg. detailed guidance) and the publication of documents without there having to be a canonical English edition.

Please don’t create news stories which only promote other content

We see a surprising amount of this sort of thing, which we guess is down to old habits (imposed by legacy CMS software) dying hard.

This news story https://www.gov.uk/government/news/dbs-news-publication-april merely states the fact that this publication https://www.gov.uk/government/publications/dbs-news-may-2013 has been published, and adds no value. The news story has then been featured on the organisation’s homepage at https://www.gov.uk/government/organisations/disclosure-and-barring-service

Please don’t do this.  

All the information in the news story could have been included as detail on the publication itself, and the publication could have been featured. It’s senseless creating two URLs for a single piece of content like this. 

Flag your FOI contact today

The changes to FOI information on organisation pages we told you about last week have been live since early this week. But most departments are yet to update their contacts. Please go and do that today. 

It only takes a second. Just edit the relevant contact and change its type to “Freedom of Information contact” as shown here: 

Here’s the before and after to show what it will do on the frontend: 

Before

After

Shout if you have any problems. 

Bug with document series

There’s a bug right now which prevents you adding documents to a series, unless the series’s summary field has been populated.

We introduced the bug when we added the summary field to series and made it mandatory. Oops, our bad. We’ll ship a fix on Monday.

In the meantime, if you go in and edit the series and add a summary the error will go away.

A quick Pivotal tip

We’re in the habit of sharing links to tickets in our public Pivotal Tracker project to let people see how we’ve translated their request into a user story, and so they can track where it is in the backlog. 

Pivotal’s interface is not exactly intuitive, so here’s a quick tip on how to see where the story is in the queue. 

When you click the link to a ticket, you’ll get a full screen view like this: 

To see where the ticket is in relation to all the others, look in the top right corner and click the diagonal arrow circled here: 

This will minimise the ticket but keep it open so you can see where it is, like this (you might have to scroll to find it):

Stories in green are done. They show in the ‘Backlog’ and ‘Done’ lists.

Stories in yellow are being worked on currently. They show in the ‘Current’ list. 

Stories in grey are queued to be worked on next/soon. They show in the ‘Current’ list (this sprint) and ‘Backlog’ list (next few sprints). The team works through them in order. 

Stories in blue are pending. They show in the ‘Icebox’ list. I’ve grouped them into approximate priority groups (P1 = high, P3 = low), but they are not necessarily prioritised within those groupings. You’re welcome to raise a support request via https://www.gov.uk/support/internal if you want to dispute the priority of a story you care about, but please do take a look at all the other tickets above it so you have a sense of the relative priorities overall. 

A change to the ‘relevant to local gov’ checkbox

You no longer need to check a box on documents to specify whether they are relevant to local government (contrary to what we said in previous posts).

This relevance is now being inferred from the association to policies. All you need do is tag your news, speeches, publications and consultations to the relevant policy and the rest will follow automatically. 

The only place that checkbox now exists is on policies, and DCLG will be setting it for all policies so other departments should just not touch it. 

No format for that? Talk to us!

All too often, we’re seeing examples of publishers in departments hijacking content formats to publish material that it would be better to model explicitly as a thing in its own right. 

Here are a few of examples where it would have been great if the publishers had flagged to us that there wasn’t a suitable format or functionality, rather than shoe-horning it into a format designed to do something else. 

• Using the publications format to publish directions to office buildings like these two examples: How to find 22 Whitehall and How to find Abercrombie House
• Using the publications format to advertise overseas jobs like this one
• Using news articles to fake blog posts instead of using your perfectly serviceable blogging platform
• Putting foreign language content into formats which don’t currently support translations like this detailed guide

So please, please tell us about new or as-yet-unmet needs using the (government-only) support form. It may well be that we agree you should temporarily use an existing format if your need is urgent, but at the very least we need to know you’ve had to do that so we can plan to meet the need in a better way.

Please don’t write “statistical press release” in titles

Some publishers are titling their press releases about newly published statistics with the phrase “Statistical press release” or similar phrases. 

Here’s one from this morning: 

And here’s a load more

As we’ve said on this blog before, duplicating format labels in title fields is bad form and results in this kind of thing appearing in email alerts and feed readers:

“Press release: Statistical press notice: NHS 111….”

So please don’t do it. 

We suggest a better way of approaching this is to title it “Latest statistics about NHS 111…” 

We don’t think it’s justified to have a distinct sub-type of press release just for press releases about statistics on the announcements index. Let us know if you disagree strongly. 

It’s also questionable whether you need to issue a press release about the statistics at all, rather than merely featuring the actual stats publications themselves on your organisation’s homepage. 

Local info for info4local people

As mentioned a while back, the info4local email service is closing over Easter, and all existing subscribers will be migrated to GOV.UK.

(In case you don’t know, info4local is a service that sends email alerts to thousands of local government employees about stuff central government is publishing of relevance to them. It’s pretty popular and many local authority staff rely on it to be able to do their jobs). 

After Easter, those email alerts will be coming from GOV.UK.

We’re migrating the existing subscribers over in time for 2 April, and soon after that will be adding the ability for users to subscribe to any combination of filter options, and additionally to opt for these mails to only include stuff that’s relevant to local authorities. 

Here is a mock-up of how that might end up looking. (Emphasis on the words mock and might, this is not yet built): 

Now this last filter option is where publishers in departments come in. 

For this to be an effective service (you know, the kind of thing a person can rely upon to do their job), it’s vitally important that you check the ‘relevant to local government’ box on content items that are of  - ahem - relevance to local government.

The reverse is also true. It’s vital that you don’t tick the box for content that is not relevant to local gov. 

For identification purposes, said box looks like this :

Consider a thing to be ‘relevant to local gov’ if it’s about something that is implemented at the local level (like housing, schools, leisure services) or will have an impact on local government activity (like local government finance, transparency etc). 

From 2 April, Info4local editors will be actively checking whether the flag has been applied correctly on each item of new content, and you can expect to see feedback from them, both within the publishing tool and by email, about your use of the flag and also whether your titles and summaries are clear enough and written to style.

It’s also easy to see whether a document has been tagged as ‘relevant to local gov’ without going into edit mode, just by clicking on the ‘associations’ tab in admin:  

..and then scrolling to the bottom where it will either say….

…or…

One last thing. We’ve retrospectively tagged a load of published documents as being ‘relevant to local government’ based on the policies they were already associated to. It’ll be about 90% accurate, and means that when the filter option goes live there will be representative content there to see, so new subscribers can get a sense of what they will get in their emails. 

Editing documents you’ve scheduled for publication

We received some questions about the scheduled publishing feature, the answers to which are worth sharing with all admin users. 

The scheduled publishing feature allows you to specify when a  document will appear on the live site. 

Remember that if you set a ‘scheduled for publication’ date, you must submit the article and it must also be reviewed and published by an editor. Otherwise it won’t appear at the scheduled time. 

Content which has been scheduled and published will appear all around the site simultaneously at the scheduled time – there won’t be a delay because of the cache.

But what kind of changes can you make to documents after they’ve been scheduled for publication? 

• If you have a document scheduled for publication and you notice an error in the live version, you cannot publish a change to the live version without affecting the new version that is awaiting publication. You can only have one unpublished edition and one published edition of a given document in the system. In other words you can’t have two drafts on the go. 
• If you have a document scheduled for publication and you need to publish it earlier than the date you have scheduled it for, you need to edit it, change (or remove) the scheduled date and then make sure an editor publishes it.

Note that you can’t schedule things to publish at a time that is less than 30 minutes away (this is because of the CDN cache). 

Beware the cached 404

Be warned! If you (or any of your colleagues) attempt to view a URL shortly before the content is due to be published, you will cause a 404 error page to be cached at that URL for up to 30 mins.

A few people have been caught out by this recently. 

We will add a feature to address this asap, when the current wave of department moves is done. Here’s the story - https://www.pivotaltracker.com/story/show/46200225 

Meanwhile, DON’T!