Responsive Web Design: Creating Flexible Websites That Last

1. Introduction: One of the best and one of the worst things about the Web is how frequently it changes. For me at least that's incredibly exciting because I get to re-investigate different techniques for designing for the modern Web. Hi. I'm Ethan Marcotte. I'm an independent Web designer, author, and speaker, and today's class is about responsive Web design. Responsive design means that we can create one Web experience that's served up to every device and browser and it'll intelligently reshape itself depending on the size of the screen. So, in this class we're going to be looking at a design that was created for a fictitious magazine and then translating it into a completely responsive design using the three ingredients that every responsive layout has: fluid grids, flexible images, and media queries. As we look at every one of those ingredients individually, we'll be putting them together to create a completely device agnostic, completely responsive design, and toward the end of the class we'll be looking at some strategies that you can use to reshape your design process to help you become more responsive front-end developer for the screens that we know about today as well as for the ones that haven't been invented yet. I think that flexibility at the heart of responsive design is so important and it always has been important because we've never been designing for just one size screen. I mean, there are browsers embedded in the dashboards of cars now and this is not the Web that I signed up for, but now we have the ability to actually design one experience that can reshape itself flexibly regardless of where it happens to be. So, this class I think is really for front-end designers and front-end developers. We'll be looking at a little bit of CSS, but you don't need to be a CSS expert. We'll be working through some of the fundamentals of how you can actually translate your designs into a responsive layout. For me, I really hope that you walk away from this class with a real appreciation of what it means to be a mobile-first designer and how that will change the way you think about designing for the modern Web. I'm so glad you decided to join this class. Let's get going. 2. What is Responsive Design?: So let's start the class by answering the question, what is responsive design? Because when I work with a new team or new client, that's one of the first questions I get. Because everyone is incredibly excited about that phrase, responsive web design. But everyone tends to have a slightly different idea about what it means for them and for their company. So, I'd like to start today by telling you some of what it means for me as a designer. To do that, I'd like to tell you a story about a tree. But this is a rather special tree, and it's located in the heart of the Pando Forest, which is in Utah. Now Pando is rather special forest. It's some 100 acres in size. So, let's say you and I are traveling side-by-side through this forest, and as we do so, we're surrounded by some incredible nature, this beautiful white tree trunks shooting up out of the ground all around us as far as the eye can see. After some time travelling through this forest, I turn to you and I say that I've lied to you, but just a little bit. Because you see, Pando is not actually a forest, Pando is just one tree. You see, Pando is actually the Latin term for ''I spread.'' Pando wasn't what's known as a clonal colony, it's one single giant quaking aspen tree. So each tree that you and I might see with our eyes is actually just one stem and every single one of them shooting up out of this massive underground root system they all share. There were some 40,000 stems estimated be in Pando today. Now, Pando is actually quite an old tree. It's some 80,000 years in age, which basically makes Pando one of the largest and one of the oldest known organisms alive on the planet today. I think this is a really wonderful story to start with. Because I think as designers or maybe as human beings, we tend to look at things that seem visually complex, and it's our instinct to see them as more distinct and more separate than they actually are by default. I've been thinking about that a lot in my own design practice. Usually, when I'm looking at a different forest entirely. Which all the different devices and browsers that I'm being asked to deliver a beautiful and compelling experience to. That's a more complex forest that I've ever had to deal with when designing for the web. But the thing is, is that when we're designing for the modern web, this is just table stakes. The web is anywhere and everywhere that our users happen to be with whatever screens happen to be closest at hand. So, at least for me, it's critical to understand the web as a completely flexible design medium. In other words, when we're designing for the web, we're designing for a complete infinite canvas. It's completely flexible canvas, and our designs have to be as flexible and as accessible as the devices are that our users are holding in their hands. What's exciting for me as a responsive designer is that there's so much excellent responsive design work out there on the web today that I can draw inspiration from. I'm sure you found so many wonderful responsive sites out there, but let me show you a few examples that I really like today. The exciting thing I think about responsive design as it's happening today is that there is really great responsive work being done across different industries. Here's Amherst College, which is a really great example of a responsive Higher Ed site, and it's beautiful, and it's impactful on pretty much any size screen. You notice that as I'm resizing the browser window, the responsive design is changing its shape to make it accessible to screens both small and large. Publishers too have been using responsive design really effectively over the last few years. Here's the Financial Times, which has a very stately and very beautiful responsive layout, using flexible grids, flexible images and media queries, to create a really beautiful responsive experience. But it's not just about publishers or Higher Ed websites. There are a number of web applications out there that have been using responsive design very effectively as well. Here's Adobe Type Kit, and they have a very complex interface that you can use on screen small and large to not just browse fonts but also filter them along a number of really complex axes. The reason so many of these organizations and companies have gone responsive is because they recognize the fact that being device agnostic is just table stakes for designing for the modern web. We're designing for so much more than just desktop devices. Mobile computing has exploded in recent years. There are some eight billion mobile devices estimated to be in use worldwide, and that number doesn't seem to be going down anytime soon. Tablet computing isn't necessarily the newest kid on the block anymore, but it's still floors me that in 2011 alone, some 80 new tablet devices entered the marketplace in one 12 month period. That seems wild to me. So with all the churn that we're seeing in both mobile and tablet computing, there's an understandable amount of investment and experimentation in trying to understand what the next post desktop context might be. So, there's a considerable amount of investment happening in smart TVs and smart watches and so many new different screen contexts that actually have really powerful browsers on them as well. How many of these are we are going to be designing for in the future. Now when we're looking at a complex marketplace like this, it's very tempting to say that we should be designing mobile specific experiences or tablet specific experiences or desktop specific experiences. But actually it's much more powerful and much more freeing if we stopped designing for individual devices and instead think a little bit more flexibly. Think about delivering one experience that can be viewed on any sized screen. Because ultimately we're not just designing for devices, we're designing for the people on the other sides of those screens. Think about a reader of your website who might be coming back to that website at multiple points in the day with whatever device or devices happen to be closest at hand. This is something that a lot of publishers and organizations have actually realized. That by being a little bit more flexible and not trying to control the experiences much across different devices, they can actually drive and improve engagement across all those devices by being a little bit more device agnostic in how they design for the Web. Ultimately, responsive design means that you're designing one flexible experience, that's delivered to every device that might visit that website. Now, that experience might change in its layout or its presentation depending on the size of the screen but that's okay. Because ultimately, it's one website that you are delivering to all of your users. In doing so, that's going to help you reach more devices and more people than ever before. So, these are just some of the things that were cycling through my head when I first wrote that article called Responsive Web Design. This is an article that was published back in 2010, which is basically saying that the flexibility that's inherent in the web is something that we need to see as a strength, rather than something that we need to try to control or limit. Now, in the article, I put forward this high level recipe for what makes a responsive design. Specifically that every responsive design begins with a fluid or flexible grid-based layout. A layout that's built with percentages and proportions rather than inflexible pixels. Then, there are images and media that are flexible themselves that work within those flexible layouts. Finally, we have media queries, which are a little bit of pixie dust from the CSS specification. They allow us to control the flexibility in ways that are useful to us. We can change and adapt those fluid layouts at different breakpoints. In other words, creating layouts that can change their shape and represent information. In other words, they can respond to the changing shape of a browser window or the device's display. So, that all sounds very technical. But ultimately, it's important to recognize that a responsive layout at the end of the day is just flexible in nature, but then it changes and adapts at certain breakpoints to make it accessible to screens narrow and wide. In this course, we're going to be looking at the sample design for fictitious magazine, one that was created by, for, and about dinosaurs. Now, the sample files for that design are going to be accessible in the resources section for this course. If you'd like to follow along, please do. But this design is what we're going to use to actually show you how those three ingredients from a responsive design snap together. So, we'll be using fluid grids, flexible images, and media queries to translate this design into completely flexible, completely responsive design. We'll also look at some strategies to change our design process, so that you can be more a flexible designer or developer yourself. With that, let's get started. 3. Step One: Fluid Grids: So, let's start with the foundation of a responsive design which is really a flexible or fluid grid-based layout that's going to power your entire experience. Because really every responsive design begins with a flexible foundation. So, let's take a look at how we can translate a markup for a design and turn it into a completely flexible grid-based layout. So, this is the markup that I've created and sketched for our fictitious magazine called Rawr which is by, for and about dinosaurs. Now, if you've ever designed a webpage in Photoshop or in Illustrator, you're probably going to be pretty familiar with how a layout like this might work. Now, this is just a picture of a website and from top to bottom we've got things like recent articles, a cover story, a letter from editors to the magazine and then finally, a footer all the way at the bottom. Nothing really super fancy, but this is actually really nice use case for us to show how you can translate a fixed-width design into something that's much more flexible. Now, in the resources section for the class, you'll find a link to some sample files that I've created and I'll be using these today to basically work through the three ingredients for responsive design and show you how they can actually be applied to our sample layout. So, I'm going to start with the very first section on creating fluid grids. So, in this HTML file, I've created basically a simple lightly style design for the recent article section on our sample layout. Now, you'll notice that there's not much in the way of design, there's just some simple font sizing and simple styles and there's no images. I really just want to focus on the content and the layout for this first section. So, if I'm going to translate this into a completely flexible grid, I need to go back and look at my design. Now, in this mock-up, I'm going to focus just on the recent articles. I've got a very straight-forward five column grid for this wide screen layout. Now, if I want to translate this into HTML and CSS, I can basically use something called CSS Grid to build this layout fairly quickly. Let's take a quick look at the HTML for this one module. So, inside of this articles recent div, I've got four elements. I've got the header which contains the title for this section as well as a link to read more articles and then underneath that header, I have two articles which are basically teasers for the content that I want the user to read or click on. Then finally, have an aside element which contains a list of additional links, basically to secondary stories. If we go back to the layout, you can basically see that that's more or less what we've created. So, in my mock up, I'm going to focus just on this recent article section. What I'm going to do is, I'm going to take a quick inventory of the different kinds of content that I have inside of this module. Well, right off the top, I have a header that announces the title for this recent article section as well as a more link off to the side that allows me to create a link to more articles. Then underneath that header, I have two prominent stories which are basically just teasers of content to entice the reader to tap or click on those articles. Then, I have a list of related articles shunted off to the right in a sidebar. Now, I'm not going to focus on the layout, I just want to focus on those different content types because what I've done is, I've translated those into some rather straightforward markup. I've got a container for that recent articles module and then inside of that, I've got a header with my headline, hence the name. Then, I've got two article elements which contain a little bit of teaser information for those two pieces of content. Then in this aside block, I have an ordered list which contains again, a list of links to secondary stories. If we go back and look at our prototype, that's more or less our starting point, we don't have a layout, but we have some light font styles applied to that very straightforward markup. Now, if I want to translate that layout into HTML and CSS, I'm going to go back to my grid and take a look at the columns that I'm working with. Now specifically, every single one of these columns is 180 pixels wide and I've got five of them and the gutter between each one of those areas is 25 pixels wide. Now, this is just in my markup and I'm dealing with fixed inflexible pixels. Now, if I wanted to build this layout fairly quickly in my CSS, I could do that with something called CSS grid. Now, CSS grid layout is a fairly new way of creating layouts for the modern web. If you've ever done anything with floats or absolute positioning, CSS grid actually combines the best elements of both of those and allows us to create layouts much more quickly, it's incredibly powerful. So, for example, in my articles-recent block, I could write a little CSS that basically says, inside of articles-recent, I want to set this to display grid and then I'm going to do grid template columns and then I'm going to do 180 pixels and I'm going to write that five times. Then, I'm going to write grid-column-gap 25 pixels. Now, these are all the pixel measurements that I took directly from my markup. When I save this and I reload my browser window. So, in Firefox there's a really handy utility that I can use to quickly inspect my grid-based layouts. So, I've opened my browser's inspector and if I select this articles-recent block that I just created a grid layout on, over on the right panel there's an option to toggle the CSS grid highlighter. So, if I click on that little symbol, this is going to show me the skeleton for the layout that I just created with those three lines of CSS. I basically created a stage that's a grid layout and by setting grid template columns to 180 pixels five times, I've created five-180 pixel wide columns and grid column gap 25 pixels basically created a 25th pixel gutter between each one of those areas. Now, each column is created by setting up some gridlines, one on the left and one on the right. Now, every single one of those is actually numbered and we can use those numbers to lay out the different parts of our grid along those grid lines, in other words, to complete our layout. So, for example, our header element is currently constrained to this first column, what we want it to do is span the full width of those five columns across all six grid lines. To do that, I can just address it in my CSS articles-recent header and I can basically say, grid-column-start: one and then I can also say, grid-column-end: six. So, I'm going to reload my browser and now we've got a header that spans the full width of our grid layout, from the first grid line on the far left to the sixth grid line on the far right. So, let's see if we can actually improve the width of our stories as well. So right now, both of our stories are basically just spanning one column just like our header was before. So, let's be a little bit more explicit. So, for the first story which is class to story-lead, I'd like to see grid-column-start one, but I wanted it to span two columns. So, what I'm going to do is I'm going to say, grid-column-end three. So, that it basically goes to the grid line that's at the end of the second column. I'm going to save my CSS, go back to my browser and realize and now that story is spanning two columns rather than being squished up into one. Let's do the same thing with our final story which is classed as story-alt. Now this one's going to start at the third column basically at the end right after that first story, and then also I wanted to span two columns. So, I'm going to do grid column and five. Now if I save my work and reload the browser, now we've got something that actually looks a little bit closer to the design that we laid out in our markup. We've spanned two columns rather than being scrunched up into one. Now this is a basic layout and we can actually improve on this just a little bit more. Grid-column-start and grid-column-end can actually be expressed a little bit more concisely because we can use this sort of slash notation in one grid column property to say that we want this element to start at this grid line and end at this far one by using that slash notation. So, for the story-lead element for example, we could basically say grid-column one slash three instead of grid columns start one and grid column end three. For story-alt, instead of grid-column-start three and grid-column-end five, we can do grid-column-three slash five, just a slightly different way of doing the same layout with a little bit more efficiency. Now here's the thing about this layer that we just created. We used pixels to perfectly translate the layout from our markup into code but the thing about pixels is they don't really change their shape. So, if I resize my browser window to simulate what this might look like on a smaller screen, things are going to look a little bit weird. So, I'm going to make my browser window a little narrower and as I do that you're going to see that the layout doesn't change its shape. In fact I get this really cool little horizontal scroll bar to signify that I've got more layout that's shooting off the right hand side of the screen. So, this is where we need to take that fixed and flexible layout that we designed in sketch and translate it into something more proportional. There's a very straight forward looking formula that you need to use to do that. We're going to talk a little bit about some math here and I apologize about that because I'm terrified of numbers myself. But if you're translating any fixed width layout into something more proportional, use this formula. Target divided by context equals result. Let me show you how that works. Let's say you've got a piece of your design that could be a column in your grid, it could be one particular module. Well chances are good if you've used a program like Sketch or Photoshop to design your layout that has a target pixel value in that layout. Now rather than taking that pixel value and putting it in our CSS like I just did, what we want to do is we want to take that target pixel value and translate it into something more proportional. To do that we divide it against the context that it sits in. More specifically we divided against the width of its containing element and the design. Once we divide those two numbers together, we're left with the percentage-based result that we can then translate into our flexible grid. Let me show you how that works. Now I'm back in my mockup and I'm going to look at the characteristics of the layout that I designed and try to understand the relationships between different widths in my layout. Now as we saw before, the width of each individual column is 180 pixels wide. Now that's the target pixel width. What I want to do is I want to actually understand the relationship of that value against the entire width of the design which has 1,000 pixels wide from the left edge of the grid to the right edge. So, really rather than saying 180 pixels, I want 180 pixels divided by 1,000 pixels, target pixel value of 180 pixels divided by the context that it sits in which is 1,000 pixels. So, if I divide those two numbers against each other, I'm going to get 18 percent. So, if I replace the rest of those 180 pixel references with 18 percent, I now have the beginnings of a flexible grid. Now as I resize my browser window, the pixel values of those columns will change over time but the proportions that I designed in my markup will stay intact and that's the key component of a flexible grid right there. The relationships between widths rather than the widths themselves. Now there's one tiny little piece of detail work left which is this 25 pixel column gap that we have in here as well. But we can actually translate this into something more percentage-based as well. Now the 25 pixels is what we designed in our mockup but we can also use that target divided by context equals result formula here as well. We're dividing that 25 pixels against the same context as before, 1,000 pixels the full width of our grid-based layout. So, 25 pixels divided by 1,000 pixels is equal to 2.5 percent. So, now when I save my work, both the columns and the gutters are completely flexible with narrower pixel insight and now I've got a completely flexible grid. Now one tiny little bit of finesse work that we can do with this layout. I've written 18 percent five times but there's actually a really great little tool inside of CSS grid that allows us to be a little bit more concise. Specifically, there's this function called repeat, which allows me to basically say rather than writing 18 percent five times, I can basically say that I have five columns that are 18 percent in width and that's basically going to be exactly the same result which is a little bit more concise. Same exact layout just a slightly different way of expressing it. The one last thing to keep in mind and then I will leave the math behind for a little bit, is that there's also this very cool unit inside of CSS grid called the fractional unit which basically means that we can perfectly represent the remaining space. Instead of writing 18 percent, we can just say one f r which basically says that for any space that's left over after we've allocated our column gaps, I want you to perfectly divide that space five times into our five separate columns. So, rather than doing super complex math for every part of your design sometimes that one f r unit will be all you need and then we've got our completely flexible grid. 4. Step Two: Flexible Images: So, in the last lesson, we created a couple of flexible grids using this new technology called CSS Grid layout. But in our grids, we didn't actually include many images. So, let's fix that. What I've done is in the second section of sample files that you'll find in the resources, I've gone back into the flexible grids, and I've added some images, a key parts of the design. In the recent articles module, I've included some photos at the top of the featured articles themselves. In the letter from the editors, I've included a little photo that a company is the byline over in the left-hand column. I've also gone ahead and created a full layout in a flexible grid for this really splashy looking module called, our cover story, and I'll show you some strategies for managing images here as well. But let's start at the top of the design, first and foremost. Now, just as before, our images are dropped into the html and the grids are completely flexible. So, let's see what happens when we actually resize the grids now that we've included images. I'm going to make my browser window a little narrower to simulate what happens on smaller screens. Just as before, our columns are going to be completely flexible. But, oh my goodness, things are broken now that we've included images. Here's the thing with images, is that when they're displayed to the end user, images actually have native dimensions, they have a width and a height. As we've dropped them into our designs without doing anything with them in CSS, they're just rendering at their native dimensions and they're breaking our layout. They're escaping the columns that they sit in and breaking the experience for the end-user. But just like any other aspect of our designs, we can actually control the presentation of those images with our CSS. Now, if you want to have flexible images appearing inside of your responsive designs, there's one very straightforward piece of CSS that you should know to make them work inside of your flexible grids. That is, image, max-width 100 percent. That doesn't seem like much, but that one chunk of code basically says that an image can render at whatever size it wants to, as long as it's never wider than the element that sits in. In other words, that means that image can render at whatever size that it wants, but if that column is smaller than the image, that image is going to resize proportionally and shrink up to fit inside of that column. Let me show you what it looks like inside of our sample design. So, if added the image max-width 100 percent, and now as I resize my browser window, you'll notice that the images are resizing proportionally as well. They're completely flexible and resizing just as flexibly as our grids are. Now, you might notice that on wider screen resolutions, some of these images aren't necessarily fitting the full width of the column, and maybe that's okay for certain parts of your design. But at least for this one, I'd like to ensure that these particular classes of images are always going to be full width. To do that, I had a slightly different piece of CSS, just for those images. So, as you might remember, inside of this articles' recent work, we have two article elements that contain those teaser stories that are prominently featured inside of that module. Now, the images themselves I've classed with a little bit of html, I've given them a name of art. So, basically I can say that inside of those story elements, I want those art images to always have a width of 100 percent. That's a little bit different than max-width 100 percent, which basically says that the image should never exceed the width of its container. Width 100 percent says that I always want that image to match the width of its containing elements. So, now if I go back, you'll notice that those images are perfectly flush against the width that they're containing column. They're still completely flexible, but now regardless of how wide that column gets, there are always going to be completely full bleed. Now, let's move down a little bit further. Now, again, we have this inset image that accompanies the byline in the letters from the editor. Just as before, if I resize my grid to make it much smaller, that image max-width 100 percent is doing beautiful work ensuring that that image resizes proportionally. Now, as we'll see in a later lesson, there's a lot of fit and finish work that can go into controlling what images you serve up to your users, but that image max-width 100 percent rule is really the first step on our journey. It's one of the most critical tools on the responsive designer's toolkit. So, we've managed to constrain some of the images that we've included in our html in ways that don't break the flexible grids we've created for our responsive layout. But what if we're dealing with background images? That is something that comes up pretty frequently in my work and I'm sure the same is true for you as well. Now, I'm going to go back to the design that I created in sketch for this one particular layout. There's one element in particular that I'm going to focus on right now, which is this background image of a fossil footprints that I'd like to have included in my design. So, to do so in my CSS, I'm just going to include that SVG file. So, on the main element, I'm going to set a background image that points to the path of my footprint.SVG file, and now I'm going to use the background-repeat property to say that I just want one version of the image, I don't want a whole tile in the background, and I'll set it to no repeat. Now once I've done that, I have a massive image as the background for my design. Now, that's not what I laid out in sketch, ideally what I'd like to see happen is I'd like to anchor that up in the top right corner and I'd like to make it a little bit smaller. To control the size of background images, just like we do with inline images, we can use the background size property. Now, background size is a very powerful property and it can be very handy under different circumstances. For example, I could set it to 200 pixels, auto. Now, what that means is that the image will resize to a width of 200 pixels, and then I've set its height to resize to auto, which basically ensures that it'll resize proportionally to fit inside of that width of 200 pixels. Let's see what that looks like. So, now we have a tiny little footprint up in the top left corner of our design. Now, I can make that a little bit more prominent, I could set that background position to 95 percent and zero, which will basically move at 95 percent of the way across the horizontal axis, moving it over into the right-hand column, and then have it anchored up at the top right corner using a background position of zero. So, now we have it anchored up in the top right. Now, that's fine, but just as with our images before, the width of that footprint isn't changing. We can also use proportional values for our background sizes as well. So, what I'm going to do is I'm going to set this background size to 30 percent, which will basically set it to 30 percent of its containing element, in other words, in this case, the full browser window. Then I'm going to bring its background position down just a little bit off the top, it feels a little close to the edge of the browser window. So, now that I've set the background size to 30 percent, the image is much more prominent, and also, it's going to resize proportionally. So, on smaller displays, that image is just going to be much smaller than it would be on wider ones. Now, as I said before, background size is incredibly powerful. In fact, there are some other properties that might be useful to you in other parts of your design. There's this one in particular called cover. It can actually be really helpful. One responsive site that I think uses this very effectively is in virb.com. So, this image that you see up in the top banner area right on their homepage is actually a background image. As I resize the browser window, you'll notice that that image always maintains its size to match the width of its container. So, as that container gets narrower or gets shorter, it's set to background size cover which basically ensures that the image will always perfectly cover the available space in front of it, it's a really powerful property and it can be very useful to us as well. But these are just a few of the different strategies that we can use to manage background images more flexibly in our designs. Using background size and background position, we can actually really precisely control not just the placement but also the proportional scaling of our background images as well. Now, background size is really great, and in fact there's a way to do something very similar with inline images as well, and to give you an example of that, I'm going to show you our cover story. Inside of the our cover story module, there's a very large prominent image that's included inline inside of this content area. Now, it's set up in a grid-based layout, just as we did with our other flexible grids, and if I show the grid lines for this one particular image, this intro art image, the inline photo is basically set to span five columns. But it doesn't quite meet the full five columns, and it's also leaving a little bit of a gap at the very bottom of the image. Ideally what I'd like to see happen is I'd like to have that image be full height, so it perfectly covers the vertical space inside of this module. Well, I can do that by setting height 100 percent on that image. So by setting height 100 percent on this image, we've actually stretched this image a little bit on the vertical axis. Ideally what we'd like to see happen is we want to ensure that those proportions remain intact. Now, the way that we can do that, because this is an inline image, is with something called object fit, which is a slightly newer property in CSS. So, what I'm going to do is, I'm going to set object fit to cover, and you'll notice now the image retains its original proportions. It's basically a little bit like background size cover but for inline images. We've stretched that image across a certain space, but we've basically said that the image that appears inside of that space should resize proportionally inside of that canvas, and this is another really valuable property that can be helpful to you in certain circumstances. So, in this lesson, we've looked at a couple of different strategies for managing inline images that appear on our html and also for background images. By using some of these techniques in concert with each other, we can have images that are every bit as flexible as our flexible fluid grids. 5. Step Three: Media Queries: So, in our last two lessons, we looked at the ways in which we can use flexible grids and flexible images together. But the thing about flexible layouts, is that they're not always the best experience. So, for example on our recent articles module, once I bring the browser Window in about, let's say 50 percent, we can already tell that this isn't the best experience for the user. Some of the line lengths, start to feel a little bit cramped. They start wrapping really dramatically. This layout is not really a pleasure to read anymore. It doesn't feel as comfortable as it does on a wider screen. The same is true, if we move down a little bit further to the letter from our editors. Again, the layout looks fine. It's resizing proportionally but the reading experience isn't necessarily ideal. That top headline looks really heavy and prominent. In fact, if we bring our browser window even a little bit more, it starts to take up considerably more real estate than it actually needs. Again, our grid is resizing flexibly, but it gets to a certain point the design, where it starts to break apart. So, not the best experience we can start serving to our end-users. So maybe, we need to look at a way in which we can take this flexible foundation and reshape it a little bit. To maybe change the way that the information is presented, at certain screen or viewport widths, in order to serve up something that doesn't just fit, but also feels at home on any size screen. This is where media queries come in. This is a little bit of CSS that we're going to apply to our flexible foundation to improve the experience, so that it looks beautiful on small and wide screens alike. So, I'm going to write a little bit of simple CSS, that shows you how a media query can work. Because really media query is like a question, we're asking a browser. We're asking the browser if it meets certain characteristics or conditions. If it passes that test, and says, yes I meet all these conditions that you've spelled out in your media query, then we can conditionally apply some extra style rules just for those specific circumstances. I'm going to start with something very straightforward which is to say that on the body element, I want the text color to be black. But when I have a screen width that's at least 500 pixels wide, I want the color to be red, and I want the text to be bold. Let me show you what that looks like in practice. So, here's what the screen looks like on a smaller device. I'm using Firefox's responsive design mode, to simulate that narrow screen effect. But as I make the viewport a little bit wider, the text is going to resize proportionally. But once I hit a screen width of around 500 pixels, the design changes pretty dramatically, because that media queries conditions have been met. In our media query, we said you should only apply the red colour, you should only apply the boldface, if we've at least got a minimum width of 500 pixels. If that's the case, then we're going to make things look well, frankly ugly. This isn't the most useful media query, but at its core, this is the flexibility that we can apply to our responsive designs. We can change the layout and change the typography and change other aspects of our design, in ways that are a little bit more useful to us than red text. So, let's take a closer look at the syntax for media queries. Now, we said before that this is a little question we're asking the browser and every media query basically breaks down into two specific components. Every media query begins with a media type, which outlines the class of device or more specifically the media that we're trying to style. Now, in the CSS specification, there are four acceptable media types that are outlined. Screen, like mobile and tablet and desktop browsers. There's also the speech media type, for oral browsers that might be reading content allowed to the user. There's also the print media type, for print specific styles and then finally, there's the all media type, which basically says that this media query should apply to all media. Now, the media type is completely optional. If you leave it out, you're effectively saying that this applies to all media. It defaults to that all media type. The second part of the media query is, the real key to unlocking the power behind a media query. That's the media feature. This is really the question that we're actually asking the browser. As we've said before, this particular media feature is saying, is your viewport, is your browser window at least 500 pixels wide? If so, it applies the styles inside the media query. Now, there are a whole host of different media features that you can actually query. We're not necessarily going to cover all of them in this particular class. If you're interested in learning more, there's going to be a link in the resources to a full list of all the different options you have available to you. It's fair to say that most of what we do in a responsive design is, by applying min-width queries to layer more complex styles on our designs as screens get wider over time. So, let's take a look at our sample layout and look at some ways in which we can use min-width media queries, to quarantine some of these widescreen styles to well, wider screens. So, when I'm starting to apply media queries to a flexible layout, I find it's really helpful to look at the areas in which my design is starting to break down and where it's starting to break down as the screen gets narrower. So, as we said before, we're still dealing with a flexible grid-based layout, that's five columns wide, which really is ideal for wide screen devices and browsers. So, below that widescreen point, we want to apply a different layout. We only want to apply that five-column layout, when screens are at least above a certain width. So, I'm going begin, by taking some of the widescreen grid layout rules that we've written for the recent articles module and surrounding them with a media query. So, I'm going to write media, min-width, 60em's. Then I'm going to take all of these grid rules that we wrote for the recent articles module, and apply them inside of that media query. Now, 60em's, is basically equivalent to writing 960 pixels. I like to use m-based media queries because they're a little bit more accessible. If somebody changes the text size in their browser, then the media queries are going to more or less follow that preference for the end user. If you're more comfortable writing pixel based media queries, that's totally fine. This is a stylistic preference and one that I find is a little bit more accessible, but regardless of how you write it. Now, that we've got a media query that says, above this wide screen width, above a width of 60em's, apply this grid layout. If I save my changes, and I go back to the browser, and refresh my work, when I fall below that 60em's threshold, I lose my grid-based layout and things linearize to a single column design. Now, at this point, that's not very attractive. But I think you could see how on a smaller screen display, this actually works incredibly well. We've started with a small screen friendly layout, and then when we get up to a certain width, we can make the design as complex as it needs to be. We can take better advantage of the space that's available to us. Now, that doesn't change the fact, that we still have this awkward transition period. So, what I'm going to do is, I'm going to apply a media query of 35em's. So, I've written at media, min-width, 35 ems, which should target that middle-range layout pretty well. Now inside of this area, I'm going to target my articles recent block. I'm going to declare a grid-based layout. But instead of doing a five column layout, I'm going to do a four column layout. Then I'm going to bring in the column gap down to two percent. Now, before I continue, I just want to note that we're layering on complexity as the spring gets wider and wider. All of the rules from the previous media query, we'll apply the following ones. So, this is kind of like a layering effect that we're doing in our design as things get more complex. I mentioned that because we've declared display, grid at this point in the CSS, which means when we hit our widescreen layout, we can actually remove the second declaration. We've already declared it a narrower breakpoint, and so it's still going to be an effect when we get up to the wider one. So, now we have a four column layout. You might remember this weird default placement of items in our grid layout from the previous lesson. But what we've actually done here, if we turn on the grid lines in Firefox, you can see we've created a four column flexible grid. Now, we can use this to complete our design just like we did before. At this breakpoint, I still want my header to span the full width of the module. So, to do that, I can actually take the rule from the widescreen breakpoint and move it up to the narrow one. That's something that I want true both at this mid-range breakpoint, and also at the widescreen. I can basically say grid column start one, and grid column and negative one to have its span the full width of the row. Now, we've got a full row header up at the top. Now, remember, we have a four column layout that we're working with instead of a five column layout. So, what I'd like to see happen is I'd like all the stories inside of my articles-recent block to have a grid-column-end, and I want to span two columns. So, once I save this, we now have more or less the kind of layout we're looking for at this middle-range. Both stories are equally weighted across this horizontal axis, the both spanning two columns, and the secondary stories are sitting down below. This is much better than what we had before, because we had a single column layout for small screens, and now we have a nice middle-range breakpoint for everything in the middle, moving up to the top. So, this is an improvement, but there's a little bit of fit and finish work we can still do. Specifically, this list of stories down here at the bottom feels a little bit like it could be taking better use of the available space. To do that, I'm going to actually treat this list like a grid itself at this particular breakpoint. What I'm going to do next is I'm going to say that once I've reached a breakpoint of at least a width of 35 ems, but also at a maximum width of 60 ems. I want to treat that list a little bit differently. So, this is a way that we can combine media features together to make more complex media query. We can basically say we want it to be at least 35 ems wide but no greater than 65 ems, just to target the middle area. Once we've got that middle breakpoint in place, then I can write a little code to target my sidebar. Specifically, I'm going to write articles-recent-aside and articles-recent-teaser-list. This will let me target both the aside element that contains the sidebar, and also the list inside of it. Then I'm going to write display: contents. Now, this is a magic little piece of the CSS Grid specification that allows us to turn off those pieces of HTML. In other words, we're telling the browser to kind of pretend that those elements don't exist and just focus on everything that's inside of the list itself, specifically our links to secondary stories. Once we do that, I save my work, I go back to the browser. Those list items are going to be treated like they're part of the grid that sits above them, and so they're going to be laid out on those four columns. Now, there are different ways you could approach this problem. You could use other layout methods to lay out those elements are along the same grid lines, but this I think is a really effective way of doing something similar. Because we've actually scoped it to a maximum width of 60 ems, once we move up to our widescreen design, you'll notice they pop back into the sidebar. We've turned off those styles above our widescreen layout, and then they're basically situated back in that fifth column. So now, we have a flexible grid, flexible images and media queries working together. We've started with the widescreen layout and we've turned off parts of the design that aren't appropriate for smaller screens. That for me is the sign of a really effective responsive designer. To ask yourself those hard questions, not just about the small screen and the widescreen, but to ask yourself, what other experiences you might not necessarily be considering, and have a design or layout in place that speaks to some of those middle ranges? So, now that we've made the recent articles module responsive, I've gone ahead and actually translated both the letter from the editors and also our cover story modules along the same exact way. I've started by looking at that flexible layout and looking at ways in which it was breaking down, and applied some media queries, not just to disable more complex styles, but also to refine the approach at smaller wider screens. Just to give you a quick insight into some of the decisions that I made, the letter for our editors actually I approached in a very similar way to the recent articles module. So, on smaller layouts, I ended up opting for another four column layout again specified with CSS Grid. Again, I'm treating the secondary links down at the bottom in a very similar fashion to the way that I did in the recent articles block. Then below a certain screen point, I'm relying just on text to supply some design for smaller screens. In other words, there's no grid layout here to speak of, although I certainly could apply when if I want it to. For the cover story, I did something very similar. So, rather than overlaying the blurb and the image on top of each other, I decided just to stack them on smaller screens. It's just as impactful, but it's a little bit simpler when I don't have as much screen real estate to work with. But then as the screen gets a little bit wider, I can start looking for opportunities at the widescreen to then introduce the full layout only when I'm above that screen width of 60 ems. But below that point, there just simply stacked. That's how you make these fluid layouts responsive, with a little bit of media query work. 6. Fine-Tuning Your Design: In this lesson, I want to touch on three distinct areas that can really put an extra level of polish on your responsive designs, specifically typography, fallback layouts, and imagery. So, in our last section, we looked at some ways that we could reshape our flexible layouts using media queries to ensure that things look beautiful on the small screen, but also on the widescreen. So, what we've done so far is we've got a really nice adaptation happening at the grid level for each one of these modules. Things move from a one column layout to a four column layout, and then finally to a five column layout at the top end. But if you spend a little bit of time looking over these designs, you'll notice some areas in which they still need a little bit of extra attention, specifically on their typography. So, for example, this really prominent headline in the letters from our editor's module. On smaller screens, that really big prominent text starts to feel well pretty big and prominent and. In fact, if you look at this on a small screen device or on a tablet, you'll probably notice that it starts to overtake the rest of the screen. So, in the previous lesson, we use media queries to modify our grids so that we weren't serving widescreen layouts up to small screen users. We should also look for opportunities in our responsive designs to ensure that we're not serving widescreen topography up to small screen users. So, what I ended up doing in this lesson, is actually looking at some ways to use media queries to customize the typography. So, for example, on a smaller screen device, I basically brought the type size infer that headline considerably. Then when we got up to our mid-range break-point at around 35 M's, I can bump up the type size a little bit more. Then once we get up to our widescreen layout, we've got the full headline and view. Now, this can also apply to our cover story as well. You've got this really big, beautiful headline and that blurb on wider screens. But on smaller screens, that type sizing doesn't necessarily feel appropriate. So, we can also tighten that up, maybe make that subhead little bit smaller as well and reduce the padding on the blurb as well to ensure that it feels really nice and appropriate at every size screen. So, these are kind of the challenges in front of the responsive designers to think not just about how the layout is changing at the macro level, but also to look at these small little details like this and ensure that things feel at home on smaller screens too. The other thing we should talk about is what to do when browsers don't support some of the features that you might be using to power your responsive designs. Now, for today's class we've been using CSS Grid really heavily to provide that flexible fluid grid that sits as the foundation for our responsive designs. Now, you don't have to use CSS Grid, you can use floats or flexbox or what have you if you prefer to do that, but at least for me I find it's a really great way to design layouts for the modern web. The thing with CSS Grid though is it's relatively new and there are still some older browsers and devices out there that don't natively support it. So, what's the best case scenario for those devices and browsers? You have a couple of different options. One is you could avoid CSS Grid. That's a perfectly valid choice. Instead, what I actually like to use is something called Feature Queries. Now, we've been using media queries extensively throughout this course to adapt our responsive layouts based on the characteristics of the media that's rendering our designs. Feature Queries allow us to actually ask the browser if it supports certain CSS features, and if it does, then we can conditionally imply those more enhanced layouts. Now, the way that Feature Queries are written is with the Art supports directive. Now, if we look at our designed in Internet Explorer, things are going to look a little bit weird on those older versions of Internet Explorer that don't support CSS Grid. So, the questions we have to ask yourself is, do we want to supply a fallback layout that's written with floats, or with flexbox, or what have you, that is basically visually similar to what we've created with CSS Grid? That's a perfectly valid approach, and depending on who's in your audience and the kinds of browsers they use, that might be the best option for you. For most of the projects that I've been working on recently, instead what I've opted to do is to serve a single column layout to browsers that don't understand CSS Grid, and then for browsers that do, for more modern devices and browsers, I serve them a full grid driven layout. So, list four our fictional magazine, I'm going to write a Feature Query, and I'm going to ask the browser if it supports display grid. Now, if the browser understands Feature Queries, and it understands display grid, I can apply more advanced rules inside this block. Now, really what I want to see happen though is I want to constrain the width of the body element only to browsers that don't understand it. So, instead, I'm going to set a margin of zero auto for all browsers and set a maximum width of 30 ems on the body element which will basically create a nice, centered column in the middle of the browser window if they don't support CSS Grid. Now, for browsers that do support CSS Grid, I want to turn off that maximum width and I want to set the margin back to zero. These are my more advanced layout rules. Now, if we go back to Internet Explorer, you're going to see that things are perfectly centered in the middle of the browser window. Now, that may not necessarily be layout that you and I have spent a considerable amount of time designing, but the important thing is that it allows every browser and every device access to the content on our web page regardless of their capabilities. For browsers that are a little bit more advanced, they get a slightly more refined experience. So, this fine-tuning lesson, we've looked at ways to massage our topography a little bit and also to provide a better experience for less capable devices and browsers. There are also different ways we can make our images responsive as well. Sometimes simply resizing an image isn't necessarily the best approach. You might want to serve different file formats to different devices if they don't support the kind of image you're trying to deliver to them. Maybe you want to serve higher definition images to higher-quality displays without overloading less capable devices with images they won't render. Or maybe in certain circumstances, you want to be very specific about the crops of images you're showing up to certain classes of devices. If you spend some time browsing through this full page layout that I've made, you'll see different instances in which I've used different parts of the responsive images specification to do just that. For example, the logo that appears on the masthead uses the picture element and inside the picture element, you'll notice that there's a source tag. Well, that source tag points to an SVG file which is a nice, crisp vector rendering of our little logo mark, but it's only served up to browsers that understand the picture element and that except SVG images based on the type attribute we've put on that source. If a browser doesn't understand the picture element or won't accept SVG images, we've left an image inside of our picture element that acts as a fallback that points to a plain old SVG file. In other words, we can conditionally deliver that higher-quality image to the browsers and devices that understand it, and if they don't, we leave them with a nice fallback. We can also be very prescriptive about which kinds of images we want shown on different break points. We can also use the picture element to do that. You'll notice on the cover story, on smaller screens, I'm loading a slightly different crop of the image. It's a little bit more tightly focused on the dinosaur's face, but on wider screens, we go back up to that full, square image that's overlaid on top of the full module. It's a slightly different crop and it's a little bit more widescreen friendly. I'm able to specify which image gets loaded in where using the picture element again. But now I'm actually using the source tag to actually say above a certain break point, I want to use this media query to conditionally load in that white screen image. Then by default, I have that plain, old image tag that acts as the baseline experience for small screen users. So, in our lesson so far, we've looked at different ways to adapt our layouts to make them more flexible and more responsive, but in the next lesson we're going to take a step back from HTML and CSS, and instead talk about our design process and how it might need to change now that we're designing for more devices than ever before. 7. A More Responsive Process: In the lesson so far, we've looked a lot and responsive layouts. But now, I'd like to talk a little bit more broadly about how your work as a responsive developer or responsive designer might change over the next few months or few years. In one of the very first lessons, I said that the things that make a design responsive are fluid grids, fluid images, and media queries. But, the thing is that those are really just about layout, about establishing a visual hierarchy, and defining how that hierarchy might need to change over time using breakpoints and fluid grids. The thing is that all of those ingredients are really just focused on layout, about establishing a visual hierarchy, and then using media queries to articulate how that hierarchy needs to change as screens get wider or smaller. The thing is that design is so much more than that. There's this quote that I love by Paul Rand. He once said that design is the method of putting form and content together. More recently, a colleague and friend of mine, Mark Boulton said that design is the stuff around the end result. Design isn't just the final set of mockups or the site that you've launched, it's the process that you took to get there. The path that you walked to the hard questions you had to ask yourself as a designer or as a developer. That's what ultimately shapes your design. So, when we're asking ourselves, what makes a design responsive? I think the emphasis is a little bit on the wrong part of the phrase. In other words, how does our process need to change to make responsive design much easier for us? How do we need to become more responsive designers or more responsive developers? So, I'd like to talk a little bit in this lesson about how my practice has changed over the last few years. I'd like to begin by talking about one specific case study, which is the redesign of the Boston Globe, which was the first large-scale responsive redesign that happened a few years ago. Now, when I and my colleagues were brought in to help with this project, the team had already created this suite of really beautiful comps for a wide screen layout, much like we did in this course today. So, the challenge we had to figure out was how do you actually take these pictures of a website, and translate them into a completely responsive fluid design. Because the challenge with mockups is they're fixed width pictures of a website. They're not necessarily as flexible as the canvas we're actually designing for on the modern web. Now, you might be able to work around this, right? Because comps could be replicated, you could show different versions of a layout at different break points, but that's incredibly expensive. Breaking out small screen and mid-range breakpoints for all these different pages gets really difficult in Photoshop or in Sketch. So, these design tools aren't necessarily as flexible as we need them to be when we're designing responsively. We also found the way in which we were managing the creative process was a little bit too inflexible for responsive product. More specifically, when it got to the point for transitioning between design and front-end development, the client had this idea that they had already approved the work. They'd signed off on the comps, and so it was just more or less a design in the browser that represented the design in the comps they'd approved. Unfortunately, those comps were not nearly as flexible as we needed them to be. So, that's why very early on, I and the other teammates that I was working with, realized we needed to break down that wall between design and development, and instead, iterate more quickly over the design and the browser. All of us were working effectively as one creative team. Some of us designing primarily in Illustrator or in Photoshop. Others working primarily with HTML and CSS. We were all designing this responsive site together. The way we worked through this was with more collaborative design review, is where we would sit down as a group and actually review the next set of work together, specifically reviewing the comps that design half of the team had produced. When we convened as a design team, we introduce the design to each other. So, the design half the team would tell a little bit of a story about how they got there, some of the decisions that they made in this layout, and how it fulfilled the needs of the business. From then, it was really on the development half of the design team to ask a lot of questions, and they were wide ranging questions. They might address questions of layout, about what happens when you have two dominant pieces of information. Let's say in a module, and then what were the expectations on the design half of the team if you've lost the benefit of two column side-by-side. If you're rendering this module on a small screen display, which one of those two pieces of information should appear first? They might address questions of interaction. If you're looking at a photo carousel for example, as it was designed in Photoshop, it's probably fairly easy to guess how this might work if you have a mouse available to your device. If you tap or click on an item to advance the carousel. But what happens if you don't actually have a mouse? What happens if you're on a touch-based display? Do you want to build an affordances for touch and be able to swipe through those photographs? What happens if somebody doesn't see the design as you and I might, and they're having this information read aloud to them in a speaking browser? That's also something we can design. So, what are the expectations from the design half the team about what that experience should be? I'll be honest, I've been on the receiving end to some of these questions in many projects and they're terrible. Because very frequently as a designer, I haven't considered some of these options. But we realized very early on in the redesign of the Boston Globe, it's okay if we didn't have answers. Really, what we're trying to do is ensure that every member of the team has a shared understanding of what got us up to this point, because at some point, the process it's going to be incumbent on one-half of the team to inherit the other half's work. So, they have to be able to make recommendations about how to proceed. This is something I've heard from every one of my clients, ever since I worked on the Boston Globe. That when you can bring design and development closer together, it always, always results in stronger digital responsive products. The quality of the work improves, the more closely design and development can work together. Part of that is actually treating the prototyping phase as part of the design process, because once you've got a shared understanding of how the comps got up to this point, you have to get them out of comps and it to code. In other words, you need to get them into a flexible responsive prototype that actually is the canvas we're really designing for. Once you can do, that you can have front-end developers actually making recommendations about how to begin with a small screen layout, and introducing flexible grids, flexible images, and media queries to create a prototype that's as responsive as possible. Now, in the prototype, they very frequently won't necessarily have reference designs for every one of those breakpoints. In other words, they're designing in the browser, and they're making good recommendations more often than not, but they're just recommendations. So, that's why at the other end of the prototyping phase, I find it's incredibly helpful to circle back as a team, and actually have a more interactive design review. But rather than printing out designs and sticking them up on a wall or maybe projecting them up on the screen, it's actually incredibly helpful to load the prototype up on as many devices and browsers as possible, and hand it out to people. Actually, let them work with the design in these different devices, and talk about how the design actually feels to them. These more interactive design reviews are an incredibly powerful way to verify a responsive design live in as many devices and browsers as possible. You can just have a running conversation about how the responsive design feels. Does the layout feel appropriate as we're looking at it on differently sized screens? Does it feel right if I'm on a touch-based display and I'm swiping through different elements? Or most importantly, do any elements actually need additional design direction? Look for opportunities in your design where some parts of the element might be breaking apart, and maybe the design half the team can decamp, and make some recommendations about how to dial in some of those details. In other words, if you can use prototyping and traditional design tools closely together, that's always going to result in a better responsive product. In other words, treating your Photoshop comps or your Sketch files as canonical, as the perfect reference, is something that's going to actually compromise the value of your responsive product because they're pictures of a website at the end of the day. They can't tell you what happens on differently sized screens or when fonts don't load or when some part of your design doesn't actually render in the browser. In other words, HTML and CSS are the best design tools we have to fill some of those gaps. But ideally, we'll be working with these together. Now, the other thing that's incredibly powerful, and I think this is true for any responsive project, is taking a hard look at the information we design on these screens, and this was very valuable to us on the Boston Globe. At every point in the process, we were always asking ourselves what value does this content have for the mobile user? Mobile first was coined by designer named Luke Wroblewski over 10 years ago. At the time, he was arguing that mobile screens need to be our priority in the design process. He was arguing this for a number of reasons. Mobile traffic had exploded back then and frankly, it's still exploding now. But also, these devices have all these wonderful capabilities. So, if we start designing for them first, that will actually improve the product, and introduce new and exciting features. But finally, and I would say maybe most importantly, he was arguing that mobile screens force us to focus. That they are screens that are 80 percent smaller than the ones we've traditionally designed for. So, if we can start by designing there, we can build a consensus around what matters most to our design, and use that to improve the experience for everyone. This is something I've heard from every successful responsive design at scale. One of my favorite examples of this is actually the dearly departed Virgin America website, and after the redesign went up, a colleague of mine and I interviewed the team behind the redesign. The design lead on the project, a guy named Joe Stewart said once, "For whatever reason, people think it's okay to have focused user experiences on mobile, but when you get to desktop, it's about throwing in the kitchen sink. One of the great things about responsive is that it forces you to make those mobile decisions on a desktop." At the end of the day, mobile first is about designing for focus. Regardless of whether you're designing for a small screen layout or wide screen layout, take a hard look at every single piece of information that's currently being slotted onto that page, and ask yourself, does it actually have any value to the mobile user? If it doesn't, well maybe that's worth having a hard conversation about the value that it has to any user. Because our audiences are so predominantly mobile these days, this really does have to be our starting point. The big secret about mobile first design, is that if you can really focus on what actually matters to your users, it's going to make your non-mobile users much happier as well. So, these are just a few of the strategies to keep in mind when you're designing responsively. Look at the ways in which you collaborate with designers and with developers, and also ask yourself some of those hard questions about a mobile first priority in your layout. If you can do that, you're going to come up with some really beautiful responsive designs that fit and feel at home on any class of device it might visit them. 8. Final Thoughts: So, in this class, we've used the key ingredients of a responsive design. Fluid grids, fluid images and media queries, to build more device agnostic and flexible layouts. We also spend a little bit of time looking at some ways that we can fine tune our responsive experiences. To adjust typography or imagery based on the needs of the device or the browser, to make sure that things fit and feel at home on any size screen. I really hope you'll just use this class as a jumping off point. Then you use some of the techniques we've looked at today to build your own vocabulary for how to build beautiful responsive sites. I'd love to see some of the responsive work you do, maybe share in the project gallery. Thank you so much for taking this class, I'm really excited to see the work you've done. 9. What's Next?: [MUSIC]