Notes on a responsive Guardian redesign

At the end of September, I finished what became an 18 month stint working with the Guardian on the UX for their responsive site.

About two years ago I worked on a redesign for the Art Fund – my first proper responsive project – writing about the research, wireframing and design phases.

Working with the Guardian has taught me a lot more about working on a responsive project, so I thought I’d share my experiences.

Performance is key

Any developers reading this have probably just gone, ‘Yeah… and???’, but bear with me – there’s a reason this section is first.

I’d suggest that performance is not at the forefront of UX and design minds. Sure, we optimise the shit out of GIFs, PNGs and JPEGs, but in a broader sense it’s something we tend to associate with developers and are happy to leave to them.¹

I’d suggest that performance is not at the forefront of UX and design minds… it’s something we tend to associate with developers

In this respect, I’ve learnt a massive amount about how UX and design decisions can effect real and perceived performance, as well as the lengths good developers will go to to achieve the optimal levels of both.

A simple example of this is the Guardian’s house typeface, Egyptian. It contains numerous fonts, but for mobile we had to pick just two (a regular and bold weight) because each font is 20-25Kb in size – the same as the desired initial page load. Even then that’s still 100Kb for the four basic weights and styles needed (regular, bold, italic, bold italic).

To get that figure down all sorts of measures were taken, including stripping unused characters and removing hinting information. And that’s just to address file size concerns – there’s also FOUC for example, or caching for repeat visitors (which was solved by Andy Hume’s nifty idea to cache them in local storage as HTTP cache can be unreliable).

Another example would be the content we’d want to put on the page. How many calls to the content API are we making? What loads in as the core content and what can be added later?

The overarching idea was to only make one initial content API call, with everything loaded afterwards – Football statistics and related content, for example, are modules that are loaded after the initial page load.

We weren’t building a website in that traditional HTML/CSS sense, we were working on a complex JavaScript application

Further, the sites architecture employs swimlaning so there’s a navigation server, an article server, a section front server, a football statistics server and so on. There are a few reasons for this, but the main one is if a server goes down people will still see everything else.

All of the above leads back to an even more fundamental point: we weren’t building a website in that traditional HTML/CSS sense, we were working on a complex JavaScript application.

There are a lot more examples and detail, but the main take away for those of us working on the UX and design is that even something as simple – to us – as using an additional font, or adding an extra module, can mean a large performance overhead.

Wireframing in HTML

As I mentioned in the previous notes, I’ve been wireframing in HTML as a preference for a long time now.

The benefits for a responsive project are numerous:

• everyone can see how the page should behave by interacting with it;
• you get a much better feel for your UX playing with it in the browser and on real devices;
• it becomes much more ‘real’ to stakeholders showing them within the browser, and;
• conversations with tech are easier because it’s pretty obvious what’s supposed to happen when x is clicked or y expands.

The tools I’ve been using are MAMP, Codekit and Textmate. To supplement that I have my own hilariously titled bootstrap, lozstrap², and my fork of Elliance’s brilliant wireframing annotation kit (meta frame), again self-reverentially titled loznotes.

The process was the same as for Art Fund: sketch with pencil and paper, before moving into code. There were numerous iterations, but broadly there were three sets of wireframes across three project phases. The first set were pretty much small screen only³ with the odd wider screen experiment. The second set started to explore more at wider screens and the final set were fully responsive.⁴

Each page was initially constructed making heavy use of server side includes, but laterly I adopted Codekit’s .kit files and began to use these instead, along with Codekit variables, for the HTML files.⁵

There were .kit partials for things like overarching template headers (e.g. the <doctype> and <head>), and page level modules (e.g. most popular).

Variables defined page types and page titles. Page types were used as filenames for the relevant LESS/CSS and jQuery files and as a class for the <body> element.

Any included .kit file usually had it’s own LESS file as well, so the most popular module or the navigation for a certain section would have an associated most popular, or navigation, LESS file.

This meant I could drop those files in to other pages and reuse them at will. Yeah, I know it’s not very performant having numerous LESS/jQuery files linked like that, but communicating the, ahem, “vision” trumped performance for the wireframes. Besides, performance is a developer issue, right..?

With the last set of wireframes, I started to annotate them fully using loznotes. This helped avoid ambiguity and explained any effects that were beyond my jQuery skills.

For a while, I’d thought about putting the wireframes in to a CMS, as I had done with ArtFund, because I’d found it useful to have the content there ready to go, rather than copying and pasting, re-formatting and editing within the HTML.

The experience of trying to make Textpattern bend to my will with ArtFund put me off somewhat – for future projects I really need to find a simpler CMS, that’s as easy to pick up as Textpattern, to use for wireframing if required.

HTML wireframes as a default

For a long time I was the sole UX person on the project so the above didn’t create any problems because I was working alone (later under the watchful eye of Head of UX Nick Haley).

In the second quarter of 2013 the project split into three tracks and three extra UX people joined the project. To get them up to speed with the HTML wireframes, Nick made me (and he did have to make me) run the rest of the team through three days of light HTML, LESS and jQuery training, which in the end I thoroughly enjoyed (irritatingly as he said I would).

The Guardian UX team is now actively working on its own bootstrap to be a common starting point for wireframing projects in the future

I’m incredibly proud of the fact that the Guardian UX team is now actively working on its own version of lozstrap – GuardianStrap if you will – to be a common starting point for wireframing projects in the future.⁶

They’d probably have got there eventually anyway, but I like to think, and hope Nick would agree, that I played a big part in making the shift to HTML wireframes at the Guardian happen.⁷

HTML to flat mock ups to HTML again

Like anywhere else the Guardian is still, not struggling, but working its way through how best to deal with issues that arise in designing a responsive project.

Pages were produced as HTML wireframes, then went back to flat visuals (in InDesign⁸), then back in to HTML for production. As a process it’s not the best or most streamlined – even just thinking about the wireframing stage, the code I produced wasn’t production ready and didn’t adhere to the Guardian’s coding standards, so it got binned in the actual build.

As a UX person I don’t want (or need in reality) to learn all the conventions the devs are using to output production ready code. As a designer probably even less so – you just want to play with the bits you need to.

You don’t want your designers (or UX people for that matter) limited by what they themselves can do in HTML

I’m not one for prescriptive “you must design in the browser”. One day maybe, when we have better tools, but right now, to your average (or shit hot) designer, it’s hard. It’s hard for me and I consider myself fairly competent in HTML/CSS. You also don’t want your designers (or UX people for that matter) limited by what they themselves can do in HTML.

At the Guardian there were some work arounds to allow designers to tinker with fonts and colours, as well as sitting next to devs tweaking elements, but, although beneficial, these are just work arounds.

Honestly I’m not sure what the solution is. I’ve high hopes for Macaw – as I think everyone has – but even that won’t necessarily address the issue of code being authored multiple times.

Using the mobile website as the foundation for your responsive site

One word, ‘genius’.

The responsive project came about because there was a business need to bring the mobile Guardian website in house. It was to be completely rebuilt and re-architected and the responsive site would be built on top of it.

So why is that genius? A number of levels:

• we were free from any constraints associated with working in the current architecture used for desktop;
• any changes on the mobile site would not affect the current desktop site, so we could (but obviously tried not to) break things and experiment, within reason;
• we could work quickly and iteratively on the mobile site – a fair few things were tried just for a week or two to see if they’d work;
• you can rapidly get good metrics – not that they are the be all and end all – behind successes and failures because you have real users interacting with the site, and;
• by the time you move up to larger screen sizes, there is a lot more of that data behind decisions taken and features that have been implemented.

One of the fascinating things about the project is that it’s constantly evolving and changing, with features being added and things being tried, whilst unsuccessful ideas are discarded. And this all happens on a live site at a much quicker rate than any large news redesign I’ve worked on.

One of the fascinating things about the project is that it’s constantly evolving and changing, with features being added and things being tried

The Guardian’s product department also held regular hack days which produced a number of good ideas that will hopefully see the light of day in the responsive project at some point.

Wrap up

The project is ongoing without me and hopefully more of the fruits of my labour should see the light of day as they start to work more at the larger screen sizes.

The team as a whole is great and, as I said at the start, I learnt a great deal from working with them and I’m taking those learnings into my current project (which also happens to be at a large news organisation).

And finally a word of thanks

Just a small thank you to Matt Andrews for giving this the once over and to Kaelig Deloumeau-Prigent for prompting me to write it – he suggested that, as it had been over a year since my last post to the blog, I should write about this project and the wireframing technique in particular. So here it is. Finally.