My friends and family are under attack in Ukraine. Donate to protect them directly or help international organizations.

Building a conference website

February 19th, 2010

Building a conference website as the conference was being organized is probably one of the biggest challenges I ever faced. It is also the project I'm the most proud of. I'd like to share that experience with you. By the way, the event is still in progress, so my work on the site is not done.

Throw away old code

The first decision was to throw away the old code base that dated back to the first PHP Quebec Conference in 2003. We decided to start from scratch with the Symfony framework and I was going to be in charge (yay!)

Priorities

The conference was moving on and I had to keep up with the programming. Developing the website was only part of my responsibilities as an organizer, which made things even more difficult time-wise. I had to prioritize and develop the strict minimum based on the immediate conference needs. There was very little time to test between deployments (I know, it's bad practice).

1. Logo and design

I was learning the framework while another member of the team, Yann Larrivée, was building the project skeleton. At the same time, we had an organizer, Mathieu Chartier, and his partner prepare the logo and the website design. Last year I was the one doing it and you could clearly see that I'm no designer and no expert in Web standards.

2. Call for papers

Besides a few static pages to present the event, the call for papers was the absolute first priority. Another member of the team had already put a project skeleton together, so I could dive right into the good stuff. Creation of user accounts, authentication, member dashboard and paper submission had to be put in place in record time.

Speakers could associate tags with their talks so that the organizers will be able to sort them out more easily. To put it in context, organizers were responsible each for his own track (php, python, java, ruby, etc.) and needed to know which talks fell under their responsibility.

The worst that could happen did happen. I was speaking at a conference in Paris during the last day of the call for speakers and the server crashed. Once fixed, we had to extend the call by three days because some people missed the deadline as a result of this extended site unavailability.

3. Talk selection

We needed a tool to sort through the 450 or so talk submissions. Thus came the admin section which was built by another member of the team, Sylvain Mathon, who had more experience with the framework. We put the talks in their corresponding tracks and spent a whole Saturday selecting the ~130 talks.

Since budget is a big consideration for a non for-profit organization, we built some tools on that same day to monitor, in real time, the estimated travel and lodging costs based on the selected speakers.

Then I also needed to implement the Session and Speaker sections. Considering the large number of presentations, I had to figure alternate ways to present all that info. I couldn't just put it all on one page as we did with PHP Quebec in the past, where we had 55 presentations at most.

4. Tickets

A conference is no good if people can't buy tickets to attend it. The next big priority was to implement a checkout process. So without time to catch my breath, I implemented a public shopping cart, then a mandatory login/registration, the billing information screen, the confirmation screen and a redirection to the payment screen. Also, I had to consider that ticket price varies over time (early bird, regular and at-the-door prices).

This was not the end. Since companies often purchase multiple tickets for their employees, we needed them to enter the attendees' names and associate those with user accounts. I made the account creation/association process transparent to the buyer. They simply needed to enter the name and e-mail of the attendees.

Then people need receipts. Also, many institutions can only pay by check and thus need an order form. And so another member implemented the PDF module for our site.

5. Monitoring tools

Now that we started to sell tickets, we needed to monitor it closely to know when and where to promote the event. For example, we sponsored another conference in Quebec City (CLLAP) and needed to know our ROI. Based on promotional codes and referrers, visitor locations and technologies, we knew how to approach the different communities.

Also, we needed to monitor the impact of the various communications by checking what tickets we sold on each day.

6. Flash sale

I still couldn't put the checkout process to rest. Now we decided to do a flash sale, that is, a special price that will only last a week. Luckily for me, the mechanism was already in place with the different pricing, so it was simply a question of adding one entry to the database with starting and ending dates.

7. Schedule

Selecting the talks is not enough. We needed to fit those in a timetable, and so assigned this task to our "schedule squad", consisting of four organizers to speed things up. They spent yet another Saturday on that and came back with a very nicely put together schedule.

On that day, I had to create an admin tool to put the ~130 talks in a timetable, a Schedule page for the visitors, and a neat way to access speaker bios and session abstracts. I made it right on time.

But the a surprise came! Some sessions were in two parts; something I did not plan for in my programming. Luckily, it wasn't very hard to implement and I could still present the schedule page for team approval on the next day. Once pushed to production, the server started to run slow and so some pages were cached, which saved tons of resources.

8. Training

In the beginning of January, we finalized the outlines for the PHP, Python and MySQL training. Now the website needed a Training sections, the possibility to purchase training tickets online, as well as a training+conference combos. The combos were much trickier, so I re-wrote a portion of the shopping cart and the way totals were calculated to allow special discounts. This proved useful for community and other specials later, so I'm glad I put that extra effort in it.

9. Buzz

I now got some people excited over a slick schedule builder that they saw on PyCon's site. So I spent a day or so on that one. Once done, appetites grew. I now had to allow people to save their schedule and optionally share it with the world. Another day went into that. I'm quite proud of the result though.

10. Joind.in

People started to nag on Twitter and via e-mail to have the ConFoo talks on joind.in. I don't blame them, as it's a tool that proved itself over the years. I contacted Chris Cornutt to see if I could help him to implement an API. I then learned via Derick Rethan's blog that he implemented one! That was indeed good news. So I sent an XML with the 132 talks over to Chris (no way was I going to enter these by hand) and he parsed it for me.

What's next?

I probably forgot some things in the 10 sections above, since I wrote so much code and specs just keep pouring in.

Next, I will write more admin tools to help me add talk abstracts and timetable to the printed conference program. I will also need the system to spit some XML to print the hundreds of badges, a system to allow at-the-door registrations, check if an attendee actually registered and mark them as present in the system when they come in the morning of the event, maybe even print badges on the fly…

I'm pretty satisfied with the result. There is still much work to be done, but this work will not have to be done over again next year. That will leave me more time for other conference matters.

Previous: PayPal DPRP in Sandbox Next: PHP 5.3 on OSX