RWD Podcast Episode #21 : Patrick Hamann

Transcript

Justin Avery: Hey everyone and welcome to another Responsive Design Weekly podcast. My name is Justin Avery and I’m your host for this week and every week pretty much. I’m also the curator of the Responsive Design weekly newsletter which is a weekly newsletter all about responsive design funnily enough.

This week we are joined by Patrick Haman, Hamen, Hamann.

Patrick Hamann: Hamann.

Justin Avery: Hamann. Dammit, it was one of the things I was supposed to check. I need a check list for this stuff. We’re joined by Patrick. Can you believe that? Patrick is from The Guardian. Welcome Patrick.

Patrick Hamann: Hi, thanks for having me Justin.

Justin Avery: I apologize for getting your name wrong.

Patrick Hamann: That’s all right. Most people do it.

Justin Avery: I even had it written out. I’ve done this twice now I’ve done this. So when I clarified Aaron Gustafson last name, and then when I was introducing him I was, “I’m joined by Aaron Gustafseson.” So don’t feel bad.

Patrick Hamann: No don’t, don’t worry. I don’t take a grudge.

Justin Avery: Don’t, yeah, don’t take it personally.

Patrick Hamann: No, no grudges held Justin, don’t worry.

Justin Avery: He says now. Welcome. For those that don’t … We met a couple of … It’s almost a couple of months ago now at Responsive Design Day Out, and we were having a day out in the sunshine outside the pub talking about all different sorts of responsive design techniques. It was good.

Patrick Hamann: With our buddy Stu.

Justin Avery: With out buddy Stu and … Who’s the other gentleman from your work?

Patrick Hamann: That was Kaelig.

Justin Avery: Kaelig. It was some good chitchat which …

Patrick Hamann: Yes, very good chitchat.

Justin Avery: … got deep, very deep. The more ideas came out the deeper the conversation went.

Patrick Hamann: It was a great day out in fact. Jeremy puts on a very good event and extremely well curated. It’s a great place to get your thoughts induces [00:02:00] going for a chat in the pub afterwards.

Justin Avery: Indeed. Have you gone to the dConstruct before?

Patrick Hamann: I have indeed. It’s one of my favorite conferences. Unfortunately I’m not going this year though.

Justin Avery: Oh no.

Patrick Hamann: Yeah, well shank.

Justin Avery: Oh you have other commitments? You’re speaking somewhere else?

Patrick Hamann: Work, no, just work in general.

Justin Avery: I’ve had the same thing. Someone booked me off for the entire day on that Friday so I’m upset to miss out. The thing I like on the dConstruct is that it’s not specifically about anything in particular I suppose, like what we would only consider to be a good conference where they’re talking about techniques, and code, and stuff. A couple of years ago I came out and my wife came down afterward and we were staying in Brighton for the weekend. She said to me, “How was it?” Like, “Was it worth it taking the day off and spending the money for the conference?” I’m like, “Yeah, it’s gotten all right. It wasn’t the best.” She’s like, “What did you learn?” Then for the next two hours I didn’t let her talk. I was just like this and this and this and then as we if think of this also, and they can create this thing the way they want it, and they … Yeah, it was great. I really liked.

Patrick Hamann: Then you realized actually I did really like it.

Justin Avery: Yeah. Then I read a book, a blog post about it just raving that how it was the best conference I’d ever been to. It’s one of those ones. But no, they do do a great job.

For those of you that haven’t had the pleasure of catching up with you for a beer and hearing about what you’ve been doing, Patrick, you can share with the listeners how did you get into web design or the web itself, what did you do at school, what are you doing these days?

Patrick Hamann: Web development, where do I start? Yeah, I studied something very weird and unique called digital development. Well no, it was actually interactive media production. I was slightly confused. Before I went to uni, didn’t really know what I wanted to do and run my finger down list and was like, “Hey, that kind ticks a few of the box that I liked.” [00:04:00]

Although it was a very good course, some people say that we want to be real engineers in computer science. I disagree with that. There’s a lot of people here at The Guardian that don’t have com-sci degrees, but a lot of us that also do, and it creates a nice balance.

But there, yeah, I found a passion for web development. We did a lot of flash games development and I thought that was going to be called in the future. Then I got hooked into actually just how fun real web standards base web development is and so I started down my career as a frontend developer, worked at various agencies in London, and Old Street, Brick Lane in the hipster land and in the epicenter of it all.

Justin Avery: The Silicon Roundabout.

Patrick Hamann: Yeah. Well this is before it was called the Silicon Roundabout. Then about two years ago I decided that I wanted to change from agency world and deadlines and decided that actually maybe I should give it a go moving in-house somewhere. So I went for a job at The Guardian, fortunately which I got, so being here ever since.

For over two years now and for the last 18 to 20 months I’ve been working on the frontend development team. I’m now a senior engineer and tech lead for the content team here, predominantly on the core web team. We’re split in three teams. As I said over the last 18 months we’ve been focusing on reimagining, redesigning, and development theguardian.com from scratch. It’s a pretty amazing project to be able to work on and to really throw away everything you had and start from the beginning and think about the future of The Guardian and how we want to present that to the world.

Justin Avery: [00:06:00] With the three different teams there, are they three different teams of the same type of people, or is the frontend content team one team, and then you’ve got a backend team for the web as well?

Patrick Hamann: No, each team … We very much focus on having cross functional teams that are made of small units that we practice continuous delivery and we need to have small cross functional teams made up of a project manager, a designer, a UX-er, and around four engineers. Each one of these teams is very much empowered to make their own decision and not have this horrible waterfall effect. It’s been working extremely successful, successfully, the three teams that I mentioned there.

Justin Avery: We’re just having a couple of connectivity issues in a nice holiday house in Croyde that remain. My apologies Pat. You were talking about the three development teams.

Patrick Hamann: Yes, so we actually did start off with one whilst we still had to maintain the old website. We had team still maintain that and there was a couple of us that spearheaded away. It’s something that Brad Frost coined a phrase “planting the responsive seed,” and it’s exactly what both ourselves and people BBC News did where in large organizations like I said the idea and the concept of responsive web design is quite a daunting thing, especially in the industry where in enterprise level people were used to having that end m dot domain, then their web domain are never completely separate, and they have different functions and people who browse mobile websites didn’t want this X content or Y content.

So trying to convince stakeholders within large organizations is quite a tricky thing. What Brad meant by planting the responsive seed is like ourselves and BBC, we tried out responsive techniques [00:08:00] on our m dot domain before we really bit the bullet and went fully in. There was just one team at the beginning, and we did, in the space of five months, went from having nothing to shipping a whole new responsive platform or albeit was only optimized up for tablets to the seven inch devices. We shipped that on m dot The Guardian and it was so successful that we did get the buy-in and then eventually last year we moved over to a single domain which …theguardian.com. I don’t know for some users might know that we used on guardian.co.uk. That was an extremely big shift.

But at the same time is that we moved to a new CDN that enabled us to do quite advanced detection so that we could still serve the responsive site across a single domain whilst we were also still serving the domain site to desktop users.

Then we stopped maintaining or thought we stopped development on the outside full stop last summer, and since then we’ve now had three teams. So my team which is purely responsible for the content, so that’s article pages, video pages, gallery pages, life blogs. A team that’s solely responsible for what we call the front, so the home page, the tag landing page. Then a team that’s purely responsible for the commercial aspects of the site. So implementing responsive adverts and getting our feature parity in terms of revenue drivers on the site as well.

Justin Avery: I was going to ask about that as well. Like in terms of getting their buy-in from the internals, was the fact that they always, they just didn’t believe that this responsive design thing was going to work, or did advertising have a big blocker? I’ve heard of some large organizations having their own mobile ad revenue team that went out and solved mobile ads [00:10:00] and so they refused to go away from the m dot site. Was there any kind of blockers within that, or were you guys able to overcome that?

Patrick Hamann: Yeah, it’s been an interesting journey, but there’s two factors to that. The first one being that I still personally don’t think that the industry is ready, not even inside the walls of The Guardian. The problem for me lies more outside of those walls. The IAB for instance is only just starting to try and standardize some actual responsive formats of moving away from the banner and the MPU to actually have some things, some standards that ad agencies and creative companies can implement to these. Until we have those I think we are, all of us, let alone The Guardian is still left in this limbo land of having old creative standards but in a new responsive world.

But yes, internally we also as you mentioned we had the buy-in issues that we did have very separate teams in the commercial department that’s responsible for just selling mobile adverts and just selling desktop. Then we still to some degree have that, because we don’t have the concept fully yet of responsive adverts. We still deliver mobile optimized advert creatives to mobile devices and bigger creatives to desktop.

But I like a few things. Creative commercial was one of them. Even from an editorial perspective we had a mobile editor and we had people that were thinking about how content is displayed on mobile. That’s also had to be an organizational shift. You really need to get people thinking about not just viewing … “Oh if publishers ask when I’ve embedded a few end graphics in it,” and, “Oh, it looks okay on the desktop so it’s fine,” but you realize it’s then broken on mobile and then …[00:12:00]

I think the whole organization on the whole have been very receptive to it, and it’s taken a bit of training but we’ve definitely got to a great place, and one that we’re I would say a lot better positioned than some of our competitors are, because of the fact that we had adopted responsive early, and we do ensure that every bit of content does work across all devices now. In turn actually one of the greatest benefits is making our content more accessible to every user, regardless of the device or location they’re accessing it from.  

Justin Avery: Which is all this is what responsive design is about, right? This is the focus.

Patrick Hamann: Correct, yeah.

Justin Avery: Cast a wider net, let’s get everyone in. This isn’t something that I generally get a chance to ask a lot because usually we focus so much on our frontend delivery techniques and whether people can consume the content, and how we can best do that. We often figured about how people can create responsive content. So for the numerous authors and writes that you have on staff at The Guardian, have you had to reshape the way that your CMS and the writing process for them, has that affected more areas of the business?

Patrick Hamann: Yeah, completely. Tech [inaudible 00:13:25] nature is responsive, so that’s fine. But when you start to think about that we have beautiful graphics being created by the graphics department, we have an amazing award winning interactive team that make beautiful interactives, but they were also always only really thinking about the desktop. But we have a very good relationship with them. They sit half way in between the editorial department and the digital department, so we can communicate with them and help them create new frameworks and design patterns so that the content is flexible [00:14:00] across all devices.

Yes, the CMS completely itself has been re-architected as part of all this ongoing work to really change The Guardian and put us into a digital first position. We’ve completely re-architected our own in-house CMS, which is now an angular application and the data model behind that. At every stage we have to think about how we can represent content in a way that it can be consumed regardless of the device.

Another interesting thing here that’s helped us a lot is that although we have a great web platform, we also have very good native applications on Android and IOS. So that the content can be created once and shared across all of those platforms, be it web or native, we have our own content API. So we have a service oriented architecture that both, the website and the native applications don’t ever talk directly to the database, they consume the content through the content API, which is actually an open platform as well. We allow other third party developers to use our API and create other applications with our data.

But what I like about it is that abstraction and that separation of concerns really helps us to distill how we think about, how we model content from this responsive aspect. It needs to work in every platform, agnostic of the platform.     

Justin Avery: Because we’re going to poke around and ask particular implementation techniques and how you’re doing things, both on the front and the back end. Is there anything that you guys ought to speak about at The Guardian that you keep under wraps? Like you said, you’re ahead of the competitors.

Patrick Hamann: To be honest with you, no, not really. I mean it’s one of the great things [00:16:00] I love about working at The Guardian. Being open is core to our beliefs and ethics at The Guardian. We believe in open journalism, and that is shared across our digital platforms as well. Just as much as we believe our journalism being open, we also believe in developing in the open.

The project that I work on our entire new frontend application is available open source on GitHub. It’s not a private repository. Anyone can poke around. We like the people to have a look, suggest things to us, also learn from what we’re doing as well. As I said, the content API, we allow people to register for API keys and consume that. So no, not necessarily, we don’t really have anything that we keep truly private. We believe in being open. 

Justin Avery: Excellent, and you’ve opened a can of worms. No, no, not really. I was talking about … Actually what you were talking about in terms of working closely with that, the digital team. What were they called, who do all your infographics and things like that?

Patrick Hamann: The introductive team.

Justin Avery: The introductive team. Yeah, I was really lucky to have Ethan Marcotte as a guest a few episodes ago. I was asking him about the way … It used to be that when looked to a website we would check to see whether it was tables or CSS layout. Then when responsive arrived we’d grab the corner of the browser and drag it back and forth.

Patrick Hamann: Doing wiggle-wiggle.

Justin Avery: Yeah, yeah, Jeremy was talking about, this is what Jeremy Keith was saying nowadays he looks at the network tab to see how performance to site is like, how much you’re sending them and where, why are you sending me this much. It’s not a nice site unless it’s sub-certain size or at least loading and being able to be usable at a quick point.

I asked Ethan whether or not he thought of sites in the same way. He has a different take on when he sees a site [00:18:00] is that how well has the story been told. It sounds like that’s what you guys are focusing on by bringing those guys closer to your team, is you have that story that you want to tell. It’s just the best way of telling that story.

Patrick Hamann: Agreed. Yeah, definitely. I mean in fact especially from the media and journalism … people focusing on the moment is storytelling and how to best deliver that. There’s people that like Vox in America are really, really pushing the game for that. I like to think, yeah, that our interactive team are definitely doing that as well. But obviously focusing on performance and delivering how that is displayed across devices is like Jeremy’s [inaudible 00:18:48] obviously is still true.

Justin Avery: Now one of the things that’s … So you’re doing a whole bunch of work now, so you’ve [delivered this sign 00:18:58], you’re kind of mister performance within The Guardian. At least that’s what I referred to you because I couldn’t remember your last night, Patrick Performance, PP. But the way it seems to be happening is that you’re doing a whole bunch of work around sending the most important content down the wire first, doing a test like cutting the mustard, and then sending the rest of that information down.

If I looked at those in the three different steps I was wondering if you could maybe talk about the many steps, like how what you define as important content, how do you cut mustard, and what is that? Then what is the conditional loading after that? Like how do those steps work in this approach?

Patrick Hamann: Okay. No, that’s a lot. That’s a very large question.

Justin Avery: Question one, how do you decide what’s the important content?

Patrick Hamann: Question one, how do we decide what is the most important content is obviously quite an easy one. For us anyway it’s the content that users came there for. [00:20:00] So if we just take a traditional article at The Guardian, it’s the article. If I’ve searched on Google for a specific topic and I found The Guardian article at the top, I click on in, I as a user have come there to read the news, to read the article.

Interestingly we have both on the service side end and the frontend we have what we call our line in the sand. The most important one in that is that we only ever make one blocking database request for a user to come to the page. The rest of them can be lazy loaded in synchronous which I’ll talk a little bit later, but that means even on the server, most websites if you take a traditional WordPress website, just to render the article what’s actually happening on the server side is that WordPress would ask the database for the article, but then also ask the database or the comments associated to that article, and then maybe all of the related other bits of content on the site from that article.

Then you might even have like a most popular component of all the most popular articles on that blog and you get a moment of time. In fact actually WordPress would be ending up to making six or seven database requests just to render the article, when in fact all the user really came for is to read the article.

So when we set out in the project we set a rule that we only allow ourselves to make one blocking request to the bit of content that the user came here for. As you mentioned in your free question it’s really prioritizing content at the forefront. Everything is else secondary and it shouldn’t block the critical path, a user clicking on Google to then having the article rendered, we should only have one thing that blocks against the database. The rest of it can all just be subsequent request that we can ajax in or conditionally or lazy load another point in front of the page, depending-

Justin Avery: So that’s the …

Patrick Hamann: [00:22:00] Yeah, go on.

Justin Avery: That’s the third part, right? So that’s the third part. There’s another bit which comes in before you decide to load less stuff in, or does that stuff pretty much get loaded in regardless?

Patrick Hamann: It depends. Yes, the second bit you mentioned is about cutting the mustard. So cutting the mustard for those of you that don’t know is actually a technique and a phrase coined by the BBC news team, specifically Tom Maslen, a good friend of mine, where they decided there were so many browsers in the world that we can’t literally set up all of them. For a site that gets the amount of traffic that The Guardian and the BBC do, it would be a full time job for us to sit there testing every single possible permutation of device and browser.

It’s much easier to focus, as we all should be doing, on feature detection rather than device detection. We set a line of saying these browsers we deem to be future proof, we deem that they have enough features that we are going to serve all of our content, be it the secondary content or the primary content too. Then any other browser will fall into a lower bracket. Although we always have the rule that we have to still send the content to them, and it needs to render okay, but they don’t have to have the nice to haves of that most popular container in the bottom or related links, which is great because it fits in with our one blocking request rule.

So all browser will get the content, but then based on certain features on your browser, web or not, for instance you have queryselectorall in your Javascript capabilities, or you’ve got a good ajax object where you would be able to then we can progressively enhance the website to have all these nice extra components. So we cut [00:24:00] the mustard and we do that by … Actually I just need to quickly check because it changes from time to time. Javascript latest … Nope. Sorry, bear with me two seconds.

Justin Avery: While you’re having to look, I sent a tweet out this morning actually which you currently came back, and I’ll ask you this after we finish with this set of questions ,to go back to that difference between lazy-

Patrick Hamann: Conditional loading, yeah. So our cut in the mustard test is whether or not they have queryselector, whether or not they’ve got a native ad event listener, and do they have local and session storage availability.

Justin Avery: Does that give you an idea if this is a particular level of browser that we can then give all this stuff to, or are they specific requests around the types of things that you want to do after that?

Patrick Hamann: They are specifically related to the types of things we want to do. If we want to deliver these features the best we can we need to use those three things, and therefore it’s just feature detection rather than, “Oh I want to support this device, therefore oh I know it’s got that.” It’s very much around the specific features.

We’ve actually built onto that list. So local and session storage for instance I think, we didn’t use to have them. But then we noticed the pattern that we were using them a lot and we were relying on them for our features, and therefore we added it into our test. Unfortunately, yes, that means [inaudible 00:25:44] and support for a certain group of browsers, but when we have over 7000 different devices accessing our website every day we need to make these decisions.

Justin Avery: It’s not like you’re dropping support. [00:26:00] They’re still getting the content.

Patrick Hamann: Exactly.

Justin Avery: Right, those requests.

Patrick Hamann: And then everyone else just gets a progressive, a nicer experience. But everyone gets the content.

Justin Avery: It’s a nice thing. A question around that serving of the content which is something again which I’ve been chatting with a few folks about recently is, one is around the navigation. Do you consider the main navigation of the site the top level as part of the content, like would that get served as part of that non blocking single database request, or is that something which is also … ?

Patrick Hamann: No, no the navigation is definitely hardcoded into the initial payload, although it’s progressively enhanced. We use Javascript for certain bits of our navigation, to show and hide the rest of the sections in the site, or depending on where you are. But if you don’t have those abilities, you don’t cut the mustard, therefore you’re not going to get our Javascript application. Obviously we still want you to be able to navigate to those sections of the site that we’ve hidden off canvas.

We just use a simple technique that we still got the full navigation in the DOM but it’s down the bottom of the page, and that link gets progressively enhanced if you do it to show [inaudible 0027:20] if you do have Javascript. If not, it’s just a fragment identifier straight down to the bottom of the page. We’re never preventing a user from navigating the site, just as we’ve got content we’re never preventing them from seeing it. We just progressively enhance it with Javascript.

Justin Avery: That’s awesome. That’s a really good approach. I like that. I only asked that because I think there was 37Signals [inaudible 00:27:45] recently or Basecamp I think they call it now, around only loading the actual article, like not even the navigation for the sites. That was seen as something in addition to what the content requested [00:28:00] was for the user. So it was an interesting approach.

Patrick Hamann: It’s very interesting. I personally think it’s taking it one step too far. But if you’re being a purist then, yeah, you should only really be rendering the content. 

Justin Avery: I also used to think, and this might be just me being bad at frontend stuff that, when the talk of conditionally loading CSS in was the same thing, it was like well CSS is just something which will come down in the head. But now we’ve got this whole critical CSS which could be sat in the head which is this viewport that you see. So it loads within the first, I think it’s-

Patrick Hamann: 14.

Justin Avery: 16 kilobytes. Yeah, 14?

Patrick Hamann: Yeah.

Justin Avery: Yes, are you guys doing that stuff as well?

Patrick Hamann: Yeah.

Justin Avery: To make the site even more powerful?

Patrick Hamann: Oh definitely. Yeah, we spent a lot of work in that area. I like to think that we’re one of the first major sites doing it. Although it’s had a lot of hype recently the technique, which is brilliant. There’s Ilya and Scott for instance have been doing a lot of evangelism around it, and Addy and the rest of the Google Developer team, myself included. Actually funny enough the technique originates from Google and Bing.

Steve Souders has wrote a great article dating all the way back to 2011 when he realized that the search product for both Google and Bing were inlining, the whole of this is it’s not even just above-the-fold content. They were literally inlining the rest of it. Then they would-

Justin Avery: Oh wow. I suppose it’s so simple.

Patrick Hamann: Well yeah, exactly, but I also I deem those websites to be the fastest sites in the web. Google search was our page. It’s hands down probably the fastest in the world. So if they’re doing it [00:30:00] then you’ve got to be doing something right.

We started looking in to the technique. In fact it’s taken us quite a lot of time to really nail it. I don’t think we’ve nailed it properly yet for various reasons, but yes, we’ve been doing that since the beginning of last year. It went from our website rendering in 1.5 seconds, yeah, 1500 milliseconds all the way down to we’ve got at about 700 milliseconds now.

Justin Avery: Wow.

Patrick Hamann: We really got to break the 1000 millisecond barrier. If you want your users to perceive your website as a fast, and that’s what we needed. It’s one of the goals that we set out in recreating the site. We knew that the old Guardian website was extremely slow, especially for rendering. So we’ve spent a lot of time and effort in doing that. There’s still a lot things we can’t do, but having inline CSS has enabled us to always stay below that 1000 millisecond, regardless of what else we [check 00:31:11] on the page, at least we’re painting to the user within that budget.

Justin Avery: So you have taken upon the performance budget?

Patrick Hamann: Yes, yes, Tim Kadlec’s great, great idea about setting performance budgets. Yes, that’s why I called our lines in the sand. For instance the one blocking request and rendering within a 1000 milliseconds are both very high up in our lines in the sand. We’ve actually got a few more that you can find on the GitHub. But specifically about inlining CSS we’ve done it slightly differently to some other people that we don’t use any of the tools that have come out over the last of couple of months for automating the process, using fonts and … 

Justin Avery: So critical CSS or …

Patrick Hamann: Yeah, using [crosstalk 00:31:58] as part of your grunt [00:32:00] built script. They’re great products and I think it’s great that people are using them. But two things on this, is that firstly the concept of what is above-the-fold is that tricky thing in responsive design, which above-the-fold. Sorry that concept doesn’t really exist anymore. So yes, you may have a tool that is working it out for 800 viewport but what about the viewport that is only 320 pixels. It’s that and it’s also about certain content because of the way that we do lazy loading, a lot of our secondary content. Even though they might eventually end up above-the-fold, I don’t want them eating in to that 14k budget for what I’m inling in the head.

So actually us as the application developers are a lot more knowledgeable of what’s we deem to be critical CSS and what we don’t. We’ve actually found that technique a lot better. We have tried to automate the process, and each time we’ve tried it we’ve given up, and we’ve realized that actually us as the developers should make that final call of what is critical and what isn’t.

We’ve had to create some tools around that though. So answering Kaelig, who I mentioned earlier, one of our developers, came to me one day and he was like, “You know the technique is great, but actually we’re finding ourselves a lot that we’re eating into that 14k budget. What can we do about this?” Actually what a grand task called asset monitor that in our bill process and CI server I’m constantly measuring the size of those head files so we can actually graph this and we’ve got a dashboard that is constantly at any given moment in time I know the exact size of all of our core assets, be it inlined CSS, even our global CSS file, our global Javascript application and some of the other ones. So I can set [00:34:00] alerts and thresholds and know when we do break that 14k barrier with the build. That should actually break the build and say, “You can’t release this introduction because you’ve eaten over the 14k inline budget, and we need to have a think about that.”

It’s also about observing just in our peer review. So we use poor request a lot as part development process in GitHub. So if I see or any of the other developers sees someone adding a module to the head CSS file, you have to ask them a question, “Is that really a critical module? Is it going to load above-the-fold? No. If not, then it shouldn’t be in here.”

It’s a tricky balance. It’s that same thing of feature blow. Everyone seems to think that their new module that they are developing is critical, but you really have to question these things. It’s nice. That’s something of developing responsibly it’s helped us do is really honed down the focus on what is critical and what isn’t and prioritize the things that are. In our world, in the publishing world that is only our content.        

Justin Avery: It seems like you guys are doing a little work around continuous improvement and releasing themes. [Inaudible 00:35:22]. Has this feature over from the desktop site and to the work that you did around the mobile and the type of stuff of getting the responsive stuff right first. Has responsive design made it harder to do the continuous improvement approach, is it making it easier?

Patrick Hamann: That’s a great question. But there’s two bits to that. Firstly you can know that like in fact the responsive and developing from a mobile first approach and doing this planting the responsive seed whilst having both of them has allowed us to use [00:36:00] what we call the beta site, even though our mobile device is not a beta site. It is what we get on a mobile.

But we are really using it as a place to experiment and a test lab because we’re lucky enough to still have the fully or the old site working with all of its features, so it’s enabled us to a great place for experimentation that we’ve opted in, quite a couple of thousand users that do you use it as their sole even on the desktop, but we can use that as test beta to run lots of AB tests and try out, experiment with our new thinking and futures.

Actually responsive design or at least tackling it from that mobile first approach and still maintaining the second site has enabled us to move a lot faster. The but to do with continuous delivery is not so much from an engineering perspective. It is more from an organizational perspective. It’s very much changing culture. It’s quite easy to do the tooling side of continuous delivery. We’ve got great ops team that built an amazing deployment tool that enables us to do rapid deployment four or five times a day, and we no longer have to chalk it over the wall to them.

But actually the thing that’s hard about continuous delivery is the culture shift within, inside organizations. Both from product or design and editorial they’re very scared that, yes, I’ve built something over the last day and I’m going to instantly put it out to our millions of users without validating it through loads of regression testing or UX labs or going to out this person or that person.

In fact, we all know as engineers that the best to validate an idea is to get it in front of our users and learn them for those things. But it’s taken quite a while for that culture change to go through the business. [00:38:00] But now we are at that point. The designer’s word, our design is they know love working like that. It took them a while to get used to it, not knowing that everything is never really … The first time we release a feature it might not be as polished as they like to their standards, but that’s because we are iterating it. We’re releasing features in chunks.

It took them a while to get a grasp on that and get the head around it. But actually now they love knowing that they can get instant user feedback from their designs or tweak this or tweak that. Because our time to fix or time to change is now … We used to work in scrum like two week sprint cycles and it would take them two weeks until they’d get their new design validated against users. But now they can get a design validated in the space of half an hour. It’s really liberating for everyone from engineering to design to product.

We also heavily rely on things like feature switches that when we release a new feature we can put it behind an on off switch that we have a dashboard for. I can develop something today that someone’s requested, a new feature someone’s requested, but I can deploy that code into production, but I might no t have to actually turn on the feature until next week, until someone in another department has okay-ed that it’s all right for it to be turned on. But as far as I’m concerned, the development work was finished weeks ago. Having systems like that in place has really enabled a rapid development and continuous delivery and iteration.   

Justin Avery: I suppose the other side of that as well is being able to switch off again if something is wrong with it, which isn’t seen as something that’s-

Patrick Hamann: Precisely. That’s, it’s really good that you mentioned that, because one thing that we did find in the old site as well is just that you’ve turn in to this very large monolithic code base of feat creep over feature creep [00:40:00] over six years. You’ve now got a gigantic code page with like files and files and even sub folders in your project that these features are now even not being used by anyone anymore, or they didn’t actually really ever get that much traffic, but we’re still supporting them and we still got to do bug fixes for them. Whereas if you’ve got something that has a switch and we even took this concept one step further by adding dates to our switches, [inaudible 00:40:29] dates and such.

An ex colleague of ours, Matt Chadburn came up with this idea. That is something that we only want in the short term, a feature for the World Cup, or it is something that the project shouldn’t really be doing, but we want to validate it in production first, so we can grab some data and go back to the person that requested and say, “Actually hey look, this feature didn’t really get much traction.”

If we added a date to these things then when that date comes by, rather than them just getting forgotten about and living in the code base for the rest of eternity, we’ve got an alarm that says, “Right, this feature has expired. You need to something about it. You even need to delete the code, or you need to turn into a permanent feature, and have a quick thinking and look at the KPIs for it, did it actually get a great click through, did it do this?”

It’s been truly like it’s one of the best things I love about our project, is that we can think of features like that. It allows us to have a vocabulary and something that we can communicate with our stakeholders, okay, like, “Yes, we will build this feature but it needs to prove that it’s worthwhile doing over the next two weeks and then we’ll readdress it.”

Justin Avery: That is such a good idea as well. I spoke to a lot of clients about content management systems and about publishing dates and how they should set, not for news items so much, but the content they have [00:42:00] is like setting feature status so that in six or 12 months they get reminded to go back and check the content, so that they don’t have this huge big review of their content in three years when they really need to move on to a new system. But I never thought of applying that same concept to features within the site as well. That’s a really great idea. Yeah, that is awesome.

I realize time has gotten by. But I’ve got two questions in one question to ask of you as well. The first one is just to elaborate a little bit more. We talked a little bit on Twitter earlier about the difference, is there a difference between lazy loading and conditional loading. I was looking at things like lazy loading images and whether the condition of the image becoming within the viewport would mean that it’s conditional loading or is it still considered lazy loading?

There were some great answers and I think I got what everyone was saying, but they were trying to answer it in a 140 characters let’s say. So if you would like this opportunity, well, I would like this opportunity for you to explain just in a slightly little bit more detail about you consider the difference between the two?

Patrick Hamann: My answer to you and initially the simple answer is yes. I personally believe that there is a difference between conditional loading and lazy loading, and my response to you is that obviously one of them is conditional, the other one isn’t.

An example of this is as you said of images, we might lazy load in images or we might progressively enhance the images using a responsive image technique, a polyfill before picture comes in for instance, and we’re always going to do that. But we lazy load it because it is not essential to the critical rendering part. Or we’re always going to show the comments below the article. But again, they’re not critical, [00:44:00] they’re not deemed critical enough to be on the critical rendering path. I would deem those lazy loading.

But conditional loading, as the name says, we would normally use this technique if we for instance were to polyfill a new web functionally that that we’re only going to load to that blob of Javascript. If the current browser or device does not support the feature, therefore we can additionally look to see if they have the feature and then we’ll load it. I think that that kind of hopefully in layman sense that’s what I mean by the difference between conditional and lazy, that I would always use lazy loading for content and conditional loading for features. Does that make sense?

Justin Avery: It does. To be fair 140 characters spelled out the same kind of thing. Well at least I thought so, anyway, but it’s good to get the clarification anyway.

Patrick Hamann: On that note thought it’s very good to see that a lot of websites are starting to approach these questions of really what are essential content, and that should be the only thing going down the wire, and then we can lazy load the rest of them.

To have really performance sites we as web developers really need to be asking these questions to each other and to product and design as well. It’s okay for you to go back to your client and say, “Do you really need this fancy component at the bottom of your page? Do you might if we lazy load it?”

Justin Avery: The chances are it’s not that important. Now the other thing that I’m going to ask of you is to ask a question of our next guest. For each person that I speak to I always ask them [00:46:00] to pose a question to the next guest on the show and see what they came back with. Now Brad Frost actually was the last guest on the show, and he had to answer what was his favorite Star Wars episode. It was a new [inaudible 00:46:17] so I’m glad that he chose one of the older one.

His question, so he didn’t know who it was for, but his question was around these days our industry changes so quickly. Every day or every week or every month there seems to be a new latest and greatest way of doing things. At first it was Grunts, then it was Gulp, then it might be Broccoli, and you’ve got Angular, and you’ve got … So these things always, these new things keep coming up. So his question to the next person, who was you, is how do you stay on top of all of these things, and how do you make the decision about which one you’re going to pick up and run with?

Patrick Hamann: Wow, it’s a very good question Brad, so thanks for shooting it at me. But I think it’s a very important question as well. It’s something that I see a lot of upcoming developers and junior developers asking a lot on places like Twitter and on their blogs, or even at conferences, it’s so fast-paced that how do we stay above-the-fold.

There’s a few things here. Form a personal perspective for me it’s definitely Twitter and blogs. I learn more from reading people’s blogs than I ever did do at school or at college. Trying to keep up to date with following people in Twitter in your topic and interest areas there’s already quite a good list of curated lists. You could just follow whole lists of people in web development. [00:48:00]

Again, find out if those people do have their own blogs because normally 140 characters isn’t a great place to sharing knowledge. A long form article is much better of sharing knowledge. GitHub obviously is a great place. But the biggest one for me really is actually your own peers and colleagues, and working with great people, and making sure that you are around people that can educate you. There’s that great saying, “If you think that you’re the best person in your workplace or you think you know the most then it’s probably time for you to leave your current position.” I think I believe that.

Also, I’m very fortunate at The Guardian to work with some extremely intelligent people of each of area of web development that are really pushing themselves. I love learning from them. I learn something new every day here. So, yeah, making sure that you’re immersed by working with great people.

The last one is actually conferences for me. It’s a tricky one because it’s quite an expensive thing to do, but obviously most conferences publish their videos online these days, so you don’t have to just attend, you can still watch them. My fiancé is completely fed up of me watching techy conferences on our television at eight o’clock in the evening. [Inaudible 00:49:35] “No, don’t worry, it’s good for my work.” But truly, again, as well as blogs, conferences is the other place that I truly learn the most from.

Even in my own subject area as you said as frontend developer where there’s web components, there’s angular, how to then even chose which one of those you want to focus on? [00:50:00] For me it’s just what I’m passionate about. So a lot of the time that is just really focusing on performance and CSS architecture. So, yeah, I think, yeah, I pick what I want to know and I focus on that, and hope that my colleagues can teach me the rest.    

Justin Avery: Awesome answer. I’m sure Brad will be happy. I think Pat it’s at the end of our hour now, but thank you for everything.

Patrick Hamann: No, thank you very much for having me.

Justin Avery: I have a ton of other things that have just popped into my mind as we’ve been chatting, but I’ll save that for the next conference we catch up. How do people see what you’re up to, Twitter, websites? Do you have any upcoming speaking gigs or anything like that?

Patrick Hamann: Oh yeah. So yeah, just on Twitter is my full name, at Twitter is @PatrickHamann and I’m actually fortunate of, yes, I’ll be speaking at a few conferences coming up. This Friday I’ll be speaking at Redevelop Conference in Bournemouth. It’s the first ever Redevelop Conf. I’m actually really looking forward to it. I’m not actually not my normal rant about performance or CSS. I’m actually talking about some of the stuff we talked about today, about culture and about continuous delivery at The Guardian. So I’m really looking forward to that.

I’ll be at Sass Conf in New York in October. I’m giving a workshop there about optimizing your critical rendering path. Eventually in November I’ll be talking at Velocity about breaking news at a 1000 milliseconds. It’s a case study on the new guardian.com and how we’ve made it and render lightning fast.

Justin Avery: Awesome. The one last thing, our next guest, what would you like me to ask one question of our next guest?

Patrick Hamann: One question of your next guest, for me, [00:52:00] I’m going to keep it … I’m not going to go for the film tangent like Ethan did for Brad. I’m going to stay technical. I want to know what is your favorite feature of CSS? Or what is your favorite CSS property?

Justin Avery: Nice, different.

Patrick Hamann: For me, I’m quite boring, but it saved me, especially in response web design it saved me a ton ass of time which is my favorite CSS property is box-sizing, so box-sizing, border-box, it saved me many hours. But I’d like to see if there’s any more interesting questions.

Justin Avery: I know who’s coming up next, but I won’t spoil it. I think they’re going to have something a little bit leftfield but it will be-

Patrick Hamann: Great, no, it’s good.

Justin Avery: Will be good, I’m sure. Thank you very much.

Patrick Hamann: No thank you Justin. Thanks about doing it.

Justin Avery: [Crosstalk 00:53:00] in taking time out of your day. Thank you to all the listeners for listening to the podcast. You heard where you can check out Pat’s stuff, Patrick’s stuff. Yeah, thanks very much for listening and we’ll see you again next week.

Patrick Hamann: Cheers.Justin Avery:  Thank you, bye.