Re: Voting Booth Mockup

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Sun Jun 01 2008 - 21:45:53 CDT

Ed Cherlin wrote:

> Thanks. Alan.
> On Sun, Jun 1, 2008 at 9:39 AM, Alan Dechert <> wrote:
>> I put together a mockup of our voting booth design. One person, no
>> toolshave
>> for assembly.
> Looks good, but it will require testing under something resembling
> real-world conditions. Can we have a kit at the conference for people
> to try out?
I'm not sure it would be practical at the LinuxWorld conference --
especially given space considerations. Maybe for some other presentation,
but it's a matter of resources. I wrote an OVC check for $64 to Home Depot
for the materials -- and that was a stretch. If others want to take that on
as a project, I'm all for it.

>> The ballot layout (printout from 2004 demo) represents an LCD panel
>> mounted
>> on the board. The printer shown is a battery-powered HP H470b, which I
>> use
>> for demos. For LinuxWorld, these will be cheaper printers (maybe HP
>> D4260 ~
>> $40 ea) with surplus PCs underneath the table. We plan to use 15" LCD
>> panels (1024x768) for LinuxWorld, and have a mouse.
> Some people have told me that in production systems we should use
> something more reliable than inkjet. What do people think?
We had a discussion about that on this list a few years ago. I think Karl
Auerbach won the debate for inkjet.

I've been doing demos up and down the state with Inkjet printers. They are
great for this, and can be battery powered. The h470b will run all day on
battery -- 400+ sheets is way more than any single voting machine would need
to do.

Furthermore, it might be that the inkjet technology will be much further
advanced in the next couple of years.

Go to this page and watch the video of the A4 printer:

Check their FAQ:
"We plan to introduce components in 2008, enabling our customers to
introduce their first products in 2009." The timing seems good for a voting
system product that might get its first large scale use in 2010.

>> In a production system, we might have a smart printer that could run
>> Linux
>> and have a DVD drive. Ports, switches, and drive opening would all be in
>> the rear of the device. Once booted, it would be attached to the board
>> so
>> that there would be no access to these things until the polls close and
>> the
>> machines removed.
> I see how that prevents replacing the DVD, but it seems that somewhat
> more is needed for the ports and switches. How would the printer be
> attached? Shouldn't the cables be secured in place and covered?
I'm not sure about your issues with ports and switches. I guess you mean
someone might still be able to get their fingers back there. The printer
(smart printer designed for election-dedicated duty) could butt up against
the back of the back panel -- flush or almost flush. I mean if someone is
hell-bent on damaging the system, they could bring a hammer. But I don't
see much problem preventing cheating.

The cable from the device to the screen should be embedded in the table top.
The power cable should be routed underneath to a power supply -- certainly
out of reach for the voter.

>> A big variable for production use will be the screen. Larger, higher
>> resolution, and touchscreen would be more expensive but might be worth
>> it.
> I see COTS 20" LCD displays, 1680 x 1050, for a little over $200
> retail. 15", 1024 x 768, as low as $125.
> Touchscreen (Surface Acoustic Wave), 17", 1280 x 1024, about $500, 15"
> , 1024 x 768 $400.
> Well, we should talk to Mary Lou Jepsen of Pixel Qi in San Francsco.
> She is planning a wide range of new lower-cost, higher resolution
> screens for 2009, following on the 1200 x 900 display she created for
> One Laptop Per Child at about $30 manufacturing cost. I wrote her an
> e-mail about it but Pixel Qi is tied up in raising venture capital at
> the moment. When that is done we can have the conversation we need.
Ted Selker told me that touch screen capability could be added at no cost --
software only. That is, the technology used to put the pixels on the
display could also be used to detect a touch. We really do not need or want
color, if that helps keep the cost down. It doesn't seem like anyone is
making monochrome screens these days, however.

I'm looking for people that would be interested in partnering for the
display. So, I am interested in any meetings or discussions that could be

>> For navigating the ballot, I want to have the entire ballot laid out on
>> one
>> screen (our current demo -- using Pvote -- only shows one contest at a
>> time). Clicking on (or touching) one contest will fill the screen with
>> just
>> that contest. After making a selection, after a slight delay (maybe 2
>> seconds), the screen reverts to full-faced view.
> We'll have to ask the User Interface specialists about that. I can see
> an argument for a fixed, automatic delay, or for waiting until the
> user is satisfied and clicks to go back to the full ballot. Speaking
> for myself alone, I prefer for the machine to wait for me. In general
> I prefer for programmers not to be too smart on my behalf.
I think a feasibility study could look at that. I will put that on the
scope of work we will be giving to LA Co. for a feasibility study. Set up
human trials comparing the various options.

>> Depending on screen size,
>> resolution, size of ballot, etc, the text on the full-faced view may or
>> may
>> not all be readable.
> If we want to get fancy, each contest could have a scrolling window.
> Just providing a readable summary on the main ballot display might
> work and would be much simpler.
Again, put it in a feasibility study.

>>However, it will be clear which contests have been
>> selected and which ones are left -- and the selections made should be
>> readable.
> With color or some other form of highlighting?
Yes, something like Pvote. Have you seen that?

> I have put out a call for Python programming help on the ballot
> creation software. Has anybody contacted you yet?
Not yet. I will also put out some notices soon. We are now in a real time
crunch for LinuxWorld.

>> A voting booth (one per poll site) with enhanced access features would be
>> laid out differently (wheel chair access, etc.), but use the same
>> components
>> -- along with added headphones, etc.
> We need to get that in front of the disabled advocacy groups that need
> to be clear on what we are proposing. ...
I agree. I plan to contact some of them next week to get input for
LinuxWorld. As for a production system, this needs to be part of a
feasibility study.

> Some reflexively oppose any
> paper ballot without looking at the details. We know that we offer
> better assistive technology than DREs, but these groups won't know
> that until they see it for themselves.
Yes, but most know by now that paperless voting is on the way out. NIST and
the EAC talk about "Software Independence" (SI). Bottom line with SI is
that it means paper. The debate about paperless voting is just about over.

>> Before exiting the voting booth, the voter places the ballot in a privacy
>> folder (covers text but leaves bar code exposed). The folder with the
>> ballot will be handed to a pollworker at the ballot box.
> We have to get this clear with the disabled community as well. You
> omitted the option of going to a private reading station,
> independently programmed, to verify the bar code. The reading booth
> can be the same physically as the assistive voting booth, can't it?
I don't mean to omit the ballot verification station. At LinuxWorld, the
ballot verification station (a bar code scanner mounted for hands-free
operation) may be part of the enhanced access voting booth -- given space
considerations. BTW, the bar code scanner I have (Richard Dawson has one
too -- a Symbol DS6708) can work in hands-free mode. In a production
system, the scanner might be at a point between the voting booths and the
ballot box.


Alan D.

OVC-discuss mailing list
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon Jun 30 23:17:06 2008

This archive was generated by hypermail 2.1.8 : Mon Jun 30 2008 - 23:17:12 CDT