unsolicited advice for gov data app and viz builders

I spend a good deal of time exploring apps and data visualizations that use government data. Unfortunately, most of that time is spent yelling at my monitor about how they are missing some critical element or don’t provide me with enough information. In that spirit, here is some unsolicited advice.

1. show your work (and if you can’t, stop what you are doing)

First and foremost, your project needs a clear and concise explanation of what you did. What data did you use, how did you transform / normalize / prepare it, and how did you represent that data visually? If you can’t answer all of these questions, then you need to stop what you are doing and get some help; feel free to ping me and I can point you in the right direction.

You should know what every chart, map dot, thematic layer, and/or graph in your app means and be able to clearly communicate that to your users through concise, narrative text.

2. link to the source data and include the proper disclaimers

There’s a ton of public government data now available. Lots of it is from the same agency and multiple data sets will have similar sounding titles. You should, whenever possible, clearly explain what data set you used, where someone can find and download it for themselves, and re-present any and all disclaimers that the data providers attach to the data. It’s hard for me to count the number of projects that completely ignore this when it comes to crime data.

Everyblock.com does a really fantastic job on this.

3. label everything

It kills me when I see a chart w/o the x and y axes clearly labeled or labeled but lacking units of analysis. Come on people, this is an easy one.

4. provide an easy method for user feedback

I’m the kind of person who would love to ask you questions or point out awesome (and sometimes bunk) things about your project, but far too frequently there’s no easy way to send you my thoughts. Everything should include a feedback link. While it should go without saying, you need to respond to the feedback you do receive.

There’s more – much more – I can write here, but I think that these are the most critical basics. If you app meets these four tests, give yourself a pat on the back.

Please add your suggestions / ideas / comments below – my hope is that this list becomes a resource for folks over time; bookmark this and refer back when you start working on that next project.

2 thoughts on “unsolicited advice for gov data app and viz builders

  1. Hey, I’m a gov data app and viz builder now! This is great advice. We can build on this.

    At Fermi we deal with very different kinds of information: Science data and population data are different beasts. I don’t think we need to “show our work” in quite the same way because the data is pretty “pure”. We provide the underlying numbers, and there’s no significant post-processing beyond or data manipulation beyond caching and calculating aggregates like medians and means.

    Maybe a way of encapsulating your four points is to say data-driven apps need to provide context for what they’re presenting. If it’s crime data, we need the context that calls and crimes are independent phenomena. If it’s network data like I work with, we need to explain what various measurements mean to the user, and provide historical context (which is hard and computationally expensive) to compare against so that people can know if 500mbps is low or high, normal or completely anomalous.

    Providing *useful* information is key. In my imaginary “neighborhood tech finder” web app the ONE thing you’d provide is your address and the first thing you’d see is an accurate, up-to-date answer to the perennial question: “how much does motherfucking Internet cost per year in my hood?”

    Beyond user feedback, I think there’s a way to imagine data driven apps that allow users to slice off a piece of data and then ask their compatriots what it means. Part of the problem of providing context is that sometimes knowing what data “means” is hard and not amenable to machine analysis. In our case, we can show the user *where* a network traffic jam is happening, but to know what happened (which is often “someone dug up a fiber cable” or “a router kicked the bucket”) you kind of have to call the person in Kansas.

    I can imagine a niche for tools which let you explore data and then share what you find for some collaborative analysis.

Leave a Reply

Your email address will not be published.