By GovFresh · January 6, 2014
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.
There was an interesting Hacker News comment that caught my eye around the release of a Bureau of Labor and Statistics API. User @nmcfarlwrote:
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 understandthe 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?