How I refactored CSS when redesigning a website iteratively

Nowadays it’s thankfully common that any backend redesign of a system, website or service is done iteratively, bit by bit. I often hear that that cannot be done with the frontend, that redesigning the look of a website always means you have to do a so-called “Big Bang release“, the very risky practice of releasing all relevant changes in one go after months of working on it.
I can prove that this is not true, because I’ve done two iterative redesigns of a website twice in my last job.

When I was rewriting and redesigning most of Zopa’s website iteratively in 2013, I used a specific method to refactor the CSS. When trying to explain how I did that, I found it’s easiest to explain its principles by showing what I did in a simplified version.
Here is that simplified version.

(Note: This blog post was hiding in my drafts folder for a couple of years. Nowadays it is best practice to use encapsulated components to achieve something similar.)

The simplified “website” I’m using as an example is quite unexciting. It has a header, a heading, a paragraph, a call-to-action link and a small widget with two radio boxes and a button.

0. Old design

This is a page of the website to redesign and refactor.

1. Prototype of new design

Create a prototype of the new design with at least the general layout and basic elements.

2. Old design in new shell

Change the surrounding layout (header and main content wrapper, I call that the “shell”) on all pages of the old design to share the same markup and style from the new design. At the same time prepare everything for the two different designs.

  • Move all old styles into a ‘v1’ folder.
  • Move all new styles into a ‘v2’ folder.
  • Update HTML for the shell across all pages.
  • Remove the old CSS for the shell (‘v1/layout.css’) and add the new CSS (‘v2/layout.css’) in old design pages (currently all pages).
  • Include an additional CSS file (‘layout_adjustments.css’) in all old design pages. That overrides the new CSS to make it look the same on pages with an old design CSS base.

3. First page in new design

Port the first page over to the new design:

  • Adjust the markup accordingly.
  • Instead of using the CSS files from the ‘v1’ folder, use the ones from the ‘v2’ folder.
  • If something is not designed as it should, see the next steps.

4. Unique component in new design

When porting a page with a component which is only used on this page (or on a small number of pages which can be ported together):

  • Adjust the HTML to the new design.
  • Add the new CSS (into ‘v2/components/*.css’).
  • And remove the old CSS (from ‘v1/components/*.css’).

5. Shared component in new and old design

When porting a page with a component which is used all over the website (on new as well as old design pages), what to do on a new design page:

  • Adjust the HTML to the new design.
  • Add the new CSS into a file which only contains CSS that can be shared between both designs (‘v2/components/*.css’).
  • Do this only together with the next step (changing shared component in old design).

On an old design page:

  • Adjust the HTML to the new design.
  • Add the body class ‘v1’ to old design pages and ‘v2’ to new design pages.
  • Make adjustments in the CSS for the shared component (in ‘v2/components/*.css’) by prepending changes with the ‘.v1’ class.
  • Remove the old CSS for this component (from ‘v1/components/*.css’).

6. Last page in new design

When the last page is ported over:

  • Delete the ‘v1’ folder.
  • Remove all occurrences of CSS rules prepended by ‘.v1’.
  • Remove all occurrences of the ‘.v2’ class in the CSS (not used in this example).
  • Remove ‘v1’ and ‘v2’ classes from the body.
  • Optional: Move contents of the ‘v2’ folder into the root.

All the things:

Tags: , , , ,

Leave a Reply