Fixed/Liquid: Frontend

We split our CSS into three major bundles. The foundations (base), code for small screens (small), code for large screens (large).

base.css All the foundations: reset, grids, components, etc. (all screens).

All the foundations: reset, grids, components, etc. (all screens). small.css Small screens: less than 600px (width).

Small screens: less than 600px (width). large.css Large screens: greater than or equal to 600px (width) Plus: Application “legacy” code.

We used a class applied to the body element to distinguish between liquid and fixed layouts.

The CSS for the grids were specified using the classes above as global scope. Like so:

This way, the same HTML could be used for both layouts. The only switch we needed to do in redesigned pages was that class on the body element.

Now, for our own sanity, we decided that our fixed layout would be essentially the large layout locked, on all screen sizes. To achieve that we just needed a tiny switch on the head of the document:

Notice that the url for the large.css bundle is exactly the same. We only vary the media attribute appropriately.

A magic bundle

The magic lies in how the large.css bundle is structured and kept. It includes:

Code for the fixed layout (legacy) only valid in the fixed layout inside a .fixed-grid context.

inside a .fixed-grid context. Code for the liquid layout in large screens only valid in the liquid layout inside a .fluid-grid context.

inside a .fluid-grid context. Code shared between the fixed and liquid layouts, without any context.

Fixed/Liquid: Backend

Of course this will depend on your framework and language of choice, but for the sake of completeness we’ll cover our Ruby On Rails solution. Feel free to leave suggestions for others, but a similar mechanism should be easy to adapt.

In a nutshell, we assumed by default, all pages use fixed layout. As we redesign views, we identify in each controller which actions are to use a fluid layout, if any.

Weighing the cons

We know some of you are already thinking that navigating a website with some pages with fixed layout and others liquid is not an optimal experience. And you’d be right. It’s not optimal. But it’s also not disastrous for the user, pages are still accessible and usable, albeit not as comfortable as they could be.

We weighed this against how long it would take for changes to be visible using the alternative lockdown method.

Example of navigating through different pages while Progressively Redesigning.

However, we did employ a strategy to lower the negative impact.

Redesign the public pages first. This way we provide an introduction to the product with a more cohesive and comfortable feel. These pages were also simpler , thus quicker to be seen live.

This way we provide an introduction to the product with a more cohesive and comfortable feel. These pages were also , thus quicker to be seen live. Redesign components responsively even when only used in fixed layouts. By redesigning components assuming any screen size (setting max. and min. widths), we could easily set a fixed-width around it on legacy pages. For example: .fixed-grid .campaign-card { width: 290px; }

By redesigning components assuming any screen size (setting max. and min. widths), we could easily set a fixed-width around it on legacy pages. For example: .fixed-grid .campaign-card { width: 290px; } Choose carefully which components to redesign first. The idea is to look at what is blocking pages from being switched to a liquid layout and deal with them one by one.

Conclusions and takeaways

Nothing in this article is particularly new or rocket science but the combination of these strategies makes this solution extremely easy to use and versatile enough to the point that we don’t even think about it since adopting it. It also allowed us to continue development of new features alongside the redesign, which is completely invaluable for our business.

If you have a website with quite a number of pages and complex forms, using this approach you can start bringing change to key areas of your product a lot faster than having to wait months (or even more than a year) to even see a change. It also allows you to adapt your result as feedback from users start to roll in.

What do you think? Have you used this approach? Would you use it?