Jacob T. Bigham

Background

Long story short: Campus JAX is a venue I love, and I was blown away by how inefficient their website and ticketing system was. Staff were spending several unnecessary hours per week answering questions on the phone, making manual changes to events, writing out name cards for tables, and assigning customers to seats. Everything was by hand, and the website itself was divorced from the actual ticketing, which meant that any time they wanted to update an event, they had to do so in two places. And, because they were using a third-party ticketing system, there was zero leeway for customization or extension.

I knew I could build a unified system that would create a better experience for customers and staff, and I also knew I could generate a steady passive income stream from ticket service fees. So, I asked the owners if I could breathe new life into the site and revamp JAX's ticketing. They said yes, and a great project was born!

Table Assignments

I first set out to develop a backend system for allowing staff to assign customers to tables more transparently and efficiently. I created a prototype and worked closely with the manager at JAX to validate exactly what features they would need in a final product.

We then developed an algorithm for automatically assigning customers to seats, which has reduced what used to take a half hour every night to microseconds. Once tables are assigned, my system automatically generates a seating map, check-in list, and table name cards for our staff to use.

Overall, staff are spending about ten hours less per week managing table assignments—and, should the venue decide to allow customers to choose their own seats in the future, I have already built in that functionality.

The Back End

I decided to build the system on Django because—unlike, for example, Flask—it has great facility for viewing and editing your data, and it is critical for staff to at any time be able to see current events, sales, customers, and remaining tickets.

In general, an event is linked to a group of event seating configurations, which contain seating options, ticket allocation, and prices. An event is also commensurately tied to a seating chart, an optional banner ("Sold Out", "Limited Seats Remaining", etc.), and any purchase items for seats at that event.

The system manages ticket inventory, automatically adjusting based on sales and preset minimum and maximum allocations per section. Should the venue wish to switch to a demand-based pricing model in the future, I have already built in that capability.

Whereas the staff used to have to micromanage available tables to make sure there was space to accommodate customers, the system now automatically factors space and seat availability into which tickets it displays to customers, saving staff yet more time and energy.

The Front End

More than anything, I wanted to remove as many frictions to purchasing tickets as possible. Any design choice that gets in the way of finding an event, adding to your cart, and ultimately checking out is probably not useful.

At every turn in the redesign, my north star was to make buying tickets the most clear, obvious, and simple for customers. Of course, I have found that what I thought would be best was not always best, and I continue to alter the experience based on customer and staff feedback.

For instance, I originally chose to first display to customers only the most expensive ticket option alongside a button that would reveal all other options. To me, and to the owners, this made sense as an opportunity to nudge customers toward premium ticket options. We found that this format at best was not leading to greater sales of premium options and at worst was leading to confusion and potential mistrust. I know better than to think I know better about our customers than they do, and so now we display all available options together!

The Problems

Did someone say collectstatic? Django has its quirks, and integrating my system with Heroku, Stripe, AWS, and existing DNS records has proved, at times, tremendously challenging. I undertook this project as a solo venture, and it marks the first time that I have built such a large system—much less one effectively from scratch. For the first month after I released the new system, I felt like I was on-call, and I spent more hours debugging than I'd care to admit. This is a site that makes over $500,000 in sales each year, and there's been no shortage of pressure!

The Little Things

I care a lot about the little details, and they continue to evolve as I learn more about our customers' behaviors. For example, what size and color should our purchase buttons be? Should we round fees to the nearest quarter? I am A/B testing where appropriate and getting direct customer feedback (and observing how they use the site) as often as I can.

And that attention to detail expands beyond the site itself. I've created new, dynamic email templates for our marketing staff to use, and I automatically generate social-media-ready images that get shared along with event links—that way our artists' names don't get cut off when they share on Facebook and beyond.

It's all a learning process, and I'm continuing to make the system better every day: from the most obvious of features down to the ones you don't even know are there!

Background

When I started my internship at Amazon, I spent the first two or three weeks getting up to speed with React (and TypeScript) and familiarizing myself with my project's codebase. Learning React for me was like when my algebra 2 teacher showed us that a TI-84 could invert a matrix: I was immediately relieved that I didn't have to do it by hand anymore, and I lamented the time I spent doing it by hand when, all the while, a simpler solution existed.

Before I went to Amazon, I interned at QSC, where I worked on a pretty complex UI that depended on hundreds of states of the application and of the devices that the application controlled. The whole app was polling-based and built in JavaScript with no type checking. Needless to say, it was a rough time, and we had to manage every state change manually, with no help from the compiler. I did my best to create structures that forced clearer code: we had, for example, classes with constructors with over 10 arguments, none of which were named, so I introduced argument dictionaries and a test suite that verified the correct arguments were used. What I really wanted was a centralized way to manage state changes and then cascade those changes down to small components, which could themselves decide how to render based on current state. We'd done our best, but there's only so much you can do in JavaScript with a small team.

So, React was a dream come true. I wanted as much practice as I could get, and I had wanted to redesign QSC's TouchMix application for some time, so I decided to take a stab at building its interface with React. (Importantly, I had no access to and never had access to any source code for QSC's TouchMix application.)

The Features

Really, I think the application speaks for itself and is fun to play with (it was definitely fun to debug, and there's still much to learn). The version of the application I have released on my website keeps track of 20 inputs, 10 outputs, and all the processing settings in between.

I added in channel presets and a modern interface for DCAs, mute groups, and phantom power. I also included fully-editable effects settings with knobs and controls that emulate those on the real mixer, and I added a custom interface for viewing effects send levels. The app also features an extremely simple interface for naming channels and a fully interactive EQ canvas (pro tip: I discovered that inverse tangent is a good stand-in for shelving filters).

To the lay person—or perhaps even to the audio engineer who isn't familiar with TouchMix—this means very little. But to me, someone who uses the actual application almost daily, it was really exciting to explore how the application could have been designed more intuitively and to facilitate some of the most common tasks.

I had originally intended to release this app as an open-source editor that anyone could use to load and edit their mixer scenes. For legal reasons, that will not happen—but I am really happy with how much I learned about building a React application, and that's enough for me!