Building a Conference Website and Giving It All Away: How It Was Done at DrupalCampLA 2009

The Drupal community is alive with meetups, user groups, and camps. However, there isn't a published formula on using Drupal to accomplish the needs of a large meetup, camp, or convention. This By Them worked with LA Drupal organizers to design and develop what we hope will be a useful camp formula for others, available for download under the GPL.

DrupalCampLA.com was built on Drupal 6 using core & contributed modules to handle event registration, sponsorship management, featured speakers, user bio's, and session proposals. The website features an attendee driven event schedule where members propose sessions and only registered members pick which sessions they'd like to see (in the BarCamp style). Planning the schedule for the day of events has been made flexible enough to allow organizers to maintain a master schedule with ease. Not to mention that all attendees get their own schedule view with the sessions they pick.

Website: http://2009.DrupalCampLA.comProject Time Line: 2.5 weeksDesign and Development: This By ThemLA Drupal Event Organizers: Chris Charlton, Christefano, Mike Stewart, Nicole Bluto, Rain Breaw

Introduction

This By Them (TxT) is a boutique Drupal design and development shop located in Orange County, CA, just south of Los Angeles. TxT team is active in both the local and global Drupal community and is responsible for a variety of contributed Drupal modules, including the Services Module, Search Ranking Module, Fuzzy Search Module, and the Ubercart Coupon Module. Based in the desire to contribute to the local Drupal community and upon learning of plans for the third annual DrupalCampLA, TxT emailed the organizers of the LA Drupal users group and proposed to design, build, and ultimately host the web site to support the event. Mike Stewart, one of the LA Drupal organizers, skeptical of such an amazing offer replied with a wish-list of features, including features to remove many of the scheduling hurdles that are common pitfalls for organizers, as well as attendees, of these events. TxT accepted the challenge! Mike, Blake, and John Romine met the next week at the OC/PHP meetup (organizers of Orange County Drupal meetups) to work out some of the details.

Motivations & Goals For the Event

Attendance should be free to cheap.
Encourage new people from outside of the Drupal community to participate and learn.
Self-organizing.
Transparent and open planning process.
Attendee driven schedule (BarCamp-style).
Interactive & Fun.
Provide valuable sessions and networking opportunities.
Provide value to sponsors by connecting them members within and outside the community. The organizers feel it behooves the community as a whole, and attendees in particular, to be aware of the companies that are enabling a valuable and free learning & networking event. Especially when considering our current economy.
Encourage a strong Drupalchix participation.

Site Requirements

Encourage easy and (mostly) self-organization of lots of people and easy interaction to help maintain a small event feel.
Help spread best practices by utilizing modules that are configurable to varying requirements, and use techniques that are easy to extend.
Address perceived shortcomings of similar event sites (primarily scheduling: both master schedule & personalization).
Release the code under GPL and make it available to others to build on.
Highlight the sponsors & people that helped make the event a reality.

Original goals included: the ability to highlight session presenters, emphasize a Drupalchix track, highlight sponsors, the people that help make this possible! Plus, detailed scheduling needs.

The importance of improving our ad-hoc scheduling became apparent after LA Drupal organized DrupalCampLA 2008, with over 450 registered attendees at the LA Convention center. The 2008 camp was successful, but scheduling was tedious and manually intensive. The goal for 2009 was to attempt to recapture the intimacy of DrupalCampLA 2007; where scheduling took place on the wall of a hallway with a bunch of post-its and people raised their hands to indicate what session they were interested in attending. To that end, we defined requirements to capture useful information we could act on, reduce the complexity of scheduling, and enable attendees to drive the feel of the camp. Here is a list of the goals:

Help users to openly drive the session selection process, reminiscent of smaller BarCamp meetups; even if the event is much larger.
Help organizers understand which sessions will be attended allowing them to utilize the capacity of the venue
Provide a master event schedule with multiple tracks available on the site
Provide personalized scheduling viewable as a user logged into the site, or via a personalized iCalendar feed. The lack of this feature at other conferences is a personal peeve of Mike's. Apparently too many missed sessions at other conferences due to schedule changes and difficulty keeping the schedule up to date in a calendar. Seriously, what's the point of walking around with a wireless device that can sync with an iCal feed if the technology is not being taken advantage of?
Combined, these features allow organizers to easily make schedule changes during the event itself, all while keeping attendees informed of the changes to their picked sessions.
These features also imply a certain self-organizing aspect that help make the camp more manageable and hopefully help the attendees to feel more in control of what the camp will be.

Process

During any site build process we generally try to stick to the following process because it allows us to communicate expectations and explore possibilities visually before a bulk of the work is done. This is important when time line and budget are a major factor... because when are they not?

Planning

Site planning includes gathering site requirements by determining what is the purpose of the website, who are the users of the website, who are the administrators of the website, etc. In addition we find that it is also helpful to do some background research on the methods that may be needed to deliver on the requirements. This would include setting up a basic Drupal installation with a few modules and putting together a proof of concept.

After the basic planning discussion has happened we like to put together a wire frame description document. It lists of each the pages of the site along with each of the major features and calls to action that we'd like on those pages. This document is done using text and usually goes through a few revisions as each of the stake holders reviews and visualizes the site in their own minds. Below is a sample of the wireframe descriptions we put together for this project:

First you'll note that some of the items didn't make it to the end site result. They were removed during the wireframe and design phase for streamlining the user interface. Download the entire document here.

Creating the Wireframe

The goal of wireframing is to deliver a low resolution site map where each page of the site has the blocks of content with the visual cues and calls to action present. Download the complete wireframes here.

Design Compositions

Based on the wireframes a design composition is usually created for the homepage and any number of the internal pages. For this particular project we did one comp for the homepage and one comp for an internal content page. This was mainly due to the size of the site (relatively small), and the project time line (roughly 2.5 weeks). [provide link to both comps, phase 1 and 2]

Revision 1

Revision 2

Site Building and Functionality

The site building phase is usually done in tandem with the design composition phase. However, its usually only possible to do this when you have wireframes that really outline the features and functionality of each of the pages of the site.

Theming

After both the design compositions and the site building is done, you can begin theming the site. On most sites you will still perform some of the site building during the theming phase but we generally recommend at the very least building all of the blocks of content that will be used throughout the site and then placing them to match the wire frame. We find that this really helps speed up the theming process because you are only focused on styling the pages using css.

Solution

The web site was based on the latest Drupal 6.x release and utilized many of the current generation modules such as CCK for content customization, imagefield and imagecache to handle imaging Views & custom theming built on Zen for content presentation. (A full list of the modules used to build the site is listed below)

Attendees and Registration

Site registration is open to anyone, but requires email verification.
When users register for the site user details are handled by the Profile module.
The User module settings allowed us to customize the content of the email that is sent to new users.
The SMTP Module is utilized to keep email traffic off the webserver and to enable easy integration with Google Apps as an email server.

Sessions

Session Proposals nodes were created by CCK to provide the following additional fields: Day (text select), Time (text select), Track/Room (text select). In addition we created a new taxonomy vocabulary called "Categories" so that sessions could be organized into the following: Business Side, Code & Development, Design & Usability, Drupalchix, Performance & Scalability, Showcase & Strategy, Site Building. Using taxonomy to categorize the sessions was very helpful because of the benefits of Views module integration. Using the categories we allow visitors to filter out sessions based on their interests.

You may ask how were we able to put the day/time/room as CCK fields if were allowing anyone to create sessions? The answer was by enabling the content permissions field. This allowed us to provide general camp members with the ability to add and edit their own sessions, while only administrators had access to set logistical information about the session.

In order to gather user interest we used the Flag module. We created a new flag type called vote and allowed only registered site attendees to then flag or "Pick" their favorite sessions. Using the Flag module we were easily able to create Views of the sessions that had been flagged the most which allowed us to then choose which ones we ultimately wanted to have on the schedule. The other benefit to this is that we can provide each attendee with their own list of sessions that they are interested in. Where this really helps is when scheduling conflicts happen and sessions times/locations are changed, the view makes it easier for the attendee to see the sessions that are important to them.

Sponsorships

We built a node for each of our sponsors using CCK type called sponsors. The fields of the sponsor node type include: Logo (image), Website (link), and Attendees (user reference). In addition we used the Taxonomy module once again to separate our sponsors into "Sponsorship Levels." You'll notice on the sponsors page, its simply a view where we included the taxonomy term field. Then we set the view style to "Unformatted" and choosing to Group By the Taxonomy Term. This gave us a nice little header above each group of sponsors that we could then easily style. Another benefit to using taxonomy was the ability to easily select only platinum and gold sponsor logos to be shown on the footer throughout the site and platinum sponsor logos on the homepage.

Once the node was created by an administrator they assigned the node ownership to the sponsor's user account. The benefit to this was that the sponsor could easily adjust their own company description and logo at any time. In addition we thought it might be cool to show which people at the camp were from that sponsor's company, so we added the user reference field. And again we overrode the theme function that outputs the generic user reference field content and extended it to show that users profile picture. You'll notice we also make sure to grab the default profile picture in case someone doesn't have one uploaded, and then we pass it through imagecache to crop the image.

/** * Theme function for 'default' userreference field formatter. */ function txt_drupalcamp_userreference_formatter_default($element) {   $output = '';   $default = variable_get('user_picture_default', '');   if (isset($element['#item']['uid']) && $account = user_load(array('uid' => $element['#item']['uid']))) {     $filepath = $account->picture ? $account->picture : $default;     $output = l(theme('imagecache', 'mini', $filepath, $account->profile_fullname, $account->profile_fullname), 'user/'. $account->uid, array('html' => TRUE));     $output .= ''. theme('username', $account) .'';   }   return $output; }
Homepage

The homepage was put together using the Panels module. We often use it for landing pages because it provides us with the ability to easily place (and replace) related content in different regions of the page.

Contributed Module List

Admin Role - Automatically assign all permissions to an admin role.
Administration menu - Provides a dropdown menu to most administrative tasks and other common destinations (to users with the proper permissions).
Content - Allows administrators to define new content types.
Content Permissions - Set field-level permissions for CCK fields.
Embedded Media Field - Provides an engine for modules to integrate various 3rd party content providers, such as Video Neighborhood, Image Neighborhood, and Audio Neighborhood.
Embedded Video Field - Defines a field type for displaying third party videos, such as YouTube and Google Video.
Fieldgroup - Create display groups for CCK fields.
FileField - Defines a file field type.
ImageField - Defines an image field type.
Link - Defines simple link field types.
Node Reference - Defines a field type for referencing one node from another.
Number - Defines numeric field types.
Option Widgets - Defines selection, check box and radio button widgets for text and numeric fields.
Text - Defines simple text field types.
User Reference - Defines a field type for referencing a user from a node.
Context - Provide modules with a cache that lasts for a single page request.
Context Contrib - Provides integration with Context on behalf of the following contrib modules: Nodequeue, Views, CSS Injector.
Context UI - Provides a simple UI for settings up a site structure using Context.
Date - Defines CCK date/time fields and widgets.
Date API - A Date API that can be used by other modules.
Date Popup - Enables jquery popup calendars and time entry widgets for selecting dates and times.
Date Timezone - Needed when using Date API. Overrides site and user timezone handling to set timezone names instead of offsets.
Flag - Create customized flags that users can set on content.
Flag actions - Execute actions on Flag events.
ImageAPI - ImageAPI supporting multiple toolkits.
ImageAPI GD2 - Uses PHP's built-in GD2 image processing support.
ImageAPI ImageMagick - Command Line ImageMagick support.
ImageCache - Dynamic image manipulator and cache.
ImageCache UI - ImageCache User Interface.
SMTP Authentication Support - Allows the sending of site e-mail through an SMTP server of your choice.
Nodequeue - Create queues which can contain nodes in arbitrary order
Backup and Migrate - Backup or migrate the Drupal Database quickly and without unnecessary data.
Better Select - Use stylized checkboxes instead of the default multiple select HTML element in forms.
Diff - Show difference between node revisions.
DrupalCamp - Customizations for DrupalCamp website
Path Filter - Input filter to convert internal paths, such as "internal:node/99", to their corresponding absolute URL or relative path.
Pathauto - Provides a mechanism for modules to automatically generate aliases for the content they manage.
Textile - Allows content to be submitted using Textile, a simple, plain text syntax that is filtered into valid XHTML.
Thickbox - Enables Thickbox, a jQuery plugin.
Token - Provides a shared API for replacement of textual placeholders with actual data.
Twitter - Adds integration with the Twitter microblogging service.
Twitter actions - Exposes Drupal actions to send Twitter messages.
Panel pages - Create pages that are divided into areas of the page.
Panels - Core Panels display functions; provides no external UI, at least one other module (such as Panel pages) should be enabled.
Google Analytics - Adds Google Analytics javascript tracking code to all your site's pages.
Promo - System for creating callout blocks with uploaded images.
External Links - Adds icon next to external links on the site.
jQuery Update - Updates Drupal to use the latest version of jQuery.
Views - Create customized lists and queries from your database.
Views Bulk Operations - Exposes new Views style 'Bulk Operations' for selecting multiple nodes and applying operations on them.
Views UI - Administrative interface to views. Without this module, you cannot create or edit your views.

Server Architecture & Tweaks

Code hosted on GitHub because that's what the developers prefer when they have the option.
Capistrano is used for deploying the code to the development server. While this technology is mainly used by Ruby on Rails developers, This by Them uses it as a means to easily deploy their PHP code. Our deploy script performed the following:

Check out latest revision from Git
Update the public directory to the last downloaded release
Create a symbolic link back to the file uploads directory
Reset some file permissions
Restart PHP (xcache doesn't like it when you deploy on a different physical path and so restarting php helps keep it fresh)
In addition there are a few helper commands to sync files between your local environment and the dev server, as well as a dbsync script to pull down and update your local database with a fresh copy from the dev server.

Hosted by Slicehost, This by Them prefers Slicehost as their hosting provider because of their low cost of entry for virtual private servers (slices). Their control panel allows us to get new server instances up and running in a matter of minutes. And did we mention their prices are really reasonable?
Nginx/PHP setup, We prefer to run our setup on Nginx with PHP as a fastcgi process instead of Apache with mod_php, to each their own. Here you'll find some help on setting up php with nginx.
AutoMySQLBackup script.
Amazon s3sync script that we run after our database backups are completed. Also helpful in setting it up was this blog entry.

Acknowledgments

We'd like to also note that we referenced the following existing camp/conference related websites to help us in our planning and execution:

Download Distribution

As mentioned above, all you will need to get your own camp/conference site setup is included in this friendly package*. Included is a readme file that will explain how to setup the site. It's basically the same as setting up a normal Drupal site except you'll want to import the database file we've included so that all of our views/content types/settings are ready to go!

We have decided NOT to release the graphics from our theme for various reasons, but primarily because we wanted to make sure the brand/image/appearance of our camp site remains unique. However, all our customized theme templates and javascript have been included in a basic zen sub theme called camp. We recommend using the camp theme as your base and adding styles as you see fit.

* The site code and data are provided as is, with no warranty and no guarantee of support. The code is released under the GPL license (same as Drupal core).

Drupal version: Drupal 6.x

Original Article:

Building a Conference Website and Giving It All Away: How It Was Done at DrupalCampLA 2009