Viewing entries tagged
usability

Comment

Online Voter Registration for Jurisdictions Large and Small

Much of OSDV's currrent work relates to election technology for voter registration.* In recent blog posts, I've been talking about voter registration in the context of OSDV's mission to put much needed, innovative election technology into the hands of elections officials and voters who are underserved by the best that the for-profit election technology market has been able to deliver so far:

  • clunky, arcane, and opaque registration systems,
  • clunky, arcane, and opaque adminstration technology, and
  • voting systems that don't accurately record votes.

(The latest in the latter saga of woe is NY state BoE's report from an investigation of how the "phantom vote" phenomena manifested itself in voting systems that recorded votes not actually cast by anyone.)

Specifically for voter registration, among the many needs is one at the front end of the process: just getting people to fill out the administrative forms that are required for voting "eligibility management:

  • register to vote,
  • update a voter record,
  • request an absentee ballot or absentee status,

or the even more arcane forms that overseas and military voters use for

  • the same purposes but with different administrative rules, plus varying state-specific requirements.

The good news for citizens of the Commonwealth of Virginia is that help is on the way, with a new voter service that will step a voter through each of several complex and VA-specific application forms and combinations -- and produces properly formatted paper documents that regular people can actually understand, both voters before they sign and mail the forms, and local election officials who process them.

But what about other states and localities that don't have the resources for the type of comprehensive project that the VA SBE has undertaken with OSDV and other participants? The good news for them is that there is a middle way. We took the first step a couple of weeks ago when we went live with a new release of the "Rocky" OVR assistance system operated by RockTheVote and hosted by Open Source Labs. The main feature of the new release was a web service application programming interface (API) that provides access to all of the Rocky functions. However, rather than via a browser of a user, the API provides those functions to other web sites.

How is that a benefit to elections officials, and a public benefit to voters? Sorry to make this post a cliff-hanger, but the explanation of the API will have to wait for next time. Stay tuned, it's worth it!

-- EJS

* (As some readers may have figured out already, even-numbered years to focus on registration and reporting as the voter-visible bookends of an election, while odd-numbered years have more focus on the mechanics of casting and counting ballots and data interperability to enable public transparency.)

Comment

Comment

New Citizens: Adding Usability to the Voter Registration Process

As I wrote last time, I had the wonderful opportunity to observe a citizenship oath ceremony. It had a big emphasis on voting, and included San Francisco elections department people on hand to help the new citizens register to vote. Today, I wanted to share the flip side of what I saw, and I want to start to connect it to some election technology work that we're doing now -- work that I think can deliver some real public benefit. After the ceremony, I saw a real distinction between two groups of people. One group was clearly enthusiastic about voting as a benefit of their new citizenship. Some had already filled out the somewhat cramped and confusing voter registration application form from the packet of many administrative documents they were handed earlier. Others very sensibly got some help in filling out the forms by walking up the the table where the elections division folks were offering to help people with the form. Either way, most of them were very appreciative of the elections folks being there to help and to make sure that the completed forms got to the right place quickly.

Another group was markedly un-interested, despite the encouragement to vote, in the dealing with yet another form, more government officials, and an additional disclosure of personal info to yet another part of the government. I found it sad but understandable. But for part of this group I also felt frustrated, because I was seeing right in front of me a form of barrier to franchise, albeit largely unintentional. The enthusiastic group tended to be younger, more voluble and confident speaking English (for most of the new citizens, English is a second or third language - about 2/3 of the new citizens that day were born in El Salvador, Mexico, or the Philippines), and more technologically literate (if fiddling with a smart phone is a sign of that). The rather sizable less enthusiastic group had a lot of grandparents being assisted by younger family or friends.

For these people, the application form might well be daunting: two pages of instructions in small font in addition to a form with little boxes that are hard to read for anyone, much less a user of reading glasses. And for those who actually read the instructions, there is some real confusion over whether you can vote if you lack a driver's license or SSN. (I expect that some people lacked one or maybe both.) More vexing, the elections department people told me how conscious they were about people's need for help in doing the application form correctly, and having to deal with more paperwork, and having to take the initiative to walk over to speak to more government people, in order to get the help.

In fact, one of them said that they wished they had the voter registration form on an iPad, and each of them could work the crowd with iPad in hand to get people filling the form with as large print as needed, in whatever language was convenient, with as much online assistance as possible, and no pages of daunting instructions. That really great idea really got to me, because I had 90% of it on my laptop in my backpack. I could have pulled out the laptop, which like an iPad, could be used for browser access the online voter registration assistance service that's operated by RockTheVote, with OSDV/TrustTheVote technology that I helped build. We were so close to what the elections folks needed to be more helpful to the people standing right there!

But even with a few iPads and a printer and wireless network to connect them, the elections department folks would not quite have had what they need: an online voter registration (OVR) assistance system that is used by the government, not by an NGO that might (incorrectly) be construed as partisan. Particularly in the setting of the citizenship oath ceremony -- outside, a madhouse of partisan political organizations clamoring for attention -- the government folks need to be using government systems.

And they don't have it, at least not most elections folks, even though it is so close.

So what we need to do is get this OVR technology delivered in a way that lots of elections officials can adopt quickly, adapt and localize quickly and easily, and get into production operation quickly and easily without having to spend a bunch of money, with all the government procurement hassles that that would entail.

We need to do that; the citizenship ceremony experience made that plain, as well as the government officials' need, and so … well, so we are doing that, specifically, right now. More on details next time.

-- EJS

Comment

Comment

NY Times: Hanging Chad in New York?

NYT reported on the continuing counting in some New York elections, with the control of the NY state house (and hence redistricting) hanging in the balance. The article is mostly apt, but the reference to "hanging chad" is not quite right. FL 2000's hanging chad drama was mainly about the ridiculous extreme that FL went to in trying to regularize the hand re-counting rules for paper ballots, while each time a ballot was touched, the rule could change because the chad moved. In this NY election, the problem is not a re-count, but a slow count; not problems with the paper ballots per se, but with the opscan counting system; and not a fundamental problem with the ballot counting method, but several problems arising from poll-worker and election officials' unfamiliarity with the system, being used for the first time in this election. Best quote:

Reginald A. LaFayette, the Democratic chairman of the Board of Elections in Westchester, said older poll workers had trouble reading the vote tallies printed out by the machines. “You take the average age of an inspector, it’s maybe about 65, and so you put a new product out with them, and the change has been overwhelming to some of them,” he said.

It's another example of the of situation I recently described in North Carolina. These voting systems were built for time-to-market, rather than designed, engineered, and tested for usability and reliability -- much less designed for simplicity of the process of combining tallies into election results.

The recent experience in New York is nothing truly new - but rather an example of the usability issues manifested in an election organization that, unlike those elsewhere using similar voting system products, has not yet learned by experience how to use these quirky systems with greater speed and transparency than the first time around. Of course, it is a shame that this type learning-by-doing in real elections is necessary at all, to get to a reasonably transparent election process. But that's what the vendors served up the market, and that's what TTV is working to improve on.

-- EJS

Comment

Comment

Votes Lost & Found in Myrtle Beach

Election officials in Myrtle Beach, SC, noted the absence of about 260 votes in the recent election there. Fortunately, the votes were found, and the reason for the error discovered -- and both before the election was certified. It's a good thing that Myrtle Beach election officials were making their lists and checking them twice, because it's quite possible for the omission to have been overlooked until after the election was final. However, the story is a good illustration of how some technology design decisions create the scope for operator error. The basic story is that in one polling place, a poll worker made a mistake in the process of extracting electronic vote totals from a voting machine, using a removable data storage cartridge in a way that's similar to how you might use a USB flash drive to copy some files off of your PC. The problem, however, it that these particular voting machines are designed to be picky -- if you don't use the right cartridge the right way, the data is not copied, and is omitted from the supposedly complete vote totals compiled later (Also, it is not obvious to exhausted poll volunteers when this mistake occurs.)

You might ask, why so picky? Wouldn't it be better to record vote totals in a way that didn't depend on a poll worker not making mistakes at the end of an 18+ hour day? Well of course, put that way, yes. But when you look at the actual details of the way the iVotronic voting machines work, you can see that from a techie perspective, the design is not crazy -- right up to the V-8 moment of realizing that a consequence is that operator error results in lost votes. Those details are not technical, quite instructive, and well explained by voting technology expert Doug Jones:

The electronic cartridge (PEB) is used to initialize the machine in the morning, enable the machine for voting before each voter, and close down the machine in the evening.

In some jurisdictions, a polling place has multiple PEBs: a master PEB for opening and closing the polls, and another used for routine voting. When you do this, only the master PEB has the zero report and the vote totals on it. If you've got several iVotronics at the polling place, and you use a different PEB to close the polls on some of them, the master PEB won't have all the totals; then, when you upload it, you'll be missing votes from some machines.

This is an excellent example of a procedural error of the type that the voting systems could help defend against, but don't. It would be possible to write specs that lead to automatic detection of machines believed to have been deployed for which no totals have been reported. Sadly, we haven't got such behavior in our system specs, and as a result, we chalk such problems up to human error and let the voting system off the hook.

As you can see, once again the devil is in the details -- and thanks to Doug for the infernal info.

-- EJS

Comment

Comment

Two Ballots, New Ballots

Following a previous post with before-and-after pictures of an ideal "re-modeling"of  a ballot, I have a couple notes about how such remodeling is harder in practice; another ballot image to illustrate; and some good news about on-going TTV work on ballot image processing. That ideal remodeling showed how to both fix one of class of usability flaws (visually "losing" some of the candidates in a race), and typical approach to increase accessibility, abandoning the eye-crossingly stark and skeletal black-and-white layout for one with colors, shading, fonts, and space to help visually separate distinct elements and visual highlight important elements. But the the "after" picture is idealistic in two ways.

[1] The full range of accessibility issues is much larger. To get an idea of the how much larger -- for example, variations on one color or two, one language or two, paper size, placement of instruction text -- check out part of the results of the AIGA work on ballot design. Or, take a look at the below sample image, which shows some of the fruit of two years of expert input and testing -- which we at TTV are very fortunate to be able to leverage!

[2] The intended use of these images is to be printed as paper ballots that are marked by voters (manually or with digital assistance) and can be counted by an optical scanner. The previous "after" picture lacked the big visual mess of a bunch of black rectangles that leapt to the eye much more than the actual ballot information - needed for an optical scanner to orient the ballot image and find the marks. The AIGA sample below has these "timing marks" added back in, with a bit less visual clutter, but still a lot of them.

The good news I mentioned is about the timing marks and their usability impact. Results so far indicate that our scanner can get by just fine with only marks in each of the 4 corners -- thus dispensing with most of the usability impact of the timing marks. This may seem ultra geeky, but it is the sort techie result that keeps us going. ;-) More details on this result in a later post.

-- EJS

AIGA Optical-Scan Sample Ballot

Comment

Comment

Ballot Design and the importance of (simple) usability tests

In another department of our megaplex one of my colleagues, Aleks Totic is working on ballot layout and design for the TrustTheVote technology suite. I came across this great blog post from the Brennan Center at NYU that describes a recent situation where it appears a simple bit of questionable (but valid) layout may have caused many voters to skip past a ballot initiative. From the conclusion of the article:

"What probably would have alerted officials to this problem ahead of time, and at little or no cost, would have been a simple usability test: observing ten or fifteen King County citizens as they "voted" on the ballot before the design was finalized. This solution is simple, easy and cheap. The Usability Professionals Association has a great explanation of how it's done." (from Ballot Design Still Matters)

Yes, it's true, no matter how wonderful our ballot design guidelines are, and how well an automated checklist is applied to a ballot before printing, a simple usability test ("it aint rocket science") is so simple and cheap, it should never be skipped.

It's a good article: read the whole thing!

Technorati Tags: , , , ,

Comment

Comment

RSA Conference Panel: Lessons Learned from 2008 Election Technology

I spoke in a panel at the RSA Conference yesterday, on the topic of lessons learned in 2008 about voting technology. I thought I'd use this blog to share my remarks, but even though we each spoke for only 5 minutes before the question and answer period, I covered three areas of lessons learned; so I'll cover them in separate blog posts on each topic of (1) Usability lessons (2) Audit lessons (3) Transparency lessons.

Comment