bridging the gap between designers and developers at theguardian.com

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.

theguardian.com/uk?view=mobile

As some of you may already know, we’ve been busy developing a new responsive theguardian.com

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!

55 contributorsgithub.com/guardian/frontend

We count 55 contributors on the GitHub project.

~25 touch HTML/CSSgithub.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.

~16K lines of CSSgithub.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.

Developer toolbox

Scala

Play!

GruntSass

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.

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).

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?

Colours

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

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.

$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!

$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.

$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.

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.

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.

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.

sass-mq

• Reusable @media query abstraction

• Each breakpoint is called by a name instead of a measure

github.io/sass-mq

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.

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.

The grid

up to 16 60px columns

20px gutters

20px outer margins (10px on mobile)

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.

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.

// 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.

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.

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]

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

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.

CommunicatingOn 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].

Examples

Example 1On 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; }}

Example 2From 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); }}

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!