I’ve heard variants of this story cropping up around Texas on systems using Hart Intercivic’s eSlate voting system. The general problem goes something like this: a voter selects “straight ticket Democratic Party” and then presses the “Cast Ballot” button. The machine then presents a summary of the voter’s choices, and, to the voter’s horror, they find “Bush/Cheney” selected rather than “Kerry/Edwards". I’ve heard variants on this story elsewhere on different voting machines, but I think the eSlate story is easier to analyze.
What went wrong? Maybe we’re talking about:
- Human-factors error: the voter pressed the wrong sequence of buttons, perhaps a result of a confusing interface.
- Software error: a bug in the machine software caused the flip.
- Hardware error: something physically in the machine broke or misbehaved.
- Tampering / fraud: a deliberately fradulent modification to the machine caused the flip.
The easiest cases to dismiss are hardware errors (the machines otherwise appear to be working fine) and tampering (if you were smart enough to tamper with the software to change the results, you wouldn’t have the summary screen show the other candidate). This leaves software bugs and human-factors issues. My gut tells me we’re looking at a human-factors problem.
On this particular machine, when you select a “straight ticket” vote, it causes all races that have a candidate for the selected party to be highlighted with a red dot. Other candidates are dimmed into a grey color with lower contrast than you have before you make a selection. How could a voter get confused? The “straight ticket” selection appears as the top “race” on the ballot. You turn the “select” wheel to scroll to the party you want and press the big “enter” button. After this, the machine helpfully advances the current selection to the next race, the presidential race. If a voter were to think that the “enter” button had not done anything yet (perhaps because there is a noticable delay while it is performing the selection) and were to then press the button again, they might indeed end up selecting the top candidate on the list of presidential candidates, who just happens to be George W. Bush.
Is this the only plausible explanation for the behavior some are experiencing? Far from it. Luckily, if this is the problem, then the summary screen is the solution. It requires the voter to make sure that these selections are indeed the ones the voter wanted. And, indeed, some voters caught their mistakes and fixed them. In that sense, the system worked precisely as it was designed.
How can the vendor engineer their system to avoid the problem next time around? For starters, they could reduce the latency after selecting a straight ticket with some performance tuning of their software. They could also use a “Just a minute…” popup window of some kind to make it clear that the machine got the command and is working on processing it. They could even consider ignoring button presses that occured while the machine was busy. However, whatever they try, they need to evaluate it. It’s called the scientific method. You get a bunch of test subject voters, with demographics representing people in the real world rather than just college students, and you can experimentally compare the “control” group with the old system to the “experimental” group with the modified system. If the control group is more accurate, then you go back to the drawing board.
This kind of testing would be of fantastic value for every electronic or paper-based voting system. For example, human-factors testing would have caught the “butterfly ballot” issues in Florida in the 2000 presidential election. Such testing could be conducted by the vendor, on new software releases, and by the customers (counties, states, or other municipalities) for each new election. I suspect that human-factors testing will become a growing and important engineering step for any voting system, regardless of its technology.
(edit: I got the names of some of the buttons wrong – it’s corrected now.)