Last time, we wrote about the idea of a voter information service where people could crowd source the data about polling place wait times, so that other voters would benefit by not going when the lines are getting long, and so that news media and others could get a broad view of how well or poorly a county or state was doing in terms of voting time.
And as we observed such would be a fine idea, but the results from that crowd-sourced reporting would be way better if the reporting were not on the “honor system.” Without going on a security and privacy rampage, it would be better if this idea were implemented using some existing model for people to do mobile computing voter-stuff, in a way that is not trivial to abuse, unlike the honor system.
Now, back to the good news we mentioned previously: there is an existing model we could use to limit the opportunity for abuse. You see, many U.S. voters, in a growing number of States, already have the ability to sit in a café and use their smart phone and a web site to identify themselves sufficiently to see their full voter record, and in some cases even update part of that voter record.
So, the idea is: why not extend that with a little extra record keeping of when a voter reports that they have arrived at the polls, and when they said they were done? In fact, it need not even be an extension of existing online voter services, and could be done in places that are currently without online voter services altogether. It could even be the first online voter service in those places.
The key here is voters “sufficiently identify themselves” through some existing process, and that identification has to be based an existing voter record. In complex online voter services (like paperless online voter registration), that involves a 3-way real-time connection between the voter’s digital device, the front-end web server that it talks to, and a privileged and controlled connection from the front-end to obtain specific voter data in the back-end. But in a service like this, it could be even simpler, with a system that’s based on a copy of the voter record data, indeed, just that part that the voter needs to use to “identify themselves sufficiently”.
Well, let’s not get ahead of ourselves. The fact is, State and/or local elections officials generally manage the voter database. And our Stakeholders inform us its still likely these jurisdictions would want to operate this service in order to retain control of the data, and to control the ways and means of “sufficient identity” to be consistent with election laws, current usage practices, and other factors. On the other hand, a polling place traffic monitor service can be a completely standalone system – a better solution we think, and more likely to be tried by everyone.
OK, that’s enough for the reasonably controlled and accurate crowd-source reporting of wait times. What about the benefits from it – the visibility on wait times? As is almost always the case in transparent, open government computing these days, there are two parallel answers.
The first answer is that the same system that voters report into, could also provide the aggregated information to the public. For example, using a web app, one could type in their street address (or get some help in selecting it, akin to our Digital Poll Book), and see the wait time info for a given precinct. They could also view a list of the top-5 shortest current wait times and bottom-5 longest wait times of the precincts in their county, and see where their precinct sits in that ranking. They could also study graphs of moving averages of wait times – well, you can ideate for yourself. It’s really a question of what kind of information regular voters would actually value, and that local election officials would want to show.
The second answer is that this system must provide a web services API so that “other systems” can query this wait-time-reporting service. These other systems should be able to get any slice of the raw data, or the whole thing, up to the minute. Then they could do whatever visualization, reporting, or other services thought up by the clever people operating this other system.
For me, I’d like an app on my phone that pings like my calendar reminders, that I set to ping myself after 9am (no voting without adequate caffeine!) but before 3pm (high school lets out and street traffic becomes a sh*t show ;-)); but oh, when the waiting time is <10 minutes. I’d also like something that tells me if/when turn-out in my precinct (or my county, or some geographic slice) tips over 50% of non-absentee voters. And you can imagine others. But the main point is that we do not expect our State or local election officials to deliver that to us. We do hope that they can deliver the basics, including that API so that others can do cool stuff with the data.
Actually, it’s an important division of labor.
Government organizations have the data and need to “get the data out” both in raw form via an API, and in some form useful for individual voters’ practical needs on Election Day. Then other organizations or individuals can use that API with their different vision and innovation to put that data to a range of additional good uses. That’s our view.
So, in our situation at the TrustTheVote Project, it’s actually really possible. We already have the pieces:  the whole technology framework for online voter services, based on existing legacy databases;  the web and mobile computing technology framework with web services and APIs;  existing voter services that are worked examples of how to use these frameworks; and  some leading election officials who are already committed to using all these pieces, in real life, to help real voters. This “voting wait-time tracker” system we call PollMon is actually one of the simplest examples of this type of computing.
GAM | out