Responsive Web Design - but for real!

CSS3 Media Queries(and Responsive Web Design)but for real!

The truth, the lies, and the legend!

Rudy Rigot

[email protected]

@rudyrigot

http://rudyonweb.net

Clever Age

So, this talk was given in Krakow, Poland, on Oct 21st 2011, and i removed a few slides to make it more intelligible here.I'll skip the presentation of myself, because you can find that on the internet: http://rudyonweb.net/about

Responsive Web Design

So, the topic of the day is Responsive Web Design...

Adaptive Web Design?

Responsive Layouts?

Mediaqueries?

Fluid grid?

Responsive Web Design

That'smy word!I guess it's safe to say that it's been a little bit of a BUZZword lately (ah ah), and like any buzzword, it gets confused with a lot of other words.We'll try to do two things today: we'll try to kill the buzzword and put some acurate definitions on things; and then i'll try to give you some input about how a proper big "too-many-templates-not-to-wireframe" project might go.This last part is going to be interesting, because a lot of things are still being experimental at the moment, so the best practise are still much to be written.

"Whatever is well conceived is clearly said" - Nicolas Boileau

SOME TRUTH

Alright, let's put some truth into this, and be acurate to kill the buzzwords.(you could say that the words don't matter on the battlefield, as long as everyone knows where we're going about, and i would agree; but i assume we're all professionals around here, so we're all into acuracy, supposedly)

Responsive Web Design"i'm a webpage, and i care about your display!"

If i had to put a definition to a site in RWD, then it would be any website that cares about your display.


?

It basically means that if your display width changes, no matter what the technical way is, you have a serious case of RWD on your hands!


Adaptive Web Design"i'm a webpage,and i care about whoever you are"

Adaptive Web Design is very often confused with Responsive, and there's a good reason for that: RWD is AWD! But reverse isn't true...



See:Progressive Enhancement

client 1

client 2

It basically is a website that changes according to the browser context, whichever element of the context it uses. If you read the "Adaptive Web Design" book, thinking to read about RWD, you might be disappointed, because all that thing talks about is progressive enhancement (which is basically the same thing as AWD)


http://www.londonandpartners.com


Examples: here is a RWD, whose width adapts depending on the browser width. If you want to see responsive websites in actions, you might just want to go to http://mediaqueri.es/



http://www.prevention-medicale.org

Whereas here is an adaptive website, which isn't responsive: it doesn't move when you resize your browser, however, look at what happens when you disable JS (the image to the left).The JS version offers a nice menu, and a beautiful slideshow; that's exactly what they call "progressive enhancement". Adaptive Web Design, in other words.Now you know the difference between the two pretty well, so let's move on.


Fluid Grid"how large may i be again?Wait here as i stretch my columns!"


Fluid Grid is simple, and has been existing for years (people could do it from CSS2 already). Each of the columns of the vertical grid simply expands with the browser.The tricky bit is: the contents in the columns too need to be "fluid"!


Responsive Layouts"how large may i be again?Wait here as i rearrange my blocks!"



And Responsive Layouts are pretty much the same as Fluid Grids, but once in a while, blocs will move, and get on top of each other.Same tricky bit: the contents still need to be fluid, though.





So this is what you get. A happy buzzword league, which you can relocate precisely in your brains, now!




?


One question though: are you sure you got the difference between Responsive Web Design et Responsive Layouts?




http://w3qualite.net


This is a blatant example of a website with RWD, but not especially Responsive Layouts. No bloc was moved during the making of this browser size change!(This is only the header of the site here, obviously. The site is a site about web quality, started by a few cool friends of mine)





Wait! I read something, and i thoughtResponsive Web Design was this thing!But some of you may ask...




Yep, it used to be,and now it's blurry!


Wait! I read something, and i thoughtResponsive Web Design was this thing!To which i respond: it used to be. Actually, the book speaks about Responsive Layouts, and refers to them as "Responsive Web Design". The book was published by the almighty Jeffrey Zeldman (and written by Ethan Marcotte), but Zeldman published a blog post later saying they got the wrong word, and that RWD should point to any technique that allows you to have multiple-sized websites.




Used to be the one called Responsive Web Design between May 2010 and July 2011!!


So, basically, between the publishing of the book (May 2010) and the one of the corrective Zeldman blog post (July 2011), Responsive Layouts was what was called Responsive Web Design!So, you still find it heavily in litterature.What it proves, though, is that the topic is burning HOT, and that history is being written as we speak.




From now on, let's speak about this!


From now on, all along this talk, we'll speak about this!

Wait! How about the mediaqueries?

By the way, didn't we forget one buzzword?




Mediaqueries = technical tool


One of the things they do: they're a technical tool (not a design concept, unlike the others), and among other things, they make that leap possible.(among a lot, lot of other things)

Let's get some hands dirty a little

SOME TECH

Actually, let's speak about it further, mediaqueries are worth a chapter of this talk!

Why mediaqueries?

To understand media-queries, what's best is to get back to the initial problem that ultimately created them.

The problem

Server

Client

Webpage(html, css, js,and all that stuff)

Alright, client server HTTP every day stuff. Nothing new.

The problem

Server

Client

Webpage(html, css, js,and all that stuff)

Monochrome, tinye-book

Same webpage(same css& js ?)

But now the same website goes to a different client. And it's not a fancy display screen like the other, it's a shitty monochrome e-book.How do i control better what is being showed in the e-book?

Two solutions!

Basically, it's either the server deciding, or the clients.

Solution 1: the serves sends different files

Server

Client


Wait! How the helldo i know whoi'm talking to?If it's the server, the server sends a different CSS stylesheet to each device. But it needs to know first what device it's talking to.


Server

Client


HTTP headers (User-Agent)


And if you look at it, devices identify themselves with something called a "User Agent", which is sent in the HTTP headers by the client.Pretty awesome, isn't it?


Server

Client




Well, actually no, not pretty awesome.

Browser sniffing is NOT an ideal solution!

I'm not saying it's the devil in every case, but it is definitely not the ideal reponse to your issues (more about being pragmatic about that later)

1- User Agent parsing is error-prone

Opera 9 Opera/9.64 (Windows NT 6.0; U; en) Presto/2.1.1

Opera 10a Opera/10.00 (Windows NT 6.0; U; en) Presto/2.2.0

Broken!


Some of you may know the story: when Opera 10 alpha got released, they used the same-looking User Agent as the previous version (pretty logical). But, the User Agent being quite messy (as you can see), its parsing can go wrong. So when some servers were looking into separating old to new browsers, they recognized Opera, and read the 7 first characters of the User Agent string, thus thinking to be talking to "Opera/1"!Bottom line, some websites were displaying their old sucky version to the latest Opera browser!




Broken!


http://www.allocine.fr

Of course, this kind of stupid mistakes in code wouldn't happen for a major website, since as we all know, they're all made by clever people who never make mistakes. So it wouldn't happen to one of the most visited websites in France, our local imdb, for sure (oh wait, yep it did!)




Yeay, fixed!



So, when Opera release its final 10th version, they had to label it wrongly, to ensure that every server would still work fine.And every single person on Earth was happy ever after!




Yeay, fixed!



But...

Actually, they weren't...




Oops?



Because some other parsers trying to tell mobile browsers from desktop browsers think they're talking the Palm Pre while really talking to desktop Opera and its web engine, Presto.




Oops?



http://www.state.gov

And of course, this would not happen to big websites, since they're still being made by clever, beautiful people who never make mistakes, like those who made the US Department of State website, for instance, which displays like the picture on the left while in the latest desktop versions of Opera!So that's one first reason to avoid browser sniffing: it's hard to parse a string as complex as the User Agent; and that's actually also the reason why (wait for it....)


2- Browsers are liars!

IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0 (...)

Wait, what?!


browsers constantly have to lie!This little trick comes from the time Mozilla was, compared to Mosaic, the only "rich" (well, like, having images and forms, woaw) browser out there, and some servers keep using sniffing scripts today to show crappy text versions of their webpages when talking to something else than Mozilla. Nice...



3- You're sure you know ALL the browsers?


Plus, anyway, even if the User Agents were reliable, and more semantic, would you be sure to cover ALL of them easily?



3- You're sure you know ALL the browsers?

4- And you're sure you know ALL the browsers... from the future?!


And plus, all of those who have yet to exist??

So yeah, browser sniffing to the trash for now!

Solution 2: the serves sends everything,the client decides what to use

Server

Client


First solution was to let the server decide; second solution would be to send everything to the clients, and let THEM decide what CSS they're supposed to apply or not.

some other usual css stuff...But how?

some usual css stuff...If you're a regular1024x768 multi-colordisplay, then...

If you're a tinyand monochromeE-book, then...

So what you need is, in the CSS, to be able to tell which part of the CSS applies to which of the two clients (the nice display, or the e-book)

some other usual css stuff...But how?

some usual css stuff...If you're a regular1024x768 multi-colordisplay, then...

If you're a tinyand monochromeE-book, then...

CSS3 mediaqueries!

@media screen {

}

@media handheld and (min-monochrome: 1) {

}

And that's what media-queries are for initially!Now, let me attract your attention to the fact that i'm using a keyword which is "monochrome". You might suess that "monochrome" is definitely not about smartphones, tablets, and other fancy stuff...

So... mediaqueries arenot only about mobile!

monochromegridscanresolutionorientationcolor-indexcolordevice-aspect-ratioaspect-ratiodevice-heightdevice-widthheightwidthAnd when you look at the 13 keywords that are mentioned in the spec candidate release (latest version to date), you can see that...


monochromegridscanresolutionorientationcolor-indexcolordevice-aspect-ratioaspect-ratiodevice-heightdevice-widthheightwidthparticularly usefulfor e-books!

particularly usefulfor TVs!

particularly usefulfor resizable windows!

particularly usefulfor mobiles!

some of them are mostly for e-books, some are mostly for TVs, some mostly for resizable windows, some for mobiles, etc.Pretty simple graph, eh?






CC BY Yusuke Kawasaki

Yeah, no, not pretty simple graph...






But what i need you to remember is: mediaqueries are not especially about mobile. They're very much about each and every device type out there.

Truth and lies, you said?

SOME MYTHS

Next, we're going to take a few myths that are being said about Responsive Web Design at the moment, and try to pragmatically tell the truth from the lies.

Every website should be responsive

MYTH #1

One first myth that's heard out there...

Every website should be responsive

MYTH #1

Ok, that's probably more of an opinion (Andreas Bovens from Opera was at Paris Web last week, and he didn't seem to agree very much), but it seems obvious to me that there are some use cases where the mobile webapp needs to be separated.

Could be one page

Could be another page

Could be another other page

http://www.facebook.com

For instance, take the Facebook homepage, right? You could make basically at least 3 decent mobile webpages from that!And responsive will make each page turn into one page in the mobile version. You can't separate the pages.

Could be one page

Could be another page

Could be another other page

http://www.facebook.com

When you look at Facebook's latest version of their mobile website, it does look like their home was taken from that green frame in the desktop.What happens to the other features, in that case?

Browser sniffing...

Of course, who says "different use case which justifies a separate app" says "redirection to the mobile website when smart", and then says "browser sniffing"... Which means we might end up looking like that.There is no better technology today to achieve that, although i insist it is supposedly bad practise.

Browser sniffing...

So, since we're using bad practise, we might as well do it nicely: a clever way to enable the user to correct the sniffing mistakes when they happen, would be to get each version of the site to link to the other.

Responsive Web Design is awful forfront-end performance

MYTH #2

Alright, myth 2!Bad for performance? People who say such things should be ashamed!


MYTH #2

Although, yeah, they're mostly right, though...

some css foranother deviceTruth because...

some css for onedevice

USELESS !

One first obvious case: when you have a bit of CSS code (green) aimed at a device type (green), and another bit of CSS code (blue) in another media-query, aimed at other devices, then when the first device (green) downloads the CSS, the whole blue part is going to be entirely useless for him!



USELESS !

but there may be solutions?

However, one solution would be to lazy-load the bits of CSS that don't apply, i.e. to cut the various CSS bits for each mediaquery, each in a different file. The spec does allow you to write your media query in the "media" attribute of a element while embedding a CSS file. The browser could then download only the files that match its current situation, and lazy load the others as the situation changes.



USELESS !

but there may be solutions?

Ouch, browsers downloadthem all anyway! (for now...)

However, this does not at all work, in any browser at the moment (i only tested Firefox, Chrome, and Opera, though): they all download all of the CSS files first, and think later.However again, if it is better for the performance of responsive websites, and it doesn't damage anything else, nothing forbids the browsers to implement it later on.(NB: this is something i haven't discussed with the people from Opera and Mozilla that i know; i'll make a blog post about it, and ask for their opinion, though, so stay tuned!)

some css foranother devicesome css for onedevice

pngjpgjpg

pngjpgpng

Truth because for some browsers...

USELESS !

Second case: some browsers, when including CSS background images, download them, whether the CSS rule applies or not. Useless!!Naming them would be unfair, so let's just randomly name them "webkit-based" browsers. ;)

some css foranother devicesome css for onedevice

pngjpgjpg

pngjpgpng

Truth because for some browsers...

USELESS !

but this is being fixed!

However, the bug is already fixed in Webkit today, the browsers have just not all updated their Webkit engines enough to have the bug fixed.Chrome is up to date on most platforms, but i think to date, Safari is still making the mistake. But not for very long, obviously...

img.hide_me { display: none;}Truth because for all browsers...

img.hide_me { display: inline;}

png

USELESS !

Last case: you have an image in the HTML file, and it's hidden in the CSS for your device. All browsers today download the file.I had this conversation with Anthony Ricaud from Mozilla, and he was pretty clear about it: content image downloading can't be blocked by CSS rendering. HTML images shouldn't wait to know if they're hidden or not, basically (it would make the performances even way worse)

img.hide_me { display: none;}Truth because for all browsers...

img.hide_me { display: inline;}

png

USELESS !

but there are solutionsto come !!

css rule "content"

media query listener

dedicated javascript

Meh...Meh...Meh...However, some solutions are coming up.First, you can use the CSS rule "content" to insert the image on CSS (which will lazy-load it in every browser but Safari for now, as we just said); however, putting a content image in your CSS is definitely not smart for your semantic (and your SEO on the image)Or else, you have the "media query listener" feature that has been designed by Microsoft exactly to deal with such cases; however, in Paris Web last week, David Rousset from Microsoft was talking about it, and Daniel Glazman from the W3C CSS Working Group was in the room, and didn't seem so eager to see it join the spec.At last, you can lazy-load it with javascript! Either you write a script, or there are tons out there for that. But eh... it is javascript, so your accessibility expert might hate you for this...


True, not great, but will get better!

MYTH #2

So at the end of the day, i'd say: alright, the performances are impacted, for sure, but it is an issue that is actively being worked on. Either from progressive bugfixes in the browsers, or by hacking stuff a little bit, and have to make compromises on semantic or accessibility, to gain said lost performance.

My Responsive Web Design isgoing to look like crap on IE6...

MYTH #3

Myth #3!

My Responsive Web Design isgoing to look like crap on IE6...

MYTH #3

WROOOONG!I'm not saying it is going to make your IE6 optimizations easier; but it will not make them harder either.

some css foranother deviceFalling back is easy

some css for onedevicesome css forold browsers whodon't get CSS3

Mobile first?respond.js!

An obvious reason would be because fallbacking is easy: old browsers don't understand mediaqueries, so you can leave your code "for old desktop browsers" outside of any mediaquery, and override it for the newer browsers in mediaqueries.If you want to develop for front-end following the mobile first strategy (which, to me, was mostly introduced for design, but eh), you can write your CSS for mobiles in the mediaqueries-less part, and use respond.js or css3-media-queries.js, which gives IE6-7-8 all the mediaquery abilities.However, if your JS breaks, IE6-7-8 sees a mobile website, so it all depends on which importance you give to those browsers in your project. (for the sake of quality, i wouldn't do it personally)

but....

So, falling back is easy! But...

some css forone deviceFalling broken is very easy too!

some css foranother devicesome css forold browsers whodon't get CSS3

fixing and testing stuff here... what am i breaking there?

Falling broken is also very easy!Because you quickly realize that some mediaquerie-ed CSS code is going to override some other; so if you are modifying your green section here,which targets your green device, and that your blue section is overriding this green section, you might be breaking what your blue device sees without even knowing it.So, you're supposed to test on every targeted device at each iteration... Yeah, pretty annoying...

As a graphist, thinking Responsivewill ruin my creativity

MYTH #4

Myth #4

As a graphist, thinking Responsivewill ruin my creativity

MYTH #4

Brandon Baunach CC BY

Oh, come on, cry me a river here!We've been through this before: there's a new kid on the block, and you have to technically learn about it and its constraints. It might take you some time (i didn't say it would be easy), but i'm pretty sure you'll get there this one time again.And if you call yourself a webdesigner, but don't like when techniques change and improve, then maybe you should go back to print, where the technicality varies a lot less through time!(i'm not saying this in an offensive way! Oh wait, yeah, i am a little bit, you know... but i'm for sure not saying that print design is easier than webdesign)

A perfect Responsive Web Designmakes you want never to leaveyour smartphone

MYTH #5

Moving on from the whiny designers, myth #5!

A perfect Responsive Web Designmakes you want never to leaveyour smartphone

MYTH #5

Here, i strongly disagree!We're talking "perfect" responsive design here, so of course, sometimes, you'll go the wrong way for clients' constraints.

A perfect Responsive Web Designresponds perfectly to ALL devices

But i told you mediaqueries were about every kinds of devices... And i told you we could do fluid...So, ideally, if you have enough money to make the best responsive site possible, you should think about this, and make it ideally fluid for any device size.(for my blog, and most clients' websites, we usually do centered fixed-width for screens, and fluid from the tablet size downwards)

So, why do we say "Mobile first"?

So, if you need to keep every size in mind, and not only about mobile, why do people say to think about mobile first?

So, why do we say "Mobile first"?

Minimalist as a user experiencedesign constraint is good

Market share is already massive,will get even better!

Simply because, pragmatically, you will learn by experience that trying to keep a design constrained through its simplicity is very, very constructive. It has happened to me before that a client seeing his mobile (separated) webapp liked it so much, that they decided to remake their desktop webapp from scratch using the ergonomic ideas we had on the mobile one!Another reason: market share! For now, you may still have more desktop visits than mobile visits on your site; however, it is pretty clear now that this will not last too long. So if your website will have more than six months to live, when you think mobile first, you basically think about your future users!

A good Responsive designerwho doesn't know HTMLflow is not that good

MYTH #6

Last but not least...

A good fixed-width designerwho doesn't know HTMLflow is not that good...

Actually, this one's interesting: it has been debated a thousand times that webdesigners (fixed with, that is) should code a little bit, to understand how the HTML flow goes.I'm definitely an advocate of that. I think it is possible to design without it, but you're missing enough information to let yourself make technical mistakes once in a while.However, in the responsive case...

A good fixed-width designerwho doesn't know HTMLflow is not that good...

a Responsive designerwho doesn't know HTMLflow is

USELESS!

NO WAY!The technical constraints have never been so tight, and there are far less things you can technically do, than your imagination allows. So if you are a webdesigner, and you want to go responsive, i'm afraid there's going to be stuff you need to learn first...

Methodology ideas, for projects supposedly too big for responsive

SOME WAYS

Alright, now that we all have a decent understanding of what Responsive Web Design truly is for real, we should become even more practical, and discuss how things might go in an actual, proper responsive project.

Specifications

Storyboarding / Prototyping / Wireframing

Graphism / Art direction

Front-end development

Back-end development

Forgetting a few extra steps that are sometimes needed, this is how your average fixed-size project goes. What we've found, is that every step takes at least a little bit extra complexity: since the specifications will include extra info about what should or should not be directly accessible in the mobile version, the back-end should support several image sizes for the same image, etc.

Specifications





HUHG!!

But we also found that where most of the extra effort (and thus extra cost) will be noticed, is in these two steps. Prototyping a page that never looks the same is going to require a lot of time, and making and testing the responsiveness on the front-end developments as well.

Specifications





And mostly here, because we don't have tools.

But as i previously said, even though the front-end development is going to take a lot of time, it won't be technically amazingly complex (mediaqueries are a pretty simple tool to approach)In prototyping, however, there is no special tool out there that is especially adapted to Responsive Web Design yet. So not only will we have to spend some effort, but we're going to have to be creative finding solutions.

What do we know?

We're dealing with something that "moves" depending on a context

We know how to prototype for one size

There are only so many technical ways to "extend" or "reduce" elements

Non-useless "responsive" designers can be hard to find

Let's first take a step back, and look at what we know (as of, which things we know how to do, and which problems we'll know we'll have)Here are two first things...

Dealing with something that movesdepending on context?

It's all about the key-frames!(and what's in between)

"Something that moves depending on a context"? I don't know if this rings a bell to you, but it sounds to me like animation (Flash, or movies, or others...), except animation moves depending on time, and we are going to move depending on browser width.And any animator would tell you: all the staging is in deciding on the keyframes, and on how stuff happens in between keyframes.


It's all about the key-frames!(and what's in between)

So we'll do the same: we'll define keyframes (which happen at some pre-decided browser widths), and we'll focuse on those, and on how stuff happens in between.


For each template

Prototype 1

Prototype 2

Prototype 3

Remember, we know how to prototype for one size!

This will take a loooooot of time and effort, because it means that for each template, you will have to do each keyframe.Say you have 15 templates (we're talking massive websites that can't be done without wireframing, eh), and you set you mind on 3 keyframes (which is basically a decent minimum), it means you will have at least 45 prototypes to make.Even though we made the design process amazingly more complex, each part of it still remains simple, as we have decent tools today to prototype websites for each size.

Extra question: when is the designsupposed to break down?

Prototype 1

Prototype 2

Prototype 3

This immediately raises a question though: how should i decide on my keyframes?

Two approaches

Two approaches...

You know your content: content-driven

Prototype 1

Prototype 2

Prototype 3

Quite long title

Right colRight colRight colRight colRight colRight colRight colRight colRight col

Content content content content content content content content content content content content content content content content content content content content content content

Quite long title

Content content content content content content content content content content content content content content


Quite longtitle

Only works if you know your content really well,and if it doesn't vary too much accross the site or in time...

Content content content content content content content content content content content content content content content content

If you know your content really, really well, you can try to see by yourself where it makes sense to have it break down...That's what i did with my blog, because i know basically about what lengths my posts may be, and i have two or three very simple (and similar to each other) templates.However, if your site is complex, this won't work too well; first because you rarely know your content too well at the beginning of a project; and also, even if you do, out of 15 templates, i guess your content on your homepage will not happen to break down the best on the same size as the content of the category, or the content of the article, or the content of the 404 page, or the content of the internal search results, etc...

You don't know your content well:market-driven

Prototype 1

Prototype 2

Prototype 3

1024 screen

iPad(portrait)

iPhone(portrait)

Another approach: rather than selecting those sizes randomly, you can allow yourself to be a little twisted, and look at what users use the most in real life.That way, you have a website that has a very, very perfectly-under-control design in the iPad or iPhone in portrait mode, and has a under-ok-control design on every other devices.Of course, the iPhone will certainly die someday (and if they keep running on patent lawsuits, maybe sooner than later! Ah damn, i promised myself i wouldn't troll today!), so picking those devices might not be accurate on the long term.

You don't know your content well:market-driven

Prototype 1

Prototype 2

Prototype 3

1024 screen

iPad(portrait)

iPhone(portrait)

So, what you can do, is have a look at your analytics if your website pre-existed (or on a similar website you or someone else might have), and check directly what resolutions your target users use for real at the time of design.It might (and certainly WILL) change from one year to another, but at least, rather than randomly picking sizes, you have the most decent starting point.

What do we know?





Now we have the keyframes figured out, we said it was also about what happens between the keyframes.And the good news is, what happens is usually pretty similar: you don't have many way to "fluidify" a usually static element.

Prototype 1

Prototype 2

Prototype 3

Quite long title



Quite long title



Quite longtitle

How to symbolize content adjustmentfrom a slide to its next slide?

Stretching?

Fixed size?

Or even rotating?

Cropping?


What you can do, is try to list them at the beginning of the prototyping (or edit the list while prototyping), and decide which transition you're applying on each element.How to signify which?

Prototype 1

Prototype 2

Prototype 3

Quite long title



Quite long title



Quite longtitle


How to symbolize content adjustmentfrom a slide to its next slide?

Cropping?

Stretching?

Fixed size?

Or even rotating?

Well, here's an idea: you can give each transition a color, and apply it on your wireframe! We don't give a damn about colors on wireframes, right? Well then, here's an idea to use them right.Two notes: first, notice that only the images are involved. Indeed, text is naturally fluid, so you don't have to express how it will "fluidify". And second: usually, past the width of the larger keyframe, we make it so the design remains fixed and centered (we don't want a text with 50 words per line!); this way, the colors on prototype 1 describe the transition between prototypes 1&2; the colors on prototype 2 describe the transition between 2&3; and those on prototype 3 describe the transitions when the design is smaller than the width of prototype 3. Easy!

What do we know?





One last rock in our shoe: i said designers who don't know the responsive constraints will be useless. But the problem is, "responsive designer" is not yet a popularly recognized expertise. You don't find job adverts yet for a "responsive designer" position! So, most likely, i guess you are in the same situation as we were when we started: you probably don't have yet a responsive designer in your crew.

ResponsiveDesigner?

=

Fixed-widthDesigner

+

Front-endDeveloper

So here's what we did, and which proved to work well: we coupled a regular fixed-width designer / prototype maker (who knows well how information is supposed to be architectured, who has a expert approach of how the ergonomy will be on the final product, etc) with a front-end developer who knows CSS and mediaqueries well (who can technically assess if what the designer is doing is ok, all the time).I'm not gonna lie, this costed us quite a lot of money at first, because two people are working for one. But eventually...

ResponsiveDesigner?

=

Fixed-widthDesigner

+

Front-endDeveloper

after being told a thousand times what is and isn't allowed to do, your fixed-width designer learns to make less mistakes, and your front-end developer proves less and less useful.And hopla! Your fixed-width designer just gained one level!I mean... he just became the responsive designer you were looking for in the first place... :)

Prototype 1

Prototype 2

Prototype 3

Quite long title



Quite long title



Quite longtitle


ResponsiveDesigner?

=

Fixed-widthDesigner

+

Front-endDeveloper

?

One last thing: your crew or your magical guy has now produced a good set of very numerous prototypes, what should you do with it?It sometimes happens that your front-end dev (or responsive designer) tells you the design might be a little crazy anyway, and he has significant doubts about the technical feasibility of the design.

Specifications





Layout front-end testing(just to check!)

A good solution would be to have the layout made, really quickly from scratch, by a front-end developer (just the layout, not more) to check that everything can actually be built.One upside: the front-end dev will spend less time on the highly tricky bits later during the front-end phase then, so it's not exactly time that is lost forever.

Well now... what did we learn here today?

SOME OUTCOME

Alright, before we say good bye, what did we learn here today?

Technically chill

Righto!We learnt that technically, applying mediaqueries to get responsive isn't so complicated, and Rich would agree with me!Note for those who weren't at Front Row 2011: Rich Quick (yep, real name) spoke the day before, and introduced the basics of Responsive Web Design on a shorter conference; his final thesis was exactly this: adapting your existing website to be responsive is really easy, because the technical new stuff is not hard to learn.

But design process
hard to industralize

CC-BY Hayden "H Dragon"

But as much as the development isn't so much more complicated, industrializing a design process is way trickier, as we previously saw.(saw... hehe...) ;)

But we are getting there,
little by little...

CC BY-NC-ND Victor Roblas

But the good thing is: the solutions and tools are being tweaked as we speak. It is a very interesting time, because people who get their hands dirty to it can definitely improve the design process and the tools, and share with the community.No one in the world has a final answer as of "how you should definitely design your responsive website"; so, you might be one of the next guys bringing up a new idea, that might be useful to every one else.

To be continuedin your projects...

Thanks for listening, folks!If you feel like there's something you should ask me,come talk to me, i'm a human being!

(also, i'm still hanging in Krakow tomorrow,so tweet me, and we'll hang out and speak about it!)

So good luck with all that! And don't forget to SHARE, because in a year or two of time, maybe the design process will stabilize a little bit (i think we're all waiting for a book stabilizing this), and you might be able to look at one or two pages of this book saying "hey, i'm the one who came up with this!"And this will make you rich, powerful, and immensely attractive towards all of the people you meet!(or not, but at least, it'll be pretty nice) :)

Good luck with your projects! And don't forget to come back to me with your findings, i'm VERY interested to hear!

Responsive Web Design - but for real!

Technology

Transcript of Responsive Web Design - but for real!