As someone who's been asleep at the switch with regards to responsive design I get the sense that it's, well, hard. Has anyone written about the "responsive design vs forking the website for mobile" tradeoff? If I were to start hacking together a site today I would probably just create two or three completely different layouts and DRY things up as much as I could in code, instead of trying to get the stars to align and get my browser to render the same assets correctly in all browsers.
In other words, responsive design seems to bring under the fold a use case that does not exist: physically resizing a browser window from a desktop size to a mobile size and having a page render correctly as you do it. Its a nice trick, but unless you assume the same client is going to need to see the content "respond" to changes in window size, then it seems prudent to take that use case off the list and simplify the implementation around the real use case: a client with a pre-defined browser window size hits a page and renders it, full stop. (with some small flexibility since users on desktop browsers do resize their window by some % occasionally) (Ie, if you focus on this case, simplest solution may be to fork it at render time in code where you have to and keep the CSS/etc straightforward.)
I think you're slightly off with your conclusion of responsive web design. It doesn't aim to cater to people resizing their windows (that's just an added benefit), it aims to cater to all devices regardless of window size.
Assuming we're still considering responsive design, if designed from a mobile-first perspective you'd be surprised how clean the code can be to deal with this. Start with minimal resources and most of your content stacked vertically so that it's lightweight and easy to consume on a touch device. Providing you've used relative units (ems in particular) you can scale up for larger screen with super simple media queries that just bump the font-size on body (e.g. body { font-size: 120%; }). You can find an awesome overview of this approach on Trent Walton's site [1]. Compare this with a hacky approach of doing desktop-first - you're loading assets (probably) unnecessarily, hiding chunks of markup to never be displayed, hammering your CSS to fit your desktop peg into a mobile hole. I know this doesn't cover everything, and any sufficiently complex site will require more than just bumping font-size, but honestly it doesn't have to be super difficult and full of horrible workarounds.
Now with the resposnive vs. separate site debate, the way I've always thought of it is responsive site for web sites, separate sites for web apps. Apps are sufficiently complex, with enough interaction that they require fundamental changes in HTML, CSS and JS to adapt to touch devices. Which leads onto the next point, serve a separate version of a web app based on touch/non-touch not window size, as it is the interaction method that should dictate design choices not how small the window is. It might then be wise to adopt a hybrid approach for your touch-specific app, where you scale up/down for larger/smaller touch-based devices.
Note that some of this may change and become significantly simpler with the advent of the Shadow DOM [2] and Flexbox layouts [3]
Responsive web development is very hard. It's easy to get a firm grasp on it, but sometimes can be a struggle determining what happens to a footer or sidebar on a small screen. Another issue is scaling down a desktop site for a mobile site merely hides things, it doesn't reduce page load times or page weight. I think responsive can work well for some sites, but if you're hiding a lot of content for mobile users a mobile site is best. Mobile Safari will still load an image regardless of whether or not it's hidden, same with scripts and stylesheets you might not even be using on a mobile version of your site.
People often forget a 300kb image on a desktop site is fine, but making your site react to the width of a screen you're shrinking the image down but the file size remains the same. A 300kb image on a mobile site via a 3G connection times two or three can spell disaster for some people's data plans especially if they're close to going over.
Also a handy thing to remember with the target divided by the context is to multiply it by 100 to get the actual percentage value. I know you can simply move the decimal over two places, but that eliminates the step and ensures your calculations are always correct. So the final formula becomes: target / context * 100 = responsive percentage value.
I think it largely depends on the type of website you're running. For example, the kinds of websites I visit are relatively text heavy - I want to see the text regardless of which device I'm using. These websites are pretty light on images and few use any kind of 'novel' widgets or fancy animations. For these kinds of websites, I think responsive design is a pretty nice solution to the problem of different screen sizes. By and large, implementing a responsive design using the methods outlined in the OP is a nice solution which has the best trade-off between results and development time.
However, if you're running a photo-blog, then you probably want to only serve smaller images to mobile clients, and larger ones to desktop clients. Same goes for interactive websites. If your website has some novel navigation mechanism, or is very JS heavy, then you probably want to think more about whether you simply need to split your website into two separate versions: one for mobile, one for desktop.
I think a decent 'cut-off' point is when you start needing to muck about with handling viewport sizes through JS. At this point, it seems to me like your design isn't capable of handling the various screen sizes: if my mobile browser needs to run a bunch of javascript just to display correctly - by turning a menu bar into a drop-down menu for example, or modifying the page's navigation mechanisms - then in all honestly you might save yourself time and effort by simply creating a separate mobile version.
Obviously, there are exceptions to any rule, and I don't think there are any true clear boundaries, and even the 'JS boundary' can be managed nicely through progressive enhancement and dependency management.
Personally, I'm pretty happy with the 'one size fits all' solution. I don't think there's anything inherently wrong with media queries and simply modifying the CSS based on viewport size. It seems much more work to create and maintain separate versions of a website's theme for different viewport sizes.
I've always assumed the benefit is that you don't have to maintain a separate set of files for each window size... but it seems like, for all intents and purposes, you might as well be if you have to set up special cases for all sorts of window sizes, just in one document.
Yeah I guess what I mean is you should always aim for DRY but who says the code reuse has to happen on the client? Why not do at least some of the necessary changes based upon screen size upstream on the server if it reduces complexity? My guess is this is probably harder for designers than hacking on CSS. I don't buy the argument that it's more or less DRY depending on where the reuse occurs. The only argument is that there is some value in having the browser understand the layout more fundamentally, but the only use case this enables is the "resize to mobile size on my desktop computer" case, unless I'm missing something.
It's pretty DRY as you'll only be writing media queries for the parts of the site that need to change. Many times you don't have to write MQ's for everything. Writing completely different sites like you mentioned earlier would be/has been a hassle to maintain as opposed to a site that was originally designed as responsive from the onset.
The use case that someone might come to your site on a tablet, laptop and/or phone is a pretty common use case nowadays. Designing and maintaining one site to cover all of those is the goal. Simple MQ's to shift to each one is much easier to maintain than an entire other codebase.
One reason for choosing client over server: richness of data that can be queried. Media queries allow you to test for all sorts of features [1] which may be difficult impossible to test on server, e.g. color depth, pixel density etc.
Is there any point in having medium-grey text on a slightly lighter grey backgound, other than to make it very hard to read? http://contrastrebellion.com/
Its looks good in the eyes of a designer, but sucks for users. I can't read shit and made my eyes hurt (for real). I can't even comment on the content because I can't read it.
Thank you for sharing the Contrast Rebellion link. I will link to that from the updating version of the colophon of my personal website as I do personal website updates this year. I wish I could upvote that link more than once, as there are many websites posted in designs with too little contrast for reading.
And speaking of readability, there are still too many sites that break if a user resizes the browser font size (done with CTRL-+ or an analogous Apple command on most browsers), although that is not a problem with the site kindly submitted here to open this thread.
Thank you for bringing up the font scaling issues.. I do about 2/3 of my casual reading on the TV, from the couch (HTPC), and usually have to scale to 125% for readability.. I hate when the font is already too small AND doesn't scale properly.
A point made in the article is important to me as well... there are times when zooming on my phone is important too, and sites/apps that disable this ability make it painful.. I tend to make the initial size device with, and limit scaling to 1-2x, which is generally enough. I wish that more people paid attention to scaling, especially given higher pixel displays on the horizon, and already in mobile devices.
Older browsers used to just resize the font inline, and leave other elements alone, but most modern browsers resize everything these days when you use those commands, so sites shouldn't look any different when scaled up or down. It's been this way for a long time, it seems.
I don't have the best vision, and I thought it was fine. I don't know whether it was the slight background texture, or that the colours were different enough, or whether the designer changed it after this feedback - but I didn't find it too difficult.
It's easy on my eyes on my monitors. And it's #555 on #fafbfc, hardly "slightly lighter". For that font size/weight I would have gone #333/444 but it's pretty close.
I've only ever done responsive via JavaScript, as I often need to target as many old and new browsers as possible. It seems like my method is way easier and faster than this "new" fancy CSS way. Does anyone have any experiences with both approaches, and if yes, which do you prefer?
For those wondering: My method is pretty simple - I use a global ratio which is multiplied with width/heights, and a resize() function, which is called when the page is loaded and resized.
Edit: Long timer HN lurker, registered to post this. Also forgot to say I enjoyed the article, thanks!
The biggest reason I like using pure CSS for this is because it separates the display code and functionality code more clearly. Granted, you can and should be doing that with your JS anyway, but the boundaries are clearer if you keep it to CSS and you're less inclined to take shortcuts and start writing complex or hard-to-understand JS.
I tend to use CSS for the bulk of layout. Lately leaning on say Twitter Bootstrap as a base... and using JS for some tweening, or other points. I also use Modernizr, and other JS to enhance classes in the HTML element for CSS use. I find this works pretty well... I can keep my rules in CSS, but can enhance them via JS. My enhancers are the only script I put into the HEAD (before the CSS), all other scripts are just before the closing BODY element with ads and analytics last of the scripts. I do think that having a good base CSS knowledge is important.
The exception to this, would be a full-screen site/application where you are using the full field of view for an interactive display, or simulation. Then JS leaning and even canvas are more important for interaction.
As usual, nothing on cross-browser compatibility (respond.js, modernizr...), nothing on speed optimisation (a real problem in RWD), on backends issues (regarding the multiples images needed), etc...
It often strikes me, reading these tutorials about RWD, than the authors know all very well the theory but have never done a real (ie for a client) responsive website in their life.
It's all generic and general stuff, never how a stupid menu can be a real bother when you have to support two different states, touch and mouse, users without javascript, changing states, IE9 with no CSS3 transition support, etc.
Tutorials show you the easy way, the way which works only for cable users with a fancy Macbook and the last Safari or 4G iPhone users.
In real RWD, what should be easy becomes hard, and nobody'll tell you that.
(btw, i'm not a RWD hater. I just want to warn about its realities.)
>As usual, nothing on cross-browser compatibility (respond.js, modernizr...), nothing on speed optimisation (a real problem in RWD), on backends issues (regarding the multiples images needed), etc...
Well these could all be articles in themselves really. I think this highlights the fact that RWD isn't simply a case of just shrinking your 'full' website down to mobile phone size. It is a rather broad subject and not really one that can summarised quickly in a single article.
I spent a couple of nights last week reading the beginners course. I've put together a couple of simple websites already, but always using a "copy-paste-hack it about until it works" methodoly.
The beginners course was a great way to get the fundamentals straight in my head. Very well written and understandable.
No mention of calc with hard definitions as a fallback? Besides Opera, it's fully adopted on desktop browsers (including IE), Firefox for Android and soon on BlackBerry.
This just makes one realize how broken the standards really are. All these things should, to some extent, be taken care off without the developer needing to apply it.
I know how things work, just sayin'...it's broken!
I'm not sure what it is you mean by "all these things". However, if you read the standards, you'd understand why they behave very conservatively with respect to adding more stuff in there.
I was about to comment on the same thing, but actually I think it will look good on a tablet and I guess a smartphone is not the best device to read web design tutorials.
I think most pages are interested in getting a reasonable view in mobile. From my experience the cheapest and best way is to use media queries and say for everything with a viewport less than 700px, let the divs get a 100% in width. Add that to you base.css and it should already be 100x better for your customers/users.
This is a really good and succinct overview. I'm definitely saving this article both for self-reference and for showing other people who don't grasp responsive design. Thanks for writing this!
This is good stuff. Would be great if it went right in and also talked about limitations like fewer ports-per-connection, poor standards support e.g. stuff like unsupported position:fixed property, dead file-input field, terrible response times for tap/long-tap etc.
I mean responsive layout for presentation of content (blog/BS) is fairly easy. For an interactive web-app however, design logic goes quite in the opposite direction. To this end I found http://html5rocks.com a very useful resource.
Looking at current number of devices and independent implementations of browsers having different levels of support for web standards, (even on iDevices!) I feel that we are sort of back to 1995.
In other words, responsive design seems to bring under the fold a use case that does not exist: physically resizing a browser window from a desktop size to a mobile size and having a page render correctly as you do it. Its a nice trick, but unless you assume the same client is going to need to see the content "respond" to changes in window size, then it seems prudent to take that use case off the list and simplify the implementation around the real use case: a client with a pre-defined browser window size hits a page and renders it, full stop. (with some small flexibility since users on desktop browsers do resize their window by some % occasionally) (Ie, if you focus on this case, simplest solution may be to fork it at render time in code where you have to and keep the CSS/etc straightforward.)