What is fluid web design?

Today all web designers, and half the planet, are familiar with the concept of responsive web. However, there may be doubts about other terms that are back in fashion, although with a clear evolution of what they represent. Among them is fluid design.

In this sense, there is no clear consensus on what each concept encompasses between responsive, fluid and adaptive. Therefore, we will address the most useful distinctions in practice, and focus on fluid design, which offers more possibilities to adjust the behaviour of the interface for a better user experience and accessibility.

Starting from the beginning and in my opinion, it is not entirely correct to distinguish between fluid web design and responsive design. The reality is that the term fluid is being used to emphasise responsive best practice in terms of designing the elements and layout of a website in relation to the size of the screen from which it is visited.

In concrete terms, fluid design is a design system that adjusts our website, not only in its composition, but also in its sizes, heights or spaces in relation to the resolution of the screen on which it is displayed.

This means that the elements are displayed in one way or another depending on the device with which we access, i.e., if we use a 420px wide mobile phone, the web will be seen differently than if we access from a 360px wide screen. The same applies to tablets, desktop PCs, a television, a gameboy or the screen of a smart fridge.

Outside of layout, the use of relative measures is a recommended practice especially for interactive or multimedia elements, be they images, videos or animations. But it can also be applied to other web components such as typography, especially H1 or H2 headings, for example. We will see.

The essential issue is that in a fluid design, as I said, instead of using fixed sizes in pixels or other measure, relative measures such as Viewport Width (VW) / Viewport Heigh (VH) / EM / REM and percentages(%) are used.

Smooth interface design — Lamps - Augustus

The main objective of this design system is to maintain the same appearance and intention with which the prototype was designed on all devices, even for small differences in size. These prototypes are usually designed with different layouts for each screen width according to the breakpoint and with the user and the user experience in mind. That is why it is important to mention that fluid or relative design is also useful to address the accessibility and usability of the web.

However, the first thing to keep in mind is that relative sizes are not a perfect solution. They should be supplemented withfixed sizes and maximum and minimum sizes, where this is best for the result, as elements relative to the width of the screen may take sizes that are too large or too small depending on the device.

Below are some useful tips on how we approach fluid design, although it is reasonable to say that practice will be essential to master the technique.

A bit of context

Since the iPhone was released in 2007 (yes, 15 years ago today) everything changed. Smartphone users had at their disposal a quality web browsing experience that was not available before.

Nowadays, we have a huge variety of screen sizes, even up to 15 for the same device, from zoom, to the browser's size configuration options, or the Landscape option on mobiles. The point is that already at that time, Ethan Marcotte, the web designer who coined the term 'responsive', said that the behaviour and intention of users who browse from mobile is different from those of desktop and also their needs. Among other things, they are not looking to read as much text content and their navigation flows are more direct.

However, the question arises as to how much influence this behaviour has on users' acquired behaviour because they are used to a bad mobile experience, although it is true that the context in which a mobile is used as opposed to a desktop also plays a role.

Of course, all of us who used the internet in those days can agree that websites were not designed and prepared for this flood of devices and screens.

In any case, as I said, Ethan Marcotte is the first to mention the concept of 'responsive web design', in 2010. He does so in this article published on the website alistapart.com.

But accessibility and the multi-device experience had been under discussion for some time. And so had the adaptability of designs. A year earlier, in 2009, Marcotte himself published an article entitled Fluid Grids. In this article he already explains the 16px ratio of the browser and also uses the relative EM measure for titles and text, although with some differences, at least with respect to the practices we currently use in the agency. We will use EM with respect to the font size of the body and with respect to that of the browser settings, we will do it in REM.

In any case, the whole intention of this current of good practices and accessibility standards is to build a web ecosystem accessible to everyone and with the best possible experience regardless of the context and the device used to access it. And the big brands that bet on their online channel started to apply it.

Nowadays, on a website with sufficient traffic, more than 1,000 different screen resolutions can be registered by users. And our products have to be prepared for all, or at least the vast majority of them.

At this point, I ask for the reader's understanding because I will take advantage of these seconds of respite to include a positioning detail with the anchor text responsive design.

Differences between traditional Responsive, Adaptive and Responsive fluid (in practice).

Traditional responsive:

We will call traditional responsive to the most common practices of responsive design, where a fixed size of elements is usually used, but they are repositioned vertically according to the width of the screen or Viewport Width. This is what we know as stacking the elements within a container or wraper, with the container usually having relative widths in percentage or VW, and within it, the elements are arranged according to space.

As can be seen in the animation, the elements are reordered with the screen width, however, they have absolute sizes that do not vary.

To apply this adaptation, it is most common to use media queries for the different screen sizes, so that the layout of the website is adjusted to fit each width when the differences are too large.

The weaknesses of this system are especially noticeable between breakpoints, i.e. if we have defined a layout for the screen range between 1440px and 1650px, within that range the elements will not adjust dynamically with the width, as long as absolute sizes are used.

This responsive way of working is a useful and effective system when you do not require a very precise finish in your designs, or you are using a certain type of very modular and contained design.

Adaptive:

What is usually called adaptive design does not conflict with responsive design. To be understood, the difference lies in the fact that adaptive design has different files for each device, i.e. a specific layout is created for each screen on which we want the application to be displayed correctly. Using the browser's user agent, we can tell which layout should be loaded for that particular user and device.

It has its advantages, for example, you can iterate independently on a given layout more comfortably, without touching the rest of the design. On the other hand, for large sites, it is good that the user only loads the layout that corresponds to their device, as opposed to a single stylesheet, which can be very large.

We should bear in mind that on certain occasions, when we use a single responsive layout, there are elements that we hide for certain devices and, on the contrary, there are other elements that are shown. This is particularly noticeable in navigation menus. With the adaptive design we would save the user from loading those elements that do not correspond to his case.

However, it is also more labour-intensive.

From my point of view, it makes sense to use this technique in large ecommerce such as Amazon or BestBuy. It is also good practice for the development of PPPs.

If you want to go deeper into the subject, I recommend following the Flutter community, a Google-developed SDK that has its own youtube channel and a lot of content on the subject.

Responsive Fluid:

Fluid design is, therefore, a form of responsive design that avoids fixed sizes as long as they are not necessary and relativises their measurements to the screen width. Maximum and minimum sizes are also included so that a large element, such as a title, doesn't go over our heads or we don't end up with a font size of less than 16px on small devices.

Otherwise, to flow.

We will maintain breakpoints and modular stacking of elements where appropriate and, ultimately, make adjustments as appropriate in each circumstance.

All in all, the fluid design will provide a superior user experience between breakpoints and a finish that is very true to the design intent.

So, which system to use?

Well, of course, the system that best suits each case. Although I recommend applying fluid responsive as a general logic for web layout.

It is good and important to understand that when we design on our beautiful screens, we have a biased and partial view of the result, as most of the users visiting the website will probably use different resolutions.

General good practice in responsive design

As we said, each case is individual and these practices are not rigid or absolute, but it is certainly healthy to take them into account.

‍

‍

Design with Progressive enhance or mobile first logic: starting from the most demanding screen layouts in terms of simplicity to develop the design into more complex layouts.
Know and take into account the main screen resolutions, at least the widths.
Identify resolutions that are trending to bring your design forward to the next few years.
Check the web metrics history (if you have it). If you don't, use general browsing share data by devices and browsers.
Take into account the type of user interaction on each screen - on mobile we use our fingers, similarly to a tablet, versus the precision of a mouse on desktop. This implies several things for small screens:

Buttons should be large and thumb-accessible, as should links.
Ideally, sliders should be swipable, i.e. they should be able to be moved horizontally with the thumb.
The search engine becomes more important and must be accessible.
Navigation should be convenient and simplified
Focus the content on what is most important and eliminate the most superfluous elements.
Study and understand the browsing intent and context of your mobile users.

Take into consideration what happens between breakpoints, you may have black spots where elements are mounted or the layout is not displayed correctly.
Test. Not only with the dev tools, but also with real users and devices.

‍

How to apply fluid design in webflow: Fnsweet vs Wizardry

Currently there are two tools for no-code with webflow that are trending and we use them at kingseo. One is wizardry, by Timothy Ricks. The other is the Fnsweet system. Both techniques in full development in 2022.

Although we use the wizardry logic, both have their pros and cons. Let's look at the differences:

Wizardry

With wizardy we will use as reference the viewport width (vw) for the body, the parent par excellence, and all classes will inherit that reference for their proportional sizes in EM.

Me explico, el tamaño EM es un valor proporcional al tamaño de letra del contenedor parent. Es decir, si ponemos en <body> un tamaño de letra de 1vw, el valor EM de cualquiera de los elementos de la página será en relación a éste (salvo que otro parent diga lo contrario).
‍

Therefore, a font size of 3EM, will correspond to 3VW as long as its upper container has it set to 1vw.

But this only assures us the ratio between the size and width of the actual screen, what we want is that it is also proportional to the size ratios we have in our prototype.

For example:

If in our prototype we have a font size of 16px for a width of 1440px, we want the font size to be X for a screen of 1650px. Where X is to 1650, what 16 is to 1440. Yes, a rule of three.

Para este ejemplo, entonces el tamaño de letra del <body> será de 1.111111111112vw. Y nuestros tamaños de letra del Figma solo tendríamos que dividirlos entre 16 para usarlos en EM, en webflow.
‍

If we have a title with font size 90px. in our Figma of 1440, in webflow we can replicate it by dividing it by 16;(90/16) EM, where EM is equal to the font size of the body (1.1111111111111112vw).

This will make it exactly proportional, regardless of the screen size of the device where it is displayed.

But we will also need maximums and minimums, both for the containers and for the typography or any other element that we do not want to keep growing or shrinking out of control.

In this example, we define in CSS a maximum font size and container width for resolutions above 1440px.

<style>

body {font-size: 1.1111111111111112vw;}

/ Maximum font size /

@media screen and (min-width:1440px)

{body {font-size: 16px;}}

/ Maximum container width /

.container {max-width: 1440px;}

</style>
‍

If you need to see it more clearly, I recommend you watch these videos by Timothy Ricks:

And a slightly more complete one from the new version of Wizardry 2.0:

FnSweet

In contrast, FnSweet uses REM as a relative measure, which is a measure that depends on the user's browser settings.

If we use a large font setting on the computer or mobile phone, usually 18px or 20px, instead of 16px, then REM will be relative to that size.

In terms of accessibility, REM adapts the size of our layout to the user's needs. And that's a very good thing.

However, we then also have to relate it to the width of the screen by making a VW calculation.

Here is a video from Fnsweet where they explain it in detail:

The advantage of the Fnsweet system is mainly the commitment to accessibility. It is also 100% compatible with the su client-first class systemstandard, which is becoming popular in the webflow community and is itself used in the Relume library.

Conclusion: take heart in the 'One Web'.

One Web means a website as a unique and versatile product, usable by all types of users from any device. The users' experience must be our goal, as their satisfaction is the objective of our products.

It seems an appropriate mission to eliminate the frictions of navigation and facilitate the connection between all these proposals from brands, media, people and entities of all kinds, with the public that appreciates and consumes them.

For my part, dear reader, I hope I have been able to contribute some useful information to your concerns. I think that, whatever system you use, under a user-centred design philosophy you will make your products more used and valued by everyone.

By the way, if you have or work in a design studio in Madrid, or wherever, we can layout your prototypes. Just write to us and propose a collaboration.

All the best and happy designing.

‍