Re: Consensus of the OVC

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Wed May 26 2004 - 13:26:32 CDT

At 2:04 PM -0400 5/26/04, David Mertz wrote:
>For each setup (full-faced and paginated):
>1) How long did the voters take to complete the ballot?
>2a) Which was easier to confirm all selections before pressing print?
>2b) Which made it easier to modify unintended selection?
>3) Did either seem more confusing to the voters?
>4) Did one have more drop-off (were voters more likely to undervote on
>contests toward the end) than the other?
>
>[DQM]: I presume (2a) favors full-face
>
>On May 26, 2004, at 1:36 PM, Arthur Keller wrote:
>>You could have one-contest-at-a-time for selecting which candidates
>>to vote for, and full-face or the equivalent for verifying your
>>ballot before casting. In fact, I've seen DRE's that do just that.
>
>Sure, but that doesn't address (2a) at all. The scenario I
>described was of realizing an incorrect selection on Contest #1 at
>the (on-screen) verification stage. Just saying you verify
>full-face is irrelevant to this.
>
>It's possible to complicate the system, in a direction Arthur
>suggests, by using paginated selection, but then also allowing
>re-selection fall-face at the verification stage. A number of
>problems jump out with this idea (mostly that voters need to learn
>two different interfaces), but it might be worth considering.
>
>There is a nice interface that is used by many recent Linux
>installation systems. I know Mandrake does something like this, I
>think Fedora does too. On the left of the screen is a list of the
>steps users are required/intended to take. As installation
>proceeds, the highlighted selection moves down; completed steps
>might be flagged as such also. But users can return to an earlier
>step by clicking on one of the items listed at left. Such a layout
>might be intuitive to novice computer users, and allow quick
>modification of vote selections.
>
>Let me try it as ASCII art (view this in fixed font):
>
>+------------------+------------------------------------------------+
>| CURRENT CONTEST | SELECT ONE CANDIDATE FOR SENATOR |
>| Presidency | ( ) Frances E. Willard |
>| (SENATOR) | (X) Lucy Stone |
>| U.S. Rep | ( ) Karl Menninger |
>| Treasurer | ( ) William Lloyd Garrison |
>| Health care | ( ) Write-in |
>| Term limits | ___________________________________ |
>| Cat Catcher | |
>| County Commis | [<-- BACK] [NEXT -->] |
>| Verify Ballot | |
>+------------------+------------------------------------------------+
>
>Obviously, in a GUI you can use colors, fonts, graphics better than
>my ASCII version allows.
>
>I'm not saying this *IS* the best approach, but it might answer some
>navigation difficulties with paginated ballots.

I'm suggesting pagenated selection and (as much as possible)
full-face verification. However, if you finad a problem in the
displayed ballot, you click on the item with the problem, and the EVM
takes you directly to make that choice again. Once your finished,
you get back to the full-face verification. You do not have to
remake the subsequent choices in sequence. Our current RII gets you
back to remake all the subsequent choices over again, and that's a
real pain. Our current EVM has no separate verification screen.

I don't like the CURRENT CONTEST approach David suggests because it
facilitates voting only for selected races and ignoring the rest of
the ballot. Philosophically, I'd like voters to be encouraged to
vote every contest. An unwieldy system may well mean that
exasperated voters won't bother casting a vote for, say, cat catcher.
But if they need to see that screen in order to vote for President or
Senator, they'll slog through it.

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 Mon May 31 23:18:06 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:17 CDT