Episode Transcript

Karen:

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

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, we are so excited, we are like a bouncing ball. We are here today to talk to Al Jones and Joe Walker who are coming to us from BBC Design & Engineering to talk about BBC Sport. Welcome.

Al:

How’s it going? Thanks for having us. Yeah, I’m Al.

Joe:

I’m Joe.

Al:

Our accents are kind of different enough I think, so hopefully you’ll pick up the difference. But yeah, thanks for having us.

Karen:

It is really a delight to have you here, and, of course, we love your accents.

Al:

[laughs] Good. Love or hate sort of thing. So, hopefully people will like it.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, GatherContent. GatherContent is a wonderful content collaboration platform that helps teams plan, organize and produce all of their web content in one place. And on December 8th, they’re offering a free online master class—that’s right, free! And online! Regardless of whether you’re part of an in-house team or working at an agency, this class will help you with your content strategy and delivery.

Gather Content’s free online class will take place on Thursday December 8th, at 4pm UK time. If that sounds like it’s up your alley, visit gathercontent.com/masterclass to register, and thanks again to them for sponsoring.

Karen:

So, perhaps we could start off with both of you just introducing yourselves, tell us a little bit about the work that you do with BBC Design & Engineering, and maybe give us a little bit of context around the work that you’ve been doing with BBC Sport. Al, you want to go first?

Al:

Yeah, sure. So, I’ve been at the BBC for about four years now, and over that time I’ve worked on BBC Sport and our live experience that goes with that, and then the last year or two I’ve been working within GEL, our Global Experience Language. So yeah, I’m a designer here at the BBC, although typically I wouldn’t say I just do design work, and Joe would say the same about yourself, being a developer. One of the key things over the last four years has all been about how collaboration—how we’ve changed—and I think responsive web design has been a massive catalyst for that. But yeah, so I do design, yeah.

Joe:

Yeah, so, hi, I’m Joe Walker, I’m a front-end developer within BBC Sport, in Design & Engineering. I’ve been on the team just coming up on three years now, which coincides with kind of the start of BBC Sport’s journey into responsive, working alongside Al and many other designers that we have on our team, working alongside product owners and editorial, not just writing the code but looking at the user experience and how we actually roll out our responsive offering to the audience.

Karen:

Well, let me follow up on that and ask if you could talk about the role that responsive design played in your plans for BBC Sport. Were there any questions or concerns about responsive, whether that might be the right direction to go?

Al:

Well actually when I first joined the team, it was just after the Olympics in 2012, and at that time, about ten or twelve months previously there had been sort of a refresh on the sort of brand of Sport. For people in England, you’ll probably remember that Sport used to be kind of a red experience, and then it turned yellow in February of 2012. But anyway, the point is there was some work done to create experiences for the Olympics. So, like a mobile site at the time, and a mobile app as well. And then as soon as the Olympics was finished, it was a matter of taking that first mobile proposition and seeing how it could be expanded. But it was responsive from the get-go, but it was about taking what was a desktop site and turning it into one codebase. That was the key aim.

Joe:

Yeah, so initially we had a longstanding m-dot website and a long-standing desktop website. The mobile site was very much a stripped down offering compared to the desktop website. But as the BBC News started rolling out their responsive offering, I think product owners and editorial people started to see the benefit of responsive. That’s what really started kicking off our look into responsive, was the Winter Olympics of 2013, because that was seen as a good, new place to start looking at how we could create responsive medals tables, schedules, home page for Sochi 2013.

Al:

Yeah. But I think as well it was because—so a lot of the audience are obviously looking at our football scores, stats, and results and things, and that typically happens on a Saturday, and I think we started to notice that traffic was starting to lead from a mobile proposition instead of our typical desktop uses. So it was like, “We have to do something about this.” That was one of the key aspects, and that rolled back on from the Olympics back then. And as well the way we started to think about it was in terms of our key events. So, looking back to 2013 to 2014 and the last couple of years we’ve had in sport that we’ve centered things around, events, these kind of immovable things in the timeline that we have to provide for. And so it also gives you that impetus to roll out lots of things, including the responsive rollout, etc.

Ethan:

You mentioned the phrase “mobile proposition” and “desktop” a couple times, so I’d love to hear a little bit more about how you think about those two different contexts of use. When you’re planning a new product or new feature, how do you talk about the needs of the mobile user versus the desktop user? Do they effectively need the same information? Do they need dramatically different things depending on the device? Tell me a little bit more about that.

Al:

Obviously it’s been a real learning exercise over the last few years, once we’ve gotten onto that single codebase, really understanding how to provide content. Because I think, whether it was an assumption or whether we believed it, but we’ve always thought content should be the same everywhere. But it’s been difficult trying to understand context.

Joe:

Yeah, so one of the biggest things from our stakeholders has always been can we achieve feature parity with our current desktop offering on our new responsive offering? Which is something we’ve tried to do as much as we can, but obviously sometimes we have to let things go, and hopefully the users won’t really miss them too much. So yes, I think we need to kind of strip it back sometimes on mobile, but not too much, and hopefully give the users everything they require, because looking at the stats on the weekend now, we’re getting nearly eighty percent of our traffic on mobile, tablet devices.

Al:

That’s something I find quite difficult. We try and do things not just for one website or product, but for lots of them, such as News and iPlayer and so on. But each product has a completely different audience in some ways, so different personas that we design against. Our rules around same content everywhere and that consistency in form is a real challenge, especially for where there’s context. So, people are out and about, they want to see their scores on a Saturday, and how you might adjust the experience accordingly, that’s something we’re still getting to grips with a bit—and I think a lot of people are; around the industry, I think that’s something that’s a real challenge. It’s been difficult getting things consistent everywhere on one codebase. But then it’s how can you really cater for people in the right circumstance? So if someone’s watching EastEnders on the train as opposed to being at home, it’s things to do with performance that’s a really interesting factor for that.

Karen:

Tell me a little bit about how you plan and scope a project of this magnitude. How do you figure out all the things that you need to do, and how long they’re going to take, and what you should do and what you shouldn’t do?

Joe:

So I think from the very beginning, our strategy has always been kind of, component by component, how do we make our website responsive? Because BBC Sport is, by its nature, a huge beast. It’s not your typical website, it’s probably the most complicated website the BBC has. In the past, our stakeholders have been very worried about changing things for the users and the users getting upset about that, because we have a large core user base, around eighty million people a day that are coming back and using our service, so we don’t want to affect their use of it and we don’t want to upset them.

So how can we roll out a responsive website without actually affecting the audience too much? How we managed to do that was doing that on a component-by-component basis, generally releasing on the m-dot site first, and then once we feel like it’s got enough feature parity or we’ve tested with users and they’re happy, that’s when we release onto the desktop platform as well.

Al:

Yeah, I’d echo that, and it’s that remit, that we wanted to roll out the responsive offering feature by feature or component by component, I think it was great. Because you know that you’re trying to have that parity, you’re just trying to merge both sites together so that no one really notices it’s happened, and I think that’s a really clever way of doing it, because it gives you that affordance and time to learn.

Responsive web design, for us—since your article, Ethan, what, six years ago now—it’s been a learning exercise, really. So to suddenly do a big bang launch or a big splash change… And whilst it could have worked as well and it does work for some people, I don’t think the risk on the audience was worth it. We have a lot of people who come and they need their certain content, and being a public broadcaster, it’s like we have something to uphold there, where we want to make sure that people get their stuff when they want it and when they need it. So although it’s been tricky, it’s worked quite well, I think.

Ethan:

You’ve both mentioned components a number of times. I’d love to hear a little bit more about how that played into the design process for the BBC Sport work. You’ve both mentioned that there’s work with GEL happening here. Could you maybe talk a little bit about GEL, what it is and how you actually work with it?

Al:

Yeah, so just for people who don’t know, GEL’s been around since about 2010. It was probably the first or one of the first online pattern libraries as such, or online style guides. Yeah, so GEL, our Global Experience Language, is the BBC shared design framework, it enables us to create consistent and delightful experiences across all of the BBC. So, it’s not just for Sport, it’s for everywhere and it’s for everyone. So, it plays a big part in how we deliver a lot of the front-end of any of the responsive sites or apps. So in Sport, one of the key aspects of the Sport responsive codebase is our GEL foundations, which is our grid, our typography, and iconography. This foundation is the foundation to pretty much any component on the site—well, all of the components. So, a really good example is when Joe and I worked together to build, from the very beginning, a reusable component that’s now still be reused today, and how old is it now…? Three years old, nearly?

Joe:

2014.

Al:

Okay, so this was for the 2014 World Cup, and we worked on like a scores component.

Joe:

What you’d call a bracket in America. It’s like a wall chart.

Al:

Yeah, so when you have a big tournament coming up, I don’t know if you have this in America, but typically over here you kind of print out a wall chart, and you put it on your wall and then you’d fill it in on the wall as the tournament happens, pretty much. We do that here, and we wanted to create an online version of this, and that was sort of the catalyst for doing this scores component. Joe, I don’t know if you want to talk about how that became a reusable thing.

Joe:

Yeah, so I think that was probably the first responsive thing that we did around football and football data. Initially our product owners were very much, “This is a one-off piece. How do we make it essentially before this deadline?” But as a team, we wanted to work together to make it as reusable as possible, so we have really small components in there, like a head-to-head fixture where it says team name, team name, and a score, or a time. This is something that we then abstracted out to make reusable. Things like table patterns that you’d see everywhere on a website, we abstract these out to make them reusable. And still, to this day, we’re probably ten, fifteen sports into our responsive project looking at sports data and we’re still using the same patterns now. This all comes from reusability and the strength of GEL that gives us the typography and grid to use as a platform for that reusability.

Al:

Yeah, I think what’s important is that there’s these—often with design, we think of some of the big things and try reuse them. The classic example here at the BBC is like a carousel, and we’re like, okay, let’s make a responsive carousel and let’s make it reusable. But the thing is, the way that I look at it is the reuse factor of that is actually pretty small, whereas the reuse factor of some type and how we do that is massive. And so it’s establishing that reuse factor and then plowing your effort into that early on, which I think we did pretty well.

Joe:

Yeah, it’s now a foundational CSS framework that was built out of the sport codebase, which now allows us to add typography, or space, or grid to any responsive component, and this is now a reusable thing that teams in our News department or Children’s department are now using on their websites.

Al:

I think, yeah, like twenty-one teams have reused that stuff—our GEL foundations, anyway—which is massive, so. Yeah, it saves so much time. We’ve got more time to innovate on more exciting things—not that grid and type aren’t exciting for the people out there who love that stuff, because I love that stuff. But when we know it has to be done in a certain way, then it means we can get it done quickly and then move on to some other stuff.

Ethan:

Could you tell me a little bit about the process that you use internally to figure out when a pattern is seen as valuable enough to be promoted into GEL? How do you actually balance the day-to-day deliverables that you have to make, the day-to-day design needs that you have, working on specific one-off patterns, and how do you see something that you know is valuable potentially to other teams at BBC, and what’s the process for actually ratifying something so that it lands in GEL?

Al:

To be honest, that’s a process that we’re still wrangling with, because it’s a real challenge being able to have all these products across the BBC with separate teams where you have different design patterns and you want to sort of bring them together so that more people can benefit from them. That’s something that’s really challenging. So, some patterns will just be used in one product and they might stay there, but if that’s got potential to be useful for another product, then we want to make sure that people don’t have to do the same design thinking on it again. So we’ve got a few processes as part of GEL, and we’re still trying to make them work and it’s a constant challenge.

But one is where we bring together different designers and developers from around the BBC and we create what we call a task force around that. So in something like Spotify, they might call this a sort of squad mentality, I suppose, where you come together and you swarm on a challenge all together from different products, different inputs from your various audiences, and try to come up with one agreement. Then we know that we’ve got some certainties. But yeah, it’s a real challenge, one that we’re trying to tweak all the time. Whereas some of the foundational things, like the grid and type and iconography, they’re a little bit easier to rationalize and keep consistent.

Joe:

But teams can suggest improvements to those patterns, they’re constantly moving, they’re an agile thing, they’re not set in stone, and if a product thinks that they can improve it or add to it, that’s there for them to…

Al:

Yeah, that’s a good point, because one thing I should say is that GEL used to be a central team of a few people where they would create content or guidelines—rules, if you like—and then expect the whole of the BBC to then use those rules. But we’ve flipped that model on its head, and so now everyone external to GEL contributes into GEL, and it’s really flipping the whole pattern library model completely on its head because we found it just didn’t work.

Joe:

Yeah, it’s not a dictatorship, it’s everyone working collaboratively together to come up with a set of guidelines that can work across all products. But if you have a unique use case, I think that’s fine, but let all the teams understand what’s going on.

Ethan:

That’s brilliant. Well, let me just ask one last process question, which is, given how component-focused your work has been over the last few years, what kind of applications and tools are you using on a daily basis to do design work? Do you still find there’s a value in more traditional tools, like Photoshop and Sketch and Illustrator? Is it much more prototype-focused? Tell me a little bit about that.

Joe:

At the beginning when I joined the BBC, it was kind of big one-off pieces and it was very Photoshop/Illustrator heavy. But the more we’ve built out the foundation and GEL code that we’ve just been talking about, it has really helped us to be more browser-first, design in the browser, creating quick prototypes, allowing designers to actually code up their own designs, working alongside developers from the very beginning, trying to work in the kind of lean sprints, not try to tackle too much at once…

Al:

The way I see it is it’s one that I could answer differently every single day depending on who I’m talking about. But our designers and developers here—and it’s a great thing, the skill sets are on a massive spectrum, which is brilliant because it’s diverse, so some people will be okay with coding and getting into GitHub that they don’t even need to prototype it, they can just create like a branch. But then down at the other end of the spectrum, the skills would be different, so there’ll be a different scenario that has to kind of materialize to collaborate, right? So me and you, Joe, we actually pair in the browser and share a Sketch pattern and it’ll be quick, but in another world it might be slightly adjusted. But personally I still see the value of Photoshop and Sketch, it’s massive, but not necessarily in the build process but more if you’re thinking about some conceptual stuff. Because for me, Illustrator is so much faster than the browser. But that’s just me.

Joe:

Yeah, I think for the idea generation and working together, I think where it becomes a problem in the traditional sense of printing it off, putting it on a wall, getting sign-off from stakeholders, I feel like that’s where we’ve kind of come away from—with more presenting something in the browser, hopefully using real data as well, so we can actually see how it’s going to work in the real world.

Al:

Yeah, here was a point everywhere where you were almost creating an oil painting of a website a long time ago, and although it might look nice, it’s just too far from reality. For us, it’s just getting either time-to-prototype or time-to-browser reduced, right?

Joe:

Yeah, and the best results I’ve seen is when you go to a stakeholder meeting and you pass them a phone, or give them a tablet, or you just send them a URL and they start just playing with it. You normally get better feedback than just looking at a picture of a desktop website.

Al:

It also goes hand-in-hand like when we research with our audience, is that rather than sort of hitting hotspots on a JPEG, a pretend browser or whatever, it’ll be actually playing with the real thing, focusing using an actual anchor link—things like that make a massive difference.

Joe:

I think the content makes a big difference, especially when you’re doing user research or lab testing. I’ve seen lab tests where they’re looking at a JPEG and the headlines or stories are a couple of days old, and they’re just questioning the content, they’re not looking at the design or the interaction.

Al:

Yeah, they’re seeing the seams, aren’t they?

Joe:

Yeah, they’re seeing the problem with it. Whereas if we’re using more up to date things…

Karen:

Let me jump right in on that and ask, how does the content play into either the development of the design system or your plans for how you execute a responsive design as a whole? How are you considering the different sizes, the different editorial formats, and what’s actually going to be there?

Al:

That’s a great question, because that was massive early on—well, it still is, but it played a huge part in just coming up with, well, first of all it was just coming up with a hierarchy of our mobile, the smaller screens. We started small, we started, as we like to call it, minimal-first. And yeah, with our journalists here in Sport, the people actually writing the content, we did workshops to work out that hierarchy, didn’t we? The order, just simply one-two-three-four is components and then how they would build up.

Joe:

Yeah, and just simple things on like headline length, body copy length, that type of content. If they’re going to write four-line-long headlines for the home page that breaks our design, we need to know about that and cater for that in our design and build. There’s no reason why we shouldn’t. We have data providers that provide a lot of our football scores or cricket scores, rugby scores. We have to analyze that data how it comes to us and make sure that we design around it and we understand how it’s going to work in the real world.

Al:

Our top stories, for instance, that everyone sees when they first come to the Sport site, we want parity over the amount of stories that are shown, whether it’s five, ten, fifteen, and making sure that’s clear that you see the same amount of stories on mobile as you might on desktop. So yeah, just starting from a concept-first perspective with that was really important, and just forgetting about everything else allowed us to see the wood for the trees, you know?

Karen:

Let me ask if there’s any consideration that you had to put into advertising in a responsive framework.

Joe:

In the UK, we don’t show adverts. But outside of the UK, we do show adverts. So, it’s a really hard use case to design for, especially on our Sport home page or football home page, so we kind of have to build it once but design it twice and make sure that ad slots are available. I don’t know if that’s the right word.

Al:

Yeah, the way ads work for our worldwide audience and non-UK is it’s very familiar to what you would have seen on the web—like, it comes from the desktop era and that’s not really changed, it’s kind of like a fixed ad slot that we have to fit into a fluid solution. So, it’s like mixing oil with water. Maybe we should just end it there. [laughs] But it’s a challenge because it’s really tricky, because we have to have those slots. But that was a challenge, and I think, looking at other sites like The Guardian, that’s where they’ve done some really interesting stuff with their ads on their responsive site, and it’s something that I think probably in the future we would deal more with and improve on.

Joe:

Yeah, the BBC’s quite rare in that we have to design it to make sure it works for the UK audience that never see adverts and for the audience outside of the UK that will see adverts. And because the majority of our audience is in the UK, we want to make sure that the site looks its best when there’s no adverts there.

Al:

Yeah, rather than just having holes.

Joe:

Yeah, so we don’t just leave massive holes. So if you had an adblocker on other sites, you’d potentially have holes on the website, or big gaps. But obviously we don’t want that for our UK audience, so we have to make sure that it works okay, and it is a big design challenge.

Ethan:

Speaking of big design problems, I’d love to hear a little bit more about performance. I know this is something that a lot of folks at the BBC have been speaking about, not just how these responsive layouts look but how quickly they’re accessible. Is that something that you have had to factor in for BBC Sport or for GEL?

Al:

Obviously if people listening to this go and listen to the BBC News podcast that you did, because that gives insight into the “cut the mustard” test, which BBC Sport very much adopted from News—or rather industry has adopted—and so that’s why we provide a core experience to people who don’t “cut the mustard,” meaning they don’t pass our capability tests. So, there are things like feature phones and really old smartphones, and IE7 for instance. Whereas people that do cut the mustard, pass the capability test, get our responsive site where we give more stuff. But the example of performance with Sochi and our indexes of the lazy loading is quite a good example.

Joe:

Yeah, performance is always at the forefront of everything that we do. However, sometimes it does get missed and does end up not being at the top of the priority list mainly because of pressures around deadlines, around big events, stakeholders’ priority of features over performance. But in the last two to three months, we’ve tried to flip that on its head. So whenever we’d look at a new feature, we tried to set an objective around performance and make that become not creating this feature without hitting that objective. Our next big project that we’re working on is around football, and we’ve set performance as the top objective for that to make sure that it doesn’t get missed and it doesn’t get down the order. I think this happens quite a lot in the industry, where features become prioritized over performance.

Al:

Yeah, it’s like performance in plain terms, like literally the load time, like what the weight of the site is, but then there’s performance as a perceptive thing as well, which is something I don’t think we’ve even started to tackle. One example of that is, so with Instagram for instance, as soon as you say you want to upload a photo, like when you actually sort of select a photo, they start uploading it at that moment rather than when you hit “share,” and that perception is interesting.

Joe:

We are kind of bound by certain things within the BBC which affects our performance. I think the News podcast went into it in more detail. But it’s something that we’re trying to tackle by communicating with wider teams within the BBC how big a problem performance is and how we should be focused on it as a business.

Al:

Yeah, and I think as well, with GEL, one thing that’s important is GEL is not all about how things look the same, and I think the perception with pattern libraries and style guides is it’s about how it looks—consistency and look. But actually it’s not about how it looks, it’s more about reusing some of the things beneath the surface and where you can find the most value, I think, and performance can come into that. We’ve not really talked on the web about performance patterns, that’s not something that’s really abundant, I don’t think, and that’d be interesting to see how that evolves in the next year or two.

Karen:

Well as we’re coming to the end of our time here, I bet everybody that’s listening would love to get a little bit of advice from you all. Do you have any things you learned, lessons that you’ve learned the hard way that you’d like to share with our audience?

Al:

Personally I think collaboration is the thing for me. It’s all around pairing with people in your team and just talking. If you think you’re doing agile, just really question it and think, “Are we collaborating enough? Are we sitting side by side and discussing things every step along the way?” It’s all about that transparency, and I think responsive web design in particular has been a catalyst for showing the seams if it’s not working, because you get an experience down the line that comes out Because it’s not just one thing that you’re looking at, it needs to be across every single device available and still be great. It’s that collaboration.

Joe:

Mine is similar. Communication across teams, but also with stakeholders as early as you can, getting stakeholders involved from even the idea generation and even the user testing, user research. And then also communicating with the users about what do they see. They don’t really care about responsive design, they just want a good website, good interaction. So, it’s best communicating with them from the very beginning.

Al:

That’s massive, yeah. I think we’ve still got loads to learn, and across the last few years the people at the BBC have been amazing. There are so many amazing colleagues here and we still find it difficult. If people find it hard out there if you’re working for a small company or you’re doing your own site, it is hard, it’s meant to be. I think we’re still in those early stages. The web’s not that old, really, and there’s stuff we’re still getting to grips with, so. But hopefully that’s helpful. [laughs]

Ethan:

Well, as somebody who’s still getting to grips with the web on a daily basis, those are perfect words to end on.

Al:

Yeah, including Skype. [laughs] But yeah.

Ethan:

[laughs] Al, Joe, this has been wonderful. The work you’re doing at BBC Sport and at BBC Design & Engineering is straight up inspirational, and we can’t thank you enough for taking a few minutes to chat with us about it.

Al:

Thank you very much.

Joe:

Cheers, thank you.

Karen:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. Thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process.

If your company wants to go responsive but you need help getting started, Ethan and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more and let us know your company is interested.

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.