 Hello, so good evening, I'm here to talk to you about how we can start to rethink and re-imagine how we design responsibly. So a bit about me, I'm a technical architect at Beamley, so I'm currently leading a team completely re-imagining how we build our sites, specifically looking at the techniques where we adapt our site depending on the type of device that's being used. I've written a book called Beginning Responsive Design, and I contribute to loads of open source projects, it's just a few. And I use Twitter a bit too much, I think some day I can tweet 600 times, that's when I have conferences. So anyway, current responsive design techniques focus on mobile first, they focus on how things fit on a small screen, and then they progressively enhance the larger displays to provide a fuller experience. But there hasn't been the same focus on either the content or performance of our site. So what we're going to do today is look at how we can rethink the way we design and build our site to give these the area that they deserve. So first up we're going to look at how we can improve our site content and how we display it to users, and adapt it based on the type of device. So to start with I want to read a quote to you from Bobby Anderson, who says it's much better than me. Content is king, it always has been and always will be. Content is why videos visit your site, subscribe to your newsletters and follow you on social media. Content is the single most important aspect of your website. And in order to consider it, we need to know about the content before we can start our design. So this involves getting your stakeholders involved and asking them to provide you with content early on. In some cases this might not be possible, and in some cases you might have content that changes frequently, but this is about making a best effort. And you need to consider that content must work across a wide variety of devices. If we're looking at global statistics, you're looking at 65% of users on desktops, 29% on mobile phones and 6% on tablets. But don't rely on these statistics to be true to your site. You should look at your Google Analytics and look at your own usage statistics. So being me, for example, 91% of our users are on mobile. The first way in which we ensure content works responsively is to look at how we prioritise content based on the type of device. The first step to do this is to audit your content. So what you need to do is look at your content and work out the priority to your users when they visit your site. And content does not have to be in the same order on every device. So this audit should be carried out on a per-device basis. Typical responsive techniques have seen content prioritisation being considered as an overall piece, rather than in the context of individual device types. In reality, when users are trying to achieve on your site, we'll likely differ based on the type of device they are using. So we're going to look at an example of this. So for this example we look at a restaurant. So on small devices, they are likely either going to get on the way to restaurants or want to make a booking. So we leave it with a phone number, then under out directions, and then maybe a link to a call to action to make a booking. Less important information on a small device is sort of like menu atmosphere, which is content that might be difficult to view on a small screen. On large devices, people are likely sat at home or they are on their computer at work. So they wanted to find out about the restaurant in advance. So they want to look at the atmosphere and the menus and see what food they offer. This is obviously important to people who have allergies as well. And then they might want to make a booking, look at the phone number and directions. So I'm not a designer, so apologies about the design, but this is how it might look on mobile. So if you have a look, we lead with the phone number in the top corner. Information on how to get to a chicken and book a table, followed by the menu and the atmosphere. But then we can completely change how that looks on large devices. And we can lead with the atmosphere, a big bold imagery to explain what the restaurant is about. Then as users we left to right, we can lead first with our menu, booking and then getting directions. So to reorder content based on the type of device, what we can do is use CSS flux box. And for targeting we use media queries. So a simple code example is that we have an app to the wrapper with two elements. As we're building mobile first, we've got mobile content first, and then our desktop content. Then we're using media query for large devices. We can then apply a display flex to the wrapper. We want our content to stack atop of one other. So we use flex direction column. And then we use the order property to specify the order of our content. So better content for desktop will say order one. And better content for mobile will say order two. The limitation here is that not all the browsers support flex box. And if you need to support all the browsers, as there is not a reliable polyfo for flex box, it is advised that you order your HTML desktop first. So you're using your progressive enhancement technique to progressively enhance from the weakest browser, which in this case is 9 or below. So if in doubt about your users' priorities are, you should invite them in and ask them. You shouldn't make assumptions. And you can show them your wire frame. So the ideas that you have in terms of your order, you don't have to build this before you can get them involved. Another thing you should do is you need to be sure that your content is discoverable. So on large devices, navigating a site is often really easy. If we take a look at the Sony site, for example, it is a very clear navigation covering the key areas of their business. And if we can't see what you want, they provide us an easy way to search in the top right-hand corner. Unfortunately, on the majority of small devices, navigation of a site becomes a lot less obvious. So if we're looking at the Sony site again, you'll see the navigation has been claptured to a hamburger menu. And the search box has been hidden in there as well. But there's no clear indication that it's been moved. So the onward journeys have been hidden. So again, I'm not a designer, but I've quickly mocked up in Photoshop how we might want to improve this. So we can move those items inside the hamburger menu back out below the logo. We can then remove the hamburger menu and replace it with a search icon so then the user can quickly get to a search to find the content. What this has done is it's pried better onward journeys because the user can immediately get to the site. It's also provided additional context to your users when visiting your site. So we did something similar at Beamly. At Beamly, we found that users didn't understand what our site did and what it was about when they first visited it. But by adding that context in a visible navigation, they understood what our site was about much more clearly. The compromise here is obviously to push the content down slightly, but obviously the benefits are way the disadvantages. Large devices also have more space for content, but that doesn't mean you should simply hide content on small devices. If we take a look at the GLH site, they've got this beautiful map on large devices, but on the smallest way, apparently we don't need it. I mean, I might be trying to use my phone to get somewhere, but we don't need it. But what they could have done is they could have put the map as a thumbnail next to the address and clicking on it could have made it bigger. So what we're getting at is we should instead think of ways we can change functionality to better suit the device. So we're looking to look at a couple more examples. So one might be a series of FAQs. So on desktop, we might have them open. So they could use the command F to find the content they want, or they could scroll through it. One small display scrolling through that amount of content can be quite challenging because obviously by being narrow it's taller. So on our small displays, we can collapse all the content into the titles, into the questions, and have an accordion. Another common example would be a lightbox. So a lightbox allows us to provide a great experience on desktop. We don't have to go away from the page to provide additional information. So perhaps a login screen. But on small devices, a lightbox doesn't really work. You can't really see the site behind it. It's always obvious how you close it. And onward journeys are hidden. So what you can do instead is show a new page on mobile. And a bit more complex example is a parallax site where we're using scroll animation to tell a story. But quite often the technologies are flaky on mobile devices, like position fix doesn't work very well. So we can instead make the simple stack content to use a scroll through it. So how do you measure the success of your content optimization? With all our content optimization, it's important to measure. So the first thing to do is ask users to test your site and observe them. In asking your users to test your site, you're able to measure their response to how you adapted your content across each device. Another way in which you measure the success is to AB test functionality. This is where you actually have two or three versions of a component and then different users are rendered different versions. And then when you measure the success of the users, you can compare the statistics for different components of achieving the final outcome. So in summary of content, content is king. And based on global statistics, 35% of users not using a desktop browser, we need to ensure that content is optimised for all different devices. So now it's time for a cat break. OK, that's enough cats. Oh yes, that's why it's crossed out. So now we're going to start talking about site performance. So we've talked about how we display content, but we need to get that content to our users really fast. So what is performance? So if you ask Google what performance is, it gives you this. It's the action or process of performing a task or function. In relation to a website, performance is the measure of how long it takes to deliver the content to your user. So there are two key types of performance that are important to a website. The first of which is page load performance. This is the time it takes to fully download the assets of your page and load it. The second is perceived performance. This is the perception the user gets of the performance of your site. So this is what's really important. It's the impression you're giving your users. So we're going to take a look at the Guardian site to compare the two. So what you'll see is after four seconds, we can start seeing content. We can start reading the text at seven seconds. The images have come in. So the user can start reading that article perfectly fine. Now we're going to go away to the end, but at 32 seconds we finally get the page fully loaded and the adverts have finished coming in. But before that's even happened, we could have read the entire article. So why should I care about performance? So a responsive site is expected to work on a wide variety of internet connections. A user can be in the office at work on a really fast connection or out in the countryside loading websites on a 2G connection. And they still expect to be able to visit your site. So last weekend I was out camping. I'd won by a signal the entire time and the internet was really slow. So I expect those websites to work. The trend in the past few years however has been the pages of increasing weight. So since 2012 we're seeing a 106% increase in page weight. And if we look at content type, we're seeing broad increases across the board except where we do see a decrease in flash because Apple killed it. But the average time that starts rendering is also increasing. In August 2013 till now we're seeing an increase of 34%. Note that it's not just your web page that can affect the time it takes to render your page. It can also be the device and the network connection. So how can I justify to my boss how I'm spending this time on performance? So Amazon found every 100 millisecond delay in loading a page cost them 1% in sales. So a big business like Amazon that's millions of dollars of revenue. And Google found an extra 500 millisecond delay in loading the search results. They decreased their traffic by 20%. So that's 20% less adverse they can show you. So what steps can I take to improve side performance? The simplest thing you do is just simply optimise how you load your assets. One way you can do this is start to use the picture elements. Because it doesn't make sense to load a 1000 pixel wide image on a device for the maximum screen size of 320 pixels. And this is where the picture element comes in. It allows to specify different images for different viewport sizes. So this is the picture element. It encloses source elements and image elements. And how the browser reads this is it goes through each of these source elements until it finds a media attribute that matches. So these media attributes use the same media expressions that you're using your media queries. And then if it doesn't find an image that matches it defaults to the image element at the end. So the image element is where you specify your alt tag and also provide the default image. So this is how it works in practice. So as the browser is increasing width it's actually downloading another image. Browser let's pull the picture element and only download the image that the browser needs. So if you are a small device you're not wasting bandwidth downloading large images and it's on a big device you're not bothering to download the small ones. So to use the picture element on your site you'll need to include the polyfill which is called picture fill. It was developed by the same people who wrote the specification. And if you don't like spending time including polyfills in your page this week it actually made its way onto the Financial Times polyfill service. So it's currently in QA and then hopefully by next week they said they should be out. So you have to just include the polyfill service in your page and then start using it. So another thing you can do is defer loading of both image and video to prove the initial page load. So the most common thing to defer loading is images. So this is the Beamley site and the Guardian site both of which defer images. So in doing this it means our initial page rendered is quicker. But in cases where loading assets was deferred it's the importance to ensure a suitable placeholder in place. So back to those two screenshots you'll see that the Guardian has provided the space for the image to come in. That means the page doesn't jump when the image actually arrives. And what we've done at Beamley is we've actually put a loading spinner in there as well so the user sees something's happening. Simply deferring loading assets isn't nearly as screened by a lot of people but what not many people are doing is deferring the loading of content. So back to what we were talking about earlier content is part of our site but not all content is created equal. So where appropriate we can start to defer the loading of content or even choose not to load it where it's not necessary for the device. So what we're going to do is look at the metro site which while the contents are great they do a great job of deferring content. So on our small device what they do is they load the article and as you scroll past it what you'll see is they start loading related content and this is infinite they just constantly give you new content. So on a large device however they actually have space for a sidebar so that sidebar content is the stuff that would have been underneath on the mobile. So in this case they deferred it and then using JavaScript they pull it in. The benefit being is that content had never been viewed on mobile it was never been downloaded. So it saves the user downloading stuff they don't need. Another example of where content is deferred is Facebook. So this site isn't responsive but what they do do is a really good job of rendering components as they think you need them. So one of the first things that renders is the search box so you can start searching Facebook and finding content and they also then prioritise rendering the posting box because as they require you to post stuff to exist they give you the opportunity to do so as fast as possible and in doing this the perception from users that the page is interactable a lot quicker. The biggest danger in deferring content in this way is that if your JavaScript fails to load the content is deferred. So there's a lot of situations where you might fail to have JavaScript so you're ready for a tube station and you only want a page and the JavaScript fails to load. You're on a train and you go into a tunnel. Fail to load. Or if it's just a patch of signal. So one that again is not a responsive site the talk tour business site is a prime example of when too much content has been deferred. When JavaScript fails to load the user not rendering any content at all. They simply have a navigation to a page that doesn't load because there's no content. So we should therefore be careful with what content we choose to defer a loading. Another thing I should have mentioned is if it's a JavaScript error as well that also the content might load. So there's lots of situations where content might not load. So we've looked at images and deferring content now we're going to look at how we can optimise how we load our JavaScript. As early what we saw on those pie charts was that in the past few years JavaScript has become the biggest source of file size of a site with an average site to have 299 kilobytes of JavaScript. So there are two types of JavaScript. The two types of JavaScript I'm talking about are critical JavaScript. This is the JavaScript that is quite initialised on the page. So this might be anything that loads the main JavaScript any rendering type JavaScript that does the pindresal bricking and stuff. So what the responsibility of the critical JavaScript is is it should add events to track how the user tries to interact with the page. So this back to the perceived performance we talked about earlier you want to make it so that the user can interact as soon as possible. When having interacted with something while we wait for the main JavaScript to load we should show a state. And then of course the critical JavaScript should trigger the loading of the main JavaScript. So then we have our main JavaScript. So this is responsible for firing any events that have been deferred. It's any deferred event listeners which will be replaced by the real ones. And then we include the rest of the functionality required for site to function. So how this might work in practice. So we took a look at the site. If I click that button what's happened is it's changed its state. And then eventually the client side of validation has fired when the main JavaScript has loaded. And then there's a second example to use a site and interact with the page. In the background what's happening is the critical JavaScript is downloaded in the main JavaScript. So when they actually get around to making a post and clicking submit the main JavaScript is loaded so they interact straight away. So how do you achieve this? One way is to use a library called critical.js which is available on GitHub and it's also available on MPM. You load the critical.js library and you specify where your main JavaScript lives. You can then add a data attribute specifying the events that have been deferred. So this is anything you can add with an event listener. You can add in this data attribute. And then in your main JavaScript you then need to handle it. So when the main JavaScript is loaded you need to ask critical.js if the button has been clicked that's going to return true or false. And then if it has been clicked we can then fire the method that we are then going to attach to our button. And then of course we are going to attach the real event interactions. So we talked about performance. So how do you measure performance improvements? So first it's very important that as you make changes to your website you are regularly measuring the site your performance so that you know if your changes you've been making have had a positive or negative influence. The simplest tool... The simplest tool... Sorry, I thought the slide won't change. The simplest tool through this is WebPageTest. So this is the slide I was expecting. So WebPageTest is simply enter a URL. You can select a test location where you should select a location where your users are and you can get a reliable test. You can select a browser and it's not just a desktop browser you can select. In some locations you can select just like photo devices so you can test how your site loads on a Nexus 5 or an iPhone 4. And there's advanced settings which allow you to configure connection speeds. So once the test runs it'll give you a benchmark. So you have... it gives you these A to F scores like first byte time, keep it live enabled. But today we've actually focused on start render and load it so let's look at those stats. So it gives us information on how long it takes to start rendering our page and also it tells us how long it took to render the page again so when it's loading stuff from the cache. Unfortunately my blog takes longer to render than the cache than it does from the internet. And again it tells you how long it takes to fully load the second time. Again it's slower for my site for the second time. Bad cache utilisation. So we have seen that the benefits of both the user and your business to optimise the performance of your site. It's therefore makes sense to focus on your efforts on making your site perform well. So in summary. When building a responsive site we should spend time focusing on the content and the performance. Our content should be prioritised that's right for the device and it should be discoverable regardless of the type of device you run. One of the most important things is the perception of your site to your users should be that it loads fast. You don't want them to feel it's a slow site because they'll simply leave. So there's much more in-depth stuff on my blog. I notice everything to do with this talk. I'll tweet that later. I have to thank loads of people because this talk I got loads of help. I got home with Callum Gray Phil Nash, a few people at work and my wife Charlie who had to put with me rehearsing this in front of her too many times. If you want to if you enjoyed this and want to talk with me again I'm talking at halfstackconf in November. I'm talking more about this critical JavaScript and critical JavaScript path and if you want to see this talk again I'm going to give it for one last time over the air in September. So thank you. Any questions? I use and contribute to a library called EchoJS which was originally written by Todd Motto but he kind of abandoned it so I kind of took it over. That one's really good. There's a few of the ones out there. The reason I use Echo is because the API is really simple to use. You just put some data attributes on the page and initialise it and then if you add new images to the page you re-initialise it and that's it. So the Echo is really nice. So it's something to scroll so basically what will happen is it will load all of the images that are in view and then you scroll down further on the page and normally you have an offset so I have that set to 1000 pixels so anything 1000 pixels below the fold will be loaded so you start scrolling and they don't realise to keep the right position in you. Thank you. It shows that there is another reason why width and height things are really important which is to many people I've expected them. Cool. Any other questions? Hello. So it's impossible to tell if they're on Wi-Fi really because the browsers don't re-expose that to us for good reason we can't re-infer much from that anyway because a Wi-Fi connection could be really slow it could be really fast a 3G connection could be really fast it can even be fast on the 4G so you can't re-infer much from the type of connection and I was at EdgeConf I actually went to the network panel and they were talking about how they could expose this stuff to us and it's very difficult the network because you have to do like how we have speedtest.net for testing on home broadband connections you have to have that running on every single site kind of so yeah, it's very useful. Yeah. Yeah. If you're using the browser then it should get us the stats to expose those to that site down script. Yeah, I mean if you regularly browse on sites or if you just browse on another site you could potentially have data in there in it. Yeah, you can usually do that yourself. There is an API isn't it? There's a form of this API in... Yeah, measurements, yeah. Measurements by the web page on the script? Yeah, yeah. Yeah. Yeah, it's very cool. So we we use BigQuery to look at Google Analytics so soon we're actually going to start using the performance API to send stuff up to BigQuery or to Google Analytics so that we can get out of BigQuery because weirdly you can't access the normal Google Analytics performance stuff yourself using BigQuery. Cool. Any other questions? So there can be benefits of building separate sites. The examples I've given would be Google Docs. That would be very difficult to make responsive. But for standard websites there's no reason you couldn't be responsive because there are CSS techniques and JavaScript techniques you can use to make them look completely different. I mean I showed that Nanshik example and now we're just using CSS and there's a very simple demo on that link that I'll tell you later. But yeah, it's becoming a lot harder to justify building mobile sites. It's only when it's a specific API type thing that you should do that. So typically what I've normally done is you can have a match media API to check you'd have a click event match media API say should I show a light box or should I not take you to a new page? Alternatively if you don't want to use a match media API you can just check the width of the browser because obviously a match media API has limitations of not being working out yet and stuff. But yeah, I actually wrote a have you ever used a colour box? The light box plugin? I actually once wrote a wrapper around that that allowed me to turn it on or off based on the width of the device. So there's also ways you could do it. If your designer wants to use web fonts they're stupid. No. In a designer's area is that? Cool. Basically the problem with web fonts is the way the browsers treat them is we don't want to flash of unsiled text so they give you white text. So there's some really good examples that I tweeted before like of the MSDM website I was looking some documentation for one match of my book and I just couldn't get it on my phone because it didn't finish loading. So what I would do is load those web fonts with JavaScript and then store them in local storage. So the first time they might get the flash of unsiled content but the second time they won't. Yes, great. I typically don't use it for body copy anyway because from accessibility point of view the web fonts don't render as well. Oh, yes. So specification for those who don't know is a forum where basically you're meant to be able to help contribute to web standards. Unfortunately it didn't work very well as I found out if you saw that discussion. Basically I was discussing that if I want to know the context of the user, like if they're using a TV which was an example I wanted but so from the web point of view is that we should treat a TV the same way we treat a tablet whereas I personally would say that it's a completely different type of input. So there is in media queries for support for detecting roughly the kind of inputs but finger and TV remote control are treated the same so I can't use that either. But you can't read targets like TV versus tablet at the moment. I'm hoping one day we can. User agent sniffing though. It works. It works very well. It's not ideal. I want a web standard that says that the browser TV should implement. This goes back to the problem that media types were never implemented properly and media types would have allowed us to do this because there was a media type TV and media type Braille and all these different media types and they've been breath-deprecated now because no one used them and TVs were saying they were a screen or they'd report it wrong and stuff. So you can only have a TV as a screen, right? Media types had that problem that TV was a screen and websites that were optimised for screens and because all those developers were putting only screen and media queries that's when we started to have problems. But the problem with screen is and media types you can't apply more than one media type. The specification says that you're only allowed to apply one so if they can apply a screen or TV and if everything is optimised for screen they're going to say let's go for screen. And this has gone back for years and years and years with MSN TVs and all that sort of stuff those things that they had in America when they were here. They never implemented these media types properly so they were deprecated by W3C. W3C's argument is that we shouldn't be thinking devices and types which why tonight I've tried to refer to mobile too often refers to small devices and desktop should be large devices watches I guess really small devices because they're trying to get us to think in the mindset of this constantly new device coming out and we don't know what's coming in the future. There was someone else's suggestion and he was like no. I basically gave up on that discussion because it was going on for so long and I kept saying the same thing basically and I was like no. There's an API to give me an IV monitor. It might be reduced to something. This is a three and a half meter monitor that my UI might be based on what I would do on it. Part of the problem with that though is how a resolution does not equal screen, right? But say you plug a monitor into your computer it doesn't know what size screen it is it just knows what resolution it is. But anyway. Screen will tell you what resolution it might but also what resolution it is. I don't think I've exposed it at least. I think it can be flaky as well. Sometimes it knows the size. I've got a 55 inch TV at home and it gets confused. Is there any trend in the positive? Is there recently that in five years from now we'll have more information and we'll all be... This has to do with a few things. I don't know if you saw recently they've decided to get battery information. So you can see how much battery life someone's got which then apparently can be used to track you in an equal meter mode. So I think they have to be careful about what they do. You've seen those everlasting cookie things that have been done now as well where you can like computer fingerprinting you can do. You can work up all plug-ins people who got installed in the browser and then versions fingerprint someone. It's all that kind of creepy stuff. So I think they're going to be very careful about what they add because obviously this is a kind of fingerprinting stuff. It's kind of a losing battle. It's kind of a losing battle. Oh yeah it's very losing battle. Yeah it's course and pointer right? But a TV has the same reports the same one. Well if it's supported it doesn't support it anyway. But it's reports the same one so yeah it's helpful. Yeah and that's one of the arguments was the viewport size because it's up to the TV vendor to set a sensible viewport size but then they should be set to the size of a tablet but then I want to treat a tablet and I think I'll say a larger discussion for Twitter. Everyone complaining on Twitter that we need to tell what TV is. Or we could do what the picture element guys did and just crowdsource something and then build it ourselves and you've got the picture element is the best example there because basically they crowdsource the money and then build the standard and build the play fill and then it's now part of the whatWG and cool. Any other questions? Cool. You can also ask me on Twitter now.