Every year The Nerdery puts on a charity event called the Overnight Web Challenge in which teams of web developers donate 24 consecutive hours of time to build new websites for deserving local charities.
This year I participated in the Kanasas City event with some of my coworkers. Our team, Dangerzone, consisted of myself and three other .NET developers, plus three folks from the client side team. We also had a project manager join us from outside the company.
Edit: As of 2015-05-13, the site is now live at http://www.operationshow.org/
- Server Side
- Umbraco 7.2.4
- Strongly typed views using UmbracoVault, a yet-to-be publically released Umbraco ORM from The Nerdery
- No external packages
- Stored users who sign up as Members
- Custom approval and reporting dashboards in the back office
- Azure SQL Database
- .NET 4.5
- Umbraco 7.2.4
- Client Side
- Custom CSS
- ES6 via es6-transpiler
- Other Tooling
- Git deployment to azure
After arrival and setting up our equipment, all the teams met in one room to receive our pairings. While we knew a bit about the participating charities, and had a chance previously to meet with each of them, we didn’t know who we would be working with until the morning of the event.
We were paired with Seriously Playful, a local non-profit that facilitates after school improv events for high school students. Their program is called Operation Show, and they desired a new website to help get their name out, to solicit donations, and to allow students and schools to sign up and get involved.
We sent our PM and designer to a quiet space to hammer out a scope of work with our client Trish. While they were deciding what pages we would need and how everything should be laid out, the rest of us focussed on getting tooling set up: creating a dev database in Azure, building out a skeleton project structure, and putting together the client side boilerplate.
When they returned, they explained the various pages and some of the extra functionality we would need: signups for coaches, students, and sponsors, as well as the ability to create and manage seasons and events. Having Trish in the room during this time was invaluable. As we sought to understand the data structure and requirements, we would often have questions about edge-cases and user experience. What happens if a user signs up for a second season? What happens if some prankster types offensive stuff into our sign up form? Can people be on multiple teams? How many people are involved in a typical season?
With all the data architecture in mind, we started fleshing out Umbraco Document Types for the various pages. At this point, theoretically, Trish could start entering data.
The development process parallelizes pretty easy: myself and the other .NET developers could focus on putting together the server-side functionality: data accesss and retrieval, form submission handling, workflow, etc. We could lay out the pages and just print the data to the screen with the basic browser styles.
While this was happening, the client side team could focus on building out statics. They had an efficient pipeline going: Myron would design components in Photoshop, then pass them to Patrick to layout markup and styling, then pass them to Wes for any javasacript development. Once they had the site skeleton and many of the modules together, about 1 AM, they passed the statics over to me for integration: basically copy-pasting from their templates into Razor files in visual Studio and adding the controls to print out the data.
At about 4AM, we had enough of the site built that our PM could train Trish and her team on how to use Umbraco. Part of the training was entering all the content Trish had prepared.
What went wrong
We could have done a couple things better. We spent a lot of time fighting with client side build process. It would have been nice to have that working before the event.
We struggled a bit with some of Umbraco’s features, specifically crafting XPath queries to customize editors that only let the user select options from the right part of the content tree. Its frustrating trying to work with an unfamiliar tool under pressure.
What went right
Overall we were very well prepared. We had some data access utilities that could be reused from sample projects we’d built earlier. Some components were already built: contact form, pagination, etc.
We had a great client. Trish was flexible and understanding if we said we just couldn’t do something within the time constraints. When we had questions about edge-cases with the site behavior, she always had good input to help us understand their needs so we could make the right decisions on her behalf.
Tips and Tricks
Try to build out reusable components ahead of time. You may not know who you’ll be working with, but many features are common to all sites: navigation, paging, data access utilities and helpers.
Have your tooling ready: you could come to the event with a client side build process, databases, default project structure already set. This could save you a lot of valuable time.
Don’t eat too much – no point getting sick in the middle!
Try to solve the hard problems first when your brain is working at full capacity. Don’t defer difficult decisions for 4AM when everything is silly.
Spend the time up front designing a good information architecture. Its very difficult in most CMS’s to change that once content goes on. It will be even harder after missing your scheduled bedtime.
Parallelize as much as possible. Its great to keep both the client side and server side teams working at full capacity. The server side work can be done without a finalized design: even if you’re just dumping data to the screen, it helps you flesh out all the features you need. Its easy to add styles and layout later.
Its worth taking the time to make entity models so you can use strongly typed views in Umbraco. It may seem like overkill, but it will only take you like 15 minutes and will save you a ton of time trying to remember the property alias names. This is especially critical on a team: its probably easy for the one who created the document types to remember what properties are on it, but as soon as someone else needs to build a view, Intellisense will save the day.
I’m really proud of what we accomplished. In 24 hours, we donated a website that would have cost thousands of dollars of custom development and consulting time. We build a great platform that will allow Seriously Playful to maintain and enhance their web presence, helping them find new supporters and expand their participant pool.
Even under such an aggressive schedule, the team did an amazing job. The site looks awesome and performs admirably. I really learned a lot from this project and had a great time working on it.
I’m looking forward to helping out another charity next year!