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:
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).
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:
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:
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.
> 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?
> 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"
> 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. :)
> 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
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]
and how are writins added to this?
*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). 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.
> 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.
> 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. In addition, how does a blind person do a write-in vote? Or someone who is illiterate and hard of hearing?
> 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.
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.
On Sun, 2003-07-20 at 15:43, Alan Dechert wrote: > 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:
> Pretty much, I want pixel-for-pixel control over what goes on the display.
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.
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. 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. You're going to have to plan on all votes being multi-page, and you might as well just program for that. The printout could still be single page, but then it won't look like the ballot they filled out, though that's probably fine.
I really don't know why everyone wants to use touchscreens in voting machines. I hate touch screens, they are a horrible input method. 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.
"Andrew Dalke" <ada...@mindspring.com> writes: > 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). 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.
There is supposed to be no way to tell the paper ballots apart from one another. Otherwise the ballot would be a voting receipt, something that a good voting system should not provide. Search for "receipt-free voting" in Google to see what a big problem this is for computerized systems.
> Sorry but why on earth you dont just print that on paper and let people make > their crosses where they want?
In the past there has been a lot of trouble with manual ballot systems, because people can't understand the instructions, the ballots get printed incorrectly, stuff like that. You might remember the big mess in the 2000 US presidential election, that revolved around such problems. Choosing the US President turned out to mostly be a battle between lawyers over which ballots to count rather than about what the voters wanted, and a lot of the legal decisions were made according to the political leanings of the particular judges. The ballots themselves didn't get a thorough tabulation until long after the January inauguration and people disagree about how to intepret the results even to this day.
US elections are also different than elections in most other countries because a lot of different issues get voted in them. Rather than just choosing one of a bunch of different parties like in a parliamentary system, we vote separately for (potentially) the President, Senator, Congressional representative, Governor of the state, Lieutenant governor, Attorney General, Mayor of the town, members of the local school board, ballot initatives on whether to collect an extra tax on soda bottles, on whether to build a new highway somewhere, and so on and so on. Dozens of different things, all in one election. Counting ballots by hand would require reading off from each ballot all the separate votes on each of these issues. It's not like in France or Canada (I have no idea about Germany) where there's basically just one question to vote on.
On Mon, 21 Jul 2003 00:54:34 +0200, Ulrich Petri wrote: ><snip voting with computers> > Sorry but why on earth you dont just print that on paper and let > people make their crosses where they want?
To give benefits that paper ballots can't provide. E.g. allowing people to vote over the Internet who can't get to voting booths, removing the human element of transposing ballots to a database, possibly reducing double-voting, etc.
The FREE project was developing GNU.FREE software for electronic voting; development has since halted, but they have a lot of articles resulting from the development activity:
-- \ "People demand freedom of speech to make up for the freedom of | `\ thought which they avoid." -- Soren Aabye Kierkegaard | _o__) (1813-1855) | http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B
> 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
> 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.
> > 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."
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.
On Sun, 2003-07-20 at 17:35, Andrew Dalke wrote: > Heh. I read "CLEAR CHOICES" as a command "the choices are clear".
I made that same mistake (and I thought it was odd for the UI to assert its clarity :).
> > 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). 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.
You could make sure that ballots were not brought in by signing the ballot with some key that is unknown in advance, potentially a key that is generated by each machine when it is started up (then somehow recorded so the key can be verified -- written to hard disk and printed out to be collected at the end of the voting period?). That way you'd have to corrupt the actual election officials, and once you've done that it's all pretty hopeless.
> > 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?
It should be quite easy to audit bar codes. The advantage is that they are more easily machine read than text -- an on-site reader could be both simple, cheap, and reliable for a bar code, but I suspect OCR will not be as reliable. In a centralized, more controlled location OCR will probably be fine. The case of actual fraud, a mere sampling of votes will probably expose the fraud (since the text is known to be accurate since the voter will confirm the text).
I don't think filled-in dots are particularly better than bar codes. It's effectively just a slightly more transparent bar code, which isn't necessary. I think an audit trail is sufficient -- the problem with punch cards is that the voter doesn't get to confirm their choice in such a way that a recount can match the confirmed, known correct choice against what the machine read.
> 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.
Well, the only way to do a usability test is with a demo, so no reason not for him to dive in...
On 20 Jul 2003 16:06:11 -0700, Paul Rubin <> wrote:
> one another. Otherwise the ballot would be a voting receipt, > something that a good voting system should not provide. Search for > "receipt-free voting" in Google to see what a big problem this is for > computerized systems.
On the other hand, given the ready availability of cellphones with digital cameras, even in a paper-based system you can now make your own voting receipt while you're still in the voting booth. Not clear what can be done about this... perhaps you'll have to hand in your cellphone when voting, and go through an X-ray system to prove you don't have it.
> 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.
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.
> > Sorry but why on earth you dont just print that on paper and let people make > > their crosses where they want?
< snip detailed explanation>
Thanks for explaining this to me. But i wonder why you simply dont use paper and pens?
Here in germany we also have elections where more than one thing is voted upon but if that is the case we have a seperate ballot for each of those descisions and they all go into different "boxes" and are counted by different people. To be honest i was quite shocked when i saw that ballot mockup of the OP that was VERY confusing...
This one was from the election of the german bundestag (parliament) Fore other things (like tax on soda ;) the ballots looke quite similar but with only two or so options to choose from on them....
> On 20 Jul 2003 16:06:11 -0700, > Paul Rubin <> wrote: > > one another. Otherwise the ballot would be a voting receipt, > > something that a good voting system should not provide. Search for > > "receipt-free voting" in Google to see what a big problem this is for > > computerized systems.
> On the other hand, given the ready availability of cellphones with digital > cameras, even in a paper-based system you can now make your own voting > receipt while you're still in the voting booth. Not clear what can be done > about this... perhaps you'll have to hand in your cellphone when voting, and > go through an X-ray system to prove you don't have it.
Right. This receipt problem is way overblown. If we really thought this was a big problem, absentee voting would be illegal. There are problems with absentee voting but then look at Oregon -- they have gone to vote-by-mail entirely.
There are always going to be some risks but we have to make them manageable.
"Ulrich Petri" <ul...@gmx.de> writes: > Here in germany we also have elections where more than one thing is voted > upon but if that is the case we have a seperate ballot for each of those > descisions and they all go into different "boxes" and are counted by > different people.
What is a typical number of such boxes?
In a US election, the number of "boxes" that would be needed is usually more than 20 and can be as many as 50. Not just politicians but also judges, sheriffs, and ballot questions like whether to build a new school in a given location, all get voted on.
Do you really want to fill out 50 separate pieces of paper in a voting booth, and then make sure to deposit each one in its own correct separate box?
> "Ulrich Petri" <ul...@gmx.de> writes: > > Here in germany we also have elections where more than one thing is voted > > upon but if that is the case we have a seperate ballot for each of those > > descisions and they all go into different "boxes" and are counted by > > different people.
> What is a typical number of such boxes?
> In a US election, the number of "boxes" that would be needed is > usually more than 20 and can be as many as 50. Not just politicians > but also judges, sheriffs, and ballot questions like whether to build > a new school in a given location, all get voted on.
> Do you really want to fill out 50 separate pieces of paper in a voting > booth, and then make sure to deposit each one in its own correct > separate box?
wow i wasn't aware that it is that much... Here the ballots are usually printed on colored paper so you can tell which box is for what by the color. The *maximum* of different things voted on in a single election is about 5 here...
> > > 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?
What about non-English names? Names with umlauts, accents, Asian characters, and so on?
"Alan Dechert" <adech...@earthlink.net> writes: > Right. This receipt problem is way overblown. If we really thought this > was a big problem, absentee voting would be illegal. There are problems > with absentee voting but then look at Oregon -- they have gone to > vote-by-mail entirely.
In fact absentee ballots are just about the favorite mechanism of ballot fraud. Absentee voting should be greatly curtailed if not banned outright. Instead, voters away from home should be allowed to cast their ballots at any official polling place they happen to be near, not just at the one in their home district.
I have doubts about Oregon but its problems don't see nearly as bad as places like Florida (try Googling for "Xavier Suarez" and "fraud"). If they did mail-in voting in Florida, they would never get a reliable election result again.
As for the receipt problem being overblown, IIRC, Benaloh's original paper described its motivation, citing examples of the Mafia telling people how to vote in Italian elections and demanding to see receipts. There would be similar problems in the US military from what I've heard.
> > Sorry but why on earth you dont just print that on paper and let people make > > their crosses where they want?
> In the past there has been a lot of trouble with manual ballot > systems, because people can't understand the instructions, the ballots > get printed incorrectly, stuff like that. You might remember the big > mess in the 2000 US presidential election, that revolved around such > problems. Choosing the US President turned out to mostly be a battle > between lawyers over which ballots to count rather than about what the > voters wanted, and a lot of the legal decisions were made according to > the political leanings of the particular judges. The ballots > themselves didn't get a thorough tabulation until long after the > January inauguration and people disagree about how to intepret the > results even to this day.
> US elections are also different than elections in most other countries > because a lot of different issues get voted in them. Rather than just > choosing one of a bunch of different parties like in a parliamentary > system, we vote separately for (potentially) the President, Senator, > Congressional representative, Governor of the state, Lieutenant > governor, Attorney General, Mayor of the town, members of the local > school board, ballot initatives on whether to collect an extra tax on > soda bottles, on whether to build a new highway somewhere, and so on > and so on. Dozens of different things, all in one election. Counting > ballots by hand would require reading off from each ballot all the > separate votes on each of these issues. It's not like in France or > Canada (I have no idea about Germany) where there's basically just one > question to vote on.
You make a lot of good points. As I understand it, Canada administers national, province, and local elections separately. They happen at different times and are conducted by different entities. The U.S. is one of very few where you see federal, state, and local contests on the same ballot.
"Alan Dechert" <adech...@earthlink.net> writes: > You make a lot of good points. As I understand it, Canada administers > national, province, and local elections separately. They happen at > different times and are conducted by different entities. The U.S. is one of > very few where you see federal, state, and local contests on the same > ballot.
The US does not have federal contests. All elections for federal office are actually state contests. That includes Presidential elections, which are a bunch of state contests for slates of electors from the individual states. That all the elections are state contests and not federal ones is one of the reasons it's hard to impose uniform national standards on how the elections are run.
> "Alan Dechert" <adech...@earthlink.net> writes: > > Right. This receipt problem is way overblown. If we really thought this > > was a big problem, absentee voting would be illegal. There are problems > > with absentee voting but then look at Oregon -- they have gone to > > vote-by-mail entirely.
> In fact absentee ballots are just about the favorite mechanism of > ballot fraud. ....
I think that is correct.
> Absentee voting should be greatly curtailed if not > banned outright. Instead, voters away from home should be allowed to > cast their ballots at any official polling place they happen to be > near, not just at the one in their home district.
Our system, if implemented, would replace the current absentee system as well as the current poll site system.
The absentee system would work very much like the poll site system. The voter would see exactly the same screens with either one. The printout would look exactly the same. The ballot electronic record would wind up in exactly the same format as poll site ballots. Here are some advantages highlighted in the proposal:
· Voter does not need to plan · Avoids mailing of absentee request as request is made and granted on-the-spot · No need for the county to print and mail costly absentee ballot materials · Tabulation of absentee votes available on Election Day · Seamless integration with poll site system · Secret ballot and voter anonymity preserved · Greatly reduces potential for absentee vote fraud
> I have doubts about Oregon but its problems don't see nearly as bad as > places like Florida (try Googling for "Xavier Suarez" and "fraud"). > If they did mail-in voting in Florida, they would never get a reliable > election result again.
> As for the receipt problem being overblown, IIRC, Benaloh's original > paper described its motivation, citing examples of the Mafia telling > people how to vote in Italian elections and demanding to see receipts. > There would be similar problems in the US military from what I've heard.
There are still important issues there. Generally, we've cracked down on blatant coersion and vote buying. Still, some good sting operations are probably in order.
The most persistent type of corruption has to do with campaigns that overwork the absentee ballots -- helping voters make sure they vote. Sometimes it's a fine line. A campaign worker might stop by an elderly voter to make sure s/he has mailed in the absentee ballot, and the voter asks for assistance -- or the campaign worker offers assistance. How much assistance constitutes fraud where a voter is really not sure what to do? I don't have any numbers but in 2000 a lot of older folks in Florida were getting assistance with obtaining and sending in their absentee ballots.
----- Original Message ----- From: "Tony Meyer" <ta-me...@ihug.co.nz> To: "'Alan Dechert'" <adech...@earthlink.net>; <python-l...@python.org> Sent: Sunday, July 20, 2003 5:18 PM Subject: RE: Possible use of Python for a voting machine demo project -- your feedback requested
> > > > 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?
> What about non-English names? Names with umlauts, accents, Asian > characters, and so on?
Good question. Eventually, our on-screen keyboard would enable the voter to choose accented characters. I'm thinking there would be an "ACCENTED CHARACTER" button that you'd select such that when you select "E" on the keyboard after pushing the button you'd get a drop down list of accented Es from which you could select the desired one. I'm not sure if we'll implement that in the demo (probably not, actually).
Probably, Asian characters will only be available if and when the voter has chosen the Asian language at the outset (as it is, the non-English languages available varies from county to county and state to state... it may even vary from city-to-city within counties. Many, if not most, jurisdictions only offer English language ballots). Then, the keyboard would behave the way Asian language keyboards normally behave. For the demo, I think we will have at most one other language (probably Spanish) to select.
When the printout of choices is given when a non-English language has been selected, I think the English equivalent will be printed along with the translation. When it comes to write-in votes, we probably won't be able to do that. This only becomes an issue where enough write-in votes are recorded such that it could affect the outcome. Right now, election law varies a great deal on how to deal with write-ins. In some cases (e.g., Florida) write-ins have to meet some sort of qualifications (no. of signatures) before they can be written in. Again, this is something to look at in some depth when our full blown voting study is underway.
On Sun, 2003-07-20 at 19:12, A.M. Kuchling wrote: > On 20 Jul 2003 16:06:11 -0700, > Paul Rubin <> wrote: > > one another. Otherwise the ballot would be a voting receipt, > > something that a good voting system should not provide. Search for > > "receipt-free voting" in Google to see what a big problem this is for > > computerized systems.
> On the other hand, given the ready availability of cellphones with digital > cameras, even in a paper-based system you can now make your own voting > receipt while you're still in the voting booth. Not clear what can be done > about this... perhaps you'll have to hand in your cellphone when voting, and > go through an X-ray system to prove you don't have it.
In this system you could prove that you filled out *one* ballot a certain way, but not that the ballot you took a picture of was the same ballot that you submitted, since you can throw ballots away and start over.
On Sun, 2003-07-20 at 18:53, Alan Dechert wrote: > "Andrew Dalke" <ada...@mindspring.com> wrote in message > news:bff56e$8iv$1@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.
I think it would make more sense not to change the display of the unselected candidates, but only to highlight the selected candidate.
The more you reduce the amount of color used elsewhere in the display, the more color in a selection will stand out. At least for people who aren't completely color-blind -- but those people will just have to pay slightly more attention. I think font changes might confuse people. Thickening the border of the selected candidate would not.
If you have a dense ballot like you are proposing I would expect even an experienced user would be likely to make one mistake somewhere, so it should be clear how to fix it.
> > > 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?
Also a hyphen, like for Mercuri-Neumann. I assume it would be acceptable to simply leave off any accent marks, umlauts, tildes, etc. from a candidate's name (at least in the US), even though strictly speaking an "n~" (excuse my uninternationalized keyboard) isn't the same letter as an "n"... but no one will be confused by that, which is more important than correctness. However, whether Mercuri-Neumann becomes MERCURINEUMANN or MERCURI NEUMANN would confuse and distress people (even if those were likely to be counted as the same by the system).
> "Alan Dechert" <adech...@earthlink.net> writes: > > You make a lot of good points. As I understand it, Canada administers > > national, province, and local elections separately. They happen at > > different times and are conducted by different entities. The U.S. is one of > > very few where you see federal, state, and local contests on the same > > ballot.
> The US does not have federal contests. All elections for federal > office are actually state contests. That includes Presidential > elections, which are a bunch of state contests for slates of electors > from the individual states. That all the elections are state contests > and not federal ones is one of the reasons it's hard to impose uniform > national standards on how the elections are run.
I think you have a point but there is a symantics problem.
It's true that the U.S. Constitution gives most (almost all) of the authority for conducting elections to the states. You're correct to say that this makes the establishment of "uniform national standards" highly problematic. Nonetheless, we plan to address this. This is a *very* involved subject. Have a look at our proposed Election Rules Database
Then there's the concept of "Regulatory Capture." We intend to drive the discussion of how to resolve contradictions in the current voting system.
However, to say that "The US does not have federal contests" leaves me nonplussed. Federal elections involve the election of federal officials -- e.g., Congress, President, Vice President. We have the Federal Election Commission, which looks like it's being replaced by a host of commissions. You'll find the phrase "federal election" quite a few times on this page:
On Sun, 2003-07-20 at 19:34, Alan Dechert wrote: > > 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.
I think the ATM model is considerably better than a keypad. In a keypad you have to view the number, then change focus and enter in the number, then confirm the number and the selection. Thinking particularly about old people who aren't comfortable with computers, this sort of focus shift is very difficult, though in the case of a keypad likely everyone will have this focus shift and find the process more difficult as a result. The ATM model (buttons on the side of the monitor) doesn't require any shift in focus, because the input devide (the buttons) and the select itself are visually linked.
> 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.
Mice, unlike keypads, are comfortable for many people. But an older person generally has to think very hard about the movement of the mouse to match it with the screen (since they are often reasoning to themselves about how to move, rather than having an intuitive body-sense of the mouse).
Any technique that has different levels of accessibility seems like it would meet criticism for that. People will have to decide which booth to use, will have to be informed about the differences, and may find it easier or harder than they thought once they choose. But maybe it's not a big deal, I don't know.
I think the ATM-style buttons should be fairly cheap, though. You already have to create an enclosure for the monitor, and in general while you'll be using commodity PC parts you'll still have to set the system up with a certain amount of care.
Speed should be excellent -- because of the tactile feedback and reliability of the input, people could vote more confidently with less error. I would expect 100% accuracy with respect to the actual input (though inaccuracies in reading, or simple indecisiveness will still cause errors). The one problem I would imagine would be the increased difficulty of the interface for changing your vote, and that displaying the current status of your vote would be exclusive with displaying the choices for a particular race to choose among. But since ultimately correctness is ensured by confirming the printed ballot, I'm less concerned about editing if it means you can go through the process more quickly. (You could make the vote a single keypress, but then display at the top of the screen what your last selection was while still presenting the choices for the next race... given enough room you could even just split the screen in two and show all previous selections)
Potentially by using braille the keys could be blind-accessible, when accompanied with some sort of audio. Since the system would already be modal when using keys, it wouldn't have to be adapted significantly for that situation -- you'd simply need to change a setting on one of the computers to do audio output and attach headphones, and then you'd have your accessible booth.
Anyway, I just like keyboards more than mice if you can't tell...
|
