Wolfson Ball Ticketing System   Leave a comment

Wolfson Ball 2011 TicketLavish, college-sponsored balls make up an age-old component of the Oxford social tradition. The oldest, richest colleges take it in turns to hold the Commemoration ball each summer. Many others hold their smaller events in the spring, showing off their grounds in Oxford’s most seasonable weather. Wolfson takes a bit of a different approach, and throws an annual Winter ball. This avoids competition with other colleges’ events, and livens up the social scene during what can otherwise be a dull spot on the calendar.

One perennial challenge of these balls is a ticketing system. Because tickets are relatively expensive, and food and drink inside the event are included, ball organizers face a challenge preventing people trying to “crash” the ball. This has lead to a bit of a cat-and-mouse game between ball organizers and those who would rather not pay. After simple tickets were forged, intricate wristbands were distributed in advance. As material science students began to duplicate those, individually numbered tickets were given out in before the event and traded for wristbands on the night, with the tickets marked on a master list with each exchange. While this method proved effective, it was frustrating for the hundreds of ballgoers in the queue waiting for one master list to be consulted for every entry.

For Wolfson’s 2011 ball, I was asked to create a unified ticketing system that would allow ticket purchase and tracking as well as a parallelizable entry system on the night. I was able to come up with an online sales system that integrated with Google Spreadsheets for easy manual modifications. An integrated ticketing system allowed any worker at the door to turn their phone into an effective ticket scanner.

Ticket Sales System

Ball Registration SpreadsheetThe ticket sales system was a one-trick pony. As payment was delivered in person (cash or check) and the prices were tallied up using a typical JavaScript frontend, the beauty of the system was really its ability to interface with Google Spreadsheets via the Zend Framework. Using the online shareable spreadsheet as the master record of tickets has several advantages. Sales can be tracked in real-time by non-technical users. Automatically updating graphs can be embedded on an admin website, and additional “sheets” can be added to the database to distill pertinent information — payment records, dining requirements, etc. for each member of the committee. Manual changes can be made so long as care is paid to maintain the proper spreadsheet columns. In effect, choosing Google Spreadsheets rather than a formal database solution like MySQL opens a number of user-friendly avenues to the data, and the risk (of a user manually making the database incompatible with the website via direct access) was worth that reward for our small group.

The ticket itself was generated using a quick bash script that called ImageMagick to add the QR code and relevant text to a blank ticket. Two tickets were produced and e-mailed: one optimized for printing and the other optimized for displaying on a smartphone. The QR code links to t.php, described in the Ticket Scanning section below.

As ticket sales went forward, automatically generated graphs from the spreadsheet allowed us to keep tabs on our numbers. Automatically generated sales figures and student identification also helped us reclaim £2,000 in VAT without going through each record by hand.

Ticket Sales by Date   Ticket Sales by Email

Ticket Scanning at the Door

The interesting bit, while relatively quick, is done in t.php. Each ticket is printed with a QR code that links to the t.php URL passing the ticket number as a GET argument. t.php then redirects all incoming traffic to the main ball website, so anybody scanning their own ticket will be sent there. Before redirecting, however, it checks for an authentication cookie. If that cookie is set appropriately, t.php lists the names associated with a ticket and allows the doormen to check off any people who are being issued a wrist band. This immediately updates the shared Google Spreadsheet, so the doormen will easily see if some portion of a party has already been admitted.

By scanning static QR codes linking to quick php scripts that would set and clear the authentication cookie, doormen could be added and removed dynamically during the opening period as demand required. No special equipment was needed beyond a QR-capable smartphone.

The second half of the doorman code, band.php is called by a form submit by t.php. This script just updates the Google Spreadsheet record to indicate that the given attendee has been given a wristband.

The system worked quite well on the night, and the following year’s ball committee used a very similar setup!

Posted 4 Dec 2011 by John McManigle in Technical

Leave a Reply

Your email address will not be published. Required fields are marked *