Publishing government information is about much more than simply throwing 0’s and 1’s over the firewall. It’s about building ecosystems and communities. It’s about solving shared challenges. It’s about consumption — after all, that’s the American way.
Go to any agency website, and chances are you’ll find at least one dataset sitting idly by because the barrier to consume it is too damn high. It doesn’t matter how hard stakeholders had to fight to get the data out the door or how valuable the dataset is, it’s never going to become the next GPS or weather data.
We can build cruft to get around the hurdles, but so long as the workflow is optimized for the publisher, not the consumer, we’re always going to be setting ourselves up to give the naysayers even more fodder to point at as an example for why we shouldn’t waste agency resources on open government initiatives.
An interesting micro-site – it seems very much more aimed at people who know BLS data already, and much less aimed at coders. The FAQ answers the question “What is an API?”, but doesn’t even have a list of the IDs required in order to get any data whatsoever out of that API.
This struck me for two reasons. First, it shows that the data publishers still believe that key stakeholders within government, do not yet understand the concept of or value in producing an API, a chilling thought considering the critical role open government data can, should, and is playing in shaping our economy and reimagining how citizens interact with their government.
Second, the fact that the documentation is geared not towards developers, but towards internal stakeholders shows a lack of consideration for the data consumer’s user experience. In this case, listing ID’s is just scratching the surface of what a developer might expect from the private sector. Is the API responsive? Does it return data in a usable format? Are related queries properly linked? The list goes on.
All experiences — government experience especially — should be optimized for the consumer, not for the publisher, regardless of format or internal politics.
The General Services Administration, much to their credit, has begun a “First Fridays” usability testing program, which is the tangible result of a much larger and much needed effort to educate publishers of government information as to the importance of and necessity for a purposeful commitment to user experience.
But as we increasingly push for government information to be published in machine-readable formats, what becomes of that focus on the consumer’s user experience? Is the user experience format agnostic? Here, the immediate consumer of the information is a civic hacker or other developer, and the interface is an API rather than an agency website, but the intention and importance is just the same.
The next time you publish a data source, whether in government or out, just as you should with any website, ask yourself one simple question: How can you optimize the experience for the consumer?
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →