Continuing the story of accessible voting and the "we just build stuff" mantra of the TrustTheVote project, I have an example of a serious mis-understanding that can easily arise because of the jargon and procedural confusion I wrote about earlier. We had an excellent discussion with some election officials about the various components of the technology we’re building including the Accessible Balloting Device, which creates a paper ballot that represents a voter’s choices that were indicated using a computer display and pointing devices. All seemed well, until it seemed that we had created a serious mis-perception that the TTV project is trying to both build technology for, and to advocate for, particular voting methods. Ouch! Really, we do just build stuff, and make real efforts to work with election officials to make sure that we "get it right" in terms of what they need and want for their current approach to voting.
That mis-perception took the form of a very well-meaning comment that, to paraphrase slightly, the TTV model obviates the need for pre-printed paper ballots, and maybe even precinct ballot scanners. Not so! There are several voting methods that the ABD can be part of. Only one of those is the method in which everybody votes on an ABD, at least in polling places, and there are no more pre-printed blank ballots. It’s true that that model would be a big change for jurisdictions in which blank ballot printing, tear-off serial numbering, and precinct reconciliation are a big part of the current method of voting. But there are other methods that the ABD works for as well– a whole spectrum. The far end of the spectrum is the method in which everybody uses a pre-printed ballot, most marking by hand, some marking via an ABD type of device, and all ballots being counted in the polling place via the same optical scan mechanism. But for the ABD itself, and how we define it, there is no assumption about what happens next to the printed ballot, or about the use of other ballot marking schemes. The ABD is just a tool for producing a paper ballot from a bunch of human/computer interactions; the only expectation about this process is that the ABD can be configured to produce a ballot of the same format as that used for hand-marked ballots, e.g. absentee ballots.
But the key, key point, I want to make here is this: when we design and develop voting technology like the ABD, we don’t expect anybody to change the way that they run elections, in order to use it. Instead, we work with our design partners to make sure that we understand the several existing voting methods that each system could work with; and we design and develop the system to accommodate the needs of each existing voting method. We already had a 7-year experiment in which technology folks designed voting systems the way that they saw fit, and offered election officials the "my way or highway" options. We already know how that approach doesn’t work to the public benefit, and we’re under no illusion that "open source" is magic pixie dust that makes it all better. To achieve good technology results that we hope for, we are working for public benefit (and open source practices are part of that) and listening to the future adopters of our technology, rather than dictating to them. It’s more work than cranking out some code for a system that makes sense to me as a technologist, but the work, and (I hope) the result, are worth it.