Hi there. I am ben lavender, and the title of my presentation is a completely un-witty ‘making an existing web site responsive’. It’s a true story. Don’t go overboard, but you can potentially learn something.
IBEBEJOPTBVSXFCTJUFCFGPSFJUXBTDPPM Monday, July 9, 12 So real quick, who am i? I’m bhuga. I’m bhuga on twitter, where you should follow me, because I only have like 300 followers, which means you’ll be a trendsetter. i’m going to have a million soon. i’m on github, natch. there’s a lot of fun stuff there. and i own it on the only three top-level domains that matter. you can’t have it there anymore, that’s mine. so don’t get any ideas. if you haven’t figured it out yet, it’s pronounced booga, not bee-hooga. as for my credentials, i had a dinosaur website before it was cool.
before barcamp. I started a design movement that’s about returning to the root of websites: it’s time to stop letting the *content* get in the way of the *dinosaurs*. But that’s not what I’m here to talk about today. In any event, if you think I need more credentials than that to tell you about how to make websites, I don’t think you’re far enough along yet.
anything like me, when you’re sitting happily in a field, waiting to club dinosaurs, you’re deeply distrustful of new ideas. so the first thing you do when you hear about responsive design is something like WHAT RESPONSIVE DESIGN, RAAAARRAARR but there’s good news for us distrustful cavemen! because responsive design is a great way to *continue* to be distrustful of that evil device of witchcraft, the mobile phone SDK.
css methodologies that can let you continue to put off learning about mobile-specific SDKs. since you clubbed them to death years ago, it’s a way to make a ‘good enough’ version of a lot of sites and let you skip the mobile portion, at least for a while. And it’s a pretty easy set of tools to add to your existing web-development toolbox. It tastes just like charred lizard, which is to say, pretty sweet.
css methodologies that can let you continue to put off learning about mobile-specific SDKs. since you clubbed them to death years ago, it’s a way to make a ‘good enough’ version of a lot of sites and let you skip the mobile portion, at least for a while. And it’s a pretty easy set of tools to add to your existing web-development toolbox. It tastes just like charred lizard, which is to say, pretty sweet.
css methodologies that can let you continue to put off learning about mobile-specific SDKs. since you clubbed them to death years ago, it’s a way to make a ‘good enough’ version of a lot of sites and let you skip the mobile portion, at least for a while. And it’s a pretty easy set of tools to add to your existing web-development toolbox. It tastes just like charred lizard, which is to say, pretty sweet.
July 9, 12 a bit more concretely, responsive design is the Development of web sites that work in whatever context your user want’s to use them in. That means they *respond* to the viewing context, with the current, modern crop being desktop, tablet, and mobile. eventually people will want to view your website on their wristwatch, and we’ll deal with that when we come to it. But no matter. for now, responsive design is *easy* to implement. its *well supported* by the browsers that matter, namely, tablets and phones. fixing up a site for this presentation took less than two days of work, and it became dramatically more relevant.
9, 12 To talk about this, we’ll need a demonstration website. and that is the hack dat website, new orleans’ premier programming competition. cleverly, this presentation is also the announcement that hack dat 2012 will be in october of this year.
9, 12 If you don’t know what hack dat is, it’s a programming competition we had last year that we’re running again. It was a ton of fun and we had a great turnout, and we’re going to try and make this year’s even bigger. You can win $1000 or $750 and it’s just a ton of fun, so check out the website when we’re done and then come have fun with us.
stuff. When i got to the hack dat website, designed by our beloved joe ellis. it looked like this, which is none too shabby. I was quite pleased with it, really, but what did it look like on a phone?
find out. it would have looked kind of like this. on every page. which is not very useful. The site is fixed into two columns within a standard 960px grid, and we can only ever see the menu column. We can respond to this context, and do better.
and (min-width: 960px) { 2 body { 3 width: 960px; 4 } 5 } Monday, July 9, 12 So how do we respond to this new, narrow context? Well, we use the one technology that lets us query the browser for context: CSS Media Queries. CSS Media queries, a simple example of which is here, are snippets of css that only apply if a given set of conditions are met. For example, this is our first rule to make this site work at a full desktop’s width. We know the site looks good at 960px and larger, as that is the size of our grid. So let’s make sure that rule applies at screen widths of greater than 960px. in this case, the word screen applies to the media type, so it could be screen, print, all, braile, that kind of thing. and min-width is, of course, the width of the context in pixels. that context, by the way, is the layout viewport, which we’ll explain better closer to the end. for now, we’re on the desktop, and it’s the size of our browser. so in this example, 960px is called a breakpoint: our site’s behavior changes at 960px.
2 body { property: value } 3 } 4 @media only all and (min-width: 321px) and (max-width: 767px) { 5 body { property: value } 6 } 7 @media only all and (min-width: 768px) { 8 body { property: value } 9 } Monday, July 9, 12 So the first question you might ask is, what should our breakpoint sizes be? For both new sites and existing sites, it seems to make sense to make CSS breakpoints at the pixel sizes of particular devices. Here’s one that has a view for an iphone, a view for a pre-retina ipad, and a view for everything bigger than that. You can find nice, long lists of valid media queries for devices all over the web. But this is wrong. this is bad, like not having dinosaurs at a birthday party.
2 body { property: value } 3 } 4 @media only all and (min-width: 321px) and (max-width: 767px) { 5 body { property: value } 6 } 7 @media only all and (min-width: 768px) { 8 body { property: value } 9 } #""% Monday, July 9, 12 So the first question you might ask is, what should our breakpoint sizes be? For both new sites and existing sites, it seems to make sense to make CSS breakpoints at the pixel sizes of particular devices. Here’s one that has a view for an iphone, a view for a pre-retina ipad, and a view for everything bigger than that. You can find nice, long lists of valid media queries for devices all over the web. But this is wrong. this is bad, like not having dinosaurs at a birthday party.
July 9, 12 so instead of setting up ‘a site for an ipad’ and ‘a site for an iphone’, set up sites that work on certain widths, defined by how your content naturally lays out. new kinds little boxes with voices from the sky seem to be released about as fast as we can hurl them at trilobytes, so aiming for particular pixel widths of a little box of witchcraft makes about as much sense as not burning them. you do need to worry about a minimum size of 320px, for the iphone 3g and older, and a maximum width of 960px or so, for desktops. other than that, let it flow. I found that the natural limits for breakpoints were image sizes and column widths. I’m going to break down the breakpoints for the hack dat website now. if you were going to design a site from scratch, you might think about these points more carefully ahead of time, but the point of this presentation is that this isn’t very hard to do to a site you have today.
can not worry about anything else. ta-da, we’re done. in the end my breakpoints were at 485 pixels, 797 pixels, 920 pixels, and 960. none of those are a meaningful device length.
not going to go into detail about every css rule we just used, because i barcamp presentations are supposed to be short. so let’s wave our hands away at all of that layout. but there’s a few guidelines i’d like to share. it’ll be a good example for us to see some more media queries, too.
background-color: black; 3 } 4 @media only all and (min-width: 485px) and (max-width: 797px) { 5 body { 6 background-color: white; 7 } 8 } 9 @media only all and (min-width: 768px) { 10 body { } 11 } Monday, July 9, 12 So here’s an example of something not to do. here we’ve got a rule to set a black background color, and we change it for certain widths but not for others. No! bad caveman!
background-color: black; 3 } 4 @media only all and (min-width: 485px) and (max-width: 797px) { 5 body { 6 background-color: white; 7 } 8 } 9 @media only all and (min-width: 768px) { 10 body { } 11 } #""% Monday, July 9, 12 So here’s an example of something not to do. here we’ve got a rule to set a black background color, and we change it for certain widths but not for others. No! bad caveman!
only all and (min-width: 485px) and (max-width: 797px) { 5 .column-left { 6 float: none; 7 } 8 } 9 @media only all and (min-width: 768px) { 10 .column-left { 11 float: left; 12 } 13 } Monday, July 9, 12 instead, do something like this. properties which are the same for any context go in the main css portion. properties which you set in *any* media query are *only* set in media queries. this can be hard to do on an existing website, and i haven’t done a perfect job on hack dat. but your life will be easier if you make it clear what properties are overridden and which aren’t.
3 } 4 @mixin two-column { 5 body { property: value; } 6 } 7 @mixin floating-menu { 8 #menu { property: value; } 9 } 10 @media only all and (min-width: 485px) and (max-width: 797px) { 11 @include single-column; 12 @include floating-menu; 13 } 14 @media only all and (min-width: 768px) { 15 @include two-column; 16 @include floating-menu; 17 } Monday, July 9, 12 if you use scss right, your changes between different versions of the site will be expressable as mixins, and it can be clear, when looking at your media queries, that the changes can be expressed as features. here, as a sample, we’ve got a floating menu feature that we’re reusing, and some feature of the site moves from one column to two columns. it’s just not worth doing this one without scss.
{ 3 content: "#{$size}px media query"; 4 font-weight: bold; 5 display: block; 6 text-align: center; 7 background: rgba(255,$yellow,0, 0.9); 8 position: absolute; 9 top: 0; 10 left: 0; 11 right: 0; 12 z-index: 99; 13 } 14 } /* @include notify('480',0); */ Monday, July 9, 12 another cool trick is to use a mixin like this here. this will put a nice little bar at the top of the page to tell you what size media query you’ve triggered. very useful and highly recommended. the $yellow variable lets you scale the hue, so you go from yellow to red, presumably in order.
last quick tip is that chrome is a fantastic dev tool for all of this, because it’s zoom feature does not just increase text size, like many browsers, but actually zooms. this is the same thing as if you pinch and move. use it, because you’ll find that if you have any fixed position elements--and you may, in a big desktop app--zoom works rather horribly on them.
understands how to render. there are two viewports whenever a browser is rendered: the layout viewport, and the user viewport. you never had to learn about this before, because on a desktop, they’re always the same: the width is the same as the width of the browser window. On a phone, this isn’t the case. The phone will render the site at 960px, that’s the darkened area, then, when you zoom in, show you what’s in the *user* viewport, here on the left. the result is that a mobile-unaware site*looks* right but you have to pan around to find your content. But not us, right? what’s our sweet new responsive site look like?
the reason is that most websites are not responsive, so we have to tell the browser that we’ve planned for their small size. we do that with a simple html extension that apple went ahead and did without telling anyone: the viewport meta tag.
12 normally this would be on one line, of course, but i wanted to zoom this in, because it’s important. what this tag does is specify the *layout viewport*. we instruct that the width is the special value of ‘device width’, and that the initial scale should be 1, that is, we should not do any pixel scaling so that we’re rendering 960px worth of site in 480. this tells the mobile browser that ‘this page looks good at your width. carry on’. after this, your site will look fine everywhere.
there are some final thoughts before i’m done here. the first is that responsive design is not a panacea. People often use sites very differently on different kinds of devices, and its doubtful that a responsive design will take that into account. a truly responsive site for a restaurant, for example, would be a menu, phone number, and map on a phone, and not much else. a browser version might have reservations, images of what the place looks like, a little blurb on the history of the chef, or whatever. changing how that extra information is laid out wont help folks on phones much--it needs to *not be there*. responsive design is a pretty easy thing to add to many sites, and i think it’s almost silly not to do it. but it’s the easy version, and you should still talk about requirements if you have tons of mobile traffic. the second is that one of the main benefits of responsive design is that you can optimize for slower connections, but that’s actually pretty hard to do. for example, on the smaller hackdat
bhuga
kwakeuijin
hirobe1999
lamodatech
onihusube
osakatechlab
envek
nrslib
tanakahisateru
maroon1st
kotamanegi
chiroruxx
mkmk884
jonyablonski
hatefulcrawdad
paigeccino
jacobian
rasmusluckow
denniskardys
lynnandtonic
keavy
tammyeverts
jcasabona
bryan
jmmastey
