The judges would then review your work and score it based on code (cleanliness, semantics, and validation); user experience (respect for design, good choice points, interactions); and support (modern browsers, legacy browsers, size of project, resource optimization).  In the judges hands rests the responsibility of deciding one grand prize winner, 2 second place winners, 2 third place winners, and 20 runners-up.

A few Centresourcers were up to the challenge, here is what they had to say about the experience:

Mike Calhoun

The big thing that jumped out at me with this design was how EVERYTHING had a textured background associated with it. After that initial shock, my attention turned to points that seemed like they could have some kind of user interaction. There were none specified by the designer and the rules had specified that it was left to the coder to decide what (if any) they would like.  The obstacles section was an obvious choice for some kind of hover/transition.  The count down clock and form area also seemed like something that would have an room to explore with whatever I came up with while creating the markup. After a closer look, a few other smaller nuances caught my eye such as the small transparent border at the end and beginning of each section, the text shadows and many of the headings, or (again) the textured background.  In the end, I made a conscious decision to try and keep this as small as possible in terms of the file size and sacrifice complete compatibility for items like the above nuances in legacy browsers.  Although this probably hurt me in terms of scoring, I thought it would be more beneficial to learn newer practices for HTML5 and CSS3 versus supporting Internet Explorer 6 (which honestly has not been something I’ve thought about for a few years).  The trade off worked out well for modern browsers as everything looked pretty close to the design and I was able to use lots of CSS3 properties to accomplish the gradient background effects (rgba transparent backgrounds with a gradient image), font face properties for all the non standard fonts (allowed for the ticking clock), and extensive use of the jQuery animate property for my transition effect on the prizes section. In all, this was a  great experience that should pay off in the long run for applying new process to future work.

Travis Roberts

Mike went over the different sections/elements of the design, so I’ll talk about some of the tricks I used to accomplish the design while still keeping file sizes nice and small.

First, I exported all of my images as transparent GIFs instead of PNGs. The judging gives points for compatibility with older browsers, and everyone’s favorite browser to hate, Internet Explorer 6, doesn’t support transparent PNGs. The image quality of the exported assets were comparable as GIFs, the file sizes were much smaller, and they work with IE6 without having to do any weird hacks. By using GIFs, the total size for all image assets clocked in around 868KB.

Second, I used a CSS3 library (Animate by Daniel Eden) to accomplish all of the effects/transitions. This may seem counterintuitive to my previous paragraph about older browser compatibility. My thought was that effects/transitions are progressive enhancements. The site will still work fine without them, but they add a little polish to browsers that understand them. Because I used the CSS3 library for my effects, the only external javascript file I included was jQuery. This allowed my total project size to be relatively small (~1.1MB zipped).

My entry: http://cssoff.csclientsite.com/troberts/

I started out programming Drupal which endeared it to me because it was my first job, I understood it, and my employer thought highly enough of my skills to pay me. What I needed to better understand was that Drupal was not the only game in town. When presented with a new problem one must always consider what the problem looks to solve and what best accomplishes that solution. For me, I was confronted with a project that needed a pretty extensive custom database that, as hard as I tried, I could not get to work well with Drupal. After extensive research I (begrudgingly) decided that Ruby on Rails was my best option. This reflects another fact of life in web development: things advance very quickly (and usually for the better). When I started my first job, Rails was still in version 1.x with syntax that was not immediately understandable to me and was lacking in the documentation or as big a community as PHP and Drupal. By the time I came back to Rails, much had changed. Rails was older, the documentation was great, and it made complete sense for this problem. In the end, the only hurdle to overcome were my preconceived notions about frameworks and how I understood them to work. I had to consider that something had gotten better, and realize the goal wasn’t to build a site in Drupal, but to build a site that thoughtfully considered the clients’ needs and best addressed the goal of the project.

Much has been said about what technology agnosticism means or if it is even something at all. For me, it means rationally and carefully thinking of the problem and how to best solve it, where best does not mean “something with which I’m most comfortable”. This is true in all facets, be it language, framework, Drupal module, Ruby gem, or Rails plugin. We can use that with which we are most comfortable to start with, but from that point find other tools which improve our skills and improve our process. As Marshal McLuhan, said in his book The Medium is The Message, “we shape our tools and thereafter our tools shape us.”