Episode Transcript

Ethan:

Hi, this is a Responsive Web Design podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, we are beside ourselves—nay, impossibly excited—to speak with Alex Breuer, who is coming at us from The Guardian. Alex, thank you so much for joining us.

Alex:

My pleasure. Really good to talk to you both.

Ethan:

But before we get started, I’d like to say a few words about our sponsor, Campaign Monitor. Campaign Monitor has this new feature they’re really excited about, called Canvas. Canvas is an easy-to-use builder for creating beautiful, responsive email newsletters, that look great basically anywhere, even on mobile devices. What I’ve actually really enjoyed about working with Canvas myself, is that it’s incredibly easy to use. It has this really intuitive drag-and-drop interface, and actually gives me a decent amount of control over fonts and colors, and also takes care of a lot of the stuff you kind of expect to just work. Automatic image resizing is actually one that I find really helpful. And it’s actually very quick to get an email up and running in minutes. So if you’re interested, you can actually try it out without actually starting a Campaign Monitor account, if you go to campaignmonitor.com/templates you can build and export some beautiful and responsive email newsletter designs, again, without having that Campaign Monitor account. So thanks again to Campaign Monitor, and thanks for listening.

We needed to develop a site that was responsive because of the huge technical advantage of having a single code base and how we could evolve and develop the site.

I have been looking forward to this interview for awhile because I’ve been following The Guardian’s responsive experiments—which have been mostly happening in public from what I can tell—for the last year or so. I’d love to hear a little bit of background about what you’ve been working on and just how responsive design fits in at The Guardian.

Alex:

I’ve been creative director at The Guardian for just over a year and a half, and literally the day I landed there, they released what was the beginnings of the responsive site, which was an update to the mobile website, which had been previously designed and managed by a third party. But it became very clear within the business that actually we needed to have all of this in-house, we needed to develop a site that was responsive because of the huge technical advantage of having a single code base and how we could evolve and develop the site over the course of the year, which is what we’ve been doing at the moment.

Ethan:

Fantastic. I’d be interested to hear a little bit more about how the responsive design. I mean, it obviously started as a mobile-only website and it’s moving to a point where it’s eventually going to, I believe, become the default experience for The Guardian, right?

Alex:

Absolutely, yeah, that’s right.

The only way to really see if this worked was to put in front of people who would use it day after day after day and really see how comfortable people were with this as their core experience of The Guardian.

Ethan:

Can you talk a little bit more about that transitional process, what it’s been like starting a responsive on a specific subsection of your audience?

Alex:

Not necessarily a specific subsection of the audience in terms of how we’ve tested beta, which is live at the moment. In fact, we’re constantly updating the people who get to view this, so we’re really keeping the audience fresh on that. But it became very important to us as we were evolving the initial stages of the responsive structure and the patterns and the breakpoints of what we were going to do and how we were going to integrate the new thinking around content, that actually the only way to really see if this worked was to put in front of people who would use it day after day after day and really see how comfortable people were with this as their core experience of The Guardian.

Initially, we started with people who came into the site through search, which is about forty percent of our audience. Because we knew with the core audience there were going to be things missing, and so we didn’t want to scare people or push them away or worry them that this was too much of a change. Whereas people who had really discovered an interesting story through social media or through search, we felt that was a gentle way of introducing the new Guardian experience.

When I arrived, we had an Android app, iPhone app, iPad app, mobile website, desktop website, some of which were produced in different ways with content from different content systems and they all had a very, very different look-and-feel about them.

Karen:

One of the things that’s come up when I’ve talked to publishers is how the responsive design fits into the larger ecosystem of all of the different platforms and devices and touchpoints where people might want to consume news or information. Can you talk about how responsive design fits into all of the different places? How does it fit with an app strategy or, maybe, how do you think about a desktop user versus a mobile user and how you might want to day-part information for different devices?

Alex:

Just to give a little brief overview of the landscape when I arrived, we had an Android app, iPhone app, iPad app, mobile website, desktop website, some of which were produced in different ways with content from different content systems and they all had a very, very different look-and-feel about them. So, one of my chief goals when I arrived was I really wanted to develop a new design language that meant wherever people came into contact with The Guardian, there was enough fidelity of design and familiarity of interaction in content forms that people knew where to go or they knew where they were, and moving on and digging deeper through the journey’s end, that was familiar, because we had many users who use all platforms at different times of the day.

This is where the responsive design became beginnings of a content solution and not just a technical solution to make onward evolution of our digital products more robust. Also, coupled with this, with some cultural challenges within the organization, it has to be said we were really, really clear that we were learning so much even from the way people were using our mobile iterations either on web or on native platforms. That, as you suggested, when and where they were and what they were consuming was very different in terms of amount of time, volumes of content. We studied how they scrolled through various fronts and things like that, what they were browsing for.

We’ve struggled with a legacy view of what we do. Because we are a 200-year-old newspaper, and the form is the article, and challenging that has been… exciting. It’s been exciting.

The next natural step from that—because what we’re working on now is a huge, huge digital replatforming because we’re rebuilding a whole range of content tools and tools for editors as well—meant that it was a kind of perfect moment to learn from what we knew about how people were working and then to challenge some of the editorial conventions about what the atom of news was, or what the forms of storytelling were, that we needed for the different platforms and different times.

I think, like a lot of big major news organizations, we’ve struggled with a legacy view of what we do. Because we are a 200-year-old newspaper, and the form is the article, and challenging that has been… exciting. It’s been exciting. Journalists like the way they do things, and so we’ve been through quite an interesting negotiation process to get them excited about these new ways that they can bring their stories to life and how they really need to understand how that even just a nugget of a story can be really powerful in shorter forms on different devices.

We’ve just been working on some prototypes for some of the new wearable technologies. Once you have that in your hands and once you can show people the power of that, to people who are resistant to thinking there are more ways of presenting their content, it really makes that process a lot easier.

One of the things we wanted to do was to challenge the discovery process that dominated a lot of news sites, which are often driven by sections based on internal departments rather than by structuring content in ways that were of personal interest to people.

Ethan:

One of the things that’s been really exciting for me on the outside as a reader of The Guardian—the first version of the responsive site, from a layout standpoint, I think was fairly straightforward. It was basically a single column, flexible layout. I’d really love to hear a little bit more about how you’ve iterated over that design, how you’ve managed that process. Are you gathering feedback from users, stakeholders internally? Just generally how you’re corralling this project is something I’d love to hear about.

Alex:

That’s actually been the biggest challenge and it’s taken quite a long time, and probably a little bit longer than a lot of stakeholders would have liked, to get to where we’ve gotten to now. But as you said, when we first started that, we started with a list of articles, the kind of basic, conventional form. It’s easiest to develop and easiest to build into a rudimentary responsive platform. But we’re a huge producer of content, of a whole range of varieties and tones, and some require more of a visual display, some require a multitude of text-based facets, whether it be a headline standfirst and various related links around comment and analysis and things like that. We knew, even at that early stage, that this wasn’t really the right solution to bring our content to life.

Once we’re talking about watches and Glass and other wearable technologies, the article form or the headline form isn’t very exciting.

Fundamentally, one of the things that we knew we wanted to explore as a hypothesis was to turn visitors into readers and visits into journeys. We knew one of the things we wanted to do was to challenge the discovery process that had dominated a lot of news sites, which are often structured and driven by sections based on internal departments rather than by structuring content in ways that were of personal interest to people. Once we’d gotten that rudimentary structure in place on the basic site, I think the next stage was we spent quite a lot of time really thinking about the information architecture of the site editorially and what would really begin to answer those challenges I’ve just talked about. We did some really interesting work with Oliver Reichenstein and Konstantin Weiss of Information Architects because we thought it was really good to get some challenging to our own thinking from outside on that.

We came up with this idea of containers, which is the idea that pages are split horizontally into vertically stacked units of content. The idea being this is much easier to build responsively because each of these slices could have their own individual responsive behavior.

We were really keen to get away from lists, partly because we felt it’s just too backward-looking and it just felt like every other news site. But also, I think one of the key things that was behind that is that what constitutes storytelling in news and in digital platforms is completely changing and we felt the architectural structure of just lists of words really only promised more words, the basic article format. So one of the key things we also wanted to get out was a design or structure that allowed us to—as we grow into having more video, more live data, more interactive content, more animated explainers—we could have an interface that allowed you to have the right kind of visual presentation that balanced that whole range of content.

Because, again, looking forward, we knew once we’re talking about watches and Glass and other wearable technologies, the article form or the headline form isn’t very exciting. You want something to arrive as an alert on your screen and it may be the audio version or it may be the 15-second video. We had lots of ideas around what we wanted to try to create out of the design structure of the site, but we really weren’t sure what that form was. So, over the course of working with IA, we came up with this idea of containers, which is the idea that pages are split horizontally into vertically stacked units of content. The idea being this is much easier to build responsively because each of these slices could have their own individual responsive behavior and we can also update and alter each one of these without affecting the whole content structure of a whole page.

Underneath our site, there’s this really elegant, modular structure which is all built around the proportion of our core image size, so that allows us to define space and predict space as it grows across responsive patterns.

On top of that as well, I think we started out by creating these containers in the traditional structures of the organization, so we had news, sport, comments, film, etc. And again we thought when you want to discover something that’s relevant to you, you don’t necessarily think of it in the terms of the way we produce inside an organization like that. So the next evolution of that was that we were quite confident in that we wanted to kind of blend these containers, these stacked units of content together. We tried to be a little bit more esoteric about how we were going to structure this. There would be news and maybe there would be people or comments or features, long reads, short reads, so really start to think about how people consume and how that blend of different types of storytelling from all over the organization could be best corralled together.

I guess once we had these rudimentary slices or system in place, which was sort of underpinned by a… Underneath our site, there’s this really elegant, modular structure which is all built around the proportion of our core image size, so that allows us to define space and predict space as it grows across responsive patterns, so we can get that consistency and fidelity of spacing as layouts flex, so you don’t end up with odd spaces under short headlines and not enough space under large headlines. There’s still a little bit of that going on—we’re not quite there yet—but I think that’s the end goal of that. But I guess the final evolution of this system was when we got to this kind of really elegant, stacked series of slices that could be compiled either as an individual row of four, say, or you could put two rows of four, so you could build up these individual containers out of individual slices of content.

We also wanted to be able to elegantly reflect volume or tone of an individual piece within one of these slices. We built in the ability to boost an image or boost a headline, etc. so we could begin to have an editor-curated layout system, where the importance of individual pieces of content was defined by the evolving news agenda. So it’s a very flexible layout system that we hope works responsively, but allows our editors to really show change, show aliveness, show a really dynamic change or importance of an individual story over the course of a period of time, either as its presence changes or as it moves through the architecture of the container with which it lives.

We know we have a lot of traffic that just comes in at article level and a conventional navigation across the top isn’t necessarily appealing enough for onward journeys.

So what you see out there today is the car without its bodywork, basically. We spent a lot of time working around the technical processes of managing—not just how these individual slices respond to each other, but also respond—now we’re adding kind of a degree of editorial control and curation to the display as well.

The final thing which we’re most excited about how this kind of structure works, which you can see now emerging on the beta site, is that each one of these blocks or patterns of content, it’s not just self-sufficient, it’s also transferrable as well because we know we have a lot of traffic that just comes in at article level and a conventional navigation across the top isn’t necessarily appealing enough for onward journeys. So we’re really developing a system where we can take these blocks of content or containers that constitute most of our front page and section front pages, and intelligently place them at the foot of articles using the same design patterns that we’re using throughout the rest of the site, to work towards having that view that every article is a front page in a world where people come to you through search rather than being brand loyalists.

Of course, as I said, it’s still evolving. There’s still quite a large presentation layer missing from that. The next stage is to introduce tone around coloring and how we want to differentiate between comment and features and news and breaking news and live data, etc. So it’s been a kind of a long slow growth to where we’ve gotten to now.

We’re really keen that we wanted to get the editors to think about how a user uses this. We really challenged the way the editors thought about what they were presenting to people.

Karen:

You mentioned earlier that you are making changes to your content management system, to the publishing tools. Can you talk a little bit about how those changes affect the responsive design and particularly how it affects the editorial team and the way that they work?

Alex:

We’re building two key tools, one which is the basic content tool, which is the hub, which is where article content goes in. Again, still a certain amount to go in terms of having the variety of content that we want in there to serve a full responsive site in terms of having summaries of articles and a full range of headline sizes, etc.

But the core starting point for this in terms of the collaboration with the journalistic teams to challenge how they work was built out around the live blogs, which is quite a common journalistic form that we use here and there. We’re really keen that we wanted to get the editors to think about how a user uses this. An editor editing a live blog is on it all day, and so is really acutely aware of the narrative of how a live blog unfolds. But obviously as very few of us consume this live content can be there for two hours whilst something is going on, so we dip in and dip out. So we really challenged the way the editors thought about what they were presenting to people and really tried to get them to understand that they need to think about not just the constant of now, but also there will be really punctuation points in time where they’d really want to build up summaries or build up moments or build up a series of the key events. That if a reader comes at any time of the day, they can really have the option to have the top view or have the full readthrough.

I think this will evolve into how we think about what headlines mean, and what headlines mean in different places, and “Do we truncate or do we summarize?”

Working with the writers, we developed a content structure across the live blog content management, to build an interface that allowed them to pull out key events, build a navigable key events list, which lives on the left-hand side of the page, and also have a summary text field that, again, allowed you to discover various points through the live blog. Also, as individual items become powerful tools when you transfer the content over to mobile forms. Because often what we’ll do now, to avoid massive long scrolls, we’ll now truncate the live blog, certainly on phone sizes. But we’ve introduced this key events navigation, which exists independently of the core live blog text and now what that change is, in terms of editorial patterns, they now have to think about almost live crossheads to parts of a story rather than just the continuing stream of content.

I think this will evolve into how we think about an article, and how we think about what headlines mean, and what headlines mean in different places, and “Do we truncate or do we summarize?” As we move from wearable tech not being about reading but being about alerts, “Does this summary exist as a means to sync up with another device where you can save an article for later?” etc. Again, as I said earlier, once we can prototype these things, it really brings it clear in people’s minds. So the barriers against conventions of what forms should be journalistically are being broken down in quite exciting ways here at the moment.

Designers, UX designers, and devs were working closely together to test and build structures and content patterns in code, obviously because we needed to see it at all breakpoints at all times.

Ethan:

You mentioned prototyping a little bit, Alex. I’d be really interested to hear how your design process and how design teams at The Guardian, how that’s changed, if at all, with you doing more responsive work.

Alex:

It’s completely changed. We almost have on this project… and it’s continually changing. And the people who I’ve got on the team working as designers are also changing as well. More and more, designers really need to know a little bit of front-end code so when they produce even just early visual mockups, if it can be done in code, it’s so much easier. But certainly through the large early part of this process, as we were developing our structure, it became very pointless to design in flat, so we really quickly moved to designing in browser. Designers, UX designers, and devs were working closely together to test and build structures and content patterns in code, obviously because we needed to see it at all breakpoints at all times.

As we move towards that final presentation layer, designers are perhaps moving more towards conventional tools and using a bit of Photoshop, or we’ve been using Sketch quite a lot now to do that presentation layer. Our prototyping process has really, in the early days, has gone from basic UX wireframes almost straight into code and not that visual presentation layer at the outset, because we knew we weren’t even close to understanding what the problems the visual design layer might need to do, what they might need to solve until we had sorted out our fundamental responsive structure and information architecture.

At the outset of this, I think mobile was a little bit unloved within the organization. A lot of editors work and view at their desks, so they spend a lot of time looking at the desktop site.

Karen:

How did the prototyping process fit in with how you reviewed these responsive designs with the rest of the organization? Did stakeholders want to review the prototypes or review things at different breakpoints?

Alex:

They did, absolutely. In fact, we insisted on it as well. I think certainly at the outset of this, I think mobile was a little bit unloved within the organization. A lot of editors work and view at their desks, so they spend a lot of time looking at the desktop site, and certainly when I started there was this “Oh yeah, we’ve got a mobile site.”

And so those early days of prototyping, even when we were still at the simple list view, we made sure that all the senior editors and commercial stakeholders understood that “This is why we’re doing this and this is why this is important and don’t worry, it doesn’t look very good at the moment.” But it was really valuable to lead people through the process and it was really valuable because we needed to show the complex technical challenges we were solving. Yes, there were lots of challenging conversations where “Yes, but it’s not finished.” “Why is this doing that?” “Oh yes, but I want it to do this, this, and this.” So there’s always a good negotiation and conveying that understanding.

But I think more and more as we’ve gone on, we’ve been really careful to present always in the context of a focused hypothesis. We work in a very lean way here, so as we roll out new features or new major iterations, it’s always framed around solving a particular problem. It’s not just the redesign of the site. It’s “Today what we’re looking at is how are we solving the problem of a panel for onward journeys or related content on the right-hand column and how this transfers across the site.” It’s been really important to use that kind of level of detail. Also, it helps people understand the times when progress seems slow. You look at the beta and you go ”Well, not much has changed over the last few weeks.” But actually a lot has changed because we may have been solving a certain number of less visible technical problems around that. It’s always about kind of being really clear about the small steps that we’re taking in the context of that larger goal and to kind of reassure people and make them part of that process and part of that kind of decision-making sometimes as well.

Speed is the core of how we’re developing this. Because we know that compromising speed is a fundamental compromise to the overall experience of the whole site.

Ethan:

One of the things I really like about the site is, it’s not just responsive, it’s not just a beautiful site, but it’s also incredibly fast. I would be interested to hear a little bit about how the organization thinks about performance in general. Is that part of the design process? How do you actually measure whether or not the site actually feels right?

Alex:

It’s absolutely part of the design process. Speed is the core of how we’re developing this. Especially we’re really conscious of the challenges we have over people with 3G connections on their phones when they’re out and about. We really want to make sure they get to the site as quickly as possible. This has—sometimes to the frustration to some of the members of my team—has really driven the design process. Because we have explored all sorts of interesting animations and processes around navigation and expanding bits of content, all of which required a certain amount of JavaScript, which of course slows the thing down horribly. So we’ve really kind of been quite brutal in what we do and don’t choose to bring to life in that way. Because we know that compromising speed is a fundamental compromise to the overall experience of the whole site.

Ethan:

Well Alex I have to say that this has been a really fantastic half hour chatting with you. Both Karen and I have been looking forward to this did not disappoint.

Alex:

Good.

Ethan:

Thank you so much for your time.

Alex:

My pleasure.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan:

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Karen:

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Ethan:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.