Fw: Possible use of Python for a voting

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Sun Jul 27 2003 - 19:40:00 CDT

FYI, in case some of you missed it, here's the first post I made to
comp.lang.python. I talk about some of the requirements here. There have
been a lot more details discussed on this list so far. We need someone to
pull this information together and build a requirements document and a
specification for the demo software.

Alan

- ----- Original Message -----
From: "Alan Dechert" <adechert_at_earthlink_dot_net>
Newsgroups: comp.lang.python
Sent: Sunday, July 20, 2003 1:43 PM
Subject: Possible use of Python for a voting machine demo project -- your
Message-ID: <6102@initial.digest>feedback requested

> 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@earthlink.net
>
>
>
>
>
Received on Sun, 27 Jul 2003 17:40:00 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT