Prototypr

Prototyping, UX Design, Front-end Development and Beyond 👾 | ✍️ Write for us…

Follow publication

Adaptive interface: theory & practice

Mariya Tereshkova
Prototypr
Published in
14 min readMar 4, 2019

I keep seeing UI-designers hating to create adaptive interfaces. They simply create interfaces for standard screen sizes: 1024, 768 and 320/375. As a result, the developers come up with questions about the way interface behaves within the range between these numbers. Then, the developers bother the designers with these questions, increasing project work time. Besides that, developers frequently do things at their own pleasure. Now, the designer flares up about end-product appearance, because it does not meet his/her expectations.
So, how can you avoid that?

To me, designing is pure math, and adaptive interfaces are great examples that show this. It takes a lot of time to make them, but this is necessary. Here is why:

  1. Designers can control the number of page templates in a project;
  2. Designers can control the number of paddings, fonts, sizes, elements, etc.
  3. An interface becomes more user-friendly;
  4. Interface maintaining and developing become easier;
  5. Managers and developers do not have any issues neither with the adaptive design itself nor with new pages or elements, which should be urgently implemented, while the designer is snowed under with work or hit the road for vacations.
  6. In the situation where a designer works at multiple projects simultaneously or, for example, returns to a project after a long break, he/she will easily remember the website grid.
  7. If a project is passed to another designer, he/she will understand it quickly.
  8. Eventually, designers will start liking the process of making adaptive interfaces, since it will become an interesting task, which makes you calculate and think over how to design a website in fewest steps possible;
  9. In-depth development of an adaptive interface teaches designers to plan it already at the concept stage.

When I create interfaces, I never stick to some specific grid (for example, 8–12 columns). The grid is always defined by my inspiration or content. In one case the structure can be chaotic, in another — strict, 3-columned, with fixed width and paddings. However, the structure must be as much thought-out and logical as possible in any case. Every pixel should have its purpose.

👉 Rule #1
Forget about creating adaptive interfaces for 1024 and 768 (tablet), and 320/375 (smartphone) sizes. Let the grid define the way it changes.

Example 1. Post carousel

Let’s assume that we have a block drawn at the concept stage.

  • 400 px — post card width;
  • 40 px — paddings between cards;
  • 80 px — paddings from arrows.

First off, you need to define the minimum browser edge padding. This padding should make your interface user-friendly. I think this padding is equal to the arrow padding — 80 px. Now, let’s suppose that we do not want to extend the card width. So, we fix the cards at 400 px for all bigger screens.

The calculations give us the following values:
[80 + 36 (arrow) + 80] + 400 + 40 + 400 + 40 + 400 + [80 + 36 (arrow) + 80] = 1672
This means that we stop stretching the content at the point of 1672 px and extend the screen by increasing paddings between the arrows and the screen edge. Thus, we begin to narrow our interface at the point of 1671 px.

There are three options for narrowing content:

  • You can decrease post card sizes;
  • You can decrease paddings;
  • You can decrease font sizes.

Now, you need to calculate padding and card narrowing limit values and inform your developers about them.

You can begin with halving paddings near arrows by equating them to the paddings between the post cards. Then, you can narrow the cards.
The initial interface had rather large post names. We can decrease them from 30 px to 24 px.
After narrowing the content, we get a minimum allowable card size. Using this size allows fitting enough characters in the post name and description. In our case, the size is 320 px.

Calculations give us the minimum point for the specified dimensions — 1272 px. This is the second breakpoint.

Mobile First: the legendary rule.
When designers started making adaptive interfaces, they tried to make interfaces for mobile device sizes first. This allowed minimizing the number of functional elements and the amount of data on pages, providing users only with necessary information. Back in the day, “A Book Apart” publishing house released the book on this subject (by the way, I strongly
recommend it).

Today, not many designers start developing websites with making interfaces for mobile device sizes, but this approach is also possible. At some stage of making an adaptive interface, you need to define the way it will look on smartphone screens. The earlier you do that, the better.

👉 Rule #2
The closer you get to 1000 px size, the more you should think about the resulting view of an interface on smartphone screens.

The situation with this type of cards is quite simple: you either roll them up into a carousel or list them one after another. I prefer the carousel. Almost any interface can be swiped on mobile devices, so you can just hide the arrows for swiping cards and keep page control indicator present. This indicator will inform you about the large number of cards in this block.

What do we want to see on a smartphone screen? You can keep full-width cards, but it would be much better to show users a small part of the next card, so they know that there is more content present behind the screen.

So, the minimum phone screen size is 320 px:

  • The paddings between cards should not exceed 20 px. Otherwise, texts below cards will adjoin;
  • We are going to show another 10 px of the next card in the carousel. This leaves us with a maximum size of 290 px for one card;
  • You can place the card right on the edge of the screen, but I recommend you to keep another 10 px of free space, so the text below the card does not adjoin the edge of the screen.

The resulting value is 280 px.

If we narrow the card to 280 px, 17 px description text will not fit the screen. Let’s try decreasing the font size to 15 px.
The screen is still rather wide, and the cards are still present with 40 px wide paddings.

We calculate the data and get the third breakpoint of 1000 px.

👉 Rule #3
Recommended content text sizes for mobile devices are 15–17 px. Use 12–14 px only for additional and irrelevant information. It will be difficult for a moving person to read such a small text at arm’s length.

👉 Rule #4
Do not stick the content to the edge of the screen. Leave the spare space of 10–30 px (or 15–20 px in a perfect scenario). It is quite difficult to read the text that bumps into the phone screen. The exceptions are pictures and media. You should (and sometimes need) extend them along full width.

Back to our interface. If the screen size is less than 1000 px, we can make the carousel with two cards on a screen, while saving comfortable paddings between posts.
Now, we calculate the data and get the next minimum point of 680 px.

By the way, here is how the screen looks with the same grid but at 1020 px width:

Now we have reached mobile devices. The fifth breakpoint is all screens less than 680 px. We narrow the padding from the edge of the screen and get a practical slider, with the minimum card sizes of 280 px.

As the result, we get the following breakpoints of the interface changing:
1672, 1272, 1000, 680

There are no gaps. We have made the interface for any browser screen.

👉 Rule #5
In most scenarios, you need only four or five breakpoints. Element or padding values change in these points.

Is your brain fired yet? Great, let’s continue! 🔥

Example 2. Product card

Now we are going to try the fluid design. Let’s suppose we have a product card.

  • 70% of the screen are filled with product pictures. The padding between these pictures are 10 px;
  • 30% of the screen are filled with product description and action buttons for users.

To give you an example I have made an interface with one element going beyond content container edges (see yellow line below the name).

We want the content to be smooth. We do not want it to be squeezed between the pictures and the edge of the screen. So, the content paddings will be equal to 60 px. BUT! Since one element goes beyond the edge of the content, we will use an optical illusion: the paddings are equal to 60 px, but the actual values are 60 px on the right side, and 50 + 10 (for the line) on the left side. There is nothing wrong about this approach, but you should inform your developers about it as early as possible. The developer will definitely be unhappy to find this “negative” element. So, he/she will either have to make the layout over or use negative values. Usually, designers wrongly assume that some unfitting part is not that big of a deal. They are wrong though.

Let’s calculate the minimum screen size needed for our grid to work. The text and pictures can be narrowed, but the element for choosing product size and the “buy” button are limited to 264 px.

[50 + 10] + 264 (the element for choosing size and the button) + 60 = 384
384 = minimum of 30%, thus, the screen size should be equal to or exceed 1152 px. In addition, we are going to keep some reserve space for button font rendering (it can differ greatly in a browser and graphics editors). Now we round-off our point to 1200 px.

Narrowing. 70:30 rate may leave us with large pictures and no space for text and buttons. So, we change the grid rate:

  • 60% for pictures;
  • 40% for description;
  • We decrease the paddings from 60 px to 40 px;
  • We decrease the title font from 48 px to 36 px.

Now we calculate:
[30 + 10] + 264 + 40 = 344
344 = the minimum of 40%, thus, the minimum screen size for the present grid is 860 px. We also add reserve space. Now we get the second point of 880 px.

Let’s change the rate again, so the description will always fit the screen. The new rate is 1:1:

  • 50% for pictures in one column;
  • 50% for description;
  • We keep the same horizontal paddings;
  • It is time to think about mobile devices. The more we narrow the screen, the lesser becomes its height. Now we narrow vertical paddings.

Calculating:
[30 + 10] + 264 + 40 = 344
344 = the minimum of 50%, the minimum screen width for the present grid is 688 px. Adding reserve space. The third point is 690 px.

👉 Rule #6
On the average, one tap with your finger captures about 44–48 px of a screen, 40 px is the minimum. This means, that all clickable elements (icons, links, buttons) should be located far enough from each other, so users will be able to tap these elements without touching an adjacent element. Otherwise, users might touch two elements at once. This will just irritate them, and they will have to make an additional action (for example, cancelling or returning).

Back to our interface.

We could narrow the grid to mobile device sizes at this point, but the remaining range of screen sizes includes smartphone landscape orientations and tablets. If after turning the phone the whole screen is filled with the product part in its full width, it will not be useful neither for website nor for users.

Let’s continue narrowing our grid at 1:1 rate:

  • We decrease the paddings from 40 px to 20 px;
  • We also decrease the title size from 36 px to 24 px.

When you adapt screen size for mobile devices, there are three ways for making button lengths less:

  • You can remove the icon from the button and keep the text;
  • You can remove the text and keep the icon;
  • You can remove some words from the text.

The way you do that is defined by the button.

Now we swap the product description and action buttons around. Yes, developers do not like when the order of elements is changed, and you should avoid that, but in this case it is important to have the price and “buy” button, rather than product description, on the first screen.

The size of the container with the field for choosing size and the button without an icon is equal to 238 px.

Calculating:
[10 + 10] + 238 + 20 = 278
278 = the minimum of 50%, minimum screen size for the grid is 556 px. We also keep some reserve space. The fourth breakpoint is 570 px.

👉 Rule #7
You can cut the data within buttons in an adaptive interface. If the icon is informative enough and can exist on its own, you can remove the text. If it is difficult to define the purpose of the button without the text, you should remove the icon and keep the text. In the context of the “Add to cart” button, it is more important to get the key action verb across users. “To do what? To buy!”
The “cart” icon does not evoke this association, but the verb definitely does.

Now we are going to discuss the sizes for mobile devices.

Most online-shops that use adaptive interfaces extend product pictures across whole screen. I believe this is not the best idea. Users can open larger picture by clicking on it, but it is also important to place the information about product on the first screen. In a perfect scenario, users should see product price, product picture, and the “buy” button on the first screen.

We can limit maximum width of the picture to 520 px for mobile devices, so the picture will not fill the whole screen, and there will still be some space for description.

We get five points:
1200, 880, 690, 570

This article is already rather big, so the following examples are described briefly.

Example 3. Another fluid grid

I am going to use one of the most popular grid structures with three columns for content: for example, the left column contains the list of note categories, the middle column contains the list of notes within specific category, and the right column is used for viewing specific note.

With multicolumn layout the defining factor is content. If there is a large amount of content, you should narrow the navigation and lists of notes/events/entries. If the amount of content is not that large, you should enhance lists and navigation, so the content will not stretch across the screen and still be easy-to-read on devices with wide screens.

👉 Rule #8
Keep the content in the middle area of the screen. It is supposed to be the main thing on the screen, and it should not make users tilt their heads too much.

Let’s link the columns and percentage:

  • Navigation takes 20%;
  • The list of notes within specific section takes 30%;
  • Note viewing takes 50%.

On the first stage, you need to define the width of the screen, with which list names, titles, dates and other information will fit the column with given text size. They stopped fitting? That is it, you’ve found the minimum point for given sizes.

By the way, the advantage of this grid is that 1920 px text in the right column on the screen is equal to only 840 px, so large fonts are still well-readable. When using bigger screens you can build up paddings within the block, and the text will still be readable.

You can start narrowing the page with decreasing the paddings.

Then, you can decrease the screen size by removing additional data elements (for example, icons). After moving the navigation into the “hamburger” icon, you can remove the left column.

In the end, we can keep only note viewing column for mobile devices. Just remember to create the button for returning to the previous step of a website catalog (the list of notes).

Example 4. Tile structure

Another popular interface grid, especially for dashboards.

So, we have an interface with tile design, Firstly, we compress it:

  • We define the width of the cards, with which data will still fit. Let’s decrease the cards to this width.
  • We also decrease paddings between the cards and the padding from the browser edge;
  • Now we change the order of cards: first we make three rows into two rows, and then into one row;
  • Now we fold irrelevant and non-informative cards. The closer we are to mobile device sizes, the less data we need. If some cards consist of graphs, then a large amount of content will make loading of the page more difficult;
  • Let’s group the cards. For example, two cards have similar content or graphs. We can combine them by hanging tabs on the block, thus decreasing the screen height and the number of elements needed for the page to load.

👉 Rule #9
Always remember about page loading speed and mobile data. Interface elements can be extended in different rates; some can be folded or hidden. You can decrease the amount of data within a block to decrease the height of the page for mobile devices. For example, show only 10 last events, not 20.

What can be done for big screens:

  • You can increase paddings;
  • You can extend cards;
  • You can extend only one card column. Not all cards must increase proportionally.

Here is a few more rules about interface behavior (for example, about pop-up tips or some other elements).

👉 Rule #10
Remember that touch screens do not have hovers. Switch it into a clickable element or replace it with something else.

👉 Rule #11
Use the longest names, post names, etc. Show what will happen, if the text does not fit within the block: the text cuts, the font size decreases, the text jumps on the next line.

👉 Rule #12
Show the exact location of returning on the “return” button. It can be a search window, a catalog, an account list, etc.

👉 Rule #13
Do not extend the text across whole screen. Define the maximum value. Remember that users will lose the next line of text if it is too long.

👉 Rule #14
Do not distance the elements of one block too far from each other. Users can miss them.

👉 Rule #15
Wide spaces attract users’ attention, increase the speed of reading, and make searching for elements on the page with your sight faster.

There we have it. I really hope you have found this article useful. If you have any questions, please, feel free to ask them in the comment section or send me messages in social networks.

https://dribbble.com/mawsik

Images and icons: vsworld.ru, unsplash.com, flaticon.com

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in Prototypr

Prototyping, UX Design, Front-end Development and Beyond 👾 | ✍️ Write for us https://bit.ly/apply-prototypr

Written by Mariya Tereshkova

Lead Product Designer at Quintegro (Beograd, Serbia)

Responses (1)