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, I am jazz hands-ing with happiness because I can’t tell you guys how excited we are to have Niko Vijayaratnam and John Cleveley from the BBC News. Niko, John, thank you so much for sitting down with us.

Niko:

Thank you.

John:

No worries.

Ethan:

Like I said, incredibly excited to have you both here, not least because the BBC has been experimenting with responsive design in public for quite some time, and you guys just launched this massive, beautiful responsive site. Before we dive in, could both you guys introduce yourselves and tell us a little bit about what you do at the BBC?

Niko:

Sure. So, this is Niko here. I’m the product manager for the BBC News website, and I’ve been responsible for effectively the delivery of the new responsive website and the decommissioning of our older static version.

John:

And hey, I’m John Cleveley. I’m currently the engineering manager, so I lead the development team, mainly front-end developers. I was one of the founding members of the responsive team back in 2011.

We had the m-dot domain that we could basically play with. So, we moved really, really quickly in the first few months.

Ethan:

Wow, 2011. That’s wonderful. Well, I know we only have a half-hour, but I’d love to hear a little bit of an origin story of the BBC News responsive site, because it did start some time ago. I mean, I first found out about it on the Responsive News blog some time ago, and it’s been amazing to see it evolve.

I’d like to hear, John, Niko, when first there were these discussions happening about taking BBC News responsive, how did you actually convince your stakeholders to actually go responsive, and were there any concerns or questions about responsive design as a methodology?

John:

Not really. Back in 2011, it was more the journalists were just concentrating on the desktop, if I’m honest, and at that time, our mobile site was really basic—it was for feature phones. So, we were given quite a lot of freedom, in the first few years, to kind of—almost like a startup—to just get cracking.

We had the m-dot domain that we could basically play with. So, we moved really, really quickly in the first few months; we basically used user agent sniffing to be able to redirect feature phones to our new responsive site that, at the time, was completely stripped-down, just the core elements-of-the-story pages, just literally a couple of lists of stories on our front page and other indexes. It gave us a really good point to strip down all the fat that was on the desktop.

As time went by, the other journalists saw what was happening, and at the same time, we were seeing far more smartphones and tablet users on our stats, and that’s when we started having the conversation with the wider business. But I think at the very, very beginning, it was very tech-driven from the developers and the tech lead at the time, and so we were able to move really, really quickly. Since then, it’s been a longer journey integrating ourselves with the wider business.

We’ve obviously seen the move of our audience from using desktops primarily to using mobiles and tablets; and on weekends, often more than fifty percent of our traffic is from those kind of devices.

Niko:

And just to kind of add on to that from my perspective: Over the last few years, we’ve obviously seen the move of our audience from using desktops primarily to using mobiles and tablets; and on weekends, often more than fifty percent of our traffic is from those kind of devices. So, that was obviously something we could take to our stakeholders and say, “Hey, your audience isn’t where they used to be and we need to provide an optimal proposition for those devices.”

We’ve always had the World Service, so we have thirty different language sites, and they all have their own publishing chains, so it’s all really, really complicated.

John:

And another thing: At the time, the technical stack was really old. We were using statically-published pipelines. So, basically we had a Java application that was publishing out HTML. And so, we had a separate desktop and mobile proposition, and all the—I don’t know if you are aware, but we’ve always had the World Service, so we have thirty different language sites, and they all have their own publishing chains, so it’s all really, really complicated.

Not only was it about getting more devices looking great with our site, but also it was about saving money in terms of getting to a point where we’ve got a single codebase.

Not only was it about getting more devices looking great with our site, but also it was about saving money in terms of getting to a point where we’ve got a single codebase that could run across all the thirty different languages that we support. And also the different platforms—instead of having a desktop and mobile output from our CMS, we stripped back the CMS to actually produce a really simplified data feed that could be applied to the responsive site or, say, the native apps as well.

We think we should be offering a familiar experience across all of the different devices, and people may want to be getting different things from BBC News at different times of the day.

Karen:

Let me follow up on what is a popular subject that Ethan and I like to ask people about, which is the difference between mobile and desktop. So, in many organizations I think there are larger technical architecture, infrastructure constraints that have them publishing different things to mobile and desktop.

But in many organizations, there’s also sort of a broader business or strategic focus on the argument that mobile and desktop users need something different. Can you talk about how those conversations happen at the BBC? Do you think mobile users want something different from a desktop user because they’re using their device in a different context?

Niko:

That’s really interesting. We see our audience not being desktop users or mobile users because, me personally, I’m a desktop user midday, but I’m a mobile user at seven in the morning on my way into the office, and I’m a tablet user when I’m back at home. So, I’m using various products on various different devices at different times of the day.

We think we should be offering a familiar experience across all of the different devices, and people may want to be getting different things from BBC News at different times of the day. So in the morning, people might want to be getting just a quick overview of the news, whereas in the evening when they’ve got more time, or on the weekends, they may have more of a lean-back experience, where they have more time to delve into some of our features or some of our more longform content.

But in designing the new responsive site, we haven’t been focusing on the experience on any one device, but rather concentrating on providing a great experience across all of them.

I think the key is not to assume anything. We don’t really know what our users have come to look at.

John:

I think the key is not to assume anything. We don’t really know what our users have come to look at. So, we can’t say, “Oh, it’s okay. This person is on a mobile, so we’re going to cut out a load of the content so they can’t reach it.” But that’s difficult, because obviously there’s less real estate, and how do you actually get this content into the page without it being a mile long? And that’s something that is quite challenging.

But what we basically try and do is just obviously change the way the content looks to make it more adaptable and look better on a particular screen width, rather than just completely taking it out. One aspect of that is navigation, and our desktop navigation is very different from our mobile navigation—obviously you’ve got more touch, you’ve got less screen real estate to play with.

At the beginning we had separate teams. So, someone drew the short straw and had to look after the old desktop sites.

Karen:

Let me follow up here and ask about a subject that I think the BBC has been really innovative and has displayed a really careful thought process around, which is: How did you plan your rollout strategy? So, as you were experimenting with Responsive News in public, how did you plan which devices or which people were going to see which iterations at which point?

And a particular question that I have is: How did you manage the development or the ongoing care and feeding of the “desktop mothership” as you were planning this move to Responsive News? How did you deal with the need for competing maintenance across these two completely different platforms before you rolled out responsive news overall?

John:

That’s a great question. So, at the beginning we had separate teams. So, someone drew the short straw and had to look after the old desktop sites, and then we had another team looking after the mobile/responsive. Basically what we did was we took a slice of different device types.

We had a cupboard full of really old mobile phones and we just opened it and we thought, “Oh my goodness. We’re never going to be able to test our site on all of these.”

So, we started off with feature phones, and we redirected those to m-dot. Then we worked our way to smartphones. So, at that point we were adding more JavaScript. We started off with the core experience that all devices could use, just the content and nothing else. Then we basically used the “cuts the mustard” technique that my colleague, Tom Maslen, created, which basically is a JavaScript test.

At the time, there were loads of—we had a cupboard, when we first joined the team, full of really old mobile phones and we just opened it and we thought, “Oh my goodness. We’re never going to be able to test our site on all of these.” Some of those JavaScript engines were terrible.

We basically made quite a brave decision of separating good and bad browsers. How we did this was with a quick JavaScript test.

We basically made quite a brave decision of separating good and bad browsers. How we did this was with a quick JavaScript test. We just check for “querySelector,” “local storage,” and “addEventListener,” and that’s what we found likely to be a good separation between modern browsers and the older ones.

When we redirect the smartphone users, it was a user agent sniffing on the server side, and at that point when we were creating our JavaScript, it allowed us to develop much more quickly and to test more quickly as well, because we knew that these JavaScript engines were good enough to use the modern standards. Once we did smartphones, then we redirected tablets, and finally desktop.

In retrospect we should have cracked on and invested in moving the responsive site forward rather than retrofitting parts of the responsive site within the old site.

But you’re right, in between, there were times where we got bogged down by upgrading parts of the old desktop site. So, for example, we’d create a new video experience on responsive and then port it over to the old desktop site. Unfortunately, we had IE in some kind of compatibility mode, and it was an absolute nightmare. I think we spent a lot of time getting it working, and I think in retrospect we should have cracked on and invested in moving the responsive site forward rather than retrofitting parts of the responsive site within the old site.

But it’s very difficult when you’ve got, as you said, the “mothership.” When all the traffic is going there, you still have to keep it going. And it’s a very different skillset—we had different platforms with different languages, and it was actually a very challenging time.

The desktop site, it was effectively just “business as usual” maintenance of that product. We didn’t actually do any new feature development.

Niko:

To build on that: The desktop site, it was effectively just “business as usual” maintenance of that product. We didn’t actually do any new feature development apart from, as John has mentioned, port some responsive features or templates over to the old website because we had to decommission some of the back-end systems.

So, for instance, John touched upon our video pages. Some of the back-end systems had to be decommissioned, and so we created a new responsive media template and what we call “hole-punched” it through onto our desktop site—so, actually with a responsive video template working on both the new responsive site and the old one.

Before we launched it to everyone, offered it as an opt-in experience and we ran some pretty in-depth user testing, not just here in the UK, but in the States as well.

As John said, we moved the smartphones first, but then the design didn’t just work on smartphones. If you actually looked at the responsive site on a tablet or desktop nine months, or even six months, before we launched last month, you would have seen that the site actually looked pretty okay on those tablets and desktops, and we were just iterating over the design to get it to a standard at which point we were ready to launch it to everyone.

That opt-in experience really helped us to gauge that the audience were ready for it and that we were happy launching it.

We actually, before we launched it to everyone, offered it as an opt-in experience and we ran some pretty in-depth user testing, not just here in the UK, but in the States as well. We ran user testing in several locations in the UK, because we were really keen on making sure that we upheld the quality standards that we think we’re known for around the world. We also ran a survey, and I was blogging on our internal BBC internet blog, trying to get feedback from our audience as early as possible so that we could make the appropriate improvements before launching.

I think that opt-in experience really helped us to gauge that the audience were ready for it and that we were happy launching it, and it allowed us to find out some things that we wouldn’t have known about unless we had put it in front of real users a few weeks or months before launching.

Mobile-first is a great strategy because you get to convert a set of users at a time and incrementally push people to your new site.

John:

I think one thing we did find was mobile-first is a great strategy because you get to convert a set of users at a time and incrementally push people to your new site, and that helps in terms of your design and incrementing that, and also your architecture, to make sure you can actually scale up.

Another way we also increased the numbers was obviously our World Service sites. They actually went to desktop probably over a year ago, so we were fully desktop on those sites—so the Russian, and there’s thirty other sites. So, we did have—almost like dipping our toes in before we moved the big “mothership” over.

What we’ve done is we’ve started to design in browser, and truly in browser.

Ethan:

One thing I’ve been dying to ask you guys is about design process. On the Responsive News site, there was that wonderful open letter about treating design as a service, and responsive web design—that these are sort of two fundamentally incompatible views.

I’d like to hear a little bit more, as the BBC invested in multi-device design, how that changed the way you worked internally, how design and development teams collaborated, and how you maybe moved to a more iterative model of working.

We’ve developed an internal pattern library and designers and developers contribute to that together, and the patterns that we create can be reused across the thirty different language services.

Niko:

What’s been fantastic in the last year is that I really feel that our design teams and our development teams have come together in a way that they haven’t done previously. To elaborate on that: What we’ve done is we’ve started to design in browser, and truly in browser.

So, we’ve developed an internal pattern library and designers and developers contribute to that together, and the patterns that we create can be reused across the thirty different language services that we have. I think it’s fair to say two and a bit years ago, everything was PSDs, heavy design, lots of design up front, and that since then we’ve moved to designing truly in browser, where our designers are actually prototyping the product or new features in browser so that the prototype works across all the breakpoints, and that helps us to communicate to the developers in our planning sessions exactly how the new patterns that we develop should be behaving. I think that has been a monumental shift in how we work, and it’s only been for the better. It makes just general day-to-day working so much more efficient, smoother, and much more fun.

Actually, we don’t mind if a designer isn’t particularly keen on coding, if they can just sketch things up in Photoshop or whatever.

Ethan:

That’s marvelous. Just to follow up on that: Niko, would you say that the applications and tools that the design team is using, that those have changed as well? For example, are Photoshop comps still being used, but maybe more as an internal communications tool? Or is everything just sort of being done in HTML/CSS at this point?

Niko:

It’s definitely lighter design in those kind of tools, and much more of a shift over to doing things in browser.

That’s where the pattern library really has its power, because it is that commonplace that brings everybody together.

John:

Also, the feedback loop is much better. Previously, we may have had designers go away to do a project for several months, and then it gets landed on developers to kind of then feedback, and we’d just find things that just weren’t feasible. Now, there’s much better communication with developers and designers. So, we may have some Photoshops to get some initial ideas… Somebody coined the phrase, “Design in whatever, but you always decide in the browser.” And so actually, we don’t mind if a designer isn’t particularly keen on coding, if they can just sketch things up in Photoshop or whatever. But it’s the point where the designer comes and sits next to the developer, and they have a conversation about how can they actually make this work in the real codebase.

A year ago, we would’ve been in the situation where we would’ve been having to create bespoke components for various news pages.

That’s where the pattern library really has its power, because it is that commonplace that brings everybody together. It started off as a tech-y thing, but now Niko, as a product manager, has kind of almost taken ownership of that, because it becomes something much wider, something that you can show to your stakeholders and say, “You want a new page? Okay, come and look at this, and just literally pick and mix which components you want on the page.” Whereas a year ago, we would’ve been in the situation where we would’ve been having to create bespoke components for various news pages.

Actually it’s focusing people on the fact that creating new patterns costs time and money.

Niko:

I think that’s really, for me, been really eye-opening. I’ve been in the role for something like fifteen, sixteen months, and when I arrived, we did have a massive number of different components, and each component was unique, but some of them were very similar.

Now that we’ve got this pattern library, I can be going to stakeholder meetings, and a person may want a new component to present some content they have, and I can wheel out the pattern library and say, “Well, do any of these existing patterns service your needs?” And if they ask for something that’s slightly bespoke, then I’ve got a good reason for asking, “Well, why can’t we use one of these existing components?” Which is making my job much, much easier, and actually it’s focusing people on the fact that creating new patterns costs time and money, and so this idea of having a central pattern library, and having that as the common language that we can all get behind, is really helping us.

It was basically a bolt-on so that we were able to move as quickly as possible without changing initially how the journalist workflow happened.

Karen:

I’d love to ask about your content management system and overall publishing process and workflow. So, one of the things that I’ve seen is that a responsive redesign is also an incentive to fix some of the underlying infrastructural challenges that organizations might have. Can you talk a little bit about how this work intersected with any editorial changes that you might have made? What changes did you make to your content management system? Maybe even how the pattern library worked with the publishing system, if it did?

John:

Sure. I’ll take the technical side. So back when we started, we basically cheated. The development team came up with almost a fake JSON feed and what we wanted the API to look like from the content management system, and literally what we did is we scraped the old desktop site and turned it into JSON. But it was a really good way of prototyping what the JSON feed would look like, and how it would work best with the front-end code and requirements. Then we basically got the back-end team to create a new API on top of the publishing system that was already there.

So, it was basically a bolt-on so that we were able to move as quickly as possible without changing initially how the journalist workflow happened, so they could carry on creating their desktop indexes, and stories, and content—they were published to the desktop site, but also available via this API as well, which the responsive codebase was using. And so, we’re basically incrementally improving the CMS as we go.

The one quirk with the CMS that we have is that it was very much a WYSIWYG drag-and-drop. Journalists could remove all the white space, get exactly the right number of stories.

The one quirk with the CMS that we have is that it was very much a WYSIWYG drag-and-drop. Journalists could remove all the white space, get exactly the right number of stories, and it was very linked to a fixed layout, such as a desktop. So, if there was a piece of white space, a journalist would just fill that with an extra story. But obviously with responsive web design, we had no idea how our users are going to view that content. So, we’ve almost got to make journalists behave more like sticking stories within buckets and care less about the layout.

The CMS now, from our perspective, is just giving us data, and on the front-end code, we are controlling the layout itself.

At the beginning, we started to separate, from the API, the layout and the data. The CMS now, from our perspective, is just giving us data, and on the front-end code, we are controlling the layout itself. So, that separation of concerns also helped with the native apps also using the same API. We weren’t putting any layout that was bespoke to a particular platform.

Our World Service sites, they use a completely different content management system, yet they’re able to use the same components from the pattern library.

Niko:

Yeah, I think that’s a good answer there. In terms of how that fits in the pattern library: The patterns or the components that we built are actually data-agnostic. So, they don’t really concern themselves with where the data is coming from, which is great. So, actually our World Service sites, they use a completely different content management system, yet they’re able to use the same components from the pattern library. The patterns are truly reusable across our thirty different sites. Actually, we’re still using the same content management system that has been in use for the last, God knows, I don’t know, fifteen years?

John:

Probably, yeah.

Now that we’ve gone fully responsive, it affords us the opportunity to start to simplify workflows, make the lives of our editorial staff easier.

Niko:

I don’t know exactly how old it is, but it’s called CPS, the Content Production System, and there are lots of different templates published from CPS. Now that we’ve gone fully responsive, we’re starting to think about how we can possibly radicalize the number of templates that we’re actually rendering out on the front-end, possibly simplify the experience for the audience, but also the workflows for the teams.

So, although we didn’t radically change the content management system, or actually we haven’t changed it all, just the output has been changed a little bit, now that we’ve gone fully responsive, it affords us the opportunity to start to simplify workflows, make the lives of our editorial staff easier, make it easier for analysts and developers to understand how they’re to unchain works, and to just tidy up our shop, really.

Being able to basically adapt the existing content and allow the Responsive News site to be powered off of the existing CMS is actually really powerful, because it allowed us a bit of freedom to work more quickly.

John:

It’s worth noting that obviously the BBC has got a lot of journalists, we’ve got bureaus all around the world. So, we have to think about very carefully how we change the content management system. Being able to basically adapt the existing content and allow the Responsive News site to be powered off of the existing CMS is actually really powerful, because it allowed us a bit of freedom to work more quickly. But as Niko said, we’re now at a point where we’re thinking about the next step in terms of content management systems.

That’s been a direct result—using data to discover how the site is performing and then making the appropriate changes.

Ethan:

Now that the responsive redesign has been completely launched, have there been any elements of the pattern library or any components of the site that have been reworked since it’s been released? If so, what were some of the reasons there?

Niko:

One of the things that has come up in the last week: We previously had a ticker at the top of our homepage on the old version of the design, and the ticker scrolled through the latest breaking news and latest headlines. We changed that to present breaking news items in a banner that reveals from the bottom of the site. Since we launched, we discovered that actually it’s a little bit too shallow and some of the text is being hidden by the URL of the page that you’re on that gets exposed at the lower left-hand corner of the browser. So, we’ve just been iterating over that pattern in the library and looking at what we can do to improve it. We decided we’re probably going to make that bit taller, and we’re probably going to add some share tools to it, and change the actual design of it ever so slightly.

One thing that is particular to the UK is that, the BBC obviously being a British corporation, a lot of our audience are in the various UK nations, and we discovered that we had a bit of a slight drop in traffic to those indexes, those section pages. So, just this week we introduced a second tier to our navigation on our homepage, that you can quickly get into those sections. That’s been a direct result—using data to discover how the site is performing and then making the appropriate changes.

We’re constantly iterating over the new design, and now that we’ve got a single site, we’re able to do that much faster than we were able to previously.

Our audience were actually screaming out for quick links to our live TV and radio broadcasts, which we’d omitted from the design at launch. And so we’ve reintroduced those, and they went live on the site last week. So, we’re constantly iterating over the new design, and now that we’ve got a single site, we’re able to do that much faster than we were able to previously.

We are very interested in how the site is being used on different devices, and how different content types are performing on different devices.

Karen:

Let me follow up on that and ask if the way that you measure the success of the site has changed now that it’s responsive. For example, when you’re looking at your analytics data, are you still looking at mobile, tablet, and desktop and trying to evaluate those as three separate platforms? Or do you have a way of looking at your data to evaluate the site as a whole?

Niko:

Yeah, we cut the data in various ways. We obviously look at engaged time by the different templates. So, engaged time for our stories, or engaged time on our section pages, or page views for different types of content. We use various different analytic tools; so, we’re using Chartbeat at the moment, as well as others. Chartbeat actually allows you to cut the data by desktop, tablet, and mobile. So yeah, we are very interested in how the site is being used on different devices, and how different content types are performing on different devices.

Since launching, none of those metrics have dipped, which is very positive. And now that we’ve launched, we’re going to focus on trying to get those graphs going on an upward trend.

How do we evaluate the performance of the product? Well, we’re very happy that we haven’t seen any dip in traffic to the site. We’re seeing very similar numbers of pageviews per visit; engaged time is very similar. We have seen a slight uplift in referrals from search and social. So, since launching, none of those metrics have dipped, which is very positive. And now that we’ve launched, we’re going to focus on trying to get those graphs going on an upward trend.

We keep a regular check on the types of browsers that are hitting our site, and they change rapidly between different countries.

Ethan:

John, you mentioned one of my favorite phrases earlier: “cutting the mustard.” I’ve been dying to ask you guys about this, because I think the BBC was definitely one of the first large-scale responsive redesigns to really plant a flag in this idea of designing with progressive enhancement.

The scope of what you guys built is really impressive to me, because pretty much any internet-connected browser on the planet can load this wonderful responsive redesign, but then there’s this extra layer that could be optionally loaded depending on the capabilities of the device.

What impact has that had on how the BBC conducts its QA process? How do you talk about this definition of support in a responsive redesign like this?

John:

The support always starts from our stats. We keep a regular check on the types of browsers that are hitting our site, and they change rapidly between different countries. So, the devices that hit in Africa, say, are very different from the US or the UK. So, we try and keep our device cupboard full of those top devices.

From a developer’s point of view, we always try and develop for the core experience first, and then progressively enhance up, adding more and more features.

Even in our pattern library, we have a button that basically swaps to the core experience, so it’s always very much one of the first things we try and check. From a developer’s point of view, we always try and develop for the core experience first, and then progressively enhance up, adding more and more features. It works really well with the agile methodology, where you want to start with the minimum viable product and then work your way up.

Testing with responsive is really, really difficult.

But testing with responsive is really, really difficult. We do have some helping hands; we do automate some of our visual regression. We have an open source tool called Wraith, which is available on our GitHub page, and that basically takes snapshots of the site at different viewports, so we can set it running at smartphone, at tablet, at desktop, and we can run it against all of our different World Service sites, and across all different pages.

Basically what it does is it hits the live sites and then it hits your sandbox, or your development machine, so we can very quickly see any diffs. What it’s doing is getting the two snapshots and then using ImageMagick to diff the two images together. So, anything that’s different will come up bright blue on the image. We’ve found that that’s cut out a lot of manual testing we’ve had to do previously.

You know how easy it is to just get a CSS bug—it’s too easy. So, this has kind of allowed us to keep releasing quickly while still going through the hundreds and hundreds of different permutations of widths, sites, and page types. So, that’s worked really well for us.

The problem that we had was when we got integrated with the wider business. Then you get into performance creep, basically, where slowly things get added.

Ethan:

That’s brilliant. The other thing I’d like to ask about is performance. I know the BBC has been very vocal about how it was important not to just make this site responsive and flexible, but also to make it incredibly fast, and I think you’ve done that. Can you talk a little bit about how BBC News defines and evaluates performance in general?

John:

Sure. At the beginning of the project—at the beginning of any project—performance is really easy. You’ve got complete control over your stack. You can drip feed in features and make sure that everybody is aligned with your performance goals.

But I think the problem that we had was when we got integrated with the wider business, and you have third-party components; you’ve got components from other teams. Then you get into performance creep, basically, where slowly things get added. More page weight gets added, more blocking script, and then, of course, adverts for us. So for the UK site, we don’t have any adverts, and then we release to our international version, and obviously we have three adverts on the page. So, that hit us quite a lot.

We’re measuring our competitors, we’re making sure that we’ve got prioritized lists of things we can do to improve our performance.

I think we did a good job of it in the first couple of years. I think that we’ve now gotten to a point where we’re about to start a performance spike—this week, in fact—where we’re just kind of aligning ourselves again of what we’re trying to achieve and get the performance budget communicated across the technical teams, and also the product team, to try and find out how fast do we need to be.

The organization needs to really buy into performance, and I think we’re now at the point where that’s happened.

Basically, we’re measuring our competitors, we’re making sure that we’ve got prioritized lists of things we can do to improve our performance. But it’s big things, like our advertising is blocking JavaScript, and that’s in a different team from BBC News. So, it’s kind of making sure that we’ve got the facts in front of us to make sure that we can fix these problems.

But the organization needs to really buy into performance, and I think we’re now at the point where that’s happened. But it’s always a balance against new features—new features are getting added all the time—but when we get to the point where we realize the site is becoming slow, it’s making sure that it gets prioritized against shiny new features.

I wish we would’ve had a performance budget that basically alarmed and broke our build when we went over a certain size of the page.

Karen:

I have to believe that anybody who is embarking on a large-scale responsive redesign would love to have you two guys on speed-dial to ask every question that comes up in going through a process like this. Do you have any advice for people who are maybe just getting started on this journey, or perhaps mistakes that you’ve made along the way that you would warn somebody against making?

John:

Yeah, just following up from the performance thing: I wish we would’ve had a performance budget that basically alarmed and broke our build when we went over a certain size of the page and if the page load was too high. I think we could’ve done a better job of that.

Mobile-first is great, but it does leave the big, complex decisions until later in the life cycle of the project.

And also making sure that we start integrating things like advertising far earlier in the process, because I think that really bit us. And mobile-first is great, but it does leave the big, complex decisions until later in the life cycle of the project. So, for example, IE8 and IE9, advertising—all of these things didn’t come up at the beginning, and I think that slowed the process towards the end. From my perspective, they’re the two big things.

The pattern library for us in the last year has just been a godsend and it has really accelerated every aspect of the development of the site. If I could start from scratch again, I’d start by building the library first.

Niko:

I think from a product perspective, I would say be really clear on your vision. Before you even start building, think about how the whole process is going to work. The pattern library for us in the last year has just been a godsend and it has really accelerated every aspect of the development of the site. If I could start from scratch again, I’d start by building the library first.

And be really clear on your IA and your requirements. I think in order to build a great product, you just have to really honor that vision that you have. In terms of managing stakeholder requests, you’ve got to be pretty firm to achieve that.

Ethan:

Well Niko, John, I wish we had another hour to talk to you guys, but it’s been an incredible half hour or so chatting with you both. It’s been amazing—simply amazing—watching the BBC News responsive site just grow over the last couple of years, and I’m really excited to see where it goes next.

Niko:

Thank you. We are, too.

John:

Yeah. Cheers.

Karen:

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

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 also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

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.

Thanks for listening, and we’ll be back next week.