Responsive Web Design - but for real!

Editor's Notes

• #2: 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
• #3: So, the topic of the day is Responsive Web Design...
• #4: 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.
• #5: 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)
• #6: If i had to put a definition to a site in RWD, then it would be any website that cares about your display.
• #7: 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!
• #8: 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...
• #9: 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)
• #10: 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/
• #11: 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.
• #12: 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"!
• #13: 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.
• #14: So this is what you get. A happy buzzword league, which you can relocate precisely in your brains, now!
• #15: One question though: are you sure you got the difference between Responsive Web Design et Responsive Layouts?
• #16: 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)
• #17: But some of you may ask...
• #18: 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.
• #19: 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.
• #20: From now on, all along this talk, we'll speak about this!
• #21: By the way, didn't we forget one buzzword?
• #22: 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)
• #23: Actually, let's speak about it further, mediaqueries are worth a chapter of this talk!
• #24: To understand media-queries, what's best is to get back to the initial problem that ultimately created them.
• #25: Alright, client server HTTP every day stuff. Nothing new.
• #26: 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?
• #27: Basically, it's either the server deciding, or the clients.
• #28: 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.
• #29: 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?
• #30: Well, actually no, not pretty awesome.
• #31: 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)
• #32: 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!
• #33: 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!)
• #34: 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!
• #35: Actually, they weren't...
• #36: 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 ».
• #37: 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....)
• #38: … 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...
• #39: Plus, anyway, even if the User Agents were reliable, and more semantic, would you be sure to cover ALL of them easily?
• #40: And plus, all of those who have yet to exist?? So yeah, browser sniffing -> to the trash for now!
• #41: 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.
• #42: 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)
• #43: 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...
• #44: And when you look at the 13 keywords that are mentioned in the spec candidate release (latest version to date), you can see that...
• #45: … 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?
• #46: Yeah, no, not pretty simple graph...
• #47: 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.
• #48: 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.
• #49: One first myth that's heard out there...
• #50: 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.
• #51: 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.
• #52: 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?
• #53: 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.
• #54: 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.
• #55: Alright, myth 2! Bad for performance? People who say such things should be ashamed!
• #56: Although, yeah, they're mostly right, though...
• #57: 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!
• #58: 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 <link> 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.
• #59: 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!)
• #60: 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. ;)
• #61: 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...
• #62: 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)
• #63: 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...
• #64: 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.
• #65: Myth #3!
• #66: WROOOONG! I'm not saying it is going to make your IE6 optimizations easier; but it will not make them harder either.
• #67: 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)
• #68: So, falling back is easy! But...
• #69: 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...
• #70: Myth #4
• #71: 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)
• #72: Moving on from the whiny designers, myth #5!
• #73: Here, i strongly disagree! We're talking "perfect" responsive design here, so of course, sometimes, you'll go the wrong way for clients' constraints.
• #74: 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)
• #75: So, if you need to keep every size in mind, and not only about mobile, why do people say to think about mobile first?
• #76: 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!
• #77: Last but not least...
• #78: 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...
• #79: … 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...
• #80: 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.
• #81: 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.
• #82: 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.
• #83: 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.
• #84: 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...
• #85: "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.
• #86: 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.
• #87: 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.
• #88: This immediately raises a question though: how should i decide on my keyframes?
• #89: Two approaches...
• #90: 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...
• #91: 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.
• #92: 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.
• #93: 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.
• #94: 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?
• #95: 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!
• #96: 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.
• #97: 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...
• #98: … 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... :)
• #99: 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.
• #100: 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.
• #101: Alright, before we say good bye, what did we learn here today?
• #102: 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.
• #103: 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...) ;)
• #104: 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.
• #105: 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!