Hacks/Hackers Brighton: a more Responsive Guardian

I missed the first speaker – Sarah captured some notes in a Google Doc

Andy Hume, The Guardian

The Guardian pushes its content to multiple channels. It has the highest largest combined monthly digital and print readership of British quality titles. The website is kind of a big deal – it brings in both readership and revenue. It should be the jewel in the crown. They’ve done the new shiny – iOS and the like, but the web remains pretty central to The Guardian‘s digital stuff.

They have two sites – the desktop site and the mobile site. They have Java files detecting mobile and tablet devices and routing them to the mobile site. It’s very easy to just take the desktop site and cull it down until t looks like it might work on mobile. That’s fundamentally the wrong approach to responsive design. The main page is about 1.5Mb to 2Mb in size. It’s doing a lot of stuff. It even works in Lynx – a command line browser for UNIX.

Responsive design is just another facet of progressive enhancement. It allows you to add more functionality depending on the capability of the device you’re using. Once you’re aware of the device’s capabilities you can reposed in a way that’s appropriate. We think that the web has about 2bn users – that leaves expansion room of about 6bn. The chances are that the new users won’t be sat in front of desktop computers on biug fat pipe connections to the internet.

80% of its new development work is done in the open: github.com/guardian/frontend. What they’re exploring is a mobile-first responsive design. They experiment on beta.guardian.co.uk.

Hundreds of little images take a long time to download – the bottleneck is the latency for each connection it has to set up. Reducing the stuff on your page is really critical. On the home page, for example, they only load four or five preview images. The Guardian would love to have its typefaces across all the digital products – but every typeface costs 125k to 150k in download. So, they detect the device, and chuck away the typefaces for a good proportion of them, as they won’t display well. We ensure that they are only downloaded once – and we store them in local storage managed within the browser – essentially for ever.  They only download stuff towards the bottom when you scroll to the bottom – no point in doing it if you never scroll there.

They have a content store, a Web content API in front of that, and all the different channels access the content via that. The website knows nothing about the content, and the content doesn’t know how it’s going to be displayed. They now need a set of editorial controls that are decoupled from how things are presented. The central editorial tool can make decisions, and ll the clients can leverage that. The current tool is very visual – you are manipulating the site. The CMS is written in house, and is extraordinarily powerful – but it doesn’t scale across these other platforms. It’s very focused on desktop web browsing. The solution? A tool which searches the content API for new content – and then uses an algorithm to decide how important is. An editor can make a judgement tool about what is important. You are no longer thinking visually, but in terms of prioritising.

The other problem is advertising – which has traditionally been in very fixed formats. That doesn’t work in mobile. It – perhaps – needs to be more tied at the content level – tagged in as it comes out of the API.

Q&A

Q: Could you do the same sort of prioritising on ads that your do on editorial?

A: The ad servers are already really sophisticated – no publisher would want to bring that in house.

Q. Does the US site work completely separately.

A. It’s essentially the same site – that’s a whole other topic. It has a layer on top to prevent floods in Leeds hitting the front page.

Q. Will The Guardian run into the same issues as Twitter in ads not travelling with the API.

A. The Guardian should think about how it embeds advertising at a content level rather than a client level – both to make life easier and to monetize free content.

Q. Do you have any data on services like Safari Reader or Instapaper to read them?

A No, we don’t. It is a sign that we didn’t give them tyne experience they want. And they won’t get the ads.