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

[Alan Dechert]

"Andrew Dalke" <adalke at mindspring.com> wrote in message
news:bff56e$8iv$1 at slb9.atl.mindspring.net...
> Alan Dechert:
> > 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
>
> "greyed" in normal UI parlance means the option is no longer selected.
> What happens if someone pressed the wrong button?  How is the correct
> selection made?
>
Point (or click on) again to de-select.  This is one thing that may require
a little voter training. I think it's easy enough, but then we'll find out.
You could add a "reset" button but that would make an already busy screen
even busier.  I'm not sure if that would be easier.

> > 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).
>
> No apostrophe?  What if I want to vote for "O'Reilly"
>
As a matter of fact, we won't let you vote for O'Reilly.  On second thought,
you're right, I guess.  Okay we'll have an apostrophe available.  Anything
else?

> > selected.  De-selecting one of the selected candidates reactivates the
> > others.
>
> Ahhh, I think I would have been confused by that.
>
> Then again, I get confused at time by the machine I use now.  :)
>
as before ...

> > 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.
>
> Heh.  I read "CLEAR CHOICES" as a command "the choices are clear".
> What about "RESET CHOICES", or an alternate like
>
point taken.  I changed it.

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

>   Bill the Cat     [1]  [2]  [3]  [4]
>   Snoopy Dog  [1]  [2]  [3]  [4]
>   Go Fish         [1]  [2]  [3]  [4]
>   Lucy Ricardo [1]  [2]  [3]  [4]
>   James Kirk    [1]  [2]  [3]  [4]
>
This looks reasonable.  There are several ways that ranked preference has
been implemented.

This on-screen ballot is designed to closely follow paper ballot design.
Partly, this makes it easy for a voter to mark a sample ballot and have the
on-screen ballot look the same.  The design I have there also means that a
marksense version could also look the same.

The buttons in this case are just for display.  The order is set by the
order the candidates are selected.

> and how are writins added to this?
>
You would do the write-in as with other races.  If you did the write-in
before selecting others, then the write-in would be ranked 1st.

> *sigh* .. I know just enough to ask questions and be annoying, but not
> enough to know the answers....
>
> > 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.
>
> I approve of the Mercuri system (I think that's what it's called when a
> paper ballot is generated from an electronic ballot - the all-electronic
one
> I use now is scary).  ....
>
Mercuri (Mercuri-Neumann, more accurately), suggests the paper ballot be
inaccessible to the voter -- viewable behind glass.  This involves some
expensive and proprietary hardware since paper handling must also deal with
rejected printouts.

My scheme is cheaper and lower tech.  It allows the voter to handle the
ballot.  This involves a minor security issue (then again, since when have
we decided we can't trust voters to touch their ballots?).  But I think
handling the ballot is better psychologically for the voter.  This is an
issue for our full-blown study to look at in some detail, but we won't worry
about this for the demo.

> I was just thinking though.  Suppose I wanted to rig
> the elections by paying for votes.  If I know the format of the ballot, I
> could generate them myself on specially marked paper then give that
> to the people who I've payed for the vote, who go through the process
> of voting but use the paper I gave them instead of the printout..  Later,
I
> or my cronies get access to the ballots (eg, "I'm a reporter and I want to
> verify the votes") and can see if my special ballots are included, and
> reward/punish as appropriate.
>
> Not likely to be a problem in real life, but just something I was
> thinking about.
>
It is a real life problem.  We've given a lot of thought to this issue.  The
printout will be designed so that counterfeits can be detected easily.  A
voting machine will produce special markings particular to that machine and
that Election Day which you would have no way of knowing how to duplicate on
another machine.  There are various other safeguards that will be built into
the system so that counterfeits can be detected.  Again, this is not
something we'll spend any time on for the demo.

Vote buying schemes won't be effective against our system because while
elections people will know how to spot the counterfeits, crooks (out side
the system) won't be able to distinguish counterfeit from real.

I don't want to go into this in any depth because I don't have days and days
to go over all the possibilities -- we've gone over this stuff before lots
and it will be investigated in depth in the full blown study.  I just don't
have time right now -- just trying to get a simple demo built.

> > 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.
>
> That's for certain.  The tendency to move to higher-tech, more expensive,
> and less trustworthy voting machines is scary.
>
Agreed.

> > 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.
>
> The only person I've heard of in this field is Rebecca Mercuri, who
> I think is an academic.  I've read a lot of RISKS.  :)
>
> > 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.
>
> The phrase "bar code" scares me in that the bar code and the human
> readable text may differ.  Why not just have everything in text?
>
> > Blind voters will use the system wearing headphones and using a
> > hand held device to register selections.
>
> Isn't that overkill?  I seem to recall that already there are provisions
> for people with special needs to have someone in the booth to help.
>
I don't think it's overkill.  One of the current [lame] arguments against a
"voter-verified paper trail" is that "Mandating Voter-Verified Paper Trails
Could Deny Voters With Disabilities the Right to Cast a Secret Ballot."

http://www.civilrights.org/issues/voting/details.cfm?id=14878

We have to have a system that allows blind people to maintain a secret
ballot.  This requirement is pretty much absolute, I would say.

> In addition, how does a blind person do a write-in vote?  ...
>
As with current DREs, they use a device with mechanical buttons.  It's also
likely (the Help America Vote Act pretty much mandates it) that there will
be one system set up at each polling place that will be specially outfitted
for disabled voters.  Generally I don't think the voting machines will have
attached keyboards, but the one for disabled voters might include one.

> Or someone who is illiterate and hard of hearing? ...
>
We are not going to do much with this for the demo.  These are issues that
require a lot of time and effort to study.

> > 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.
>
> Python would do this just fine.  There are the various GUI projects, but
> this sounds like a good place for pygame.
>
Okay, thanks for your input.

> My caution though is that usability testing for this is deeply hard,
> and I would advise against "a few weeks" even for demo prototype
> code as you suggest.
>
Darn!  Things usually takes longer than we want.  We're not going to do a
great deal of usability testing for the demo.  Mainly, we want to
demonstrate that cheap trailing-edge PCs can make great voting machines.
It's understood that we will have some lack of functionality and rough edges
that will be worked out in the full study.  Also worth noting: the PC voting
machine software is a very small part of the overall problem.

Alan Dechert