OpenGov Hack Night: Building a Vision for a Transit Future (Part 2)

This presentation was rather long, so we’ve split this into two posts. The first one has to do with the Transit Future policy itself. This post is about the process used to build the Transit Future site.

On the April 15th OpenGov Hack NightEd Oser with Center for Neighborhood Technologies and OpenCity Apps presented their work on both the Transit Future plan and the web app that shows it off.

The Vision for Our Transit Future Site was built by Juan-Pablo Valez and Nick Dorian using the Code for America Annual Report template as a base.

Blue Line Stop

The site uses a philosophy of showing instead of telling. Juan-Pablo Valez explains below.

Valez explains that the because the project is raising money, there’s a concern that there would be a lot of confusion around the project or that the media would simply focus on the negative. Therefore the responsibility of telling the story falls to the ones who came up with the idea.

The team wanted to show something simple and very visual in order to build support for the project. When words are used, the team wanted to ensure that they used plain language and avoided jargon. (If you ever want to make sure that what you’re writing makes sense, check out – It’s not always easy.)

The first thing the site does is show the transit map as it exists today so that users can orient themselves to the map and know what they’re looking at. The site also lets users jump to the section that applies to them, like the West Suburbs. Lastly, they also made sure to set up the site for easy sharing in order to ensure the site had the widest audience. Valez explains below:

To build the maps for the site, Open City Apps reached out to local cartographer and Code for America alum Nick Doiron.

Doiron built the site using an open source template that Code for America had put together for their annual report. Some of the code was easy to change over for the new site, but there were certain things about the site that took a little extra work. Doiron explains below:

The site runs on a technology known as Jeckyll. The way that normal web blogs work is that each time you load the page (like this one) the computer has to think about what to put on your screen (including pulling our image from Flickr and the videos from YouTube.) With Jekyll, the site has the ability to display static web pages that don’t have to be reloaded every time their accessed (which makes the site cheaper to run and maintain.) The team runs the site on GitHub pages thanks to the free service offered by GitHub.

Maps are a big part of the site. To build the maps, Doiron used an open sourced tool called Leaflet. Doiron also used a tool called Mapbox to customize the maps.

To get a sense on how this works in practice, imagine an overhead projector. The Chicago map forms one layer and on top of that is another layer with all the transit lines. There’s also a third layer that highlights all the information they want to showcase during certain parts of the presentation. (For example, the airports when showing the Lime Line.) The app brings these layers together to form one unified image. To understand which lines to display, the team loaded the data into a service called CartoDB. Doiron explains below:

By using CartoDB, it becomes much easier to display the information. Doiron and Valez demonstrate below:

The site received a ton of traffic, so it was important to set up the site to handle the traffic. This is called scaling. It would take a ton of resources to constantly display every single line and tile. This can also make the site slower to the point it’s not usable.

There’s a couple of things the team did to make the site run faster. One of which was a tool in Node.js that made all the tiles once, then cached the tile. (This way, the app doesn’t have to re-draw the map each time.)

The other method that the team used to help scale the site was hosting it on Heroku. Heroku is a web hosting site that can store and run your app on the internet. (And one of the resources offered to developers at Smart Chicago.) The owner of the app can set up as many ‘dynos’ to run the app as is needed so that you’re only paying for what you need. Valez and Doiron explain below:

To find out more about the Transit Future site, visit – If you’re interested in the source code that powers the site, you can find it on GitHub here.