I’m Ashley Nolan. I’m a Creative Technologist working at TMW, a digital agency based in London. A slightly less catchy, but maybe more descriptive title for this talk would be something like ‘What I learnt as the lead front-end developer on the BBC Good Food responsive redesign.’ What I want to cover today in my talk will obviously relate pretty directly to the Good Food site, but what I want to really highlight are the main things I learned from building such a large scale responsive site, what we did well and not so well, and how that can feed into any project of any size, not just large scale builds such as this one. So hopefully some of what we learned on the project can help you make decisions in the future on projects you do.
as the lead front-end developer on the BBC Good Food responsive redesign) Sunday, 13 October 13 Hi, I’m Ashley Nolan. I’m a Creative Technologist working at TMW, a digital agency based in London. A slightly less catchy, but maybe more descriptive title for this talk would be something like ‘What I learnt as the lead front-end developer on the BBC Good Food responsive redesign.’ What I want to cover today in my talk will obviously relate pretty directly to the Good Food site, but what I want to really highlight are the main things I learned from building such a large scale responsive site, what we did well and not so well, and how that can feed into any project of any size, not just large scale builds such as this one. So hopefully some of what we learned on the project can help you make decisions in the future on projects you do.
I have been working on was the redevelopment of the BBC Good Food site, which is a very large cookery website owned by BBC Worldwide. So, for those who don’t know, BBC Good Food is one of the most trafficked food sites in the UK, with anywhere between 7 to 8 and a half million unique visits every month depending on the time of year. (30+ million page views) The first thing that I know I thought when we started pitching for the project was why do BBC need to work with an agency on a responsive redesign when they have so much great responsive work being done by other BBC properties such as BBC Sport and BBC News.
BBC Worldwide, who own BBC Good food, isn’t exactly the same as the BBC itself. BBC Worldwide is the main commercial arm of the BBC - it actually helps fund the work of the BBC through it’s revenue, and takes care of BBC brands such as Top Gear, Doctor who and BBC Good Food. Now because BBC Worldwide is a commercial company, if BBC were to share knowledge and resources with Worldwide, it would be seen as giving it an unfair competitive advantage, and so would then need to make this information publicly available to other companies such as ITV, Channel 4 and Sky, which it obviously doesn’t want to do. Therefore this was actually BBC Worldwide’s first responsive rebuild, and is why TMW were involved in helping them make decisions on the best way forward for the redesign of BBC Good Food, and how I came to be the lead front end developer on the site.
realised when making the slides for this talk that it was the 3rd of May last year that I started on the Good Food project - and back then responsive design was still pretty fresh as a concept. There were a few sites around being held up as great examples, such as the Boston Globe, but most of the sites being made were smaller blog sized sites, and not many of the big sites on the web had really taken the plunge with responsive. That meant it was a little bit daunting in terms of what we were going to do, as we were doing what a lot of other companies were going through at the time - making best guesses when it came to solving the problems responsive design threw at us.
first big call we had to make before anything else was whether or not the site should even be responsive. The main thing that made us pursue responsive was that we couldn’t see any major negatives pursuing a responsive design approach - but there were some major positives - one codebase, very flexible in terms of device support, extra time, but we didn’t think as much time as developing and maintaining 2 different sites. People who use BBC Good Food want exactly the same information whether they are looking at the site on a mobile device or a desktop, and in fact, a huge percentage of Good Food’s audience use devices to view the site, and a large amount of those are tablet users (using their tablet while they cook), so it absolutely made sense to be optimised for any potential device width with one eye on the future.
anyone who hasn’t seen the site previously, this is what the site used to look like. A typical recipe page on the old site. This look and feel was a very slight variation on first incarnation of the Good Food site, launched back in November 2006, so the design as you would probably expect was starting to age more than a little bit.
proportion of the sites traffic comes directly through search engines, as the site comes pretty high for cookery related searches. So the typical user flow would be something like along the lines of this: You’d type in your search term, find your way to BBC Good Food, find the recipe you want and your journey stops there. So one of the other goals was to try and hold onto more traffic by offering more linked content. The site also has a tonne of editorial content that goes into the site on healthy eating and general cookery tips that never really got the attention it deserved because it wasn’t surfaced very well.
proportion of the sites traffic comes directly through search engines, as the site comes pretty high for cookery related searches. So the typical user flow would be something like along the lines of this: You’d type in your search term, find your way to BBC Good Food, find the recipe you want and your journey stops there. So one of the other goals was to try and hold onto more traffic by offering more linked content. The site also has a tonne of editorial content that goes into the site on healthy eating and general cookery tips that never really got the attention it deserved because it wasn’t surfaced very well.
FOOD Search for recipes Store/Save recipes to their profile Cook recipes Sunday, 13 October 13 The key goals of the site were to be able to provide users a way to search, store and cook recipes. Some of these areas such as search didn’t really have any amazing examples in responsive design, so one of the things we decided to put our efforts into early was identifying the key areas and then to sketch and prototype those key aspects. So to show you the type of stuff we did, I’ll go through how we approached the design.
CREDIT @LUKEW Sunday, 13 October 13 One of the things we did from the outset on GoodFood was to make sure for important interactions on the site, we researched the area well before we started designing ourselves.
13 October 13 One thing that I found useful personally was reading about how interaction is defined natively on different devices. So an example of this is the touch interaction design guidelines that Microsoft have made in relation to their apps. Although these type of guidelines don’t directly relate to the web but to app’s, it’s a good idea to keep on top of what devices are doing natively as this can inspire the work we do when designing patterns - and this is definitely true of the early responsive patterns that emerged.
I think is quite interesting is on 'This Is Responsive', which is a responsive pattern library maintained by Brad Frost - I’m sure all of you have seen it, but if you haven't, definitely check it out. It's got a whole load of material aimed at helping anyone who wants to start creating responsive websites. Brad says on the site that one of his most frequently asked questions is: "How does ______ work in a responsive design?" So you could substitute the gap here for, carousels, tabs, accordions, search…any number of things. ...and I think this was one of the biggest problems I had when starting out with modules in responsive design - I was always thinking about the things I already knew, and trying to adapt them. So we find ourselves taking a fixed width interaction pattern that might not be inherently responsive, and trying to mould them to work responsively.
I think is quite interesting is on 'This Is Responsive', which is a responsive pattern library maintained by Brad Frost - I’m sure all of you have seen it, but if you haven't, definitely check it out. It's got a whole load of material aimed at helping anyone who wants to start creating responsive websites. Brad says on the site that one of his most frequently asked questions is: "How does ______ work in a responsive design?" So you could substitute the gap here for, carousels, tabs, accordions, search…any number of things. ...and I think this was one of the biggest problems I had when starting out with modules in responsive design - I was always thinking about the things I already knew, and trying to adapt them. So we find ourselves taking a fixed width interaction pattern that might not be inherently responsive, and trying to mould them to work responsively.
I make a carousel work responsively across all device widths... Sunday, 13 October 13 So on Good Food, rather than thinking 'we need a carousel, how do I make a carousel work responsively across all device widths' , it was really useful to think about the problem across device widths and apply suitable interaction solutions.
I make a carousel work responsively across all device widths... I need to display a list of images, how do I make a list of images display responsively across all device widths... Sunday, 13 October 13 'I need to show a list of images, how do I display a list of images responsively across all device widths' If that question results in you answering that you need a carousel across all widths to do this, then go ahead and implement it. But by looking at the problem, you can step back and design the most suitable way of displaying that list of images.
area this was especially true was for search filters. These are still an interaction that not many responsive sites have to deal with, but for us it was one of the most crucial areas as searching for recipes was really important, irrespective of the device. The main problem was surfacing the vast number of ways you can filter your search without it feeling ridiculously cumbersome.
solutions that have come before us SCALING RESPONSIVELY Sunday, 13 October 13 So we split it up: (and we did this for all of our major interactions on the site, not just search) And this can be done for any interaction pattern you are looking to implement. - Look at the solutions that had come before us - mobile apps, mobile specific websites, or even how successful websites (that are non responsive) were using search filters - Mobile app's are pretty ballsy - take inspiration from them (instagram)
solutions that have come before us Look at emerging responsive patterns SCALING RESPONSIVELY Sunday, 13 October 13 Look at emerging responsive patterns - we looked at how people were solving problems in responsive, not necessarily related to search filters, but that could help influence the design
solutions that have come before us Look at emerging responsive patterns Sketch (and prototype too if you have the time) SCALING RESPONSIVELY Sunday, 13 October 13 Sketch - We sketched out lots of possible ways to solve the problem
13 The sketching really helped us get away from getting too attached to ideas until we wanted to flesh them out. Prototyping was also pretty invaluable. For example, there were a couple of occasions early in the design of the project where we thought we’d come up with a pattern that worked brilliantly visually, but when we actually put together a simple prototype and started using it, we found that it didn’t feel quite right on different devices.
October 13 Doing this mobile first actually influenced how we presented filtering at wider views, as we kept the same principles of the quick and advanced filters and how they were displayed across both.
October 13 Another technique that we used, and that's become popular in responsive design, is interchanging components at different break points, while running off the same markup. The benefit of doing this is that while it may be a bit of overhead when you start to build these patterns, they can be built to be reusable across projects. So to give a couple of examples...
Sunday, 13 October 13 A carousel might be the right solution for wider views, but maybe it would be better to simply have a show/hide toggle of the pictures on narrow views. ...and this is what we implemented on Good Food for this
SCALING RESPONSIVELY Sunday, 13 October 13 Tabs are inherently floored at smaller widths - when the screen gets narrow and you have a number of tabs, then you start to have problems. But this doesn't mean we can't use them - after all the they are a tried and tested interaction pattern from the days of fixed width sites? So instead of scrapping them, we can evolve them into a responsive solution. At small widths the tab headers could be represented in a select list, or perhaps as an accordion. This is something we are using on the BBC Good Food website, and we set a data attribute to choose which component will be used at narrower widths.
13 A more custom pattern on Good Food is our implementation of off screen navigation. So we have a mega dropdown on larger widths, that translates to an offscreen navigation on narrower devices.
CREDIT HTTP://4.BP.BLOGSPOT.COM/-BV2OHXGZ4W0/UJ-LFKKNANI/AAAAAAAABIW/QIQYUY-TMVI/S1600/2-PINNACLE.JPG Sunday, 13 October 13 Aside from the responsive aspect of the project, I want to also talk about a couple of the biggest things I learned working on the project in terms of it being such a large scale architecture. For me personally, it was what it was like working on a build of such a massive scale. So before working on Good Food, I’d been a web developer for around 7 years, and had been lucky enough to work on some great projects, but in all due respect to the size of those projects, the size was nothing in terms of the traffic and profile that BBC Good Food is. I mean, I mentioned it to one of my best friends at the time, and I distinctly remember her saying to me ‘whatever you do, don’t mess it up, because I use that site all the time’. So, I think for the first few days after I knew I would be working on the project, if I could visualise my thoughts they would probably have looked something along the lines of this:
overwhelming it can seem at first working on a build of such a large scale. It had always been a massive goal of mine to work on a project that is genuinely seen by millions of people on the web, and like anyone who gets that opportunity, it’s both massively exciting and scary at the same time. I was leading the front end for the project and at the end of it, the decisions I made would help decide if the project would be classed as a success or failure.
think as the project goes on, you realise that as long as you have done your research and can back up your own decisions with good reasoning of why you have done it a certain way, you have to have faith in our own convictions. The pace of change is so high in the work that we do, and especially in responsive web builds where we are still finding our way to the rights and wrongs, that you can’t beat yourself up too much if 6-12 months time the goalposts have moved slightly, and what you did before is no longer the defacto way of doing things. Make the changes that matter, but improve things that will make a difference, not just change for the sake of change.
thing that I realised as the project went on is that many of the tiny aspects that you can sometimes take for granted on smaller builds, really do affect a site as it scales. So the earlier on you get the right processes in place, the easier things become further down the line. This is especially true when making sure the structure of your code is properly planned out for reusability in the future. I think scaling the size of your workflow up in bigger projects, really does highlight any holes in your process and where things do start to fall over.
October 13 So for example, CSS architecture. I think that I have learned more about CSS architecture in the last year than I have since I started coding CSS. The main reason I learned so much?
quickly comes back to bite you - so just like when Ed Balls tweeted his own name, if he didn’t have thousands of people wanting him to fail, he’d totally have got away with it. Unfortunately, he’s an MP...
now there’s now a day on Twitter celebrating the fact that he cocked up. And that is what, in a very roundabout way, large scale CSS architecture is like. Things that you might take for granted, or pass off as a slight hack, on a small to medium sized site, which you’d totally get away with, you really won’t get away with on large scale builds.
Sunday, 13 October 13 SMACCS, by Jonathan Snook, has become pretty highly regarded in terms of CSS architecture, and I would highly recommend that if you haven’t read it, you go and do so. I read it earlier this year, and it highlighted so many of the issues I personally came up against when trying to make BBC Good Food as modular as I could, and I really do wish I’d read it 18 months ago to put more of it into practice.
of the things that we wanted to do in terms of how we set the project up was to make the site very consistent and modular, both in terms of the design and the CSS. So just looking at a few of the screens, you can see the similarities in how it’s been considered and this meant that the CSS needed to be designed fairly modular in nature so that things could potentially appear anywhere on the site.
of the things that we wanted to do in terms of how we set the project up was to make the site very consistent and modular, both in terms of the design and the CSS. So just looking at a few of the screens, you can see the similarities in how it’s been considered and this meant that the CSS needed to be designed fairly modular in nature so that things could potentially appear anywhere on the site.
SCALING RESPONSIVELY Sunday, 13 October 13 The other issue with CSS architecture on a large scale build is how you structure your media queries. Media query structure on a large scale build feels a bit like this to me. It does feel like you are having to battle to get a structure that works and it never really feels all that optimal.
worst things to happen to CSS structure Harry Roberts @csswizardry Sunday, 13 October 13 I do personally agree with Harry Roberts when he said that media queries were one of the worst things to happen to CSS structure. We used SASS on Good Food to structure our CSS which helped massively with this.
way we approached it on Good Food was to for smaller style changes, we would do these inline using a mixin to add the media queries. For any larger functionality, such as for navigation breakpoints, it quickly became really hard to keep it readable while doing it inline, and so we broke these larger chunks of functionality into separately included SASS files and grouped the media queries together within that. This worked well for us to keep the readability of CSS as we wanted, but I’m not saying this is by any means a definitive way of doing it - whatever makes it easy to read for your team is the correct way to do it on your project.
SCALING RESPONSIVELY HTTP://JAKEARCHIBALD.GITHUB.IO/SASS-IE/ Sunday, 13 October 13 Authoring CSS for old IE devices - http://jakearchibald.github.io/sass-ie/
SCALING RESPONSIVELY Sunday, 13 October 13 One thing I think on a big project that you need to accept is that it is almost impossible to make a file structure that is so obvious that someone new to the project will instantly know where everything is at a glance. You can make their lives a lot easier, but the best way to do this is come up with a system and document it well. Style guides can really help mitigate this, and give those new to the project a great way in in terms of learning and getting to grips with the workflow.
Sunday, 13 October 13 Probably one of the biggest things that I've learned going from smaller responsive builds to working on the Good Food website is just how important it is to really think about the interactions of your site at different widths. Getting the design to visually adapt across devices is only one of our aims - if the site is hard to use or we aren't considering device specific functionality to enhance our site, then chances are it won't be as easy to use as it could be. Before you delve into actually designing patterns, you should know the strengths of the devices you are designing your patterns for and leverage them if possible. You should equally be aware of their weaknesses.
13 So the first thing to make sure when dealing with touch devices is to make sure that you are handling touch events properly. So if you add a bunch of buttons to a page on mobile, and try and interact with them, the touch events by default will feel fairly unresponsive. This is down to browser waiting around 300ms between a tap and the firing of a click event. Using something like FastClick solves this for you, by firing the click event on touchEnd. If you’d rather you can roll your own event handlers to do this - it’s up to you.
jQuery.animate() Sunday, 13 October 13 Hopefully this should be pretty widely known, but I wouldn’t recommend using jQuery animations on mobile devices. It makes interactions look really badCSS3 does directly affect how the interactions feel. This statement should be a given for anyone working on responsive sites. Bad interaction, and especially glitchy interaction animations, can really kill an otherwise good responsive site. It can give the sense of the site being broken when it's not, it's just the interactions don't look right.
Bushell Sunday, 13 October 13 I’ve ripped these examples from an article Dave Bushell wrote on developing offscreen navigation, but these two profiles show the difference in what is processed when performing a jQuery animate compared with using CSS transitions, when opening and closing a navigation twice. In the diagram, yellow represents the JavaScript running, purple is the rendering (recalculating the style and layout), and green is the painting to the screen. On mobile, we’d be shooting way below that 30 FPS line, when ideally we’re looking at running at 60fps.
!== your friend Sunday, 13 October 13 position:fixed; on devices is not your friend either - I’d say only use it if you have time to debug random issues as it can have some random side effects on older devices.
October 13 For example, this is mashable’s mobile site. Theres a use case whereby fixed positioned elements when you start interacting with input boxes then decide to stick where they were on the screen when that input was interacted with. Use with caution. We actually have tried to use it on Good Food, but have had to implement some workarounds for certain interactions like this. It does look a bit clunky on older devices that pretend they support it but don’t really.
October 13 For example, this is mashable’s mobile site. Theres a use case whereby fixed positioned elements when you start interacting with input boxes then decide to stick where they were on the screen when that input was interacted with. Use with caution. We actually have tried to use it on Good Food, but have had to implement some workarounds for certain interactions like this. It does look a bit clunky on older devices that pretend they support it but don’t really.
RESPONSIVELY Sunday, 13 October 13 This is without doubt the thing I’m most ashamed of on the Good Food build. Basically, don’t do it. We only implemented with the intention of it only ever happening on resize - we wanted the server to handle any HTML differences. Unfortunately with the amount of caching and the inability to make holes in the cache to allow for this, the resizing solution became the solution, and it was too late to go back and change things by that time. This means on mobile, we have some repainting issues which aren’t ideal, and that the team are still trying to sort out. So in short - use flexbox if you need to move stuff and change the page flow, not javascript.
13 Ad’s are a complete pain in the ass basically. Good Food is mainly funded by it’s advertising, and so it is a necessary part of the site, however when we started the project, we spoke to advertisers, and they were basically pretending responsive design was a fad. Therefore, all we could do, was server up our best guess when the page loads, and then that ad can never change. This means you don’t get the right size ads at all devices, which looks bad and also doesn’t make the most of the opportunity to advertise on those devices, which is wasting potential click through revenue.
13 Performance is an area which I’ve always had to worry about, but like CSS architecture, never in quite as much detail as we had to on Good Food. I could probably do another talk on it’s own about performace, but the biggest tip I could give would be is that if you do a lot of the simple things well, that will be 90% of your performance worries taken care of. So optimising images, compressing and concatenating files, number of requests etc. Then using tools like YSlow and Chrome Page Speed Insights will really get you to a decent place without having to go absolutely overboard. The trickier parts of performance come down to CSS paints and really digging into your dev tools.
Hammann CSS and the critical path (audio soon to come online) Jake Archibald Rendering without lumpy bits http://vimeo.com/64733304 Sunday, 13 October 13 Checkout Jake Archibalds talk and Talk from the guardian at Front end London
13 It wouldn’t be a talk on RWD without at least a small mention of using responsive images - and these were perhaps the single biggest performance concern for us on GoodFood. Images make up a large chunk of most pages on the site, and people like seeing what they will be cooking, so it was about deferring the un- necessary images until we needed to load them in. So we went for a JS insertion method for most of the images on the site, which hooked into data attributes to load in our images. Inspired by Scott Jehl’s picturefill, but used a slightly different syntax. This worked really nicely for us, and gives us a non-js fallback for anyone who doesn’t have JS turned on.
13 October 13 It’s been great to work on a website where the users are so engaged and passionate, both positively and negatively. I personally think it’s better to get an opinion one way or the other, as it tends to highlight the areas that are good or bad. In terms of the feedback the site has received since it went live, it’s been really positive on the whole.
example of some of the more positive feedback we’ve received so far. I especially like the Blackberry Z10 comment - I’d love to say we tested specifically for Z10’s but this goes to show that responsive means that devices that the site wasn’t designed for should get a device agnostic experience.
of constructive learnings, the first was just how easy it can be to overestimate user intuition on devices. When the site went live the editorial team were swamped with feedback from predominantly older tablet users who actually thought we’d deleted search, when in fact we had put it behind an icon like this.
reaction, we’ve had to literally spell out where search is by labelling it, so there’s no confusion and adding an additional search box on the main homepage which isn’t hidden behind an icon. Which is pretty interesting as I personally thought that mobile and tablet users would be savvy enough to these sort of conventions and iconography.
which has been interesting is seeing just how much impact engaging positively on social media really can have a massive impact with your audience. One area we had issues was where we had renamed something called the Binder, to sit under a section called my good food, and a lot of people simply thought we had deleted their saved recipes. It was pretty remarkable how someone vocally negative can be reversed into a positive just through engaging with them positively.
13 This is just a simple example where a small change can have such a positive impact on interaction and has been one of the most noticed changes on the site. One of the simplest things we changed was the positioning of the ingredients and the method on the recipe page to be next to each other rather than positioned apart. This has been really positively received, and it makes a lot of sense, as they directly related when you are cooking and saves users having to scroll too much when they are in the middle of cooking. So it’s not always about massive sweeping changes, but also about working out the things that aren’t quite working on a device and trying to solve it.
it been a success? The reaction has been really good from the community, and the site is still actively under development as there are a number of section we had to cut before the site went live which are now being worked on. In terms of headline statistics and analytics though, the site is holding up really well.
48% YEAR ON YEAR 390% INCREASE IN PAGE VIEWS FOR GUIDE CONTENT 80% INCREASE IN VIDEO VIEWS SINCE RELAUNCH Sunday, 13 October 13 It can be quite hard to compare stats month on month for Good Food as the stats are heavily influenced by seasonal occasions, time of year and the weather, but the upward trend of visitors and page views to the site hasn’t been affected, even though we’ve been going through a heatwave which is really positive. But some of the other baseline stats since launch in June are... So overall, yes, some positive results are starting to come out of the change, and future improvements such as meal planning will only add to the functionality of the site.
dragongraphics
sygyzmundovych
neuecc
ymachida
nikkei_engineer_recruiting
tadaken3
guvalif
shift_evolve
takumiogawa
sudoakiy
moriya0130
narirou
sansantech
chriscoyier
kevinliebholz
bermonpainter
danielanewman
paigeccino
brad_frost
zakiyama
tanoku
vanstee
rmw
sstephenson
62gerente
