FREELessons: 14Length: 2.3 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

1.2 What “Responsive” Means Today and What You’ll Be Building

Responsive Web Design today often refers to more than just having a layout that responds to different resolutions. It now tends to be a catch-all term which means providing equally great functionality on all platforms. Through this course we’ll be walking through the creation of a complete responsive design of this type. In this lesson you’ll see exactly what you’ll be creating before we set out, as we preview all the responsive features you’ll learn to build into your projects.

1.2 What “Responsive” Means Today and What You’ll Be Building

Hey, this is Kezz Bracey of the Tuts+ and welcome to the first lesson in Responsive Web Design Revisited. We're gonna start up by asking the question, what does responsive mean in the world of web design today? And that will take us through to why we're revisiting it in this course. So, it's fairly widely understood that responsive means you have to create layouts that are going to fit on phones and tablets just as well as they do desktops. And that generally means that we know we wanna make smaller layouts just as important a part of our process as larger layouts are. That we need to use media queries and break points and that we want to have a high level of performance, but if you want to give all of your users the best possible experience of your sites, then there are several other things that responsive should mean too. On your screen right now is the responsive site you'll be creating in this course. Now, I'm gonna show you the additional layers of responsive functionality that this site has, that many sites today don't include. And by the end of this course you'll know exactly how to create sites that function in just the same way. To contrast, this is a site that does not function in the way you'll be learning to create. Now these two look identical don't they? Well that's until they need to start responding in various ways. Okay now the first thing we're going to have a look at is how the base font size settings of each of the two sites effect their responsiveness. What you don't see at first glance with these two sites is that our first example here, our properly responsive site has a base font setting set in REM values. So these are relative, scalable units. While this version has a base font size set in pixels. And this is still something that's very common in web design is to set an explicit base font size as a pixel value. Now what happens if we jump into the settings for Chrome. Just shrink that down to make it a bit easier to see. Jump into advanced settings. And you'll see here we have the ability to change the font size that will be the basic default font size for the entire browser. You can change it to small. You can see the effect there. You can change it to large. Or you can change it to anything in between. Now let me just pull this off the screen so you can see what's going on a little bit more easily. Now with this responsive website, now I'm scaling this base font size up. And you'll see that the entire layout has adjusted along with it. I'm gonna scale the base font size up to 22. And you can see that everything is still fitting and working beautifully. Now, I can scale this font size up pretty much as high as I want, and the entire layout is still going to be perfectly functional. And all the content is going to be perfectly readable. Now just pull this back down to 16. Now, let's have a look at our fixed pixel based font size version. Now, I'm gonna scale this font size up and let's see what happens. Not very much. So you can see, some of the fonts I've set some of these, headings and end values, but a lot of the text just stays exactly as it is. And you'll also see, that as I increase the font size, the layout does not accommodate the adjustment. So we end up with a fairly broken looking sign. Everything's out of proportion. Things are not very readable. And everything looks just a little bit off. Okay so let's check out the next comparison. In this version of our site, we no longer have a fixed pixel based font size throughout. We now have a rem based font size. So we do get some improvement. However, in this layout we still have pixel based dimensions on all the rest of the non text element. Let's see what effect that has. Okay. So if I scale the font size up to, from 16 to, let's say 20. We've got some improvement because now we have a little bit more consistent font formatting. However, we're still ending up with a crammed looking layout. It's not really working all that well for us. And as we continue to enlarge it, you'll start to see worse and worse effects. So pull that back down to 16. Now what we really want is to have a completely scalable layout. And what we have in our original example that you'll be learning to create is scalable relative units for everything. So now you can understand why as we scale up the font in this version everything responds beautifully because we are not using any fixed pixel based values anywhere. We want everything to have the option of scaling and adjusting to fit. All right, the next thing that we want to have a look at is video embeds, and other I frame embeds. Now, in our example here, the video will scale down, or up, as it needs to, to fit well inside the content. However, in our other example, when you start to scale down the browser size, you don't get any good responsiveness from this video. It's fairly common for responsive images to be catered for, but in this course you'll also be learning how to deploy a script that will allow iframe embeds for videos and other media to also scale really easily. Next up is another issue that still pops up quite commonly, and that is menus relying on hover based interaction. So in this site here we have a fairly standard dropdown menu. You hover over the parent and then you get the dropdown child menu. But, what happens if for whatever reason, the user doesn't have a mouse? Now, we can use a really cool tool that comes built into Chrome now, and it will allow us to emulate a touch base interaction. Now let's have a look. So, I will open up Chrome Developer Tools. And I can then hit this little mobile icon and that will give us an emulator. I'm just gonna drag this off screen so you can see better. We'll refresh that, because you, you do need to refresh each time you use this tool. Okay, so now we can see without having that hover interaction, I can't see the child menu's is nothing that I can do to bring them up. And, that gives us a, a pattern that you've probably experienced yourself, when browsing the web on touch screen devices, and that is trying to chase dropdowns before they disappear, as you go to the next menu. So if I click here I see that drop-down flash for a second before it goes to the destination of that menu item. Now obviously that is not an ideal behavior. In contrast let's have a look at how that is handled on our site that you'll be creating. Now this has an actual touch base interaction system built in. Now if we hit this little expansion icon we get a drop down that stays there until the person has finished dealing with it. Then, they can either click on one of the child items to go to it, or they can manually close the menu again. And on top of that, we also have a second version of our touch friendly menu, that works when there's not enough space to show all these menu items. Now if we rotate this Apple iPad emulation, you can see it switched us into this more compact version of our menu. This compact style touch-friendly menu is something, it's very likely you're familiar with. And that brings us to another one of the things that we'll be addressing through this course. One of the approaches to handling touch-friendly interaction that's still quite common is to have a hover-based interaction at a size that is assumed to be a desktop size and then a touch space interaction at a size that's assumed to be a touch friendly layout size. So, for example, a site may switch to it's compact, touch friendly menu size at around 980 pixels and having a hover based interaction only above that and this is common even at a high level of web design and let me show you why that's still not the right way to go about it. This version of our site uses a method of switching to a compact, touch friendly menu at a resolution that is assumed to correlate with a touch base device. So, in this case it uses a resolution of 908 pixels. Now I've taken that resolution from looking at multiple examples of site designs that are quite popular. Now, that's all well and good, theoretically. So let's have a look at say, how this would look on a Google Nexus 7. Okay, that's all good, it switched to the compact touch friendly menu, that'll be just fine. So is it then reasonable to assume that anything below 980 will be a touch device and anything above 980 will not be. Let's find out by switching to some of the different emulators here. We will start by having a look at the iPad 304. Okay, well that didn't work. The iPad 3 is 1024 pixels wide, so that is not switching to our touch friendly menu, based on our resolution that we have said to have it switch at. And we also have devices like Google Nexus 10, which is 1280 pixels wide. Or even notebooks with touch screens. And in this example it's also 1280 pixels wide. So even if you chose a larger number, if you set your menu to show up at anything below 1200 pixels, you would still mick, miss out on several different devices. The bottom line is you can't use resolution as a way to decide when you need to provide touch interactivity. In actual fact, there is no reliable way to determine whether a device has touch capability or not. So, the best rule of thumb is to always provide touch capability. The last thing I wanna cover is using rem values in your media queries instead of pixel values. Now, right now, by far the most common approach is to set your media queries at specific pixel widths. Now there's a problem with that, and that is that ties your layer, the way your layer adjusts, to the dimensions of the view port. But because what you're trying to do is make sure that your content is always readable, the way that your layer adjusts should be based on your content. Let me show you what I mean. In this layer we have pixel based media queries. So as the viewable area decreases in pixel width the layer adjusts. And at face value that seems okay. However, with this layout, we have rem based adjustments. Now, this takes effect, this becomes important, again, when we change the base font size settings in the browser. If I start to increase the font size, you'll see that as we get bigger and bigger, we actually trigger some of the built in layer adjustments. So you can see that we've switched to our compact menu when we've run out of room. We've reduced the number of items per line. We've changed up the padding and that will continue. So no matter what happens to this content it's going to remain readable. With our pixel based media queries however, nothing happens because as far as these media queries are concerned the width of the view port hasn't changed. So for that reason nothing else has changed, either. Now, why is this important? It's because we want to be flexible. For the same reason that we no longer want to work off pixel-perfect Photoshop designs ported directly into the browser, we also don't want pixel-perfect code. Everything should be flexible, scalable, and adaptable. Now, there's all different types of reasons that a base font size might be changed. You might have somebody who struggles to read the tiny font on their small tablet. You might have somebody that changes the font to a larger size so that they can read the internet on their TV. I know, I myself, I often use the Internet on my television through my games consoles, through a laptop plugged in to the TV, and I'll typically have it zoomed in to 150 or 200% zoom. And I'll have the text enlarged. And there's a lot of sites that break, when they're viewed like that. You also are gonna have all different kinds of devices that you're dealing with right now and that are gonna come out in the future, and you might find that vendors are changing the default font size to better suit that device. So what we're looking at is a shift in mentality away from focusing on specific devices and specific pixels, set resolutions, and over to a fully flexible way of thinking about our designs. And in this way of thinking, content comes first. You don't put mobile first or desktop first. You put content first. And in the next lesson, we're going to dive into this content first methodology. We're going to look at what content first really means, why it's the best way to go, and how you can employ a content first workflow in your web design. I'll see you in the next lesson.

Back to the top