Drupalcon is a traditionally biannual gathering of Drupalers to learn about, discuss and advance Drupal, and to network with other community members. The Drupal Association oversees the organization of Drupalcons, seeking proposals and judging their quality, location, team, etc; selecting a North American and a European location by tradition for spring and autumn.

Drupalcon Szeged 2008 was proposed by Kristof van Tomme, and I (Gábor Hojtsy) teamed up with him to help co-organize the conference. The dates were 2008, August 27th to 31st. Having two leads helped to distribute tasks, when one of us was down or had more to do in their personal or professional lives. Kristof was responsible for all local organization including negotiations with the venue; connection with our local partner C&T and being the top person for all things related to financing. I was the lead guy for the website, speaker connections and putting together the conference program.

It happened that I kept a close hand on the website and together with some volunteers produced what was deemed the best website for a Drupalcon to that date. The upcoming Drupalcon DC site looks way ahead of us in some respects (as it was expected), but I thought it would be good to share some details behind the Drupalcon Szeged website. (I presented this topic at a Drupalcon Szeged BoF - slides are available).

We won! Or, How did we set some goals?

We won the proposal, and we were determined to impress our attendees and the Drupal Association in almost every possible way. Szeged was a great choice: a nice small sunny city; and we decided to market this Drupalcon as "Drupaltown", meaning that everything was walking distance; throughout the conference, attendees could walk around town and stumble on other attendees, get a lunch together, drink a beer or just have a chat. Some people got to love the concept so much that later Drupalcon proposals we heard from also ride similar waves. The country is relatively cheap for foreigners which in part offsets the travel costs.

We knew some of our weaknesses however: Szeged is a relatively small city far away (from most of the world) in Hungary; it does not have airports; its hotels, motels and youth hostels are not universally equipped with English speaking staff, so we were about to come up with things to overcome these limitations. We proposed to host a hotel booking system where people can book hotel, motel and hostel rooms on our site and we also proposed to run a shuttle bus system, so people can jump into a shuttle bus which would get them from the airport in Budapest to their hotels in Szeged and vice versa. These decisions drove lots of our website building activities.

Choosing a Drupal version

It was shortly after Drupalcon Boston in late spring 2008 when the Drupal Association agreed on accepting our proposal, so we needed to choose a base Drupal version from what was available at that time. Since the Drupal 6 maintainer was the website team lead, it made a lot of sense to use Drupal 6. However, we needed to build out online shop, newsletter, complex profile and so on functionality in a relatively short time, and the Drupal 6 contributed modules were not ready for that yet. Therefore we ended up using Drupal 5 and CCK and Views extensively to build functionality rapidly.

The theme

We needed to start fast, and did not want to use either the drupal.org theme (Bluebeach) or some known contributed theme as-is even only at the start. We looked at previous Drupalcon sites, and with all due respect to the organizers, we thought it would not highlight our event if we'd use Bluebeach (used for Drupalcon Boston 2008) or Garland (the Drupal default theme, used for Drupalcon Barcelona 2007). Instead, we picked a simple and easy to tweak base theme, which was the Burnt theme in our case. While people generally suggest using the Zen theme or some other starter theme, we decided to go with a much more lightweight theme instead, which gave us the most freedom in how we structured our styles and pages. We kept the fixed width, got rid of the right sidebar, added a prominent background image and put up a row with menu items, and there it was the Drupalcon Szeged 2008 theme which looked unique. We did lots of smaller tweaks to the theme through the time as the Drupalcon got closer and even after it ended, but the general theme was ready in a weekend, so we could launch and announce the conference.

Basic functionality, the content staging problem

We have used lots of the out of the box goodness in Drupal including user registrations, forums, simple menu hierarchies for the FAQs and so on. Initially we started with having an independent Organic Groups based management site with email notifications and reply features, a directory of faces and phone numbers for volunteer organizers, etc. (This could be its own albeit smaller case study). We did build out content for the FAQ and similar pages there initially, and it helped boost the amount of valuable content on the live site, but eventually, we ended up doing later content changes live on the conference website, since it was not viable to do manual content staging for each change between the management site and the conference site, and we were not about to build out an automated staging workflow, it was just out of scope.

Logo contest

Our logo contest was the first real action on the website, aimed to drive more interest in the event. We did end up with a sizable amount of logo suggestions which was great. We used CCK to set up a custom content type here and employed imagefield to have a way to upload images in specified size and get it show up in nodes easily. It was useful to have a somewhat consistent listing of logo submissions with similar image sizes. (Listings were done with Views). We used votingapi and voteupdown for voting on logos, only making it possible to vote a plus.

Real simple photo galleries

One of our set goals was to market the location of the conference and Drupalcon as a cool concept overall, so we decided to set up galleries on (1) previous Drupal conferences (2) Szeged, the hosting city and (3) the venue. We hoped people will see that Drupalcon is fun and the location (city and venue) are outstanding. We did not anticipate more such tasks later with galleries though (actual conference photos made by attendees were uploaded and shared on services like Flickr and Picasa). So we basically generated very simple HTML page nodes and used jquery_update and lightbox2 modules to make it look attractive. This helped us carry a small footprint for this functionality.

Submitting session proposals and BoFs

Next up was getting people to submit their session proposals and BoF ideas. We really wanted to give kind of more equality to BoFs and sessions, since at previous Drupal conferences, we have seen that there is so much value in BoFs. So we decided to use the same CCK content type for both, and using taxonomy to designate them either a BoF or a session. We've also used taxonomy to let submitters assign topic areas, target audiences and preferred length to these. It worked quite well, since you could list all things for newbies for example, regardless of whether it was a BoF or session. It also helped to move BoFs to sessions or vice versa when the decisions by the session quality assurance committee dictated that. Using taxonomy also gave us feeds of these automatically, so one could watch program suggestions for newcomers as they showed up. If we were to use CCK fields for that it would not be as automated. Voting was also done with votingapi and voteupdown and we did do some custom theming for the views we built from this to for example have a checkmark at sessions you've already voted for.

The only downside of having the same content type for both was that when we asked for articles from session submitters, we did add fields for the articles on the session nodes. That made it simple for speakers to add in their articles, but made it confusing for BoF submitters, since they also see that field. Some BoF submitters did add articles, but those were not published (as we documented it in the description of the fieldset). We could have had some custom code to remove these fields when not needed but we unfortunately were too lazy to do that in time to prevent this problem.

Attendee quotes

We knew people were saying fun things about Drupalcon Szeged, and we decided to try and highlight them. We subscribed to a twitter search feed on Drupalcon, we lurked on IRC channels, picked text from blog post and emails, so generally we collected fun quotes manually. Our definition for a fun quote was however to be short and from a user on szeged2008.drupalcon.org.

We did use a very simple content type even without a body, which had its title field contain the quote and its author field to reference the user who said that fun note. That made it very simple to have nodes with the quotes, and then we just had a simple SQL query and some theming to put up the text and the self-uploaded photo of the user to the site. This construct had the consequence that we could not quote non-Drupalcon site users, but it was not our intention to quote Mark Twain for example, so it was not an issue at all at the end. What was fun about it is that we have people looking to get on their fun quotes to the site, so it drove some interest from the community in itself.

The conference registration system, payment

Previous Drupalcon events used a very simple model. They had one single fixed price for tickets, and that was the single thing you could buy on the website only with online payment. So they used the simple_paypal module, which handles this quite well. Our ambitions to help people out with Szeged / Hungary were however way above this, so we needed to build a complete commerce system here.

As said above, we decided to a run a shuttle bus system, where buses can get you from the Budapest airport to your hotel and back from the venue or your hotel to the airport. That was a fun option, since you could travel with Drupal people in your last 2 hours (yes, it took long) and you did not need to worry about trains, tickets, cabs and all. We did execute on this, and from what we heard, people loved the experience. What turned out was when we started to build out a seat booking system, the buses we ended up with eventually did not have much space for luggage, so we needed to have options for oversize luggage, where you had to pay more, since your bag would actually take up space from some other person who could have also fit in. In the end, nobody bought an oversize package ticket, but we figured we'd better offer the service anyway.

For the hotel rooms, we decided to prebook hundreds of hotel rooms and resell them on the same price as we booked them, so we needed a system to handle that. We had numerous locations with maps, pricing and service information, different number of spare beds in rooms, and so on, which made this a pretty complex requirement.

We also had "AfterCon" tour offerings as well as special sponsor T-shirts. These had simple pricing, so you could either buy one or not. We had kind of "unlimited" stock of these, so you could buy them freely.

Finally, we decided to try and get people to sign up early, so we made up an incremental pricing model, where each month, the price of a ticket would increase. It required timed products, which we only sold up until a specified time and then we moved over to the next item.

Now selling (1) shuttle tickets, (2) hotel rooms, (3) aftercon tours, (4) sponsor shirts and of course (5) conference tickets was much more complicated than any Drupalcon website before. We did not however have a considerably (or at all) bigger staff, so we decided to try and get people to do all their decisions at once and then be happy with that. So our requirements included to have a wizard like user interface where you'd be required to purchase or decline to purchase these items to eventually start to pay even. Also, we decided to support two payment systems: online payment and bank transfer.

So we were shopping for a commerce system which could handle this and make it work easily. It could very well be that lack of experience or a desire to understand every piece in its completeness resulted in us not going with one of the two established e-commerce solutions: E-commerce module or Ubercart. We did a proof of concept solution with Ubercart, but it did not fulfill our requirements, and a lack of deep understanding in its internals forecast problems in a fast implementation. So we came to an interesting alternative idea: use Signup module and then charge for signups. The signup and signup status modules were used to handle the possibility to sign up to the above items and maintain the payment status. The signup payment module provided the basis for our payment system, but was modified to require and support a transaction of signups instead of payment on single signups. We did use the simple paypal module though to handle verification of the online payments, and built a simple one-click solution for our correspondent at C&T to mark bank transfers fulfilled when they arrived on the account.

Each of the five products used different content types, and nodes were used to let people sign up to them. Tickets had an unlimited signup, but signup was closed after the time window for that pricing passed. Similarly bus ticket nodes, aftercon tours and sponsor shirts nodes were all open for signup all along. The most complicated was hotel rooms. They used a CCK type with fields for HTML code for a map, description of services, and so on. We had different content types for rooms depending on the number of extra beds they had. Single bed rooms, two bed rooms, etc had zero, one and so on number of user reference fields for assignment of people sleeping together. This information was important for the hotels to pass on, so they could know whom to expect. Each node had a one person signup limit, and we built some short node access code to actually hide taken rooms from the rest of the site. Only those who signed up for a room or were specified as roommates in a room could see the room; and only the one who signed up could edit information like roommates or the dates for the stay.

Since there were hundreds of rooms from all kinds of locations with different maps and descriptions, we needed a way to make this all appear on the website in an automated way. C&T maintained a spreadsheet of the locations with numbers of rooms available, and that was imported with Taxonomy import/export via XML module and Node import module. From there all listing of our items were implemented with Views with custom CSS styling with the room service having exposed filters for certain properties.

Bios and help in financing

Rich user biographies were implemented with Bio module, with our own CCK content type including relevant fields. People could show up in the view for those looking to share rooms by ticking a checkbox and could also provide reasons on why they are looking for financial help in general to come to Drupalcon, which was also displayed in a view.

The timetable

Once session submission was closed, we needed a way to put times and dates to sessions, as well as assign them to rooms. The most obvious selection would have been Date field and Calendar module with Views. That would not print columns with the different rooms in a timetable, would not allow for implementation of the scheduling itself in an easy way (picking times when you have no idea which sessions are at the same time is hard), so we decided to only use some of that functionality. We did use Date field to specify the start and end date on sessions/BoFs, and implemented the room assignment with taxonomy again. The display for timetables was however some custom code, and it was reused in many ways, doing caching on all levels to make it fast for all users. According to our original decision to elevate BoFs given their generally good quality factor on Drupalcons, we displayed sessions and BoFs in the same timetable. It was good in digital form so that people can look for tomorrows full program from their hotel rooms or from bars in the city. We also had events at the venue on floor -1 to floor 3, so requiring people to run back to a whiteboard somewhere in the middle of the building did not sound realistic.

We did reuse the timetable in all kinds of interesting ways:

• The original timetable
• A timetable of upcoming sessions, which would remove tables for previous days, putting the current day in focus
• A personalized timetable, where sessions on which the user voted were highlighted with CSS. We've implemented a user interface for revoking votes on sessions as a custom voteupdown style for this to work.
• Printable versions of any of these timetables via print directed CSS, so people could actually print out a timetable for their personal use. Although the BoFs were changing throughout the day, having a paper program is good value for many people, so it made a lot of sense to make that self-service for them.
• A projector was used in the main hall to display a special version of the timetable (read more on that later).
• This timetable was used to let BoF submitters schedule or even move around existing BoF proposals. Anyone could submit BoFs even while at Drupalcon and place their item on a drag and drop interface to previously untaken rooms (read more on this shortly).

The fact that we did use Date allowed us to provide an iCal view as well, so that people with desktop or mobile calendars can subscribe to our program. That was where we actually used Calendar module to provide this iCal output for us. It was just a matter of turning the module on.

Scheduling the sessions was done on a drag and drop user interface which as said used the same code as the rest of the timetable displays. The only difference was that it marked cells which can still be taken with classes saying they are "dropzones" and a special table of cells at the top which contained a "dragzone" from where submitters can drag in their session. They were able to keep the existing schedule, unschedule a session or modify the schedule. We used jQuery_update and jQuery_ui modules here, and wrote a little bit of custom code based on the drag and drop demo on http://ui.jquery.com/. Check out a video demo of the scheduling done before the Drupal.org redesign keynote at the conference to get people schedule their BoFs: http://www.archive.org/details/redesign_drupal_org

Finally, the projector version of the timetable was doing some JavaScript goodness to display the most current information. We basically used a full screen browser window which was displaying a large JavaScript clock in the upper right corner and a JavaScript enhanced upcoming timetable interface. The page was set to reload every few minutes, so that new or modified BoFs will appear without human intervention. It was also set to run a JavaScript check each minute to hide rows of the timetable which are passed and highlight the current program items with a bigger font so that it is clear what is going on. This was considered to be a good improvement for attendees over solutions at previous conferences, where it was hard to make out the time and timetable from what was projected. At the code sprint, we did use the projector to show a page of conference photos from Flickr and the top of the whiteboard (see next).

Digital whiteboard

So while it was so important for us to get rid of the BoF whiteboard for scheduling of BoFs, so that people at all kinds of places can have a clear picture on the full program, we's also set out to eliminate the messaging whiteboard. This whiteboard was used at previous conferences to inform people on good bars to go, look for cab sharing, find lost stuff, and so on. We understood that we need some kind of wiki functionality here, and indeed it was not complex to implement. We added a new simple content type for whiteboard notes with no special features and granted all users to submit or edit any of these. This worked out quite well, and only attracted spammers after the conference, when we eventually closed it down anyway. The whiteboard page was built with custom SQL queries, but could be built just as easily with Views. Single items were styled to have the same height and width, so they can show up in multiple columns visually resembling sticky notes. Website admins had the right to promote notes, and we did use the system to spread news on a high impact train transportation problem, which helped people to orient and not miss flights.

Adapting to what was needed

While we tried to simplify the Drupalcon website experience a lot, it was still a huge amount of information to digest. We did come out with a very simple site with marketing messages on Drupalcon and grow to a combination of an information and commerce site. We could not ever build all the above at once before releasing it to the public, and iterating on previous developments and getting in new improvements from time to time helped us adapt to new requirements.

We came up with ways however to try and focus users to the right places. We modified the ordering and even the size and color of menu items as the conference went by. While the conference was on, the photo galleries of previous conferences or travel information were not as prominent, however the whiteboard and timetable got the prime time at the start of the navigation with bright colors and a bigger font. Less relevant menu items were greyed out. We even continued this after the event, highlighting that downloads of slides and videos of all sessions were available (making the actual timetable less useful and pushing the downloads view into the front instead).

Happy end

At the end, the feedback we got on the website and services we built was great (not that this was not true about the whole event in other aspects as well - yay beanbags). We certainly made some mistakes in how we did some of the items (especially that we did not try harder to bend an existing commerce suite instead of trying to build lots of that on our own), but overall we managed to implement cool ideas and improvements and can only hope that those coming after us will do similar to upcoming events. No question that the upcoming Drupalcon DC website is outdoing us in many ways.

Dear reader, with this I wish you happy events site building!
Gábor Hojtsy (co-lead to Drupalcon Szeged)

Drupal version: Drupal 5.x