Re: Ballots for elections with many races

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Tue Apr 27 2004 - 17:16:34 CDT

At 5:42 PM -0400 4/27/04, David Mertz wrote:
>I spoke with new OVC subscriber Kevin McDermott last night. He
>raised the issue of elections--like those apparently held in Cook
>County, IL--with a very large number of contests in them.
>Specifically, elections might contain Yes/No votes for a hundred
>different Judges, who are all subject to confidence votes.
>
>The current ballots deal nicely with cases like the California
>Special Gubernatorial contest with a large number of candidates.
>130 people ran for Governor, but an OVC ballot would only need to
>print the name of the one candidate a voter wishes to vote for.
>Nice and compact on the paper (though navigating the GUI or RII is
>more time-consuming with all those candidates).
>
>But I don't see how 100 Judicial Confidence votes can fit on one
>piece of paper. Maybe with a really small font. Or a creative use
>of space that e.g. groups together the Yes, No, and No Preference
>Judges within different boxes on the ballot. But overly creative
>typography and layout makes voter verification less simple and
>reliable. So do we just spill over to as many pages as are needed?
>Is it legal to only record the relatively rare "No confidence"
>votes, and just leave off the usual "Yes" or "No Preference" votes?
>
>What does the wisdom of the OVC opine on this matter?

The notion that the entire ballot should fit on one screen is
something that was needed for a quick demo. That assumption should
never be in the production system. We need human factors studies to
determine appropriate scaleable user interfaces, especially for the
visually or reading impaired. While normally sighted people "get"
our RII, it's not at all clear that it is useable by someone for whom
it was intended. It's merely demo quality.

It's for reasons like these that I'm in favor of mostly starting from
scratch in developing production software. I want to reuse software
developed for this project only when we decide that it fits into a
greenfield decision of what to build. I don't want to bias what we
*could* or *should* build just so we can use something we already
have.

Of course, this applies to the non-COTS stuff in my message earlier.
I am not saying I want to rewrite Gnosis. I do, however, want there
to be a fresh analysis of the software development language(s) and
platform for each component.

It does not mean that we should cease software development on the
demo software either. There are a few improvements we can and should
make to the current software to make for more robust demos. For
example, making the BRP more robust so it can be reliably demoed is a
good thing. Also, unless there is a clearly compelling idea for
handling the make-sure-only-one-vote-is-cast by-a-voter problem that
does not involve a variation of a smart card or similar token, we
build smart cards into our demo too.

Thanks.

Best regards,
Arthur

-- 
-------------------------------------------------------------------------------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Fri Apr 30 23:17:19 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT