Firefly Festival – Website Redesign

Firefly Music Festival is the East Coast’s premier music festival. It brings together over 60k fans and millions in dollars of revenue.

I worked with multiple departments within Red Frog Events to plan, design, build, launch, and actively manage the Firefly website to maximize Ecommerce revenue and deliver the best fan experience possible online.

The WordPress site I built has over 50 custom pages, is viewed by over 1m unique visitors, and includes a custom built user survey platform with over 50k active users.

I personally developed the data structure and page hierarchy for the site to ensure the best possible user experience and navigation flow.

More importantly, I imposed and enforces a strict ban on homepage slider heros – forcing the team to come up with unique and purposeful static hero content.

Firefly has seen happier customers, an easier content management flow, and better user data than ever before.


Firefly Music Festival – Survey Platform

Like any product or business, getting customer feedback is critical to ensure your solving their needs.

Firefly Music Festival took that effort one step farther by announcing that their 2017 festival would be fan-curated.

Fans would get to cast votes for festival artists, submit poster designs, and even select the name of a Taco truck.

Behind the scenes, the Firefly team wanted to collect demographic information and ensure that no one tried to game the system, all while providing multiple types of surveys across 6 categories each with their own start and end dates.

Survey types included:

  • Text Submission
  • Multiple Field Submission
  • Multiple Choice
  • Image Select
  • Rank the Following Random Selection
  • Upload File
  • Combinations of the above

Some would allow unlimited votes, while others could have a limited number of votes per day.

The complexity of this system did not lend itself to any available 3rd party solution, so I had to build the platform from scratch.

The Core Build

Since this was the first year Firefly was presenting itself as fan-curated, it didn’t make sense to invest in the platform’s full capabilities. There was always a distinct possibility of scrapping the concept for the next year, so I opted to keep the platform lean.

This meant limiting administration and management functionality severely and keeping the platform as a developer solution. The Firefly brand team would plan and organize the content and direction of each survey and I would work to build each of them out as needed.

At its core, users would need to register and fill out base demographic info. In order to prevent spam voters and cheaters, users were ultimately required to confirm their accounts before proceeding through the platform.

When a user submitted a survey, each field of their entry would be added to a master answers table that listed the survey’s ID, the user’s ID, the type of question, the question’s title, the option number of the question (for multiple checkboxes and band ratings), and finally the value itself.

Additionally, a separate table kept track of the surveys a user had filled out in order to prevent users from voting too many times.

This core data structure would easily provide for managing every survey type.

The Survey Builds

Though most surveys were simple text submission or multiple choice and could be easily reproduced, some survey builds were complex and required creative planning in order to fit them into the existing system.

The following surveys broke the mode and required core changes.

Zoom Contest

In years past, Firefly had run a “hide-and-seek” contest called the Zoom Contest.

The contest began on the web page with a zoomed out map of a city. As users tweeted a certain hashtag, the map would zoom in further and further until it hovered above a local business. There, the first fans to find the Firefly representative would win VIP passes to Firefly.

So, I had to build out a system that would allow for back-to-back city contests, track and actively display Tweets, and zoom in randomly around the specific location (to prevent people pinpointing the location too early).

Though the contest did not track any user submissions, it still became a part of this fan-engagement platform.

Big Break Live

Every year, Firefly holds a contest for bands around the globe to submit themselves for selection in the Big Break contest. After internal rounds of vetting, fans can vote on a final selection of bands and one is ultimately chosen to come out to Firefly to perform. It’s an amazing chance for new artists to reach a huge audience.

In 2017, the Firefly brand team renamed Big Break to Big Break Global and created a local content called Big Break Live.

In this contest, only bands within 150 miles of Dover, De could submit their acts.

After vetting, bands would go through multiple rounds of voting – ultimately culminating in a live show for an audience and a panel of judges.

Both of these contests required submission management, multiple voting periods, different votes/day rules, and elimination rules. As the contests progressed, more and more details about the bands would be shown.

I created a separate database table for these bands and their data, opting to use json formatting for their submitted data as some bands would provide more or less detail.

I don’t like wasted database columns.

Talent Survey

Firefly relies heavily on fan feedback when it comes to booking bands and discovering new talent.

The yearly talent survey is sent to everyone and asks them to rate acts from 0-10 and a few other demographic questions.

Fans certainly wouldn’t vote on every one of the hundreds of bands out there, so the survey needed to show 40 random acts in order to ensure voting evened out for all bands.

On top of that, the team wanted to open up voting to as many people as possible so they asked for the survey to not require a login. So, depending on if you were logged in or not, demographic questions were added to the survey and a guest submission was saved. Though not originally built with the intent to save guest submissions, I outfitted the core to handle this process.

The result? Over 15,000 submissions in 2017 and a solid foundation for talent planning for 2018’s festival.

Band Name Generator

Somewhere along the way, the Firefly team had an idea for a viral marketing product that would allow fans to feel personally attached to the 2017 festival and provide wearability to their audience.

In similar fashion to the Wu Tang Clan Name Generator, I built a Firefly Band Name Generator.

In short, a user could enter their name a random band name would be provided – but not purely random. If they entered their name again, the same response would be spit out. Change a single letter and you would have a completely different name – almost like magic.

The magic uses two techniques and no database storage.

First, the team helped me compile two lists: one of adjectives and one of nouns. These would be used to create adjective-noun pairings for the final band name.

Then, the name provided would be broken down and passed through php’s srand() function – which alters the default random number generator. With the random generator altered to fit the name, we can pass through the list of adjectives and nouns and produce a pairing. Since the name always produces the same random number generator, the same pairing is always produced. Neat!

Now that we had a magic band name pairing, we could add the name to an image (not just on top of it) to produce a shareable image.

Just upload the image to Amazon S3, add the image URL to the open graph structure of the page, and Facebook will automatically pull the image when the URL is shared.

All In All

Over the 6 month period of building and launching the product, the platform added 35 different surveys, registered nearly 50,000 users, received 225,000 submitted surveys, and stored a total of 2.1 million individual answers in the database.

Now that’s big data.

Firefly Music Festival – Discover Artists

Year after year one of the big concerns the Firefly team sees mentioned by their audience is that they don’t recognize a lot of the smaller acts appearing at the festival.

It’s impossible to expect fans to know every artist, so I proposed a section of the site be created to showcase all the artists from the lineup.

A visitor would be able to easily click any artist name and a popup would show a YouTube clip of their biggest hit (or a SoundCloud playlist if available) and links to their social profiles.

At first, every popup would load content by default – after all, they had to retrieve each of these social links and embeds from their respective artist’s custom post. This, as you can imagine, caused significant and untenable load delays for the page.

So, using the WordPress API and AJAX, I crafted the artist popup to only request the artist data when a user had clicked on the artist name. This immediately resolved page load speed issues and the popup did not suffer for it.

Getting to know Firefly’s lineup got that much easier.

But then I took things one step further.

It’s tedious to click through over 100 bands to find ones you’d like.

What if you were able to select an existing band you loved on the lineup and related artists would be highlighted for you?

That way, you’d be able to listen to similar bands to the one you already liked – increasing your chance to enjoy new music at Firefly and the likelihood that you’d attend.

I pitched the talent team and built out Firefly’s Discover Artists page on the website. The Firefly team could easily select which artists were related to each other in the WP backend while visitors could view those similar artists as they were instantly highlighted on the lineup.

Coupled with the artist popup and a full page of curated playlists, exploring new music at Firefly is easier than ever.