I'd hoped to have a tested graphical user interface version of TEVS ready before November, but that has proven impossible. As I won't be able to touch this for some time, I've posted the existing code in an alternate repository, tevs.gui, at tevs.googlecode.com. Though it works soup-to-nuts for scanning, processing, counting, and reporting at my setup, it is untested, undocumented, and incomplete.
Here are screenshots, from which behavior can be inferred. Clicking the images will get you larger versions.
There are three control panel tabs, corresponding to the stages of the process.
First tab on control panel is for scanning. The GUI calls out to a separate scanning process, which gets the scans and writes them to files. The GUI then reads the files. Controls allow for choosing endorser if available, changing resolution, selecting duplex/simplex and ballot size. If a scanner is not found (unplugged, bad connection) the user can check and click "Search for scanner" to connect. If it is present, its type is displayed. More than one scan source is not now handled.
Second tab is for processing scanned ballots into a vote database, getting info from the database, signing and writing all info to a DVD. The signing and writing process is done by prompting a user through a terminal window dialog with tar, gpg, etc..., and encouraging them NOT to do the signing on the actual machine running TEVS.
Decisions about how to insist on an educated user have been the most difficult part of this process -- it is pointless to produce a tool that is simply trusted. The disk's user is free to alter the database at will -- the assumption here is that the group using the tool is independent of the elections office and trusts itself
Merging OCR variants -- templates are built automatically on supported vendor ballot designs when the system encounters new ballot types (as in new precincts, for example), but the OCR in building the templates will sometimes read the same contest or choice with different errors from one precinct to the next. The system makes its best guesses and then asks you to confirm or alter associations between different variants of contests and choices before it totals things up. To ignore this, all one needs to do is click "Done" and the system skips on to overvote processing and counting up the votes.
Showing results -- they can also be put into a PDF and printed.
Merging OCR variants -- templates are built automatically on supported vendor ballot designs when the system encounters new ballot types (as in new precincts, for example), but the OCR in building the templates will sometimes read the same contest or choice with different errors from one precinct to the next. The system makes its best guesses and then asks you to confirm or alter associations between different variants of contests and choices before it totals things up. To ignore this, all one needs to do is click "Done" and the system skips on to overvote processing and counting up the votes.
Showing results -- they can also be put into a PDF and printed.
Third tab is for displaying results on ballots. You can walk through ballots sequentially. You can also query the database for ballots with particular characteristics (ambiguous votes, overvotes, particular precinct, etc...), and can click through the resulting list to see those ballots.
The user interface is done using Gtk, and its appearance is generated via Glade, a user interface design tool. This makes it easily alterable and translatable. Tasks like scanning, database access, and ballot processing are farmed out to other processes, generally slight modifications of the non-UI routines that already exist.
