Your submission was sent successfully! Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

Making myasnchisdf.eu.org responsive: setting the rules (2)

Tags: Design

This article is more than 10 years old.


This post is part of the series ‘Making myasnchisdf.eu.org responsive‘.

The front end framework that powers www.myasnchisdf.eu.org represents the visual evolution of the site over the past few years: designs have become cleaner, lighter and more open. It was designed without responsiveness in mind, but it has proven flexible, robust and great for our needs: user experience designers can quickly create wireframes for new and updated pages based on existing patterns and developers can create new pages that look good with little input from designers.

Web style guide front page.

Even though the framework uses a fixed-width container to wrap the content, the containers within it were built to percentages, which means that if that surrounding container were to be removed, the site would become fluid.

One page of the current site without a wrapping container.

We didn’t want to lose the work that has been put into this style guide. After a long discussion, we agreed that even though we were going to convert the CSS powering the site into mobile-first — so the media queries would be added for larger screen sizes instead of the other way around —, we were going to keep the desktop version as it was initially defined in the style guide.

This is likely a restriction that many other teams share: where there is a will and need to make an existing site responsive, but no budget and/or resources to start from scratch.

We decided that it would be a good idea if our developers, Anthony, Graham, and Karl, could sit in a room for a few days and create a ‘quick and dirty’ prototype of what our current site, using the current styles, would look like in a responsive world.

The main goals of this exercise were:

  1. To see how disastrous, or indeed how well, the style guide would play when a handful of responsive guidelines were applied
  2. To give the developers a better understanding of the effort required and issues involved in converting the existing stylesheets into a mobile-first, responsive format

We created a Google doc, structured in the same way as our style guide, where we laid out some rules that would get the developers started on the prototype.

The document started with the more broad and general rules:

  • Try to create breakpoints that fit our content, instead of just random device-specific sizes
  • Try to keep breakpoints to a minimum, with fluid designs in between each breakpoint

We then laid out some scaffolding (layout and grid) rules:

  • Content that is divided in half or thirds should convert into single column when it becomes too narrow
  • If the content is divided into quarters, there might be a step in the middle (halfs)
  • In rows that include an image to the left or right of the text, the image should move above or below the text, respectively
  • Hero images might need to be looked at individually rather than a single rule for all
  • Experiment reducing padding inside rows and boxes incrementally as the screen size decreases
  • Remove column dividers at smaller screen sizes

We then moved on to forms rules:

  • Our forms are already quite vertical, at this stage, make sure we are using correct HTML5 input types

And tables rules:

And finally JavaScript rules:

  • No forcing of equal-height boxes
  • Make tabbed content into expanding/collapsing accordion widgets

Many of our styles didn’t need changing at this stage and this was all written down in the doc too.

We also knew that, at this point, we couldn’t look into trickier problems such as the navigation, the typographic scale or how our multiple footers would play in a small screen, so we decided to leave this for later.


Navigation and multiple footers were too complex an issue to be solved at this early stage.

Now it was time for the developers, with this doc in hand, to take a first go at making www.myasnchisdf.eu.org responsive!

Read the next post in this series: “Making myasnchisdf.eu.org responsive: making the rules a reality”

Reading list

Talk to us today

Interested in running Ubuntu in your organisation?

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

Related posts

Visual Testing: GitHub Actions Migration & Test Optimisation

What is Visual Testing? Visual testing analyses the visual appearance of a user interface. Snapshots of pages are taken to create a “baseline”, or the current...

Let’s talk open design

Why aren’t there more design contributions in open source? Help us find out!

Canonical’s recipe for High Performance Computing

In essence, High Performance Computing (HPC) is quite simple. Speed and scale. In practice, the concept is quite complex and hard to achieve. It is not...