Skip to main content

Setting open standards for government documents

When I ran the open standards consultation, I heard first hand the effect that government's choice of technology was having on people. Take documents, for example. You might think sending something to a department online is an easy thing, but that’s not necessarily true.

A pet shop owner based in the North West needed to receive information on her business from a department through an online service. The information was only provided in a proprietary format. So, to read the information she was forced to spend her profits on new software – software that she didn’t want or need for anything else. She summed it up eloquently, saying that as a business: “I have almost no problems communicating with the outside world…except when it comes to government.”

I see this as government’s problem, not hers. What’s more, I’ve seen this sort of frustration inside government too, where we’ve been locked into particular technologies that have an impact on how we work with our colleagues. We need to make sure we’re using the right formats.

What are document formats?

The documents we’re talking about here include the texts, spreadsheets and presentations that we create and share in government. These documents are saved in different file formats: ways to encode the instructions for double-spacing lines, making text bold or arranging images on slides, for example.

You might recognise these formats as extensions that are added to the names of documents when they’re saved – things like:

  • pdf
  • txt
  • doc
  • odt
  • xlsx
  • odp
  • html

As part of our ongoing efforts to improve government technology through adopting open standards, the Government’s Chief Operating Officer, Stephen Kelly, has volunteered to lead two document format challenges. These have been published on the Standards Hub so that users of government documents can get involved in helping us to select the right formats.

Making the right choices

The document format challenges are descriptions of the problems that users face when they try to read or work on these documents. We are asking for ideas on how we should solve these challenges, including which technical standards we should use across government.

We’ve published two document format challenges on the Standards Hub. If you have some ideas about the open standards that you think could help, please post a response on the Hub:

  1. Viewing government documents
  2. Sharing or collaborating with government documents

I asked Stephen for a few words about his role as the challenge owner:

“These challenges will really make us sit up and focus on putting the needs of our users first. The only way we can make the right decision is if people get involved and tell us what works best. Then we’ll be able to take out some of the frustration and inefficiency, making it easier for people to do their jobs or use our services. I’m in listening mode – trying to get a better picture of what people need.”

When this discovery is complete, we’ll publish early proposals so that you can help to shape them before they go to the Open Standards Board for consideration.

Get involved through the Standards Hub - help us to make the right choice.

Sharing and comments

Share this page

1 comment

  1. Comment by Tim Blackwell posted on

    This is potentially a worthwhile effort - it's always irritating to receive documents in obscure or unwieldy file formats. Many years ago, one government department emailed its newsletters as a gigantic .tiff graphic (presumably their scanner's default format). Things have improved a bit since then.

    If government uses formats proprietary to itself, it should of course provide the means to read and preferably to manipulate the encoded data. Where government makes use of proprietary commercial formats, it should provide links to free tools for accessing that data. Unless the pet shop owner was extremely unfortunate in her choice of computing tool, or the department peculiarly recondite in its selection of file format, free tools would very likely have been available. But whenever a proprietary format is used, the first question has to be: Why?

    That said, file formats per se are only part of the problem. Far more often, government makes information available in a format that is deliberately less useful than it could be - or of no use at all.

    As an example, the Valuations Office Agency defines broad rental market areas (BRMA). These areas are used to set the maximum local housing allowances that can be paid as housing benefit to private sector tenants. The agency holds a map of postcodes to BRMAs which can be accessed interactively on its website. A number of organizations have asked for this mapping as a table.

    One VOA response to such a request went:

    "4. A BRMA is properly defined by its borders, in other words, by lines drawn on a map. The LHA Direct site already contains maps of all BRMAs. Accordingly, this information is reasonably accessible
    to you already and is exempt from disclosure under section 21(1) of the Act."

    This is of course, less than useless - the maps are *literally* pictures with boundaries drawn in thick lines - not geographic data. The maps are embedded in .PDFs, but simply changing them to another file format would make no difference.

    And if this information was provided as a table, it wouldn't matter much whether it was sent as .xls, .csv, .json or .xml - just so long as it was in a format that permitted it to be useful. Instead, some people have resorted to scraping the interactive service, which is not ideal for anyone.