Responsive Web Design – Advanced Lesson
learn.shayhowe.com
learn.shayhowe.com
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.)
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.
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.
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.
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]
[1] http://trentwalton.com/2013/01/07/flexible-foundations/
[2] http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...
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.
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.
First rule of producing good content:
1. Make sure people can read it.
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 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.
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.)
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.
If you would like to delve deeper into the subject then I would recommend checking out Brad Frost's articles. This is a great starting point http://bradfrost.github.com/this-is-responsive/resources.htm...
The beginners course was a great way to get the fundamentals straight in my head. Very well written and understandable.
Thanks Shay!
I know how things work, just sayin'...it's broken!
Responsive design has its place and the article describes that quite well. IMHO it shouldn't be applied to the article itself.
This actually made me laugh...
Hasn't everyone moved on to inline-block?
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.