What We Learned from Miami Graph

What went wrong — and right — with our civic tech project

Gregory Johnson
Aug 19, 2016 · 5 min read
Image for post
Image for post
Image for post
Image for post
Gregory Johnson and Mauro Perez. (Photo credit: The New Tropic)

That’s what brought Mauro Perez and I together during a Code For Miami meeting to work on a project we called MiamiGraph. Both of us grew up in Miami, and in many ways, we saw the city as a place that was disconnected, siloed, and behind on technology for civic issues we believed were important. MiamiGraph was a way to take open data and visualize important data in Miami that would lead to an open discussion.

Data can identify, measure, and solve big problems, but only if placed in the right format. We believed we could pull it off and wanted to test the idea out, calling it Miami as a Platform.

Our first graph was a visualization of the Miami-Dade’s County 2016 budget. Mauro handled the development work behind the graph and I handled web design and community push. Here are the lessons we learned during our time working on the project together, from August to December 2015:

Keeping it simple

This wasn’t the first Code for Miami project around budget visualization as Cristina Solana — another Code for Miami member and current co-captain — had already built a Miami-Dade County Budget data visualization two years before using Chart.js. Our goal was to expand the project, testing it out as a rapid prototype. We used D3.js to create the 2016 graph and we hoped that by creating a cool interactive graph, we could get people engaged to use the website.

In retrospect, our first graph was an eye-catcher, but it probably wasn’t the best way for us to continue building graphs. After all, we were taking simple budget data and visualizing it; D3 is much more useful for heavy Data Science projects and less on simple reports. We learned fancy libraries were good for capturing interest, not so much building out a visualization platform long-term. A part of what kept us from spitting out more graphs was how difficult it was just taking simple data and making it into something cool.

The first version of the MiamiGraph was called Miami Budget. I made it forking a Material Design framework, then Mauro building out the D3.js graph using the Socrata Open Data API from Miami Dade County’s Open Data Portal.

While the original site was made on markup we decided to use the MeteorJS web framework because it was a simple and fast way to test our concept. The original graph was clunky and made it roughly a week. We decided not to pour too much energy in the process, but rather in testing the assumption that people cared about budget data. It turns out that some did.

Be Open

We made a graph and then made a push to get it in the press. The first was an article written for The New Tropic by Dina Weinstein. I used the opportunity to make a community push by sending our story to different channels. The most successful channel was Linkedin’s Miami Tech community.

We got a lot of feedback there and realized we should prioritize which graphs to work on by demand. For example, I wrote code for a polling feature we could use, but we ended up not using it because Twitter released its own polling feature.

We also had people interested in making their own version of the graph. Sean Sellek, a graduate of the neighboring coding boot camp next to us, contributed and made a Ruby on Rails version of the graph. We learned by being open to letting others see our code, we could create engagement and lead other developers to make their own graphs.

Have a clear focus and execution strategy

Image for post
Image for post
A screenshot of Miami Budget’s 311 dashboards. (Screenshot credit: angel.co)

Mauro ended up taking some 311 data and making his own map, but it wasn’t as clear or impactful as the first graphs we made. I learned that graphs should communicate value; otherwise, it’s a pretty visual and won’t hold substance. We lost sight of that; we began to lose focus because we didn’t have a clear actionable way of measuring the success of our efforts and making another move.

As the hype began to fade, the focus on this project began to leave. We decided to go our separate ways, with Mauro handing off the project to me, just in case I wanted to take it back up again.

Questions we revisited during this project

  • Why are we doing this?
  • How do we measure success?
  • What are the steps to grow?
  • Who do we need to help us?
  • How much impact did this have?

We were very data-driven and experimented a lot. One thing I learned is that’s the best way to start a project. I think the hardest part of any open-source project is sustaining it. For us, as the months went by the team got swept away in other priorities. The lack of clarity of where we could take MiamiGraph and how we could continue to create impact was fuzzy.

The result was a loss of interest that left our project — like most open-source projects out there — inactive.

The Press

A few weeks ago at a Code for Miami meeting, I spoke with someone from the City Of Miami and learned we left a bigger impression than we thought; someone in the City of Miami Finance Department saw what we built and decided to release some data of their own. The website was up, and Catalyst Miami, a non-profit group saw our graph and decided to use it to teach their team about how the budget was being spent in the city.

Highlight by the Meteor Development Group on our project.

We also got some press from the Meteor Development Group, Code for America, Florida International University News, and Miami-Dade College. And during the National Civic Day of Hacking, DJ Patil, the Chief Data Scientist at The White House, said kudos to our efforts.

Code for Miami

A group of civic hackers (designers, developers, data…

Gregory Johnson

Written by

Miami Civic Innovation & Technology at Microsoft TechSpark. Founder of Code for SFL. I run a digital service org. Building invisible cities with lines of code.

Code for Miami

A group of civic hackers (designers, developers, data scientists, urbanists and community organizers) who contribute our talents toward improving Miami.

Gregory Johnson

Written by

Miami Civic Innovation & Technology at Microsoft TechSpark. Founder of Code for SFL. I run a digital service org. Building invisible cities with lines of code.

Code for Miami

A group of civic hackers (designers, developers, data scientists, urbanists and community organizers) who contribute our talents toward improving Miami.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store