Designing for different screen sizes & devices (2023)

Several years ago “responsive design” was a buzzword, nowadays it is a must, a norm. A huge percentage of traffic comes from mobile devices, and Google also takes into account mobile-friendliness in the process of ranking your website. The term “responsive” refers to responding to the user’s context and behavior by taking into account the different viewports sizes and devices.

So let’s start with some terms:

Fixed layout means that it does not change based on the screen size or viewport size. Except for specific cases (e.g. a special medical device or a kiosk that requires designing only for that exact screen size, or designing for an Apple watch — currently there are only a small amount of screen sizes), so except for these cases, it’s better to design a layout that dynamically changes based on the screen size.

A layout is fluid when the size of the elements inside the layout is defined by percentages, so if it proportionally changes based on the viewport size. As you can image, using only this as a solution results in suboptimal experiences either on small or on large viewport sizes. Here is a demonstration for you:

The adaptive approach means that you design a series of fixed layouts, and the one nearest in size to the given viewport size is being displayed. This is good for performance, and you can design for each and every size intentionally.

Responsivity means that your digital product or service is displayed in a way that it responds to the properties (e.g. viewport size, orientation) of the device it’s being viewed on.

It’s a combination of the fluid and adaptive approach: you predefine breakpoints, it let’s you design different layouts for the size bigger and smaller than the breakpoint — this is the adaptive nature, and at the same time it responds by stretching or shrinking — this is the fluidity.

As an example, the Bootstrap component library contains a responsive grid system, and defines 4 breakpoints for 5 different viewport size intervals.

There is extra small for a viewport size smaller than 576 pixels width, and there is an extra large category with viewport sizes above 1200 pixels, and 3 more sizes in between.

You might notice that I used two terms for the sizes: viewport size and screen size. The difference is the following: the viewport size might be smaller than the screen size, since for instance you can change the size of a window. So the viewport is the visible area of a website or an application from the user’s perspective.

When you for instance split your screen into two windows, the website or application’ll be displayed on half the screen. Others might use these terms differently, the important thing is that you need to think about cases when the user might want to resize the window, so an application is not always displayed on the full screen size. On smaller mobile devices, the screen size and the viewport size is usually the same, however, on larger tablets there might be split-screen use cases.

There are basically two types of containers: fixed width and fluid width containers.

A container contains elements of a website or an application (in our following examples, the cards). It defines the size of the horizontal area where these elements will be displayed. There might be multiple containers, and you can combine the container types as well, so for example you can place images inside fluid width containers, and text inside a fixed width container.

Let’s take a look at an example based on Bootstrap’s breakpoints.

Let’s say we have an 576 px viewport size. So it is small size in this system. The second row contains the width of a fixed width container, it is 540 px. What does this exactly mean? It means that from 576 px to 767 px width (so in case of a small viewport size) the size of the container is always 540 px. So for instance if you have 3-columns or a card based layout containing 3 cards in a row, the width of one column or card is always 180 px. The only thing that can change is the spacing on the left and right side of the container!

Here is a demonstration for you. Currently the viewport size is 800 pixels:

Now I resize this window, it’s new width is around 900 px. In Bootstrap’s system, both of these are medium-size, I haven’t reached any breakpoints yet. As you can see, I have 2 cards in a row, and the width of these cards haven’t changed, since I apply a fixed width container:

Now let’s go all the way up to around 1000 px. There was a breakpoint at 992 px width, 1000 pix width means that now we’re looking at a large viewport size. As you can see, the layout has changed due to passing the breakpoint, now there are 3 cards in a row:

If I increase the width to 1100 px, you can see that I use a fixed width container, since the width of the cards has remained the same (the only thing that has increased is the spacing on both sides of our container):

You might ask why there is no fix width container for extra small viewport sizes. The reason is that this viewport size is so small that it makes more sense or it’s more rational to use all the width available.

In case of a fluid container, the container’ll use the entire width of your viewport, this is why it’s also called full-width container. In this case the width of the cards changes as I increase or decrease the width of the viewport size, since the width is specified by using percentages.

Here are examples showing this behavior. Below 768px (this is the extra small and small size in Bootstrap’s grid system) I have only one column:

On medium sized screens there are two columns:

On large screens I defined three columns:

And on the extra large screens there are six columns:

Since I use fluid containers for this example, cards always take up the entire available viewport size. This is why the third row (fluid width container) of Bootstrap’s breakpoints table contains that in case of a fluid width container, the width of the container is the same as the width of the viewport.

Here is a good practice for designing a responsive layout: you should always check how the application or website looks like on the sort of two sides of a breakpoint, so for instance you should test it with 575 and 576 px width (the extra small and the small). Currently the smallest mobile device’s screen size is 320 px, you should check that out, too. And it’s also worth taking a look at the design on a larger viewport that’s width is more than 1920 px.

I’d like to mention that using Bootstarp’s 4-breakpoint grid system is only one solution, you can define your own system. And of course you can design a different layout for each possible viewport size, e.g. one for 600, one for 601, one for 602 pixel width and so on, but it wouldn’t be a rational thing to do. :)

When you design for instance a card-based layout, it’s also important that you specify for the developer what elements should always be aligned horizontally. As you will see in the following example, at 1200 px width a long card title will break the layout, the texts and buttons will no longer be aligned horizontally. So here everything looks fine:

When I change the viewport size to 1200 px, and the layout breaks:

After fixing this issue, I increase the viewport size to 1200 px again, and it still looks good:

And btw. this is why it’s important to specify a maximum length for each textual element displayed on a layout. The other interesting aspect here is creating translations — what happens with the layout in case you translate textual content to a language that contains longer words than English? Finally, one more thing I would like to mention here is that this is why you should always design with real content. If possible, avoid using lorem ipsum.

You might ask what happens if you have an odd number of elements, e.g. a consultancy provides 5 different types of services. How can you display 5 items on a smaller viewport size when you can no longer display them next to each other? It’s entirely possible that there will be rows that doesn’t contain the maximum number of elements, e.g. you’ll have 2 rows, one with 3, one with two elements. It’s a design decision, the important thing is that your developer team member should know about it.

In the 2nd part of this article series, I explain how to include images and some more aspects of designing for different screen sizes and devices.

Originally published at https://protostar.space on March 27, 2020.