[00:00] Imagine you are designing a screen for some colleagues. You want it to look just right so you put a lot of effort into it. Once you are happy with it, you publish it and hand it over to your colleagues. It turns out that user A has a larger screen than you designed for. They see your content, but it's stretched out in an odd way. Nothing like how you originally designed it. Then user B opens up the screen on their phone and the content shrinks, making it harder to read. All that time spent perfecting the layout of the content ended up being a waste since you didn't really know how your users were going to view it. With a physical medium this was never really a problem, everyone gets the same size newspaper or a magazine. However, a lot of content nowadays is viewed digitally, usually in a web browser. This ultimately means that your users or rather their devices get to determine the dimensions of the canvas that makes up your content. This is called the viewport of the device. So if we can't be certain of the dimensions that our content is going to be presented on, how are we supposed to make sure our content always looks great? That's precisely what responsive design allows us to do.

[01:12] Responsive design is a set of ideas and practices that can be used to help you create content that looks great regardless of the device it's being viewed on. Responsive design is a deep topic with a lot of interesting concepts, for brevity we're only going to focus on a few. Starting with the idea of mobile first or designing for the smallest screen you have. But why? Well, before we can talk about mobile first we need to be aware of just how much variation there is on all the different devices on the market today. While there are some common mistakes to be made with respect to determining the display dimensions of your content, there are plenty of best practices to be aware of. Generally speaking, mobile devices have the smallest screens. And by small, we're talking about the available width of the device's viewport. Content is typically accessed on a mobile device with a portrait orientation, meaning that the height of the viewable space is greater than the width.

[02:07] But when you switch over to say a desktop, the display is generally in landscape or the width is greater than the height. Even then you need to remember that your users can ultimately change the orientation of their devices resulting in variations of dimensions. This means that we have a great variability in width to account for. The reason that width is our key concern, not the height is that changes in height are less troubling since scrolling vertically is a more natural pattern. In other words, we can always add vertical scroll bars when the viewport is too short and that's an interaction your users are already comfortable with. Now that's great, but we still haven't answered the question of why mobile first? Well, starting your design process with the most restrictive size can help you determine which elements are absolutely critical. If you design for a small screen and have lots of things you could show you'll very quickly find yourself omitting or trying to hide unnecessary items to ensure you have room for the mandatory elements.

[03:05] As the width increases, you'll find yourself with more room which means some of those nice to haves can be added. Figuring out where to add things when there's plenty of additional space is far easier than trying to figure out what to cut when you lose space. This is a big reason why we say mobile first. The design portion is easier if you design for the restrictive sizes first and it helps you find the screens identity by focusing on just the critical elements. That being said, it's generally a good idea to try and understand who your audience is and what type of devices they'll be using to view your work. You may find that the project you are developing is intended to only be viewed on a couple of different display sizes which makes your testing later on easier. However, even this is risky since most modern devices are designed and built for usage over just a few years before being replaced. We don't mean to say that you should design for a strict pixel dimensions tied to specific devices in this case, instead get a general idea of the usage in the field and test your layouts against those sizes specifically.

[04:06] Devices change over time and your layout design needs to be flexible. Okay, so one of our key points, mobile devices generally have less available width. So we designed for mobile first because with smaller screens we get to focus on the mandatory elements first. Those additional or nice to have elements we can add when there's more available width. And you should always be trying to figure out who your audience is and what type of devices they might be using. Next step, let's talk about breakpoints. So what is a breakpoint? A breakpoint is a size in width where the application should make more drastic changes in layout and style, to respond to the variety of viewport widths. In modern web applications it's pretty common for content to resize automatically, thanks in part to things like the CSS Flexbox. Think back to the example at the start of the video, we have a low fidelity mock-up of a screen with three boxes. User B then looks at the screen with a smaller viewport.

[05:02] Now imagine a world where content in this scenario would completely change its layout, so that it would actually look good on a smaller screen. That's basically what a breakpoint allows you to do. To give another example, say you stack a bunch of small things vertically in a single column on mobile, but if the user is looking at your application on a desktop display, maybe you add a second column. The breakpoints represent the point where your application changes between these styles. The example on the left represents a smaller breakpoints, while the example on the right represents a larger breakpoint. But the content in both cases can be identical. Breakpoints allow you to design different versions of a screen, each better suited to a certain size. Again, we can't always determine how our users will view our work 100% of the time, but we can create different breakpoints that offer catered experiences for different ranges of devices. So how do we determine what our breakpoints should be? There are known dimensions for all kinds of devices right now, from smartphones to tablets to those ultra wide monitors.

[06:05] However, you probably shouldn't be targeting specific devices unless you know for certain that these are the only devices that will ever be used to view your application. We want to apply some amount of future-proofing here, so we can account for newer hardware later on. In most cases you can get by with two breakpoints, a smaller one, say for anything under 600 pixels and a larger one for anything larger. In some cases you may want to add a third breakpoint, but the complexity of the application can grow quite a bit when adding an additional breakpoint. Okay, so let's look at our key points. Breakpoints allow your application or site to change style or layout depending on available width. They allow you to design different versions of a screen for different devices. So we have those breakpoints, what do we do when we switch between them? How does our content change when viewed on a small breakpoint versus a large breakpoint? Here's where we start talking about layout or I should say fluid layout. Think of your content as a fluid, it'll shift and move around based on the container it's inside, taking up as much available space as it can.

[07:08] You've already seen this in action on modern websites, if you attempt to resize your browser you'll notice the content will flow and resize, making good use of available space. A common approach in the world of web design is to have your content positioned inside of boxes or containers, and just move the boxes around depending on the user's viewport size. If a box gets wider then we can simply make the content inside the box resize as well or not depending on how you ultimately implement it. For example, say we're building a web application. Some of our content involves an image and a sentence or two describing whatever is depicted in that image. It makes sense to put those two things next to each other, right? It's likely safe to say that regardless of width or viewports, we're always going to want those two things next to each other. So we put them in a box together, later on when viewing the content on different viewpoints we simply move the box around, which ensures our image and text are always next to each other regardless of what we do with the box.

[08:06] If we need to get more granular, we can simply put boxes inside of boxes, following the same pattern but giving us a bit more control over the position of everything, in cases where we want that. Okay, so to summarize, fluid layout means your content will shift and move around as the viewport changes. Content that needs to be adjacent should be grouped up or put into the same container. All right, so responsive design has these ideas of viewport, breakpoints and fluid layouts. How do we use them? Fortunately, there are a couple of common approaches and we'll take a look at some. It's worth mentioning now that the following strategies are oversimplified and often combine or stack on one another to achieve the result you want. First is mostly fluid, which really demonstrates the fluid layout concept. We have several containers with their own content, we don't really have to talk about the content here as that's staying the same. So we'll represent those with colored and numbered rectangles. To represent our different viewports we'll use a hollow gray border. With the small viewport on the left, we see our boxes are just stacked, So the user can scroll vertically to check out all of the other boxes.

[09:07] In a real-world scenario the boxes in this case would likely be much taller to fit all over their content, but the idea is that users will scroll vertically to access everything. With the medium viewport we see box one moved up towards the top of the screen reducing its height, but increasing its width to fill up the rest of the viewport. The other two could follow suit or could instead be positioned horizontally to each other. We still need to scroll to see all of the second and third boxes, but at least most of their content is now natively in view. In the larger report we have enough space to show everything, so no scrolling needed here. Instead of resizing the boxes why not just show more boxes if there's more available space. Off Canvas does that, it simply moves boxes out of view when there isn't enough space. Users can simply switch between different boxes via a swipe or some other mechanism. This approach is simple because the content within the boxes doesn't resize drastically, as the boxes all have a relatively fixed dimension. When small, we only show a single box, at the medium we show two and at large we show all three side-by-side.

[10:09] This approach here blends our two prior approaches, it treats each container as a column. If it can't be shown due to a lack of room, then we add it as a new row. So we drop columns, if there isn't enough room and we raise them when there is. With the small viewport, the approach is pretty similar to mostly fluid. Our content is stack because we really don't have the spare width, but once we switched to medium we add another box to the viewport. In this case, users can scroll down to get to the third box and then on the larger viewport all three columns are in view again. Now, say your screen is overall fairly simplistic and doesn't really require you to move boxes around all that much. But maybe you just need or want to make changes to the overall styling of your application, we call these tiny tweaks. For example, you may want a larger font in the smaller viewport and a smaller font in the larger viewport. These aren't significant changes, but they're impactful and improve overall accessibility.

[11:05] Further more you can do things like change the size of pattern between elements in the boxes, reducing it on mobile, increasing it on the desktop. Allowing you to maximize available space on those smaller screens. I should mention that tiny tweaks are very commonly paired with other strategies. Changing text and styling at different breakpoints is a small thing you can do that dramatically improves the overall experience of any application or site. Now something that's a little bit trickier to do when you don't have the available width is display a table. Tables are naturally horizontal, so you do run into some issues when attempting to display tabular data, especially when there's a lot of columns. So what do you do in this case? Well, you can use a card in this case. And what I mean by a card is that it's just a small panel with several labels. The idea being that each card represents a row, all the labels inside the card represent different columns in that row. Then you just stack the cards vertically. This approach basically flips or pivots the table and presents the same information in a more mobile friendly way.

[12:08] That about wraps up this lesson, in review when designing a responsive application or a website, design for mobile first. Make sure to identify what your breakpoints are as well as get a good understanding of what devices might be used. Also don't forget to familiarize yourself with some of the common responsive layout strategies.