I recently participated in FullCodePress, an event that challenged 3 teams to build a website for a non-profit organization in 24 hours. Here are a few things I learned along the way.
What a gorgeous country. Emily and I ventured to Zealandia, the Te Papa Museum, the Weta Cave, the New Zealand Botanical Gardens. From living in various large U.S. cities my whole life, I never realized how much I love a country whose skyline includes mountains.
FullCodePress was amazing. Organized by the same people that put on Webstock, this was one of the most well-constructed and enjoyable events I’ve ever had the pleasure of being involved in. Mike, Tash, and the rest of the crew were super hospitable and amazingly good hosts. They also did a fantastic job of documenting the entire event. From Twitter to photos to a plethora of interviews and random videos, the evidence was almost as good as being there.
I’m very lucky to have been part of such an awesome team. The all-star cast was composed of Jason Santa Maria as designer, Liz Danzico as user experience advocate/information architect, Karen McGrane as content strategist, Jenn Bove as project manager, and John Ford as programmer. I was responsible for front-end code.
Before the event started, we decided to have a few phone calls and Basecamp threads to make sure we started on the same page. Given that we would only have 24 hours, we had to minimize the room for error as much as possible. Our conversations focused mostly on creating a rough schedule for the time we had and compiling a list of questions for what we should expect. In looking through the sites created from the previous 2 years, it seemed we would probably creating a site that was roughly 20 pages deep.
Based on John’s recommendation and expertise, we settled on using WordPress as the content management platform for the site. John works at Automattic, so WordPress was certainly an obvious choice. We also knew that we wouldn’t have much time do much training with the client in the time we had; we could take advantage of the already existing documentation. Plus, if our client needed to make any changes after we were done, WordPress is popular enough that others could pick it up and run with it.
I set up Beanstalk accounts for our team, as we agreed that some form of offsite version control would come in handy.
We met our client as soon as our 24 hours began at 11 AM. We met Wiliam and Gurbux from the Timaru Mental Health Support Trust—Victoria House, and immediately launched into an hour kickoff meeting to learn as much as we could about our client’s organization. While the 5 of us did that, John ran some magical configuration settings on our server and set up automatic deployments to 3 separate servers: the local one we were working on, his own remote test server, and the public server given to each team where the final site would live. The extra safety net came in very handy when the servers crashed for every team about halfway through the night.
After the first hour, we sent the client away to do some content homework. The six of us each put up giant post-it notes on the wall and began to sketch ideas for the site. Using the studio method I learned in a Todd Zaki Warfel’s prototyping workshop, we spent about 10 minutes sketching and then pitching our sketches to each other. Great ideas began to emerge quickly. There were concepts for organizing schemes, rebranding, site features, layouts, imagery, and much more. This quickly got us on the same page on what we were going to create together.
Because of the aggressive timeframe, we knew we had to eliminate as much time where any of us were sitting around waiting on someone else. This meant the typical waterfall model of software development went out the window. The prototyping stage helped to centralize an idea, and each of us split up to immediately work on our individual pieces.
Although we discussed using a CSS framework like 960.gs, Blueprint, or YUI, we decided against them. I’m much more comfortable creating my own simple layout framework per site. The problem with those kinds of frameworks is how powerful they are; in order to work for everyone, they have to be so abstract that they’re not specific for anyone.
In a quick discussion with Jason, we agreed on a seven-column grid, and I was off to build it while he worked on some new logo treatments. We also decided that there would be some sort of hero image area, so I knew I had to take that into account.
We were asked to update our staging servers pretty regularly with the latest work, as opposed to waiting until the end to stage a big reveal. The goal was that anyone following along can see real-time progress as we make it, which I thought was a great idea. I decided to have a little fun with this. Using one of Big Spaceship’s mantras of “Build fast, build ugly,” I used a garish color scheme of neons to block out my sections and build my layout framework. I also decided to playfully taunt the other teams a bit by rocking some old-school markup and displaying some national pride.
We made our site a child theme of Twenty Ten, the default theme that comes with WordPress. In order to skip an integration phase, I was building directly into the theme so that content from WordPress could immediately be reflected in the build.
One thing that I thought was important was actually ditching HTML5 in favor of XHTML 1.0. Because we had such a short timeframe and I’m not terribly comfortable with HTML5 yet, I couldn’t afford to get tripped up on HTML5 bugs that I didn’t know how to solve quickly. I know XHTML 1.0 intimately, and the advantages of familiarity made me feel more confident about completing what I needed to do. Although TwentyTen is built with HTML5, I quickly converted everything back to XHTML 1.0. It didn’t take much time, as most of it was just removing role attributes and switching the DOCTYPE.
I also attempted to make the design as responsive as possible with layouts that would suit the iPhone and iPad, but alas: time ran out before I had a chance to get to it.
The 24 hours actually weren’t that bad. We heard that most of the previous teams encountered a rough patch around 4AM. I think the time change (a 16-hour difference for most of us) came in handy for once, but we made sure to plan some activities to get us through, just in case. We staged an ambush, won some arm-wrestling contests, and had our moms call to keep us energized. It goes without saying, but an abundance of coffee, soda, and snacks were always at our disposal.
After a gruesome 24 hours, the Australian team—the Codaroos—took home the win with a great site for the Lions Hearing Dogs. All in all, it was a blast! All 3 teams did a great job, it was loads on fun, and I even walked away with the coveted “!important” award: our site worked the best in IE6. Woo!…?
Thanks, FullCodePress!
Read Next