Possible use of Python for a voting machine demo project -- your feedback requested

Alan Dechert adechert at earthlink.net
Sun Jul 20 16:43:27 EDT 2003


In the world of voting technology experts, I'm known as the guy that has
proposed to use commodity PCs as voting machines running open source
software with a printer to generate the paper ballot.  While I have been
pushing the idea since Dec of '00, I haven't gotten any project funded yet.
Back then, I was just a crank with an idea.  Now people are starting to take
it more seriously.  I have some computer scientists and some students
interested in producing a demo of the system I have described.  Primarily,
this demo is intended to introduce the idea to the public.  Lots of ideas
for which language to use for the demo have been tossed around.  I would
like to get some feedback on whether or not you think Python would be good
for this and why.

This will be throw-away code.  It will be pure coincidence if we end up
using any of it when the real [funded!] project gets underway.  We will be
demonstrating to some reporters the look and feel of our voting machine --
and by extension to the public, especially since we plan to have a demo on
the web that anyone with an Internet connection can try out.  Some have
suggested HTML or XML but I'm not sure this will give us fine enough control
over the page layout.

Here are some requirements for the demo:

1) The display will be for 1280 x 1024 resolution.  While other resolutions
may be supported in the final product, the demo will only support this
resolution (the large screen is a critical usability advantage).  Here is a
mock up of the on-screen ballot image:

http://home.earthlink.net/~adechert/ballot-mockup3.gif

Pretty much, I want pixel-for-pixel control over what goes on the display.

2) The demo on-screen ballot will have pale background colors initially.
I'm thinking the columns will be alternating shades of pale yellow to help
delineate them.  We might also have the tiles (each contest is displayed in
a tile) with contrasting shades.  Once a contest is voted on, the colors
will change.  For example, when the voter selects a president/vice president
pair, the background will change; the non-selected pairs will be greyed
while the selected pair will be highlighted (very brightly -- should light
up like a Christmas tree).  The selected pair will also swell in size (maybe
10 %).  The target next to the names looks something like a radio button but
I'm thinking we may want a box.  On selection, a large red checkmark will
appear in the box (and maybe extending outside the box).  In any case, it
will be stupendously obvious who was selected and who was not.

3) When "WRITE-IN CANDIDATE" is selected, a large widow (maybe the full
screen) will pop up with a QWERTY keyboard in the upper half.  This keyboard
will have only three rows with the alpha keys (no punctuation or numbers
needed except for perhaps the hyphen... no shift, all CAPS).  We'd include a
backspace key and a space bar.  Under the QWERTY keyboard (and space bar)
we'll have a two-row keyboard with the letters arranged alphabetically.
Large instruction text that tells the voter to select letters from either
keyboard to build the string for the write-in.  When the voter selects
"DONE," s/he is returned to the original screen with the write-in selected.

4) The first button in the INSTRUCTIONS tile is for selecting a different
language.  The button label (now has Spanish and French text that says, "To
select a different language...") will have maybe one other language on it.
Upon selection, the voter will be given a list of languages from which to
choose.  I one is selected, the voter is returned to the original screen
with the text now in the selected language.  For the demo, maybe one other
language will actually be selectable and used in the display.

5) If the second button in the INSTRUCTIONS tile ("FOR LARGER TYPE") is
selected, we go from a one page ballot to multiple pages.  The button will
change to say "FOR NORMAL TYPE" and will have arrows appended to the left
and right of the button for previous and next pages.  Each contest will then
be displayed one a page of its own with larger text (maybe twice the size).
If we have the time, we may also include the option to make the text even
larger.  This paginated ballot style will require a summary screen that will
show all the selections made for all the contests: the "PRINT MY BALLOT"
option will appear only on the summary screen.

6) The CAT CATCHER contest illustrates how vote-for-n will look.  Once the
voter has made three selections, the rest get grey-ed out and cannot be
selected.  De-selecting one of the selected candidates reactivates the
others.

7) The County Commissioner race illustrates how ranked preference voting
would look.  When the voter selects the first one, the button in the "1"
column is filled and the text "1st" will appear in the space between the row
of buttons and the candidate name.  When the next selection is made, the
corresponding button in the "2" column is filled and "2nd" appears, and so
on.  There is a "CLEAR CHOICES" button in case the voter wants to start
over.

8) The printout is intended to come from a personal laser printer located in
the voting booth.  For the demo, we'll probably use the HP Laserjet 5L.

9) In our set up for the media, we'll have one touch screen system using a
flat panel screen something like this one (maybe exactly this one).

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2742571869&category=29502

We'll have one or more other non-touch screen systems that will work exactly
the same way except with a mouse.

The displays will be horizontal -- sitting in some custom made cradle we
come up with (maybe made from wood).  The Australians have done something
similar in a pilot project:

http://www.softimp.com.au/evacs.html

10) The PCs used will be trailing-edge -- maybe 300-450 MHz PII or PIII.

11) The demo will be advertised to show a new system that will potentially
cost a fraction of what dedicated voting machines (ES&S, Sequoia, Diebold,
et al, DREs typically cost $3,000 - $4,000 ea) cost.  With Measure 41 in
California ($200 million) and the Help America Vote Act ($3.9 billion) a lot
of public funds are being wasted on outrageously expensive hardware that
will be obsolete in a very few years.  Trailing edge PCs cost next to
nothing.  We can afford to put some extra money into the displays and still
have a system that is much cheaper.

12) Besides the standalone system, we'll have a web based version so others
can try it out.  We anticipate that writers will discuss the demo in their
articles and will include a URL for readers that want to go try it out.  The
web version will be hosted at one of the University of California campuses
(probably UC Santa Cruz, fyi).  BTW, we are not proposing that you will be
able to vote from home via Internet.  We are proposing that Internet voting
be used instead of the usual absentee voting methods, but this will be done
at attended voting stations (where the voter can be positively identified).
The Remote Attended Internet Voting scheme we propose has the advantage that
the on-screen ballot image will be exactly the same for poll site and
Internet voting.  The printout will also be exactly the same (mailed from
the remote location instead of dropped in the ballot box).  The electronic
record of the vote will also be in the same format.

13) I am pulling together faculty and students from quite a few universities
around the country.  However, this is designed as mainly a University of
California project.  Several UC campuses are now involved.  UC will be the
eventual owner of the software.  The complete [funded] project will involve
much more than just some voting machine software -- all the software needed
for conducting elections will be created.  We anticipate having quite a few
non-academics involved too.  For example, Roy Saltman is probably the best
known voting technology expert and he's not an academic.  I'm not an
academic either.

14) In our system, the printout represents the authentic vote -- it's what
the voter sees and personally verifies.  The printout will include the
ballot number printed in each corner (upside down at the bottom).  The
selections will be bar coded in a strip on the left edge.  Probably,
write-in candidate names will be in a separate bar code.  The printout will
list the voter's selections in text that can be easily read by humans and
scanners.  Blind voters will use the system wearing headphones and using a
hand held device to register selections.  Blind voters will   take the
printout from the printer and place it in a privacy folder.  They will be
able to verify the contents of the printout and maintain a secret ballot by
going to a poll worker and exposing just the edge of the printout with the
bar code so that it can be read by a scanner.  The blind voter will then be
able to hear the selections read back via headphones.

15) Here is some background information on the project proposal in case
you're interested:

Here's a copy of the first page of our UC Berkeley proposal for California:

http://home.earthlink.net/~adechert/src_proposal.html

This proposal was recommended for funding more than once:
http://home.earthlink.net/~adechert/perata3.jpg

U of Iowa CS professor, Doug Jones, is my main co-author for the current
draft of our nationwide proposal:
http://home.earthlink.net/~adechert/ucvs-proposal.rtf

More recent information is available:
http://home.earthlink.net/~adechert/
********************
So, please let me know what you think about using Python for this demo.
Also, if you are a Python expert and would like to help as a volunteer
(we're all volunteers until the project gets funding), please contact me
ASAP.  We want to have a demo running very soon!  -- within a few weeks.

--Alan Dechert 916-791-0456
adechert at earthlink.net









More information about the Python-list mailing list