 That's a start, I think, at the time. Hello, everybody. I'm Cristina Chumillas. I'm a designer and front-end developer at Timbra. Design and Drupal shop based in Barcelona. And you can find me at the screen on Drupal.org or IRC or Chumillas on Twitter. First, we are going to check that statement that Mary Meakin made on 2008, saying that mobile was going to overtake fixed internet access by the year 2014. And it was something like that, because actually last year in the States, it was around 70% of traffic for mobiles. And I think in the UK, it was around 66%. So something like that. But what actually happened is that mobile isn't killing the desktop. What is actually happening is that users are having multi-device experiences. They start, for example, on the desktop, and then they follow on the mobile. For example, you search an address on the desktop, then you send it to your mobile, and then you get the directions to go to the place. So that's not exactly like that. And it was around six years ago when Ethan Markott named the responsive web design. And a lot of stuff has changed since then. A lot of processes, a lot of things have changed. So for example, the processes have been evolving since then. For example, the content first and the mobile first are really a thing nowadays. Everybody does that. Content first is having the main content, the most relevant content first on the website. I'm keeping that in mind. And mobile first is thinking first on mobile. The first display, the first small display that the user is going to see. And then just work together with content first. And then you have the thing that has to be on the first place. Another thing that has changed since then is that we don't work or we shouldn't work anymore with static compositions, Photoshop, PSD, PNGs. We shouldn't work with that anymore. Instead of that, we should use responsive prototypes. Why? Because the decisions should be taken on the browser, because at the end is where the user will consume your site. So you should decide on the browser. So you should go quickly to the browser and give prototypes to the customer because there the customer will be able to decide if he wants that or not. Another thing that has changed is we don't work with lower emission, with custom, with default content anymore. Because everything works on design. All the lines for a teaser have two lines. All of them work together. And that's not the real life. You have a real content. And you have one teaser with only one line. The next one has five lines. And it's almost impossible to make a design work if it doesn't be on the design from the beginning. So we should use real content and design with extreme cases. And the last year's atomic design and components have been also a thing, a really important thing, because it has changed the way we design, the way we conceive the web. Because we shouldn't be thinking of pages anymore. We shouldn't give to the final client. We give them a page. Of course, we won't give them only a style guide. But we need to think on different components to reuse them all among the site. Another important thing is performance. And performance is really, really important on responsive web design. Because actually, it goes with the detractors of responsive what the web design used against responsive. Because they say that responsive wasn't performance. And actually, it goes like that in some pages some years ago. But the fault wasn't about the responsive design. It was the implementation. It wasn't the technique. So when we talk about performance, we talk about user experience. Because if your site is going to take more than four seconds to be load, probably around 64% of a smartphone user will just leave your page. They won't wait. And bad news is that the page average is increasing year after year. Last year only, last year, it was about 16% of weight. And the year before, it was 15%. So it's increasing a lot. Nowadays, the average is around 2.2 megabytes. And that's a lot. What I really, really, really like about working on performance is having a budget for performance to say, OK, my website will have around 1 megabyte, 2 megabytes. Let's be realistic. So if this website, I really, really, really love it. Try it, because it's performance-budget.io. It's really useful. And for example, if I want my site load in two seconds, let's say on a 3G, fast 3G, because not everybody have 4G, but let's say a fast website. How many megabytes or gas do you think the website should have to be load in only two seconds? Any idea? No? No ideas? 200 gas. Only 200 gas on a 3G. It's science fiction. I don't know you, but in the last four years, I haven't had any website just with that. It's impossible. Just due to see that, having that, we should have around 125 images, gas for images. It's like you won't have a huge hero image. It's impossible with 200 gas. And seven gas for CSS. That's not too much. And let's remember that, 10 gas for phones. I will think about that later. So when we talk about performance at this user experience, we talk about the perceived performance. And it should be the most critical metric, because for interactions, we say that one second, an interaction happens before one second, around one second. We perceive it at immediate. Between one second and five seconds is something that's OK. It's human interaction. Between five and 10 seconds, there's the limit span. You still have the user there. But more than 10 seconds, the user has gone. You don't have the user there anymore, or at least his attention. So what can we do if we have a two megabytes website, and we only have two seconds? What can we do? The perceived performance is where it comes. Let's see, for example, you go to a bar, to a restaurant, and you order something. And you are waiting around 10 minutes until the food is there. So you are like that, just waiting, doing nothing. It will be a lot within 10 minutes. But what if, on the time that you get your food, someone brings you your drinks? And also bring you some snacks. You're doing something on that time. So you perceive that 10 minutes in a completely different way. So that's a perceived performance. Let's see this example. I really like it, because they really do it quite well. It's a list apart, a list apart website. I'm sure some of you will know it. And what they do is, well, at the beginning, there's the HTML call. The parsers goes there and reads the CSS, the jQuery, and modernizer, that's some GS. And when the parser and the browser render, all that stuff, something appears on the screen. This something is content. You can read the content. But let's see here that there's no phones loaded, not yet. So you are reading something. You can do something. You actually can read the content. But you don't have anything else. You don't have the logo. You don't have the phones. You don't have anything else. Just the main CSS and jQuery and modernizer. So that's a really thing. You still are doing something. Then other images, other GS don't load it. Then you have here the logo, the healer image. And suddenly this text disappears. What's that? I will talk about this later, but this flash of invisible text. Because look here, phones are being detected. So the browser says, I have to load the phones. When I have the phones, I show the phones. And then other stuff is downloaded. So that's a perceived performance. And that's something that we can do. We can custom our themes or CSS or implementation to play with a perceived performance. Here I have a small demo with the same 3G connection on mobile with the same list apart website. And let's see. First is a connection. There's nothing here. Then there's a content, some GS, some images. The text disappears. And it's just going on everything on its place. So you can start doing something before. Actually, you have all the stuff from the website. So when we do responsive, we should keep that in mind. So some tips will be optimize your image files, concatenate your text files, your CSS, JavaScript, minify them, compress them, of course, and cache everything you can. So if you see that, Drupal Core does all that stuff. But who works? Who builds websites only with Drupal Core? No one. So there's always something that we can do to improve the implementation. So if we are doing our theme, we will have to structure and optimize our CSS. For doing that, we have the CSS methodologies, the object-oriented CSS, BEM, broke element modifier. There's a lot of stuff around that. But the most important one for theming is the naming, block element modifier, name the elements according to that. Smacks is more a way to structure your CSS. You have the layout, you have each component, you have the theme layer. So it's a good thing to follow to work on your theme. And why are they important? Because you reuse your CSS. If you reuse your CSS, you reduce your page size. And you increase the page rendering speed. So it's faster. You also make faster the rendering. What do I mean? For example, you have the class box, the last child, and the title inside. You have that. And you want to go to the title and you will see, OK, the browser will go, we'll find all the boxes, the last one, and then the title inside. No, the thing is not that easy. The browser, what we'll do is we'll find all the titles on the page. Then we'll find the last box, and then it will be parsed. It will be rendered. So it's really, really important to have only one class for each element, because it will be faster for the rendering. Of course, this methodology makes your projects larger-scale ready. You can make huge projects. And it helps you to figure out what your designs are going to be made of. And it helps you getting started in a project, because you know where the stuff will be and how it should work. And style guides. You know what our style guides are, right? OK, living style guides are just a living document of code that details all the elements of your site. OK, from here, that's OK. But what happens if you go and change your CSS, because something is changed? Then the style guide is outdated. And an outdated style guide is a completely useless tool. If you don't use it, you don't invest your time on that. But the first time you have been used to build that style guide, it's completely useless then also. So you must have living style guides if you have living style guides, because otherwise, they are useless. There are different ways to implement it, but the most important thing is that they give faster built-in times for new sections and pages, because you know where is everything, where you have to go to find the way of building something. It is standardized, the CSS. It keeps small. And the design consistency is easier to maintain, because you always know where to go to see what's the correct title, the correct color. So it's easier. So they are really useful. If you don't use living style guides, you will end up with 50 shades of red. Yeah. I've seen that in many projects or in many designs, and it's awful. So, ah, wrong button. OK. Another thing that we need to have in mind is the difference between fixed pixels versus relative units. Um, no. OK, we have the pixels, the AMs and RAMs. Usually 1AM and 1RAM is 16 pixels. That's the default for all browsers, unless you define something else on your base theme. And, um, no, OK. Let's forget it. The best one between them, of course, we are doing responsive. We don't use pixels anymore. Between AMs and RAMs, we should use always as we can. That we can, we should use RAMs. Why? Because they are more reliable. Because if imagine that you have a title inside the teaser, inside the sidebar. And you have 1.1 from the previous one on the 1.1 AM on the teaser and 1.1 AM on the title. If you don't know or you don't remember that you are working on AMs and you already have 1.1 AM on the previous element, on the further element, you will end up with a 19 phone. But if you work with RAMs, you don't have to care about that. So that's better always that you can work with RAMs. Another thing that I love, because I just discovered them one year ago, and it was like, where have you been? Is the viewport size units that for building hero images are super useful? And actually, they have been, I think, for four years. Even Internet Explorer works like that with that. But there's a path always with Internet Explorer that don't support VMAX. Here we have an example for these viewport units. And another thing that is really important on responsive design is typography and working with responsive typography. How we decide which phone size we should use. We know that on mobiles, we need to have a smaller size. On TVs, we need to have a bigger one. But why? Because we decide the phone size, depending on the user distance of the screen, not the device screen itself. Why? Because you read your mobile here. Your laptop is here, and the TV is there. That's why the TV needs a bigger phone than your mobile. That's the why, not because the device is smaller. So when we decide the size, it's because of that. Just a quick tip. When we decide the phone size, we should be thinking about having between 14 and 40 characters per line. More than that is bad for the user, because if you have, for imagine, 100 characters, it will be hard for the user to jump to the next line, because it won't be easy to find the next one, because you don't know where it's exactly the next one. So it should be between 40 and 80 characters. So what the phone size fits there. That's the phone size you need. As a general average, we will say that on mobiles, we will use the 14 pixels and 16 for the desktops. Some facts. Do you remember the 200 cut that we said before on two seconds? OK, it's about 5% for phones. That's 10 cuts. And here we have the open sans, the super used open sans phone. The wolf, that is the modern, the best choice, it's 23 cuts. But that's a regular one. There's the open sans italic, open sans both, and open sans both italic. So it's impossible 10 cuts. So do we really need phones, of course? All of them? No, I don't think so. So some tips about using a chosen web phone's format is that if a browser is already reading some format, don't use more formats. I mean, for example, the wolf, everybody reads the wolf. It's compatible with almost everything, instead of Internet Explorer. But you can use EOT, the old EOT for Internet Explorer. If you already have that, don't use SVG. You don't need it. So keep the weight of your website and only use what you need. Do you remember the flash of invisible text we saw on the demo? Before of that, there was the flash of on a styled text. It was the browsers that displayed the default phone from the system. But the phone wasn't the same that you decided for your design. So suddenly, when the browser got the phone, everything just moved. So the browser said, let's remove it. And when we detect that content is going to need a phone, we just don't show the phone. And the fault, the fault became there. So we have fault for it. And none of them is the ideal. So some other stuff is going on. There are some ideas like picking a phone that is really similar to your phone, then adjusting it takes a little bit. But that's a work in progress. And there's no any standard way. But the best way would be if you can use system phones, use them. Because, for example, for text, they are really good. Some examples for some ways for adding phones to your websites would be the phone face. It's powered by CSS. It's accessible. You don't need external plugins. But usually, there are two big phones, and there's no common format. Another one would be phones.com. You have a large collection. You have exclusive phones like Oletica Neo. But you have to pay. You have Google phones that is always only CSS, unless you want to use a web phone order, I think its name. It's really accessible. It's really cashed. That's what I really like from Google phones. Because it cashed to the phone. If you visit one site, and then you go to another site that is also using source hands, you don't need to download the phone again, because it's already in your browser. And of course, it's really, really easy to implement. And also, we have Typekit. We have the largest phone livery there. It's accessible. It's also cashed. It's easy to implement. And it has a premium service. You have to pay. And it's from Adobe. Some tips about typography. Always try to keep the visibility of your phones. Choose the correct phone size, depending on the container. Use less phones. Do we really need them? Maybe you need phones for your titles, because they will see really good. But when you are on a 14 pixels phone, there is no so huge difference between phones. So do we really need them for the body? Sure, we need them. And use more phone formats always that you can. And of course, because it will reduce the page weight. So next step, images. They are really important on the traffic, on the web. I really love this, because that's evident. Come on, everybody knows. GPEC is for photos. PNG is for logos or plain images. PNG 24 bytes is for transparencies. Yes, everybody knows. We know that, but not the customer. I remember once when we were the day before of the launch of a big website, and I was just checking the last check. And it was like, wait, 5 or 6 megabytes. And it was like, oh my god, what's going on? And I realized that we used the default content to create some content for the website and test everything. And the customer saw it, and he said, great. I love that image. So he used that. But all the images were made on PNG, and they were photos. And the only thing that happened is that I had to change it. But because I realized about that, but the customer didn't. So just try to keep it in mind. Some facts about images is that they are around 61% of the traffic on internet. The browser requests the images asynchronously, so that's great. But we usually load images too big for the device. So the aim should be to deliver the highest quality images supported, but nothing more, not a bigger image. So to do so, we have the scaled images. We have several options, but one of them is the scaled images, where it will work. Yeah, we have the Azure set here, where we say which image should we use, the sizes, and the fallback image. And that's just for changing resolutions, not for changing the image, only just to scale the image. We also have adapted images. That's a picture that you know. That's for changing images. For example, that one is horizontal, and that one is vertical, and they are completely different. Well, they are the same, but they have different proportions. So we have the picture that it's supported by everyone, but internet as well. And Opera Mini, we have here the source, where we define the different images, each for each resolution. Here we use media to say where should it be seen, and we have the fallback image here. That's picture. So on Drupal 8, we have responsive images, the old picture, in Core. It's disabled by default, but it's really quick to enable. And it has its support, because breakpoints already does different resolutions. And we also have lazy load, and Drupal 7 is on the picture model, is a country on Drupal 8. And I have a quick example for creating responsive images. First, we just enable the model, then we go and create all the image styles that we are going to use on the responsive group. In that case, I'm just creating the teaser. Try to use that to put the pixels on the name. It's really useful, otherwise you can end up with 50, 100 styles. Here I create the other ones just a little bit quickly. I would love to work that quickly. And we have the three that we need. We go to responsive images. We create a new group. We say the teaser. And I choose a group, a breakpoints group. That one is from Bartik, because I'm working on Bartik. I choose each image style for each breakpoint. And we also define a full book image for Internet Explorer and friends. And here we have, we already have it. I prepared a view, a super quick view, an easy view, where we just add here the image. And we choose responsive format with the group teaser. And it's linked to the content. I reordered it because it's nicer. And that's all, we have it. We go here, we have a list of teasers. And if we resize it, we actually have responsive images. So you see the difference between the proportions. So it's that easy now on Drupal 8. It's really, really great. We are really lucky to have that on Drupal. We don't realize that sometimes, far, far away, some people have troubles with that. So another thing that we have on Drupal 8 right now is the crop appy. We have the image widget crop module that where the user can choose exactly what part of the image want for each image. Image style, sorry. And we also have focal point that it's even easier. The user only choose what's the most important part of the image and then automatically crops the image. Believe me, it's super easy to implement. And the user is like, oh, it's super easy. Drupal rocks. So if you can, use it because by default on your websites, if you use responsive images, because it's super easy. And in the implementation, it really is easy. You just choose, instead of scale and crop, you just choose scale and crop, focal point. And that's the only difference. So it's really useful. What else? Designer's creativity. There's always one more thing on design. So what if your designer, or me, I'm a designer also, decides that on mobile, he only wants one apple. So responsive images doesn't work here. Yeah, so we need different images. What we usually do is we create, there's nothing still on Drupal 8 for that or on Drupal 7. What we do is we create one field for each image. Then we create the image style for each bread point. And then we prepare everything on Drupal 7. It goes preprocess, hook. On Drupal 8, I think we really don't need to prepare it. It's a filter. But I'm not sure I've done this only on Drupal 7. And you finally print it on a custom template. You write the picture stuff on the template, and then you have it. So it's a way to solve the designer's creativity. What I was saying before is that there are solutions that people need because they don't work on Drupal with Drupal. So there's scaling based on the solutions that scale based on the targeted end result, like responsive.io or other solutions. There are also solutions that scale based on the URL, clothing area, and other places. And there are solutions that scale based on media queries. So there are some options out there. If you want to use it, you can do it. But Drupal just works by default. SVGs, I will need a complete session for talking about that. But some of the most important thing about SVGs is that they are scaling. They have design control like interactivity and filters. They are footer proof. They are easy to make and to edit because they are cold. And they are highly compressible. And you can manipulate with CSS and JavaScript unless you are working with Internet of Floor. So always, as you can, use SVGs. Don't use SVGs for photos, of course. But if you can use it, try to use them. Asynchronous loading. What's the default behavior, for example, for JavaScript? There's a connection, the ACT-CML. Then the parser reads every line. And he phones, for example, the CSS. After this, the first JavaScript, the second. But after it is rendered, the browser doesn't print anything. So we have a problem here because we have to wait for that. There are some solutions out there, but it will be the default behavior. You place the script on the head just after the CSS. But we have the Async property that will tell to the browser that it has to be. He doesn't has to wait for that. It's good because, while the JavaScript is file is loading, the parsing of the document can continue. The JavaScript of execution no longer has to wait. But you can't guarantee the order of the JavaScript execution. The problem is that you remember that on the example I said from a list apart, there was the ACT-CML, the CSS, jQuery, and Modernizer. Because if you need something from there, you need to be sure they are loaded first. There's another option that's a defer. That solves that a little bit. It's just adding the property defer there. It deferred the scripts. The deferred scripts are executed only when the ACT-CML has been parsed. The deferred scripts will execute only in order that they appear. But it has the potential to interfere with the rendering of the page. So it's a little bit dangerous. And of course, the asynchronous has priority. So just keep that in mind. That's how the asynchronous loading could work. The most common options will be just having the typical JavaScript on the head of your page, or adding to that JavaScript these properties. You could also add the JavaScript here. And of course, you can add the JavaScript at the bottom of the body. Those are the most common options. Approximate browsers. We always forget them because, come on, who uses Opera Mini? Again, sorry. Who uses Opera Mini? $250 million at least uses them, OK? Mainly on India, Indonesia, and that countries. Maybe they are not our target. But they are hard users of that. So a lot of people use them. So we should keep this kind of browser, especially Opera Mini, in mind. Why? How these browsers work. They reduce the language, the data that the browser is going to use, compressing the resources on a proxy server between the site and the user. There's a proxy server. And then sends to the client just the compressed version and parsed version of the website. To work with them, we should try to use SVG rather than e-confunds. I don't know if you use e-confunds anymore, but try to use SVGs. So instead of that, they are super cool, but they have a lot of troubles. Not only on Opera Mini, but on other browsers. Always that you can style on your HTML with CSS, not JavaScript. Test your site without JavaScript, because sometimes the JavaScript just disappears. Of course, that's make your site performant, because they use Opera Mini because they want to use less data. So making it performant is better. And that is obvious, but test on Opera Mini is not that difficult to do. And it can help a lot of people. So I keep trying using that. Progressive enhancement. That's a really important thing, because it helps a lot this kind of user that use this kind of browser. The idea is using the basic content and the basic functionality for this kind of browser, like Opera Mini, and then serve an hates version for a bunch of browser or the ones that have more brand which to use. Beyond the mouse. When we test, when we develop, we work with our mouse, but there are touch event and keyboard event. We don't have the mouse on the smartphone, of course. So some tips to work with that is save the hover for shortcuts. Of course, the hover sometimes is really, really useful, but if you make, for example, your navigation with the hover, people with smartphones will have a lot of troubles. There are most of the operating systems have been developing different ways, because the hover is two clicks on iOS, for example. But to be safe, try to avoid the hover only for other kind of stuff, for example, a different image, a different color, so don't use it for an important thing. So be accessible in browser where a mouse pointer may not exist, and don't assume that the touch will be used, but design as it will be. So don't design your navigation with hover. Another thing is keeping touch. What does it mean? If you put the cursor on the side of your finger, they are completely different. So when you design a button for a smartphone, for a mobile, it should be bigger. For the finger, it should be 77. And for the zoom, it's even bigger, because you need more space. But not only for that, because not only because the space you need for the finger, but also because you need to have some safe space around it. And another quick tip is don't overwrite system defaults. If the system use some gesture to move to another page or to go back on the history of your browser, don't overwrite it, because you will annoy the user. So try to avoid it. And the last point is responsive design patterns. Patterns are really, really important, because we really don't need to invent the wheel on each website we design. There are things that are super cool, but the user needs to learn it. So the less things the user needs to learn on your site, more comfortable he will be there. So he will stay there for more time. That's really good, for example, for commerce. Don't invent anything, because people need to feel safe, needs to understand everything on the first moment. So design patterns are the current solutions that solve common design problems. For example, navigation patterns would have the typical off-site navigation, like Facebook. That applies to manuse for tabs, for example, for breadcrumbs, for carousels, pagination. Always use a pattern, if you can, because the user will remember it. For example, for forms, always as you can use a pattern, because the user, it will be faster for the user. For dealing with data, for example, for slideshows, for tables, for autocompletes, for search things, always that you can try to use patterns for that also, for shopping, for onboarding, for social. Then we have the progressive disclosure. That's a way of what it does is showing you the most normal thing, the most important thing, the thing that most users do on the first place. For example, here you have the email, so you click, and you go to the mail. But if you want to do more stuff, you have to move on right or left, and you have some hidden options. So that only shows the main option, and then show the other options, only if the user needs them. And, well, some conclusions about responsive nowadays. Keep adapting your workflow. It's really good to get new things on your workflow, keeping weight. Take the most of new technologies, because they can help you to make everything faster. Keep the user in mind, please. At the end, he will suffer your website, so think on them. And be prepared for the uncertain. We don't know how the browser will work in five years, and probably the website will be still there. And the last one, keep evolving, because the website is doing that all the time. So that's all. Thank you. One more thing. There are the contribution sprints. They ask us to put that information here, and a little bit of spam. There's the Frontend United in Greece next year. It's Greece's amazing on Athens, so if you want to go there, just remember that it's there. And evaluate the session if you can. Thanks. Any questions?