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

[Alan Dechert]

"Ian Bicking" <ianb at colorstudy.com> wrote in message
news:mailman.1058740232.22829.python-list at python.org...
>
> If you really want pixel-for-pixel control, then SDL will provide this
> for you.  Pygame (pygame.org) provides an interface to SDL, though it's
> somewhat low-level, pyui (pyui.sf.net) is slightly higher-level, but
> poorly documented and maybe not that helpful.  In particular, I'd be
> concerned about text rendering, and then the consistent translation of
> that to print.
>
> PDF would be easier to generate, though I'm not sure how you would make
> that interactive.  Reportlab generates PDFs nicely.  Perhaps it would be
> possible to lay out the boxes accurately so you know where they are,
> then let the PDF renderer fill in the text.  How exactly you would
> render the PDF I'm not sure... though heck, it doesn't have to be that
> interactive.  You could simply render it to images, and compose those
> images to come up with the screen.  That's probably easier and a better
> experience than allowing any change in flow or layout based on something
> the user does (i.e., you wouldn't want a selection to take up more space
> once selected, even if the text itself becomes larger).  Maybe there's
> other rendering techniques you could use that I'm not aware of.
>
Thanks for your thoughts on that.

> The interface looks really dense to me, though, while not being large
> enough for common ballots anyway.  Once you add in judges, you're
> getting a lot of options.  And the county commissioner input is way too
> dense.
>
It is fairly dense, but it will be used on large screens where it looks
pretty good.  Also, if you print it out on tabloid paper, the print is
"regulation size" for printed ballots.

There is a tremendous advantage to getting everything on one page if
possible.  Having multiple pages slows down the process greatly.  The time
it takes is a big cost factor for election administration and for voters.
This ballot has 45 candidates in 10 contests and another 3 public measures.
Some ballots in some jurisdictions will have more than this, but this is a
normal amount of stuff on average.

> Also, I suspect that the entire ballot is way to dense to be
> used with a touchscreen, where the accuracy of input isn't very good.
>
We'll see.  The touch screen we intend to use works well with a stylus.  So
if we get too many mistakes using fingers, we may just have people using a
stylus exclusively.

> You're going to have to plan on all votes being multi-page, and you
> might as well just program for that.  ...
>
I'll take this as a prediction, not necessarily correct, however.  Our team
includes some people with extensive experience with voting machine
evaluation -- they think it will work.  But again, we won't know for sure
until we try.  But beyond that, most voting machine PCs we are proposing to
use will be mouse driven.  So even if it proves to be too dense for a stylus
(very unlikely, imo) it is certainly not too dense for a mouse. Virtually
all of the testers using the web based version will be using a mouse.

>The printout could still be single
> page, but then it won't look like the ballot they filled out, though
> that's probably fine.
>
Right.  "Most experts agree" that such a printout should only show the
selections made -- not all the choices.  With 13 contests, it is no problem
to get all of this on one page.  There is probably no ballot so large that
the choices would not fit on one page.  Furthermore, when larger type is
provided to vision impaired, it's normally give at twice the size (not
larger) under existing guidelines.  So, even in these cases one page should
be adequate.

> I really don't know why everyone wants to use touchscreens in voting
> machines.  I hate touch screens, they are a horrible input method.
>
A lot of people agree with you.  Certainly, the Australians that designed
their system would agree.  They went for a keypad.

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

On the other hand, a lot of people really really like the touch screens.  We
can't make them all mouse driven since a percentage of the voters will have
a big problem with that.  But there is no reason to give up on mouse driven
systems just because some people can't use them.  Mice are very cheap and
most people are used to them.  So we just need to have enough non-Mice
systems to accommodate those that need/want them.  One nice thing about the
touch screen with our system is that it will look and work exactly the same
whether you use a mouse or touch screen.

For some, neither will work so we have to be able to accommodate them.  This
is a small percentage and I don't think we're going to worry about that for
the demo.  We're proposing a very large multi-campus study that would
investigate all these sorts of issues.

> ATM-style input is much better -- real buttons lined up along the side
> of the screen.  Very reliable, not just the hardware, but the accuracy
> of input.  The only problem is when the buttons are misaligned, so it's
> not clear how the screen selection maps to the buttons.  The only
> advantage of touchscreens is they are somewhat more flexible, but that's
> also their greatest flaw.
>
> You could even fit those buttons only normal monitors.  The buttons will
> be further away from the screen, but you can paint in strips on the
> enclosure right up to the screen so that it is very clear how the
> buttons correspond to the screen.  Even if the buttons were an inch from
> the screen and raised up off the screen, the stripes would make it very
> clear.
>
> Anyway, I wish you luck -- we certainly need open voting systems.  The
> current closed systems scare me.
>
I appreciate your taking the time to write.

Alan Dechert