As the 87th session of the Minnesota Legislature came to a close, the MinnPost interactive team wanted to create a way for our readers to explore what our elected officials accomplished — namely, what bills were passed and whether they were signed or vetoed by the governor.
Goals and Audience
We started the project with a brainstorming session to determine the audience for the application and what questions we wanted to explore and answer.
We identified the primary audience as “Minnesotans who are curious about politics and state government.” Not exactly mind bending, but defining the audience allowed us to narrow in on the two questions we felt most addressed our readers’ needs:
- What did the Minnesota Legislature actually do this session? and
- What did my legislators do this session?
From there we discussed features, rough ideas for interface and potential technology solutions. Our director, Kaeti, put together the project manifesto — a document that serves as the roadmap during development — and we jumped in to initial design.
Design
We had a few brief interface discussions about how we wanted the application to function for the audience. As we were trying to answer two questions, the design challenge was to integrate those two elements in a clear and user friendly way. We opted to use a tabbed approach to display both bills by category and the search by address function.
The default view would be to visualize the bills as categories. Our mockup relied on the idea of having category objects with relative sizes to the number of bills in the respective categories (the bigger the circle, the more bills). A user click on an object would then lead to a list of bills that would have an interface for seeing the details of the bill — description, how it was voted on, co-sponsors and timeline.
The secondary view focused on the user finding their own Representative or Senator. We decided that the best way would be to create an address imput that would find the legislators for that location and then display the bills they sponsored. This led to the same style of bill list as the category interface.
Data Collection and Processing
The Minnesota Legislature puts a lot of its activities online at leg.state.mn.us, but they do not offer an API, which would make it easier to get the data we wanted to visualize and present. Luckily, Sunlight Labs has a great project called Open States that is a standardized API for state-level data, specifically legislative data. Though very comprehensive, the Open States project did not have the Senate roll call for bills because the Minnesota Legislature does not provide individual vote information for the state Senate. This meant that we needed to manually scrape the Legislature site ourselves; using ScraperWiki, we were able to get that bit of information.
Finally, we did not want all the data from the legislative session, just the bills that were signed or vetoed. Fortunately, the Minnesota Governor’s website keeps track of what bills have been signed or vetoed.
Now armed with all the relevant data sources, Tom created data processing code to turn all that data into a usable feed for our application. Using Python, he wrote a basic script to create a JSON object that we could use in the application.
Visualizing Categories
While Tom was wrangling the data, Kevin started to try out some ways to visualize the categories. Having experience with the amazing D3.js library, he started the visualization in that. But, after some digging, we realized that D3 was not going to support all the browsers that our audience uses, so we looked for another javascript library to help. Raphaël was the clear choice. D3 is focused on visualizing structured data in many different ways, but Raphaël is a bit more lower level and provides a flexible, cross-browser framework for drawing, specificially vector-based images.
Using Raphaël, Kevin was able to make an exciting and simple visualization based around representing categories as circles with sizes relative to the number of bills in each category.
The Application
The final task was to put together the data and the visualization into an interactive story. Noticing that we had fairly structured data and re-usable parts in this piece, and a desire to learn something new, we decided to use Backbone.js to leverage its powerful models and collections. Backbone with Underscore.js and its nice templating offered a superb architecture for the application. And, with almost all our applications, we leveraged jQuery for DOM manipulation and just general helpfulness.
After setting up models, collections, and views for the bill data from Tom’s helpful JSON object, we created the basic bill list and the detailed bill view. The details view also included a timeline visualization of how long the bill took to pass; this was accompished with some basic data manipulation and CSS to show a relative representation of the number of days it took to pass or veto a bill.
Next we wanted to address the question, “What did my legislator do?” After creating a basic tab navigation for our second interface, we used a basic form for the user to input an address. In order to geocode the address to a latitude and longitude coordinate, we send a request to MapQuest’s geocoding service; we chose MapQuest because of its open terms of use. Now, with a geographical coordinate, we needed a way to figure out what district it was in. Again, Open States came to the rescue.
Once we knew the district and the appropriate representative, we could show a filtered list of bills — functionality we had already created for the category interface. Our application was complete.
Updating
We worked on this as the Legislature was closing, but not knowing when the final day would be. This meant that updating the data for the application had to be as easy as possible. Using great services and technologies like Open States and ScraperWiki, we are able to update the data for the application with minimal effort and time.
The Code
As with almost all our projects, you can find the code on Github. It is not made to be a general solution, but it can be easily forked and used for your own purposes with some minor changes.
Questions? Ideas? Let us know in the comments!
Add a new view: scaling categories based upon dollars
I really appreciate all your work on a project that was no small matter – neither technically nor in its potential impact on the viewer who wants to know what’s going on in the Legislature.
Here’s the thing that’s bothering me: you’ve got a “Controversial” category where you put the stadium bill. OK, let’s not quibble with the category. But visually, it looks not terribly different in SIZE when compared with numerous other categories which involved no more than a small fraction of the public monies “spent” in the stadium bill.
The view you’ve given is fine for listing all the categories, but could mislead insofar as the importance in terms of public money. And the spending of public monies is very, very high on the priority list of a lot of those who will be interested to use your app.
I’m not saying this is so simple, because the funding (i.e., what the Legislature spent on a bill) is not always so clear, and even if clear, the scope in time of the various spending can vary widely.
Not only that, but huge costs can be hidden in the legislation, as with the stadium bill, where the proponents drastically misreprented the amount of money they were spending. The only figures they ever talked about were on the “face” of the bill. But the true costs over time greatly exceed the “face” costs.
So representing the “spend” is not so simple. Maybe a “current year” and “extended years” would both be necessary to indicate scope in time. Then there’s the problem of representing the future costs of interest, inflation, lost tax base, triggers, etc.
I think this would be a very valuable addition to your product. But I realize you may not want to consider these kinds of changes. It would be a lot of work.
Thanks, Steve
Hi Steve. You make some great points. It is important to consider factors like taxpayers dollars, either going into the bill itself or as a consequence of the new law. Unfortunately a lot of that data is not available in any format, let alone a standard format that would allow use to make such an application as this one without significantly more resources dedicated to it.
We should have been a bit more explicit about what is “Controversial” in the Bill Explorer. We simply chose bills where the opposition had more than 30% of the votes, either in the Senate or House. This is a pretty dry idea of controversial put it made the most sense with the data that we had.
Otherwise, all the categories are sized based on the number of bills in them. Also note that categories are not mutually exclusive.
Hope that helps. Thanks for your feedback.