Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bridging the gap between designers and developers at


Published on

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:

Published in: Technology, Design

Bridging the gap between designers and developers at

  1. 1. Bridging the gap between developers and designers with Sass at @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. 2. As some of you may already know, we’ve been busy developing a new responsive
  3. 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. 4. 55 contributors We count 55 contributors on the GitHub project.
  5. 5. ~25 touch HTML/CSS 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. 6. ~16K lines of CSS 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. 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. 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. 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. 10. Colours Let’s start with a rather simple part of the system to abstract: colours.
  11. 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. 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 ! 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. 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. 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. 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. 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. 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. 18. sass-mq • Reusable @media query abstraction • Each breakpoint is called by a name instead of a measure
  19. 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. 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. ! 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. 21. The grid
  22. 22. up to 16 60px columns 20px gutters 20px outer margins (10px on mobile)
  23. 23. 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.
  24. 24. 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.
  25. 25. // 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.
  26. 26. 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.
  27. 27. 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]
  28. 28. 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
  29. 29. 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.
  30. 30. 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].
  31. 31. Examples
  32. 32. 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; } }
  33. 33. 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); } }
  34. 34. Thank you We’re hiring! @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!