Nonprofit, independent journalism. Supported by readers.


How we built the legislative bill explorer

A look behind the scenes of how we built the legislative bill explorer.

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.


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.

Article continues after advertisement

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, 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.

Article continues after advertisement

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.


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!