Pulling the Strings on Puppet Lab’s Conference Site
August 22nd, 2013 by Gage Pacifera
We are currently in the midst of PuppetConf, Puppet Lab‘s big annual conference and tech party. I’ve been putting together the code for the site, all other credits go to the wonderful folks at Puppet Labs (design credits go to Peter Irby). Check it out here:
A Responsive Design
Having a site that looked and worked great on a range of devices from mobile to desktop was a priority. Peter did a nice job putting together a responsive design that worked well on all sizes of screens. I used the Foundation Framework to handle most of the responsiveness and it worked out great. Multi-column pages collapse down to single columns on mobile devices. Large images become smaller, more manageable images on mobile via CSS media queries. For more info on some of the technical details of the site, see this post.
Flexible Data Entry
The bulk of the data needs for the site focused on speakers and sessions. I put together a fairly intuitive interface for entering that data into the WordPress system. For speakers, an admin would add a new WordPress user, assign him the role of Speaker, and then start adding info like bio, title, company and photo. Sessions included several different types of category data (taxonomies for you WordPress experts out there) such as associated speakers, location, track (basically subject categorization), type (track session, party, etc.) and dates/times.
I put together a robust filtering system for this site. Sessions could be filtered by day, subject matter, location and more to tailor what sessions and speakers the user sees on the page. The filter bar was collapsable and “stuck” to the top of the screen once the user scrolled down past it. A user could click on multiple filters and easily clear all filters. All of this worked very quickly through client-side scripting.
But So Much Data…
I’ve used the Advanced Custom Fields plugin on a lot of projects and this is the first one I’ve worked on where I’ve hit a limit on what that plugin could handle. There was so much speaker and session metadata involved and the plugin was having to query the database so many times during a page load that the schedule and speakers pages were loading at a snail’s pace. Our quick fix to this problem was to set up a cacheing server in front of the WordPress site so that users were looking at a static cached version of the site.
As a longer-term fix, we ended up switching all of the data handling to sched.org. They have a great interface for data entry and a nice UI for the end users. Of particular interest to us was the mobile site that is automatically created based from the site data. This allows for super easy viewing on mobile devices, which was a big concern for the site. They also had a very handy data upload that allowed us to add data from existing spreadsheets. The big downside is that we had to use their look and feel rather than the nice comps that Peter had come up with.
A Lesson Learned
In hindsight, I can think of a few different ways I could have optimized the data handling to avoid the debilitating server-side processing. It was a good experience for me to run into this issue and a lesson that will stick with me when planning similar projects moving forward.