Responsibly Responsive: developing the Greenbelt website

As of December 2013, we handed over the Greenbelt website to Greenbelt Festivals and are not now involved with the project.

Earlier this week edgeofmyseat.com (that is to say Drew and I) launched the all-new Greenbelt website. The site was designed by Wilf Whitty of Ratiotype, and brings the strong visual identity that he has developed for Greenbelt printed material to the website.

This is a really special project for us. Our company has a long working relationship with Greenbelt Festivals, we have for many years looked after their box office and customer database. We are also however Greenbelters and Greenbelt volunteers, onsite Drew volunteers with the official photography team and I volunteer as a floor manager in the GTV Studio. We love the festival, so it was always going to be a labour of love as well as an interesting client project.

Greenbelt placed a lot of trust in us to design the architecture of the site, and what we tried to do from the outset was provide them with an infrastructure not just for the main site, but for other projects in the future. In doing so we’ve met a lot of interesting challenges and both Drew and myself will be writing about these in the coming weeks.

My role in this project was mostly on the front-end, and so this post is to outline some of the decisions that went into the front-end of the site. All of these points probably deserve their own post, and I’ll expand more in future weeks rather than create an epic Friday afternoon essay.

A responsive design

From the outset we knew we wanted to provide the site with a responsive design. It makes absolute sense for Greenbelt, the festival has always embraced new technology and mobile – there are iPhone and Android apps developed for the festival guide. We know there are a lot of people onsite at the festival using mobile devices and also who use them at home.

That said, I wanted to built the site in a responsive way but without creating a reliance on JavaScript or bloating the front-end. I wanted to be able to take a sane approach to responsive design that wouldn’t store up a whole bunch of technical debt for me to wade through every time I needed to make a change. I also wanted to support old browsers in line with what I knew from looking at the statistics for the existing site – but in a way that made it easy for me to drop the extra stylesheets when they started to disappear from the stats.

I’m not into cleverness for it’s own sake, so if we were doing responsive design it was going to be a responsible responsive design, progressively enhanced to support as many users and devices as possible.

Embracing the one web

I was very keen that we didn’t offer a cutdown version of the site to people on mobile devices. I wanted someone on a phone to be able to access all of the content and the phone and tablet versions of the layout to be understandable in the context of the desktop layout. My aim was that the content was the same no matter what you used to access it – embracing a one web approach.

I am using a mobile first approach, with media queries loading in the layout and changed navigation for larger screen widths. This means that mobile devices and those browsers that do not support media queries get the basic stylesheet. This contains all the text formatting that will make the site readable. The exception to this being the older versions of Internet Explorer that made a significant appearance in our server statistics – and I explain my approach there below.

It had to be super fast – for everyone

As Bruce Lawson pointed out in a post yesterday, speed is important. Even if a user has a large screen, it doesn’t mean that they are actually on fast broadband. In our case it was highly likely they are using mobile broadband or slow wifi while at the festival. Therefore instead of worrying especially about load times for mobile devices, we worried about load times for everyone. From a front-end perspective that meant compiling together CSS where appropriate, not writing bloated CSS and mark-up, ensuring images were optimised as much as possible and served quickly. While optimising the front-end was important – serving these assets quickly turned out to be the most important thing. Read Drew’s post on How to Make Your Website Fast.

What we ultimately didn’t do was attempt to serve different images at different breakpoints, instead preferring to try and optimise all images and serve them quickly. As already mentioned many users may be at standard desktop size yet using mobile data connections and a small images for small screens approach wouldn’t help them. I am following with interest the responsive images debates and this may well be something we revisit. All assets are served via a media server built as part of the project so recreating assets for a future responsive images strategy is a possibility.

Care and feeding of old browsers

When I was in the final stages of browser testing the site, I was making silly comments about IE6 on Twitter and was surprised at the number of people who acted with some incredulity that we would “support IE6”. Not supporting IE6 was never an issue, it’s a browser people use, it shows up in the logs. It may well just be people in offices who still use IE6 checking the festival date to fill in a holiday form, but I am going to support them.

That said, I will not reduce the experience for the majority in order to support legacy browsers. Support does not equal “looks the same” I am also very against solving problems before I have them with a starting point of a mass of polyfill JavaScript as some kind of “boilerplate”.

Looking at the stats our Internet Explorer users were split mostly between IE9 and IE8. The site worked beautifully on IE9, the problem we had with IE8 was that our media queries – used to deliver the mobile first design – are not supported. I could have used respond.js to polyfill media query support for Internet Explorer 8 and below but I don’t see what the benefit of doing so really is. IE8 users are on a desktop and a fixed width layout is appropriate, so as part of the compilation process for the CSS we compiled together all of the layout CSS and served that to IE8 in a conditional comment with an additional stylesheet to fix the width at 940 pixels. With a few lines of JavaScript to polyfill some selectors we were done. As IE8 is using the main CSS any changes will be compiled into the CSS for IE8 and I don’t have the overhead of maintaining different stylesheets for browsers that are going away.

As you can imagine IE6 and 7 needed a little more shoehorning to get them to behave but they also are served the old IE CSS along with additional CSS to prod difficult elements into place. It turned out to be pretty trivial to serve most of the layout to IE6 and 7 and the number of IE7 users we have in particular warranted that extra work. In the future we may just serve IE6 the basic styles as usage drops off.

HTML5

If you look at the source the site has an HTML5 doctype however we are not, at this point, using HTML5 semantic elements. The reason for this being that I wanted to be able to support old browsers without the use of JavaScript or adding redundant mark-up. That said it probably would take no more than a day to switch the site to using HTML5 elements in the mark-up once we get to a point with those old browsers that we feel happy just serving them the mobile stylesheet. All of the mark-up is templated rather than being mixed into the PHP. I also tried to avoid clarifying selectors with an element extensively in the CSS – meaning that .wrapper for example could select div.wrapper now and section.wrapper in the future.

The big use of HTML5 on this site is in the media section. All of the video and audio content is served as HTML5 with Flash for fallback. We are currently using encoding.com to encode the various formats for video.

Navigation

The hardest part of the front-end build was the navigation. There is an awful lot of it and some of it is fairly complicated – for example the facets in the contributors section. I’m pretty pleased with the end result that Wilf, Drew and I came up with, I’m sure it can be refined as we see how people use it and navigate in practice.

… and relax

I can’t remember the last time I was so nervous when a site went live. We really wanted to produce something that would bring the festival to people all year round, that Greenbelters would love. Hearing good reactions from other people who love the festival was worth a lot. Greenbelt produce a huge amount of content, which previously was spread over various sites such as Flickr and YouTube. Being able to centralise and make use of that content really has been one of the big challenges of the project, and it is lovely to see people enjoying the effort that has been put in by so many people over the years.

It doesn’t end here, we’re very happy that we have a continued involvement in the site as well as the festival and I’m really looking forward to helping Greenbelt share all the fantastic stuff they are doing at the festival and throughout the year.