In May 2004 Washington Apple Pi conducted its annual election for its 2004-2005 Board of Directors. Only this year was different: this year we did it online. To some of you this change sounds obvious, and years overdue. But not everyone welcomed the idea, and some expressed questions and doubts. If you’ll indulge me in a bit of storytelling, I’ll do my best to describe how this took place and how it works.
Chad the iMac ballot box sits at his post, guarded by trained attack penguins. (Photo by Jon Thomason, taken with a Pentax Optio S digital camera.)
At some level—positive or negative, and often both—Americans have an emotional reaction to the process of voting. Whether it’s for President of the United States, for President of the Class of 2006, or for a seat on the Board of Directors of a computer hobbyists’ club, there’s something noble and something absurd about the pageant itself.
Then inevitably just as you think you’ve gotten past the latest one, the next is ready to begin. It always seems to start earlier than before. And according to Washington Apple Pi’s corporate bylaws, every year is an election year.
Without keyboard, mouse, or remote login capability, even its administrator can't get in. (Photo by Jon Thomason, taken with a Pentax Optio S digital camera.)
Each year, then, the Pi election process lurches back into gear. The Board of Directors appoints a separate Election Committee, approves a detailed set of rules, and then gets out of the way. It’s usually at this particular meeting, too late to do anything, that someone raises his hand and asks why we don’t conduct our elections online.
The case in favor of an online election is simply this: money. It costs money to bind a return envelope into each Journal, and to perforate a pull-out page, and to rent a post office box. And that’s only the Pi’s recent best practices—a bargain compared to what we were doing ten or twelve years ago when each election was guaranteed to be hotly contested. At least one year’s election was even nullified and rerun, doubling all those costs.
Another argument for the plus column is less often discussed: our return rate from paper elections is just awful, and getting worse each year. The last two years we only barely met quorum requirements. You can debate among yourselves whether that’s an inevitability of this increasingly isolated, self-service culture. Me, I think it comes down to situational appropriateness: if you’re online and presented with a clickable link guiding you through voting, you might lend a moment of your time. But anecdotal evidence tells us you’re likely to be reading your Journal on the Metro or on the toilet, two places where you won’t be easily persuaded to tear apart your magazine and lick it.
A tamper-evident sticker will help assure this monastic discipline until June. (Photo by Jon Thomason, taken with a Pentax Optio S digital camera.)
There are also some valid arguments against electronic balloting. I won’t presume to do them justice, but somewhere between perception and reality most of us believe there exists some gap between Pi members who have access to the Internet and those who do not. The actual size and severity of this gap remains an intractable and often divisive topic, which won’t be settled here. And with that debate comes concern of whether a shift to voting online creates a de facto shift of representation across that mysterious gap.
Last year at this time, another volunteer confronted me with an odd request: put together an online voting booth. This wasn’t official. He wasn’t asking me to hop into the debate of whether the organization should conduct elections that way or not. Maybe I’d build it and it wouldn’t ever see light of day—heck, that might even be my own best-case scenario. The point was, the software would exist by the time the next year’s meeting came around and somebody new raised his hand to ask the annual question. The policy decision could either happen or not, but it wouldn’t be for lack of a programmer.
This was an interesting proposal. I enjoy self-contained projects, especially when they give me a chance to learn something new. So I taught myself the PHP language, thought through the broad-strokes design, and waited to hear who the lucky Election Committee would be to own this hot potato. I was not at all keen to be stirring up somebody else’s debate all year, so for proof-of-concept prototyping I hatched a different scheme…
Years ago, TCS crew member Paul Schlosser hosted an annual football pool by hand. It was fun, and community-building. But as his Pi responsibilities increased, this sort of thing became too much effort to continue. Fellow crew member Nancy Seferian hoped that this friendly tradition could be rescued, maybe by turning to automation. Each year she’d ask me to create something that would fix this. I’d always want to help out, but realistically it was always too far down on the list of priorities of Pi development. I was also never really sure what exactly was needed or how the game was even played. Many years later, the subject had been essentially dropped.
WAP Football Pool 2004 final standings. Congratulations, David! Not to mention Kristen…
This online election thing, I realized, provided a surprise opportunity. I guessed that Nancy would probably be on the Election Committee again. We could build a football pool for practice, testing a few pivotal concepts like integration with Pi account and password mechanisms. We’d have several months of user, compatibility, and deployment testing on the sly, and then this voting booth thing would be a snap. Key to the whole process: this would be done in the context of a game, not of a chore. That makes all the difference.
The Pi’s 2003-2004 Football Pool was a hoot for many of us. It was hastily constructed during the preseason, at first only recording people’s picks. We played through its construction, not adding tallying and leader board features until several weeks into the season. Toward the end, as Super Bowl XXXVIII rolled around, I figure we had most of the kinks worked out. <wink>. See the season’s champions in the accompanying sidebar.
With the football season over, we had a number of other tasks in the air including replacing the Pi’s entire network and most servers, negotiating for exciting TCS Explorer changes mentioned elsewhere in this issue, and hosting the General Meeting program in March. Once that meeting was behind us, I turned my full Pi attention to online balloting.
We collect statistics on TCS usage, telling us which web browsers participants use to access the service so we can best support and improve it with them. By this time, 55% of user sign-ins used Safari, 25% used Mozilla or Netscape 7, 10% used Internet Explorer for Mac, and a trivial number still used struggling “version 4” browsers from the 1990s.
Now, bear in mind that this data comes from a self-selecting group of members who feel sufficiently comfortable online today. These numbers are not gathered or expected to represent all members. Assuming there does exist a significant access gap, these numbers probably under-represent our members’ lingering attachments to Netscape 4. Then again, some might argue that when necessary, our offline members will use whatever browser is installed at their library or community center, or friend’s house, or office… be that Internet Explorer for Windows or one of the Mozilla-based browsers.
Limited browsers get full functionality but no frills in Universal mode.
What these numbers do tell us, specifically, is that a compelling majority of members now use web browsers that are capable of a much higher quality of interaction, in a way that’s nicely standardized and easier to support. It would be foolish to spend the majority of development effort fixated on the foibles of the lowest common denominator, given that the end result would lead to a negative experience for the broad majority. It’s important to this experiment that the experience be a positive one for as many members as possible.
With that said, it would be inappropriate to draw a line in the sand and decree that members who use six-year-old browsers on eight-year-old machines to access the ten-year-old Web have no vote in a 25-year-old organization. They may not be able to access much of their favorite content on the Internet anymore, as each site around the world evolves with demand, but as we’ve discussed there’s something unique about elections. Every member deserves a vote, and this year it’s especially important that a member have every chance to express a vote against the Internet and integrated Pi services online.
Modern web browsers receive the full treatment in the Interactive mode.
Viewing those statistics, it became clear to me that our voting site should be constructed in two parallel implementations, showing identical information in a slightly different way. Members with modern software should be presented with an “Interactive” mode, which makes voting as simple, failsafe, and pleasurable as possible. While members on limited or known bug-ridden platforms should have available an alternative, catch-all “Universal” mode doing its job with no special bells and whistles.
Of course, the Election Committee would also need to decide what if anything to do about traditional paper ballots. But my charge was to assume there would be no such thing, and to do my best to make them unnecessary. A paper ballot is a tool for members who don’t use the Internet, not a crutch for programmers who do.
I gave a lot of thought to the design and implementation, struggling to satisfy all sides of the Pi’s own political climate and thus avoid a potentially devisive situation. Coincidentally, the national press began ramping up attention to the heightening controversies of electronic voting in California, Florida and Maryland, and toward the upcoming 2004 presidential election.
I vote in a Fairfax County, VA, school auditorium following a two-step process. First I line up at a front desk, where someone checks my identification and places a mark next to my name on a list of registered voters. Then I’m ushered to the next available booth where I make my selections, review them, and lock in my vote. This double-blind separation between the registration desk and the voting booth helps ensure that my vote is counted anonymously and equally. More elaborate schemes could provide further assurances, but their complexity might increase the chance of error and eventually reduce voter turnout.
Using this real world procedure as a model, I designed our site to show a three-step process and to walk the user through each one. Step One, “Identify” asks for a name and password and determines eligibility. Step Two, “Select” presents a list of candidates and write-in fields to choose. Step Three, “Confirm” shows exactly how the system interpreted that input, for review. It’s easy to back out of the process or to simply walk away and return at any time. But upon pressing Confirm, your attendance is recorded in one table and your ballot in the other. Your “I voted!” sticker appears only on screen, so its effect on suede is temporary: the reverse image effectively disappears given sufficient lighting.
The web site is implemented in the PHP programming language. It follows respected software design practice of separating behavior from appearance: the data is collected and processed independently of the page content and design. Object-oriented programming techniques allow the pages to be constructed differently in each mode, while their exact written content remains common to both. As a user first enters the site with a particular web browser, the software senses which mode is appropriate to display. If it can’t reliably guess from the circumstances then it presents a menu. The user can override the recommendation and switch modes if necessary, but I don’t imagine anyone would.
The MySQL database schema consists of two tables: one for attendance, the other for ballots. The two are unrelated; you can’t match an individual member to her ballot or vice-versa. You can, however, tell exactly when a given member voted and using which account name. That’s important for when two separate family members attempt to vote, and the second needs to be told he’s become ineligible.
Voters received a special “I Voted π” sticker after completing online voting.
Come the middle of April 2004 I could no longer hide behind fun and football. I presented the site to the Election Committee and the Board of Directors, including fake data for a mock election. They had many good suggestions and identified a couple unanticipated compatibility issues, greatly improving the site. Then we put it up for a second week, in public with different data and a new mock election. This time the test was more of my deployment technique than of the code. Here again there were many good suggestions, and the site benefits from those earliest and lowest-risk ones such as wording improvements.
It’s worth noting that both mock elections were, as announced, being closely observed. I was talking to the server all the time, measuring its reactions to things, and watching results come in. Helpers were encouraged to vote multiple times, through a loophole that was opened until halfway through the public test. This helped our few testers explore a large variety of browsers and scenarios, before finally testing for certain that one member only gets one vote. In the end, I became very confident in the accuracy of the server and in its fairness to a variety of user actions.
I do have the results from both races, by the way, in case anyone wants to know if Mojo Jojo made the cut for rookie Powerpuff Girl, or who beat out Ms. Krabappel for Springfield Board of Education: Apu or Moe. Ask me on the Open Forum board of the TCS, at http://tcs.wap.org/topics?b=talk.
May Day approached. The official election ran from midnight May 1 to midnight June 1, and during that time the machine was entirely out of my clutches. It takes a leap of faith to know that the server is doing its job, since I couldn’t talk to it until June. If Apple released an emergency security update that affects it, we’d be out of luck.
The server was a standalone Bondi-colored iMac, donated to the Pi’s reclamation program and set aside for this temporary assignment. Its name was Chad, and its only job was to host this site and collect ballots. It performed no other tasks, hosted no other services, and only interacted briefly with its neighboring machines in order to check passwords.
Digitally, Chad sat behind a hardware firewall and offered no services other than Personal Web Sharing. Specifically, upon completion of testing, Remote Login (SSH) services were disabled. I couldn’t get its attention if I wanted to, or in an emergency.
Physically, because it was a revision B iMac, it had a hinged side panel that covers all the access ports. Only power and Ethernet were connected—no keyboard or mouse. The access door was completely covered by a tamper-evident reflective sticker bearing several witnesses’ signatures. Come June 1, the Election Committee and I would examine the machine, open it up and analyze its contents together.
I found myself feeling silly on several occasions, especially early into this process, having to explain why I was being so meticulous about setting up one simple web site. After all, I build and deploy more complicated things all the time, and this was taking my attention away from some other things people want me to do. Surely this was overkill.
Votes rolled in throughout May, especially in response to e-mail announcements from the Pi.
But I was exonerated in the last few days before the voting booth “went live”—as well as across several days thereafter. At that point other people began thinking it through, snapping to attention, and asking probing questions about my anticipation of specific edge cases. These weren’t only the usual curmudgeons and naysayers I’d been anticipating from the beginning, but also friends who had been ribbing me earlier for taking the task so seriously.
By that time, of course, my hands were tied: the software was complete and hardened through a formal (for us) quality assurance process. I had locked myself out and the rest was on autopilot, armed only with the unflatteringly paranoid, detail-minded prep work which I’ve done my best to outline above.
As you’ve read elsewhere in this issue, the Pi’s 2004 election is complete. Participation was up: we passed our quorum requirement within seven days. By halfway through the month we’d matched the entire number of ballots cast in 2003. Three e-mail reminders via the Pi Announcements mailing list each prompted a strong wave of returns.
The debate between clicks vs. stamps will continue, but thanks to your refreshingly positive response to this experiment the organization remains intact, with a full roster of seats filled for the upcoming year. Congratulations, Washington Apple Pi!
Jon Thomason, a professional computer programmer, has been involved in Pi telecommunications since he was a teenager. Jon's writings appear regularly on the Washington Apple Pi TCS, http://tcs.wap.org/.