There is often a vocabulary gap between designers an developers, who should aim towards a ubiquitous way of conversing about colours, typography, viewport sizes, or the responsive grid system of a digital product… To bridge this gap at the Guardian, we use a CSS pre-processor as a communication enabler through the abstractions it allows us to put in place. Talk given at the Front-end London meet-up on April 24, 2014. Listen to the talk + slides on YouTube: https://www.youtube.com/watch?v=DAfW1RSWYDA

1. Bridging the gap between
developers and designers
with Sass at theguardian.com
@kaelig
Hi!
!
I’m Kaelig, I’m a front-end developer, and as you might have guessed from my accent I am French. Two years ago I wrote a book in French about how to
write maintainable CSS, then I moved to the UK to learn English. My first job was on the responsive BBC news website. And now I basically do exactly the
same job, but at the Guardian instead.
!
Today I’d like to talk to you about how we bridge the communication gap between developers and designers at the Guardian.
!
The other day, I dreamt that I punched a designer in the face. And I really felt bad about it for a long time after I woke up. So maybe this presentation is
my way of absolving my guilt. Who knows.
!
I hope you can take away some of the things I’ll show you to apply them in your workflow and your day job.

2. theguardian.com/uk?view=mobile
As some of you may already know, we’ve been busy developing a new responsive theguardian.com

3. Release cycle
~4 times a day
We release about 4 times a day. What this means from a product perspective is that we can iterate on features very quickly: we put a feature in front of
people, see how people use it, and then iterate on it. Depending on its performance, after a few days or weeks we can decide if this feature is worth
keeping or deserves a violent death. A lot of features never make it past 4 weeks, you’d be surprised to see how much code we put in and then throw
away!
!
And in the spirit of the guardian’s openness about journalism, the entire project is open source!

4. 55 contributors
github.com/guardian/frontend
We count 55 contributors on the GitHub project.

5. ~25 touch HTML/CSS
github.com/guardian/frontend
Around half of these 55 contributors actively commit, and most of us will touch the HTML templates and/or the CSS files at some point. That’s a lot of
people, who of course produce a lot of code, with different levels of expertise in the array of languages we use.

6. ~16K lines of CSS
github.com/guardian/frontend
Our CSS codebase is quite big. With 25 people releasing 4 times a day, things can go wrong pretty quickly. Part of my job is to craft the tools that will
enable people to make changes easily to the codebase, whatever their knowledge and skills might be when it comes to user interface development.

7. Developer toolbox
Scala
Play!
Grunt
Sass
RequireJS
Bower
AWS
Node.jsSelenium
Our front-end toolkit is comprised of numerous tools. We are free to use the tools we want depending on the job. Today I’m going to focus on a single
part of our toolbox: Sass.
Sass is a CSS pre-processor. It brings programming capabilities to CSS, like variables, if-else conditions, loops, functions… It’s very useful on large
codebase like ours because it avoids us to repeat ourselves all the time.
When used wisely, you’ll see that it’s much more than a developer tool. It’s also a really great communication tool.

8. Design system
Let’s talk quickly about our design system.
A design system is a set of principles and abstractions around breakpoints, typography, grids, layout, shapes, colours… and what have you… that will
dictate the way you build your site around its content.
The rules must be clear to everyone to us to focus on the important bits of the user interface (what the users see).

9. Design system
Developer toolbox
4 grid columns
4x40px + 3x20px
Happy and productive collaboration is something we care about a lot. For that, we need to be able to communicate very efficiently between people
across teams.
!
Unfortunately, our developer tools and our design system don’t know anything about each other.
!
With our design system, we’re able to think: “4 grid columns”. But in code, it is something that means “four 40 pixels wide blocks with 20 pixels between
them”.
As you can imagine, this is a massive communication overhead that heavily impacts productivity.
!
Question is: can we get the developer toolbox to reflect the design system, so that we all speak the same language during planning, design and
development phases?

10. Colours
Let’s start with a rather simple part of the system to abstract: colours.

11. Sass variables
Declaring a variable in Sass:
$variable: value;
Using a variable in Sass:
$my-color: red;
.my-text { color: $my-color; }
It will output in CSS:
.my-text { color: red; }
First, let me introduce you to a concept we’ll use heavily when abstracting the design system away: variables.
!
[ go through the slide ]
!
Get it? Let’s see how we can use that to our advantage when it comes to colours.

12. $c-brandBlue: #214583;
$c-error: #d61d00;
!
$c-neutral1: #333333;
$c-neutral2: #767676;
$c-neutral3: #bdbdbd;
$c-neutral4: #dcdcdc;
$c-neutral5: #e3e3db;
$c-neutral6: #edede7;
$c-neutral7: #f4f4ee;
$c-neutral8: #f6f6f6;
Core palette
Here are the main colours used on theguardian.com
!
Hexadecimal values like #e3e3db are a bit hard to communicate and remember, and easy to mess up with. Referring to colours by their names would be
so much simpler!

13. $c-brandBlue: #214583;
$c-error #d61d00;
!
$c-neutral1: #333333;
$c-neutral2: #767676;
$c-neutral3: #bdbdbd;
$c-neutral4: #dcdcdc;
$c-neutral5: #e3e3db;
$c-neutral6: #edede7;
$c-neutral7: #f4f4ee;
$c-neutral8: #f6f6f6;
Core palette
Guardian blue
Gray scale
!
So we gave them names that we can all use.

14. $c-brandBlue: #214583;
$c-error: #d61d00;
!
$c-neutral1: #333333;
$c-neutral2: #767676;
$c-neutral3: #bdbdbd;
$c-neutral4: #dcdcdc;
$c-neutral5: #e3e3db;
$c-neutral6: #edede7;
$c-neutral7: #f4f4ee;
$c-neutral8: #f6f6f6;
Core palette
Instead of saying “this bit of text need to be #767676”, we simply refer to a colour directly by its name.
!
Much better, right?
!
You can see we prefixed all colour variables with c-. It’s to differentiate them from other variables which have nothing to do with colours.

15. Tones
$c-newsDefault: #005689;
$c-newsAccent: #4BC6DF;
!
$c-featureDefault: #951C55;
$c-featureAccent: #F66980;
!
$c-commentDefault: #E6711B;
$c-commentAccent: #FFBB00;
!
$c-features-primary: #4e0375;
$c-features-secondary: #7d0068;
$c-features-tertiary: #951c55;
We did the same with tonal colours in use for different sections of the site. Again, these come from designers.
!
This was a really simple first step and you can do it too. Make sure you name the variables with names of colours people want to use when communicating
design intents to each other.

16. What you want to avoid
$error: #ff0000;
$red: #ff0000;
Better
Be careful when naming colour variables. Avoid being too specific. In most cases you’ll want to be abstract enough so that your values reflect a concept,
not the colour itself.

17. Breakpoints
Now let’s talk about breakpoints.
!
In any responsive website, you have a couple of main breakpoints that everyone should know about.
!
Again, we want to give names to these breakpoints to streamline communication in the team. It’s not only useful for designers and developers. It’s very
useful for QA as well. When reporting bugs it’s also easier to refer to “a bug at tablet breakpoint” than “a bug between 740 and 900px”.
!
Unfortunately our tools don’t know about these names. So we had to build an abstraction that speaks the same language we do.

18. sass-mq
• Reusable @media query abstraction
• Each breakpoint is called by a name instead of a
measure
github.io/sass-mq

19. Naming breakpoints
$mq-breakpoints: (
mobile: 320px,
tablet: 740px,
desktop: 980px,
wide: 1300px
);
Naming breakpoints is tricky because from a philosophical perspective we’d like to be as device agnostic as possible. We could call the major breakpoints
“small, medium, large…”. But from a practical perspective this would not necessarily help us.
So we are calling our major breakpoints with device families that everyone knows of: mobile, tablet, desktop, and wide for wide screens.
This way, the business, the designers and developers all know a same set of names when referring to breakpoints or families of devices.
In this slide you can see the configuration we are passing to sass-mq. A breakpoint has a name and a width. We only have to remember the names, and
that’s it. Oh and of course, designers build their designs and deliver them around these 4 main breakpoints.

20. sass-mq: example
.header {
background: blue;
!
@include mq($from: tablet) {
background: transparent;
}
}
.header {
background: blue;
}
@media all and (min-width: 37.5em) {
.header {
background: transparent;
}
}
Sass
CSS
In this example, we are telling the header to have a blue background. Then on tablet we’d like it to be transparent instead.
http://sassmeister.com/gist/11261517
!
Sass parses this instruction and outputs the corresponding CSS. We declared our breakpoints in pixels because it’s easier to understand for humans than
ems, but sass-mq outputs media queries with relative units so that our layout scales with the level of browser zoom and / or user defined font size.

21. The grid

23. up to 16 60px columns
20px gutters
20px outer margins
(10px on mobile)

24. As with colours, we created a set of variables and helpers, this time for the gutters, column width, etc.
!
Its documentation stands in one image. Everyone can pick it up really quickly and not worry too much about pixel values.

25. Now you know about the grid…
let’s play
I did not tell the whole story when I was initially showing you how we name breakpoints with sass-mq. In reality we have many breakpoints: 4 major
breakpoints (that I showed you earlier) and 5 additional minor breakpoints. These breakpoints help us deal with layout changes and happen at widths that
are determined by the grid.

26. // Article breakpoints
$a-rightCol-width: gs-span(4);
$a-rightCol-trigger: gs-span(11) + $gs-gutter*2; // 900px
$a-leftCol-width: gs-span(2); // Grows to 3 columns on wide viewports
$a-leftCol-trigger: gs-span(13) + $gs-gutter*2; // 1060px
$a-leftColWide-width: gs-span(3);
!
// Facia breakpoints
$facia-leftCol-trigger: gs-span(14) + $gs-gutter*2; // 1140px
!
$mq-breakpoints: (
mobile: gs-span(4) + $gs-gutter, // 320px
tablet: gs-span(9) + $gs-gutter*2, // 740px
desktop: gs-span(12) + $gs-gutter*2, // 980px
wide: gs-span(16) + $gs-gutter*2, // 1300px
!
// Tweakpoints
mobileLandscape: gs-span(6) + $gs-gutter, // 480px
desktopAd: 810px,
!
// Article layout
rightCol: $a-rightCol-trigger,
leftCol: $a-leftCol-trigger,
!
// Facia layout
faciaLeftCol: $facia-leftCol-trigger
);
Settings for most of our breakpoints are in the main configuration file. Here is how we use the grid AND sass-mq to define breakpoints. Mobile starts at 4
columns + its outer margins. Tablet, 9 columns + outer margins, desktop 12, widescreen 16.
!
As you can see we favoured breakpoints built around the layout and device families. But we’re also quite pragmatic and have some “industry standard”
breakpoint at small sizes, hence the 320 and 480 pixel breakpoints for mobile and mobile landscape.
!
And that was the breakpoints.

27. Typography
Let’s talk about typography!
!
Typography is a critical element of a successful design, and we care a lot about it at the Guardian.
We’re lucky that a set of fonts was designed especially for us a few years ago by the great foundry Commercial Type.
These fonts are called “Egyptian” and “Agate”. They part of the Guardian brand, and were created for an optimal legibility in multiple contexts.
!
That’s really cool to work with such quality material.

28. Egyptian Text Bold
• On the designers’ computers:
“TE4 Text Egyptian Medium - regular”
• In the CSS: EgyptianText 700 / bold
And we use 4 different fonts…
The only issue with these fonts is that they have completely different names depending on if you would use them in, say, Photoshop ; and if you’d use
them on the web. We even use different font weights on the web than what the font name would suggest.
!
[read slide]

29. Speaking the same
language
• Header
• Headline
• Body Headings
• Body Copy
• Data
• Text Sans (we could not find a better name)
Once again, we agreed on a shared convention and we gave names to all fonts / weights to reflect their usage

30. What we did is that we put them all in a matrix.
This matrix contains:
- the name of the font in Photoshop, for designers
- the actual name in the CSS that the browser will read
- the abstraction developers want to use when writing CSS
- and the “Human friendly” name we choose to give it when talking about it: header, headline, body heading, body copy, data, and text sans.
!
Thanks to this matrix, we all speak the same language when talking about typography.

31. Communicating
On mobile, the component title should be a headline 3.
On tablet and up it is a headline 4.
Can you change the table cells text to “data 4” on desktop?
When the byline is in the sidebar, it should be a header 1.
As a result, we streamlined a lot of the communication between designers and developers.
For example, when dealing with responsive text we’d say [first quote],
When dealing with design changes we’d say [quote 2]
And when dealing with location based creative directions, we’d say [quote 3].

32. Examples

33. Example 1
On mobile, outer margins are half a gutter.
On mobile landscape and up, they are a full gutter.
.container {
margin-left: $gs-gutter/2;
margin-right: $gs-gutter/2;
!
@include mq(mobileLandscape) {
margin-left: $gs-gutter;
margin-right: $gs-gutter;
}
}

34. Example 2
From mobile to tablet, the call to action text is a headline 2.
After that, it’s a headline 4.
Its colour should always be neutral 5.
.component__caltoaction {
color: $c-neutral5;
!
@include mq($to: tablet) {
@include fs-headline(2);
}
@include mq(tablet) {
@include fs-headline(4);
}
}

35. Thank you
We’re hiring!
k@elig.me
@kaelig
If you’re a designer, I hope you’ll want to talk more about your design systems with developers. And if you are a developer, I hope you’ll want to make
communication better by getting your tools to speak the same language as the team’s language.
Thank you very much, and please come talk to me or shoot me an email if you’d like to work with us on making our responsive website even more
awesome!