LWS Flux Live(ish) Blog (#lwsflux)

by lwsadmin. 0 Comments

Designing for the Responsive Web

A talk by Laura Kalbag (@laurakalbag).

Responsive Web Design is the natural evolution for web design. But the web is not an endless publishing platform. We’ve always known that there are different size screens, but we always locked it to one size. We know we need to be flexible, we need to stop thinking about averages and think about proper fluidity.

As designers we often push our creative ideas to the back of our mind. We try to focus on things that work. This talk is not technical at all. The slides are going to be interesting, a cross between Pictionary and Catchphrase. The talk is ignorant of technical difficulties on purpose.

Designers need to be able to write HTML and CSS. Knowing the code can constrain too much though while you’re creating. Try to forget this and think about the content, rather than worrying too much about technical difficulties too early on.

The first part of the project, you need to decide whether you’re going to sell responsive design.

So why bother?

It’s the easiest and cheapest. You’d be a bit daft not to think of optimising for different devices. It’s also future friendly. The web is going to exist on a lot of devices.

It’s also just fun. It’s good to have a challenge. We like learning, we like doing new things, so why not jump on the bandwagon?

Responsive Design as defined by Ethan Marcotte:

  1. it has a fluid grid
  2. flexible images
  3. uses media queries

Adaptive sites (often described as a branch of Responsive Design): Multiple versions of a design, designed around specific break points.

To be honest, she doesn’t care. Laura likes to have flexible websites. It’s important that the website is reactive, it reacts accordingly to different devices. It doesn’t necessarily mean mobile. Natalie Downe thinks you can have a responsive website and a separate mobile site. It’s more about users and content.

Once you have an idea for a responsive design, you have to sell it to the client. The important thing is, you need to keep communication going, let them air their concerns. Let them know who it is it’s being designed for. Which devices, which techniques, will it be adaptive or responsive? Although it’s difficult talking to clients about these things.

Think about why you’re doing responsive design. Are you doing it because it’s trendy? Make sure you’re doing it for the right reasons. Beware when looking at site analytics, don’t infer too much from a device being “mobile”.

Another option when making a site responsive – don’t tell the client anything. Anna Debenham says it’s “like accessibililty, you’d do it anyway”.

When you get into a responsive design project you need to immerse yourself in the content. Sometimes you need to give the client a push, they aren’t often forthcoming with it. She’s jumped straight into the design and development phase because as you’re designing you’re also developing. There isn’t a strict order anymore.

Whatever you do, with mobile devices, don’t fall into the “users on the move” cliché. You can’t assume context. Screen size doesn’t dictate connection speed or context. Things like touch screens, you can assume a small amount, e.g. you need touch point big enough. Also, hover interactions don’t work on a touch screen (this is bad usability anyway).

Design for the known. The safe way is to always design around the screen width. If there’s a small screen width it’s probably going to be close to you, if it’s a large screen you’re probably sitting much further away. When you’re designing think about the content hierarchy. What’s your ‘king of content’? Put this right on the top for both large and small screens.

Which brings up, which do you put at the top? Branding or content? She would probably put branding at the top, you want people to know where they are.

Brad Frost has a good list of responsive navigation patterns: http://bradfrostweb.com/blog/web/responsive-nav-patterns/‹

Also, don’t throw away content just because someone’s on a small screen, you’re only going to frustrate people doing that. You *can* get rid of excess design. This is all about the content, it’s important to drop your ego and strip away the design.

A big challenge on the large screen is thinking how it relates to the small screens. What do you make the same on your sites? What do you make different? The way to do this is through a design system. This might sound highly involved but we sort of doing this in our head already.

In design systems the big thing that can really help is colour. It’s an instant way for people to tell they’re on your site.

Once on the smaller screen and you’ve thrown away the excess decorative elements, you’re often left with the typography. The proportions between the font size and the line height, you’re creating a feel across your whole site, through the design system.

The great thing about the design system is that you can reuse it. Use it to plan individual elements and how they relate to each other and the overall design.

There are two good resources for this:

Paul Lloyd: http://paulrobertlloyd.com/about/styleguide/

Dan Cederholm Pear Library: http://simplebits.com/notebook/2012/02/07/pears/

Lorem Ipsum – The most important part of design is what you’re deigning for. Lorem Ipsum is just guessing. You can’t use it with design systems. It would be just a collection of arbitrary stuff.

You can also differential though different layout. Grid systems are a good way to do this. Don’t fall into the pattern that you have to reuse the same grid across each of the layouts. All you need is symmetry, a three column grid can break down to a two or one column.

Break-points  – Making your sizes around specific devices is dangerous, what happens if the devices disappear? You don’t know what devices people use to browse your content, you do know the size of your content, so design for that.

Flexibility – you can use major and minor break-points. You can use the minor ones to keep things neat and tidy. This can help with readability.

Process – we’re moving away from print based workflow. We need to mock up and get feedback as a continuation. Part of the problem with this new design process is that we haven’t got the best tools for the job. Between the browser and Photoshop/Fireworks we haven’t got two things that work well together. The problem with working in the browser, how do we stay creative? She thinks, if she designs in the browser everything ends up in boxes because that’s what CSS is good at. Forget about being purist on designing in the browser, do what is most creative. Robby Mansen said “Designing in the browser doesn’t necessarily foster creativity”.

What about mobile first? She quite likes designing desktop first. That doesn’t mean she’s not thinking about how it might work on the mobile screen. Do whatever comes first. Do the thing that presents you with the most problems, start with the problems you need to solve.

Do you have to create a million mockups for every break-point? If you do too many, you’ll fall into a black hole of mockups.

There is no best process anyway. There is no magic bullet. The magic bullet might be realising that everybody is different. You just need to make sure you’re continually communicating with clients. Open up your process and make sure you’re not wasting time. Test your design. She does this through the DropBox app by loading PNG images full screen on her iPhone.

Speed – some think the process will take longer. You can’t expect it to take the same amount of time. But you’re creating something that’s so much more and so much better.

As part of developing this new process we need to not be scared to reevaluate it. We need to take what we did right and adopt it and know what we did wrong. Then share your processes and thinking. You need criticism.

CSS: The Boring Bits (Peter Gasston)

A talk by Peter Gasston (@stopsatgreen).

He changed the title of the talk from “CSS3: The Boring Bits” because he’s going to be covering some CSS4 as well.

When he was coming up with the talk, he was trying to think of some boring things. Matrix Revolutions came to mind. Also, Lord of the Rings. Both boring. Oh and Cold Play, he appreciates what they do, but with the best will in the world, they’re boring. Apple vs. Android, the debate is so boring.

People tend to get more excited about the flashy things in CSS. You’ll be able to do native filters, sepia colouring, blurring, live graphical things. Cross fading as well. It’s very cool that you can do this, but Peter can’t think of any use cases yet.

He’s interested in the boring bits of CSS that you’ll never see in Smashing Magazine. He’s going to talk through the stuff you’ll be using soon, some stuff that’s a little way off and some stuff that’s just proposals.

Backgrounds and Border

Note: This section is a record of the comments Peter made (as accurate as I could make it) not the code. For that we’ll link to his slides from here.

The four value background position, it’s just landed in Firefox. It gives you a whole lot more control over how you position your background images. Border corner shape and border clip. Both will be implemented quite soon. Border clip will enable you to make completely custom borders in CSS. However this is all too close to being too exciting.


In XML you can define namespaces. Where this is useful is in SVG. You can namespace your CSS using XML and SVG. Boring but useful.


You’ll be able to load individual characters for each font. This is great as it improves loading times for your fonts.

Device Adaptation

Often we use the meta tag, but this is a very blunt instrument, it doesn’t work with tablets very well for example. You can set the viewport and set breakpoints instead.


It doesn’t get more boring than this. The “rem” unit. In CSS you can use the “em” size, but this inherits it’s size relatively. With the “route em”, you don’t have to worry about the em inheriting font values. You can use this now, in everything except Internet Explorer before version 9.

“vh” is viewport height, “vw” is viewport width, “vmin”  this works in a few browsers, only some support it.


attr() is fairly well supported across devices. An example of this would be attr(title) or attr(data-color color).

calc() is going to make layouts a lot lot easier.

cycle() – put a comma seperated list of values in here it will cycle through the styles. This means you won’t need to do loads of nested styles.


Target – the new hotness. It you link to an internal part of the page, you can highlight the element that they’ve just selected. You can build full image galleries using CSS, no JavaScript required. The drawback is it messes up the back button.

:dir() is a way to style different languages depending on it’s direction.

:not() this is quite well implemented at the moment. His company is working for Spotify who use Chromium for their rendering engine of their application. He was able to use this selector. It’s incredibly powerful once you start using it e.g. div:not(.foo)

:nth-* is another way of iterating. The classic example is zebra striping on a table. Otherwise the only other way is to do it programmatically.

:matches() lets you put in a comma seperated list of simple selectors.

:link, :visited and now :any-link will work on any link on the page. You can go one stage further with :local-link just for links from this website.

:column() you can use this to style tables. You’ll be able to use this in Internet Explorer 10. :nth-column() and :nth-last-column()

:past, :current, :future you could use this on screen reader programmes to highlight things that haven’t been read and grey out things in the past (just an example, may not be a good one).

$E > F this is the parent selector. You can now select the element E where the element F is inside it.

You can also use data attributes.


He hopes he’s shown that boring can be exiting. Within a year and a half to two years, we’re going to be able to use this stuff. If you compare what we know now and what we will need to know in a few years, it’s going to totally change. Buy his book (it’s not boring)!


Leave a Reply

Your email address will not be published. Required fields are marked *


HTML tags are not allowed.