PollwatchUSA

When our team set out to build the PollWatchUSA at the PDF:Applied hackathon, we didn’t know how we would make it work. The initial vision was to create a platform to crowdsource problems at polling locations on election day. The closest thing we knew we could do was to let users tag a report with an approximate location, but we also knew that geolocation API was not precise. Densely populated urban centers can have dozens of polling locations in close proximity, and attributing a problem to a polling place is important if we wanted to seek accountability for the problems.

Thankfully, a new arrival to our team introduced us to the Voting Information Project API. Despite professing that she wanted to be a minor part of the effort, Kathryn Peters helped connect us to existing geolocation tools that played a huge role in shaping the PollWatch tool. Immediately, the team, led by Susan Lerner of CommonCause, saw the potential there. We built the prototype, and our team won the top prize at the hackathon.

In the next few weeks, we went through several iterations of our concept. Our initial sketch of our users told us that they would be feature phone users, which, unlike smartphones, do not support the Geolocation API. Lacking that, we reasoned, they would need a zipcode search interface to find nearby locations. Speaking with the Microsoft team, which is one of the principal providers of the VIP API, we found out that we could indeed query polling locations by geolocation and zip code through their API. Using these features, we went on to build a search interface to our site and automatically detect nearby polling locations of the user.

But this approach turned out to be a dead end. As the election day approached, the Microsoft API was moved to production servers, and the zip code search feature, as well as geolocation-based search feature, did not survive the transition.

We had to change tack quickly, so we abandoned 2/3 of our product, deciding instead to focus on the part that would allow the voters to report problems at their own polling locations. A voter would enter his home address and file a report for that location, and no other location. This meant that if you voted with a temporary ballot at a different location than the one where you typically voted, for example, and you saw some problems there, you would not be able to report them. But that was a compromise we had to make to have a functional app by election day, which was only a month off.

However, it would not be so easy. The VIP API did not yet have the polling locations for New York State. Even though CommonCause staff had diligently scraped the polling locations in New York City from pdf files, we found out that this information would need to come from the Board of Elections. New York Board of Elections has a reputation for being slow and intransigent, which often pits them against the open government activists like Susan. The odds of getting New York into the VIP system by the election day were looking increasingly small.

At this point, Susan decided to deploy her formidable skills as a persuader to get on the case of the Board of Elections. In the meantime, the product team, consisting of myself and Jeremy Canfield of ReBoot, started working on fallback plans, including a plan that used geotagging, inaccurate as it was, even though that would make us a vanity crowdsourcing project with poor data.

A week before the election day, we heard the good news. The Board of Election had decided to release the data, and it was waiting for us at the lobby of the Board of Elections building, but there was still the uncertainty and fear that the data would be unusable. Low-quality data is the blight of anyone who ever felt the tedium to have to clean it. Susan dashed off to retrieve the disk. When she got back to her office, she wrote the team an excited email with the subject line “VICTORY DANCE.” “We have the disc and the data is useable! YAAAY! Chalk one up for the good guys!! YIPPEEKAYAY! Dancing on the desks!”

I replied to her email the only way I knew I could:

The next few days VIP staff worked hurriedly to add the data into their database. When the entire state’s data was available, it would become available on the API. We impatiently refreshed our browsers and waited, and waited, for four days. At last, just a few days before the election day, the New York State data was certified. Our web app was now fully functional with data from the VIP API, and we were ready for the Big Day.

Epilogue

VIP was awesome for us, and we couldn’t have built PollWatch without the VIP API. But the fragmented and shifting nature of the API required us to shift alongside it. An obvious pain point we felt was for other ways of querying the API for polling locations, such as geolocation based and zipcode based. Other things we wished we had would include a way of querying for historical information. A few days after the election day, for example, the polling places disappeared from the API, and we in turn had to disable new reports.

Going forward we will tailor the PollWatch platform for local elections, and that means we will need many more “victory dances.”