Absentee Ballot Request, the Horatio Way

Today’s guest-blog is a follow-up to our continuing report on the OSET Foundation open source software repositories (currently housed at github) and related source code development efforts.  And it's from one of our contributing developers, a well-respected government I.T. technologist, Waldo Jaquith.  Without further words, Waldo, take it away!

Thanks, everyone.

So, earlier last year (2014) the Commonwealth of Virginia didn’t have a way for voters to request absentee ballots online.  This was intended to be part of the Voter Services Portal work the OSET Foundation’s TrustTheVote Project would eventually incorporate, but hadn’t gotten to it.  However, this meant voters had to download a PDF, print it out, fill it out on paper, and mail it to their local registrar.

And then, without warning, everything changed. In September of 2014, the Attorney General issued an opinion that electronic signatures may be used in transmitting voting-related forms to the Virginia Department of Elections and state registrars. At last, Virginians could request absentee ballots online.  It only remained to build the infrastructure for them to do so.

The Idea

State Republicans, under then-executive-director Shaun Kenney, had launched Virginia GOP Absentee just weeks after electronic signatures became legal.

Senate Democrats, sensing an opportunity, reached out to Aneesh Chopra, former U.S. CTO and Board Adviser to the OSET Foundation, for his assistance building such a tool. Aneesh, in turn, reached out to me, offering project funding from his Innovate Virginia Fund. I've worked with the Department of Elections data for years, as a hobbyist, and I work in open data professionally, so this project was catnip for me. I figured it would take a week of work to put together the minimum viable product, and we got started immediately.

At the outset, we all agreed on a few things:

1. I would work with Virginia Republicans on this.
2. The resulting tool would be free and open source, as usable by everyone—all political parties.
3. It would be designed with an eye towards standards, reusability, and possible eventual adoption by the State Board of Elections.
4. We were intent on solving a civic problem, not a partisan problem.

The State Republicans service isn't open source, and was created for a narrow purpose, but they learned a lot in the process of building it.  So, I consulted with Shaun Kenney and former party spokesman Garren Shipley, who offered a wealth of practical advice and some cautionary tales.  I thank them for their collegial assistance in the spirit of “a rising tide raises all ships.”

The Software

OK, so since this audience has really diversified over this past year, I need to forewarn you that I am going to describe some technical stuff here, but provide definitional links for the curious, and I am going to do my best to keep this simple (because actually it really is).  Ready? Here we go…

I wound up creating two programs: a server and a client. This allows for the client to be deployed on candidates’ web sites quite easily, many of which can send their data back to a single server (which, while easy to set up, is outside of most candidates and committees expertise). I named the software Horatio, for Horatio Seymour, the former governor of New York, who was an ardent opponent of President Abraham Lincoln’s creation of an absentee balloting system to allow deployed Union soldiers to vote in the 1864 election.

The client is really simple: a single page of responsive HTML, with a hard-coded form, that uses some jQuery to provide some interactive elements. It’s just the paper form as HTML.  Some client-side error checking ensures that the form has been completed properly. If everything looks OK, it submits the form data as JSON to the server.

The server is written in PHP, and is scarcely more complicated than the client. Upon receiving the JSON via a RESTful query, it validates it against a schema.  If the JSON is invalid, it returns a code to the client, which prompts the user to correct the error. And if the JSON is valid, then it:

1. Saves the JSON to the server's file system.
2. Maps every JSON field to a pair of coordinates and writes the contents of those fields to the prescribed location on the PDF of the absentee ballot application.
3. Identifies the correct registrar for the application.
4. Sends eMail of the PDF of the application to the Registrar, using Mailgun.
5. (If the eMail to the Registrar bounces or otherwise fails, the application is immediately and silently re-sent to the Department of Elections, as a fall back. Registrars can and do use any eMail address that they want, which change and break often.)
6. Saves the PDF to the server file system.
7. Returns a "success code" to the client, including the Registrar’s contact information, informing the user to whom their Form has been submitted.

This all required all of 7-days of development time, that’s it. The resulting tool could use all kinds of improvements in its architecture, but it works just fine. It can be seen in action on a live site, which is to say that test form submissions are a bad idea.  Please don’t do that.

The Impact

One Senate candidate tested Horatio, aggressively incorporating it into his door-to-door campaigning.  If a voter isn’t sure they can vote on Election Day, he presents them with a tablet where they can complete the absentee ballot application form.  Literally dozens of people file applications on his tablet every day.  Surely, many hundreds of people will do so over the course of his campaign.  And the point is, so can ANYONE regardless of political stripe or venue.

Candidates and committees are adopting this tool, each with their own client, all sending data back to a central server.  Horatio, of course, is good for those campaigns and good for all candidates, causes, and parties, but also good for voters who can vote absentee with such ease.  Republicans are far more slowly adopting Horatio.  I have every hope that they will, and I (or anyone at the TrustTheVote Project) would happily volunteer a few hours of my time to help them do so.

The Future

Eventually, I’d like (and so would the OSET Foundation) for the Virginia Department of Elections to deploy their own copy of the Horatio server (ideally incorporated into the open source Voter Services Portal already in production there), to which anybody in Virginia could direct applications.  Because the application format is a simple, lightweight JSON representation of the form contents, all manner of software could generate the data, obviating the Horatio client for many purposes.

And, of course, I'd like to get rid of the use of PDFs as well as using eMail (which in fact, is a brittle, unreliable transport mechanism). It would be better to send JSON directly to the Department of Elections via HTTPS (a more secure web transport means), who would route it to the appropriate Registrar.

In the end, Horatio is a “minimally viable product,” the result of a short sprint to prove that it’s possible.  Its early success is making a clear argument for the need for improved election technology infrastructure, and I hope, demonstrates that agile development processes with lightweight software and open standards are the way to get there—quickly.

Editor Notes: 
We appreciate Waldo's post here today.  And we're proud to collaborate with him.  We also want to applaud him for his continued work at US Open Data.

We are delighted to have Waldo’s contributions to the Repository of election technology software, and we look forward to more contributions from several others who are working on similar projects to help innovate election administration in the digital age.  Our objective is to provide a major repository of such open source election software, all of which should “plug-and-play” with the larger Framework we have under development.  We thank Waldo for sharing this work with our readers.  If you would like to contribute, participate, or work on the TrustTheVote Project, please get in touch with us.