Sunderland AFC Website.

Tackling the responsive website build for Sunderland AFC

Recently there has been a lot of talk in web community about responsive web design, a term first coined by Ethan Marcotte in this article. It describes an approach that aims to create an optimal website viewing experience for any user, regardless of the type of device used to access it. Content and navigation re-sizes to fit any viewport, from a widescreen monitor right down to the smallest mobile screen. Breakpoints are put in place at certain screen widths that trigger content to load in or re-shape for the best viewing experience.
It allows the site to be fast on the smallest devices as the content and functionality that is only needed on desktop will only be loaded as and when it is required in an asynchronous, and unobtrusive manner.
Editors only have one set of assets and content to manage as it is the same site appearing on all platforms.

Back last Summer at Aqueduct we had been waiting for the right client and opportunity to put into this methodology into practice. We had won the pitch for the Sunderland website and were in the planning stage. They wanted their new site to be cross platform so we decided that this would be a perfect opportunity for us to put into practice these bleeding edge ideas.

The way it works.
Utilising a mobile first approach we were able to progressively enhance the site by adding in new functionality and content required on desktop or tablets with an Unobtrusive javascript pattern triggered on globally assiged screen width break points. At the same time we were able to shift around the content. So on mobile portrait everything is in one column. In landscape a bit more space can be utilised. As we move up into tablet sizes the content can be split into two columns, and into three for desktop with more content being added at each pre-defined point.
This opposite approach to this is the desktop first approach which we don’t advocate as it has a big impact on the loading times of mobile devices. The content would be hidden on mobile. but still loaded by default which is wasteful.

The technical preparation process.
As a the lead front-end engineer on the project, it was decided that I should be involved at an early stage in the design process to help the designers and UX with outlining the initial grid that would be used across the site. The base structure would need to be very flexible and dynamic across the different break points. In a traditional build, the process would start with UX, move through the design phase and end up in front of a developer as a Photoshop psd to be cut up and templated. This approach in a modern responsive design is problematic as there is the potential for many unseen issues to crop up along the way.
So we spent time sitting around tables, sketching mock-ups and prototyping to get a solid idea on direction. I was then able to loosely prototype a flexible grid system so that we would have a basic framework with working breakpoints in which to start development. This approach saved us a lot of time in the later stages of development as a lot of the design was still on-going with changes coming in from the client and it allowed us to add new features within the bounds of the grid that would not break existing integrated code or result in too much reworking.

Dynamic image loading
Probably the most important thing we wanted to get right was the loading of images. We wanted mobile users to have assets served to them that were optimised for their device but at the same time serve high resolution, full size assets do desktop users. It just so happened that at the time there were a number of theories doing the rounds with regards to this new way of thinking. The two main forerunners in the debate though were still at very early stages of development and each were pushing hard for adoption by the W3c. It was impossible to tell who would win out in the end and rather than head down a route that could potentially be a dead-end in the near future, we decided to simplify things a bit an wrote a small javascript plugin to dynamically load the appropriate assets dependant on screen size after the page in the site has fully loaded. Things have since moved forward a bit in the debate and at some point we will be able to update what we have done and adopt an early working draft version.

Graphical Stats, animations, matchday centre and large related dependencies.
Another thing that made the development of a the site even more challenging was the fact that a lot of things were going on in different parts of the site aside from just content! There are different sized galleries with full screen options, complicated hover events, graphical statistics that animate in match reports, not to mention a live updating match day centre. All these areas needed to be fully responsive and some of the features only needed to be available on desktop. What that means is that all the assets and logic driving anything that wasn’t available on mobile needed to be only loaded for tablet and desktop users. So we used Require.js, an advanced javascript module loader and wrote unobtrusive, modular code to drive specific areas of the site that could be added and removed without affecting other areas.
What we have learned and what can we improve on moving forward?

As more and more devices become available and as web users begin to spend more time on these devices instead of the traditional desktop, and as the lines become blurred between what is a tablet/mobile device, a future implementation of a “popular device width” driven breakpoint system becomes invalid. With the dilution of widths across multiple devices it becomes pointless to specify these breaks around these widths. Instead, it is becoming good practice to implement a “device agnostic” or “content driven” breakpoint architecture. In other words, we shouldn’t be targeting the widths of today’s popular devices. Instead we should be looking at our designs, layouts and content and deciding when a breakpoint should alter the layout of content purely from a visual standing regardless of what device it may eventually appear on.
Pitfalls of the simplified dynamic image loader
The way we implemented this was quick and effective but it had it’s drawbacks. To make some of the images linkable we’ve had to add in work arounds and the multitude of different sized images along with dynamic server side resizing have resulted in some images not being as optimised as they could be. Luckily the system was implemented in such away as that it can be over-hauled and replaced with a more robust standard implementation as it becomes available and more widely used.

A simpler site?
A simple website is simple to develop responsively and quick to load. This is easy to understand. So the differences between a single template blog and say the Nike website (which is partly responsive) are immense and the complexity of planning and prototyping a whole site to being responsive becomes apparent as more and more features are required and added. The Sunderland build was somewhere in the middle. At it’s heart it’s a content rich website for fans of the club to get all the information that they require, but it also has a lot of templates, varying content and loads of visual information and data. There were some tricky situations where global breakpoints were affecting templates in unwanted ways and we had to provide workarounds to get the job done, But these issues can be minimised with proper planning and prototyping in the design phase.

In closing
We are hugely proud of what we achieved with the Sunderland build. We were able to put a lot of new tools into practice and the result is a fast, minimal, stylish site that is accessible across all platforms, managed from one content management instance. It is future proof, customisable and scalable and we have already started added new features. The match day centre is constantly evolving and improving.
This whole process is being improved with each new build now, and the web keeps moving at blinding pace so there are always new techniques on the horizon.