From Fixed to Responsive
Implementing a Progressive Redesign at Seedrs.com
Websites are never done. If they don’t keep improving, they decay. Sometimes adding features isn’t the solution, a redesign is in order.
A redesign is always a great time to iron out a lot of the kinks that were never fixed due to technical or time constraints. However, not all redesigns are born equal. A couple of options lie before us.
In this particular case, we had the all-too-common problem of switching between a fixed-width layout to a responsive one. To achieve this, we could have picked two paths.
- Lockdown the product into maintenance mode and focus on the redesign: keep fixing production environment with critical fixes but halt new feature deployment. Focus all efforts in the redesign of all pages, deploy all at once. Ideal for websites with only a handful of different pages.
- Progressive Redesign: create new responsive foundations, make old code work alongside the new code (with a fixed-width grid); redesign pages and components (using a fluid grid) one at a time, deploying changes as they are finished.
When your product has more than a handful of pages to be redesigned and upcoming decisive features that need immediate deployment, the lockdown scenario is not an option.
The Progressive Redesign allows you to rebuild your foundations for a responsive approach and start showing change much faster in production while allowing new features to be developed side-by-side. A solid strategy for the order in which components/pages are redesigned is critical to the success of the redesign, though.
Each company and product has their own specific constraints but we’d still like to share how we implemented the Progressive Redesign at Seedrs.com, an equity crowdfunding website.
Getting started
Preparing for the Progressive Redesign
Just like in cooking shows, preparation is key. Rewriting legacy code is hardly ever pleasant but these guiding principles will help you a lot along the way.
We already had these implemented, but you can take the opportunity of the redesign to introduce them into your workflow.
- Design Systems, not pages. This is also known as using a Styleguide or Pattern Library approach. It means creating components prepared to be reused anywhere on the site or app. Learn more about CSS Systems and Atomic Design.
- Well planned CSS file structure. Splitting up the CSS forces structure into your code. Our code was already split up between public and private pages, depending on whether they required Signing In to visit them. It was also easy to pick up which was foundation code and which was page-specific code. This organisation helped a lot when we started rewriting the code into the new responsive codebase.
The plan
After considering all of the above and updating our Graded Browser Support matrix (bye bye IE8), we set out with a plan.
- Implement a new boilerplate/frontend architecture for responsive projects: reset, fluid grids, typographic scale, vertical rhythm, named color palettes, etc.
- Maintain all legacy pages with a fixed layout, no media-queries.
- Redesign using a liquid layout, with media-queries.
- Don’t maintain across old and new layout styles. When a component was to be redesigned, all occurrences should be updated and old styles removed.
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).
- small.css 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.
- Code for the liquid layout in large screens only valid in the liquid layout 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.
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.
- 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; }
- 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?
