• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Responsive Web Design - but for real!
 

Responsive Web Design - but for real!

on

  • 14,532 views

Responsive is the new buzzword! ...

Responsive is the new buzzword!
The main idea here is to:
* kill the buzzword, and replace it with some accurate truth
* and talk about the very difficult industrialization of the wireframing process, and some ideas for solutions to it (experimental part!)

Statistics

Views

Total Views
14,532
Views on SlideShare
7,294
Embed Views
7,238

Actions

Likes
26
Downloads
180
Comments
0

31 Embeds 7,238

http://graphism.fr 5610
http://rudyonweb.net 490
http://www.uzful.fr 455
http://www.conseilsmarketing.fr 230
http://www.ig.gmodules.com 64
http://paper.li 56
http://www.scoop.it 51
http://sharingroom.spade.be 49
http://storify.com 47
http://www.conseilsmarketing.com 36
http://veillete.blogspot.com 36
http://feeds.feedburner.com 30
http://blog.uzful.fr 17
http://prisma-labs.intranet.prisma-presse.com 11
http://voyelle.tumblr.com 9
https://twitter.com 7
http://veillete.blogspot.fr 6
http://us-w1.rockmelt.com 6
https://twimg0-a.akamaihd.net 5
http://lanyrd.com 4
http://a0.twimg.com 4
http://doku.oeamtc.at 3
http://www.twylah.com 2
http://tweetedtimes.com 2
http://safe.tumblr.com 2
https://si0.twimg.com 1
http://translate.googleusercontent.com 1
http://www.newsblur.com 1
http://twiddle.heyhey.fr 1
http://www.blagactu.com 1
http://127.0.0.1 1
More...

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • So, this talk was given in Krakow, Poland, on Oct 21 st 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
  • So, the topic of the day is Responsive Web Design...
  • 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.
  • 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)
  • 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 is very often confused with Responsive, and there's a good reason for that: RWD is AWD! But reverse isn't true...
  • 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)
  • 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/
  • 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 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"!
  • 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?
  • 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)
  • But some of you may ask...
  • 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.
  • 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, all along this talk, we'll speak about this!
  • By the way, didn't we forget one buzzword?
  • 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)
  • Actually, let's speak about it further, mediaqueries are worth a chapter of this talk!
  • To understand media-queries, what's best is to get back to the initial problem that ultimately created them.
  • Alright, client server HTTP every day stuff. Nothing new.
  • 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?
  • Basically, it's either the server deciding, or the clients.
  • 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.
  • 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?
  • Well, actually no, not pretty awesome.
  • 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)
  • 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!
  • 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!)
  • So, when Opera release its final 10 th 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!
  • Actually, they weren't...
  • 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 ».
  • 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....)
  • … 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...
  • Plus, anyway, even if the User Agents were reliable, and more semantic, would you be sure to cover ALL of them easily?
  • And plus, all of those who have yet to exist?? So yeah, browser sniffing -> to the trash for now!
  • 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.
  • 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)
  • 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...
  • And when you look at the 13 keywords that are mentioned in the spec candidate release (latest version to date), you can see that...
  • … 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?
  • 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.
  • 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.
  • One first myth that's heard out there...
  • 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.
  • 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.
  • 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?
  • 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.
  • 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.
  • Alright, myth 2! Bad for performance? People who say such things should be ashamed!
  • Although, yeah, they're mostly right, though...
  • 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!
  • 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.
  • 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!)
  • 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. ;)
  • 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...
  • 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)
  • 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...
  • 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.
  • Myth #3!
  • WROOOONG! I'm not saying it is going to make your IE6 optimizations easier; but it will not make them harder either.
  • 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)
  • So, falling back is easy! But...
  • 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...
  • Myth #4
  • 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)
  • Moving on from the whiny designers, 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.
  • 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, if you need to keep every size in mind, and not only about mobile, why do people say to think about mobile first?
  • 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!
  • Last but not least...
  • 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...
  • … 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...
  • 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.
  • 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.
  • 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.
  • 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.
  • 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...
  • "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.
  • 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.
  • 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.
  • This immediately raises a question though: how should i decide on my keyframes?
  • Two approaches...
  • 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...
  • 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.
  • 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.
  • 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.
  • 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?
  • 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!
  • 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.
  • 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...
  • … 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... :)
  • 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.
  • 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.
  • Alright, before we say good bye, what did we learn here today?
  • 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 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 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.
  • 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! Responsive Web Design - but for real! Presentation Transcript

  • CSS3 Media Queries (and Responsive Web Design) but for real! The truth, the lies, and the legend! Rudy Rigot [email_address] @rudyrigot http://rudyonweb.net Clever Age
  • Responsive Web Design
  • Adaptive Web Design? Responsive Layouts? Mediaqueries? Fluid grid? Responsive Web Design That's my word!
  • "Whatever is well conceived is clearly said" - Nicolas Boileau SOME TRUTH
  • Responsive Web Design "i'm a webpage, and i care about your display!"
  • ? Responsive Web Design "i'm a webpage, and i care about your display!"
  • Responsive Web Design "i'm a webpage, and i care about your display!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • See: Progressive Enhancement client 1 client 2 Responsive Web Design "i'm a webpage, and i care about your display!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • http://www.londonandpartners.com Responsive Web Design "i'm a webpage, and i care about your display!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • http://www.prevention-medicale.org Responsive Web Design "i'm a webpage, and i care about your display!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Responsive Web Design "i'm a webpage, and i care about your display!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • ? Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • http://w3qualite.net Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are" Wait! I read something, and i thought Responsive Web Design was this thing!
  • Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Yep, it used to be, and now it's blurry! Adaptive Web Design "i'm a webpage, and i care about whoever you are" Wait! I read something, and i thought Responsive Web Design was this thing!
  • Used to be the one called Responsive Web Design between May 2010 and July 2011!! Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • From now on, let's speak about this! Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Wait! How about the mediaqueries ?
  • Mediaqueries = technical tool Responsive Web Design "i'm a webpage, and i care about your display!" Responsive Layouts "how large may i be again ? Wait here as i rearrange my blocks!" Fluid Grid "how large may i be again? Wait here as i stretch my columns!" Adaptive Web Design "i'm a webpage, and i care about whoever you are"
  • Let's get some hands dirty a little SOME TECH
  • Why mediaqueries?
  • The problem Server Client Webpage (html, css, js, and all that stuff)
  • The problem Server Client Webpage (html, css, js, and all that stuff) Monochrome, tiny e-book Same webpage (same css& js ?)
  • Two solutions!
  • Solution 1: the serves sends different files Server Client Monochrome, tiny e-book Wait! How the hell do i know who i'm talking to?
  • Solution 1: the serves sends different files Server Client Monochrome, tiny e-book HTTP headers (User-Agent) HTTP headers (User-Agent)
  • Solution 1: the serves sends different files Server Client Monochrome, tiny e-book HTTP headers (User-Agent) HTTP headers (User-Agent)
  • Browser sniffing is NOT an ideal solution!
  • 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! Browser sniffing is NOT an ideal solution!
  • 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! Browser sniffing is NOT an ideal solution! http://www.allocine.fr
  • 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 Yeay, fixed! Opera 10 Opera/9.8 (Windows NT 6.0; U; en) Presto/2.2.0 Browser sniffing is NOT an ideal solution!
  • 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 Yeay, fixed! Opera 10 Opera/9.8 (Windows NT 6.0; U; en) Presto/2.2.0 Browser sniffing is NOT an ideal solution! But...
  • 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 Oops? Opera 10 Opera/9.8 (Windows NT 6.0; U; en) Presto/2.2.0 Browser sniffing is NOT an ideal solution!
  • 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 Oops? Opera 10 Opera/9.8 (Windows NT 6.0; U; en) Presto/2.2.0 Browser sniffing is NOT an ideal solution! http://www.state.gov
  • 1- User Agent parsing is error-prone 2- Browsers are liars! IE8: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0 (...) Wait, what?! Browser sniffing is NOT an ideal solution!
  • 1- User Agent parsing is error-prone 2- Browsers are liars! 3- You're sure you know ALL the browsers? Browser sniffing is NOT an ideal solution!
  • 1- User Agent parsing is error-prone 2- Browsers are liars! 3- You're sure you know ALL the browsers ? 4- And you're sure you know ALL the browsers... from the future?! Browser sniffing is NOT an ideal solution!
  • Solution 2: the serves sends everything, the client decides what to use Server Client Monochrome, tiny e-book
  • But how? some other usual css stuff... some usual css stuff... If you're a regular 1024x768 multi-color display, then... If you're a tiny and monochrome E-book, then...
  • But how? CSS3 mediaqueries! @media screen { } @media handheld and (min-monochrome: 1) { } some other usual css stuff... some usual css stuff... If you're a regular 1024x768 multi-color display, then... If you're a tiny and monochrome E-book, then...
  • So... mediaqueries are not only about mobile! monochrome grid scan resolution orientation color-index color device-aspect-ratio aspect-ratio device-height device-width height width
  • So... mediaqueries are not only about mobile! particularly useful for e-books! particularly useful for TVs! particularly useful for resizable windows! particularly useful for mobiles! monochrome grid scan resolution orientation color-index color device-aspect-ratio aspect-ratio device-height device-width height width
  • So... mediaqueries are not only about mobile! particularly useful for e-books! particularly useful for TVs! particularly useful for resizable windows! particularly useful for mobiles! CC BY – Yusuke Kawasaki monochrome grid scan resolution orientation color-index color device-aspect-ratio aspect-ratio device-height device-width height width
  • So... mediaqueries are not only about mobile! particularly useful for e-books! particularly useful for TVs! particularly useful for resizable windows! particularly useful for mobiles! monochrome grid scan resolution orientation color-index color device-aspect-ratio aspect-ratio device-height device-width height width
  • Truth and lies, you said? SOME MYTHS
  • Every website should be responsive MYTH #1
  • Every website should be responsive MYTH #1
  • Could be one page Could be another page Could be another other page http://www.facebook.com
  • Could be one page Could be another page Could be another other page http://www.facebook.com
  • Browser sniffing...
  • Browser sniffing...
  • Responsive Web Design is awful for front-end performance MYTH #2
  • Responsive Web Design is awful for front-end performance MYTH #2
  • Truth because... USELESS ! some css for another device some css for one device
  • Truth because... USELESS ! … but there may be solutions? <link rel=&quot;stylesheet&quot; type=&quot;text/css&quot; media=&quot; min-width : 600px &quot; href=&quot;styles-600.css&quot; /> some css for another device some css for one device
  • Truth because... USELESS ! … but there may be solutions? <link rel=&quot;stylesheet&quot; type=&quot;text/css&quot; media=&quot; min-width : 600px &quot; href=&quot;styles-600.css&quot; /> Ouch, browsers download them all anyway ! (for now...) some css for another device some css for one device
  • Truth because for some browsers... USELESS ! some css for another device some css for one device png jpg jpg png jpg png
  • Truth because for some browsers... USELESS ! … but this is being fixed! some css for another device some css for one device png jpg jpg png jpg png
  • Truth because for all browsers... <img class=&quot;hide_me&quot; src=&quot;image.png&quot; /> USELESS ! img.hide_me { display: none; } img.hide_me { display: inline; } png
  • Truth because for all browsers... <img class=&quot;hide_me&quot; src=&quot;image.png&quot; /> USELESS ! … but there are solutions to come !! css rule &quot;content&quot; media query listener dedicated javascript img.hide_me { display: none; } img.hide_me { display: inline; } png Meh... Meh... Meh...
  • Responsive Web Design is awful for front-end performance True, not great, but will get better! MYTH #2
  • My Responsive Web Design is going to look like crap on IE6... MYTH #3
  • My Responsive Web Design is going to look like crap on IE6... MYTH #3
  • Falling back is easy some css for old browsers who don't get CSS3 Mobile first? respond.js! some css for another device some css for one device
  • … but....
  • Falling broken is very easy too! some css for old browsers who don't get CSS3 fixing and testing stuff here... … what am i breaking there? some css for one device some css for another device
  • As a graphist, thinking Responsive will ruin my creativity MYTH #4
  • As a graphist, thinking Responsive will ruin my creativity MYTH #4 Brandon Baunach CC BY
  • A perfect Responsive Web Design makes you want never to leave your smartphone MYTH #5
  • A perfect Responsive Web Design makes you want never to leave your smartphone MYTH #5
  • A perfect Responsive Web Design responds perfectly to ALL devices
  • So, why do we say &quot;Mobile first&quot;?
  • So, why do we say &quot;Mobile first&quot;? Minimalist as a user experience design constraint is good Market share is already massive, will get even better!
  • A good Responsive designer who doesn't know HTML flow is not that good MYTH #6
  • A good fixed-width designer who doesn't know HTML flow is not that good...
  • A good fixed-width designer who doesn't know HTML flow is not that good... … a Responsive designer who doesn't know HTML flow is USELESS!
  • Methodology ideas, for projects supposedly too big for responsive SOME WAYS
  • Specifications Storyboarding / Prototyping / Wireframing Graphism / Art direction Front-end development Back-end development
  • Specifications Storyboarding / Prototyping / Wireframing Graphism / Art direction Front-end development Back-end development HUHG!!
  • Specifications Storyboarding / Prototyping / Wireframing Graphism / Art direction Front-end development Back-end development And mostly here, because we don't have tools.
  • What do we know?
    • We're dealing with something that &quot;moves&quot; depending on a context
    • We know how to prototype for one size
    • There are only so many technical ways to &quot;extend&quot; or &quot;reduce&quot; elements
    • Non-useless &quot;responsive&quot; designers can be hard to find
  • Dealing with something that moves depending on context? It's all about the key-frames ! (and what's in between)
  • Dealing with something that moves depending on context? It's all about the key-frames ! (and what's in between)
  • Dealing with something that moves depending on context? For each template Prototype 1 Prototype 2 Prototype 3 Remember, we know how to prototype for one size!
  • Extra question: when is the design supposed to break down? Prototype 1 Prototype 2 Prototype 3
  • Two approaches
  • You know your content : content-driven Prototype 1 Prototype 2 Prototype 3 Quite long title Right col Right col Right col Right col Right col Right col Right col Right col Right 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 Right col Right col Right col Right col Right col Right col Right col Right col Right col Quite long title 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
  • You don't know your content well: market-driven Prototype 1 Prototype 2 Prototype 3 1024 screen iPad (portrait) iPhone (portrait)
  • You don't know your content well: market-driven Prototype 1 Prototype 2 Prototype 3 1024 screen iPad (portrait) iPhone (portrait)
  • What do we know?
    • We're dealing with something that &quot;moves&quot; depending on a context
    • We know how to prototype for one size
    • There are only so many technical ways to &quot;extend&quot; or &quot;reduce&quot; elements
    • Non-useless &quot;responsive&quot; designers can be hard to find
  • Prototype 1 Prototype 2 Prototype 3 Quite long title Right col Right col Right col Right col Right col Right col Right col Right col Right 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 Right col Right col Right col Right col Right col Right col Right col Right col Right col Quite long title How to symbolize content adjustment from a slide to its next slide? Stretching? Fixed size? Or even rotating? Cropping? Content content content content content content content content content content content content content content content content
  • Prototype 1 Prototype 2 Prototype 3 Quite long title Right col Right col Right col Right col Right col Right col Right col Right col Right 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 Right col Right col Right col Right col Right col Right col Right col Right col Right col Quite long title Content content content content content content content content content content content content content content content content How to symbolize content adjustment from a slide to its next slide? Cropping? Stretching? Fixed size? Or even rotating?
  • What do we know?
    • We're dealing with something that &quot;moves&quot; depending on a context
    • We know how to prototype for one size
    • There are only so many technical ways to &quot;extend&quot; or &quot;reduce&quot; elements
    • Non-useless &quot;responsive&quot; designers can be hard to find
  • Responsive Designer? = Fixed-width Designer + Front-end Developer
  • Responsive Designer? = Fixed-width Designer + Front-end Developer
  • Prototype 1 Prototype 2 Prototype 3 Quite long title Right col Right col Right col Right col Right col Right col Right col Right col Right 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 Right col Right col Right col Right col Right col Right col Right col Right col Right col Quite long title Content content content content content content content content content content content content content content content content Responsive Designer? = Fixed-width Designer + Front-end Developer ?
  • Specifications Storyboarding / Prototyping / Wireframing Graphism / Art direction Front-end development Back-end development Layout front-end testing (just to check!)
  • Well now... what did we learn here today? SOME OUTCOME
  • Technically chill Righto!
  • But design process hard to industralize CC-BY Hayden &quot;H Dragon&quot;
  • But we are getting there, little by little... CC BY-NC-ND Victor Roblas
  • To be continued in 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!)