1 Posted by Joe McCann on 9 September 2011 | Permalink

"The purpose of JavaScript is to add a usability layer to a web page."

For web documents, I agree. For web apps, I'd say it's a requirement. Responsive design, for purposes of this discussion, should consider a web document vs a web application and design accordingly, IMO.

2 Posted by Terence Eden on 9 September 2011 | Permalink

I take issue with (3).

I resize the images on the server based on the browser's UA.

I use http://docs.sencha.com/io/src/ - but there are plenty of other server side image resizing libraries.

So, essentially, your point (2) should be "Only send to the device what it can use."

You can still use the same HTML, JS & CSS - but large media (including those in video and audio tags) should be optimised for the device requesting them.

Those are my thoughts on the matter.

3 Posted by Trygve Lie on 9 September 2011 | Permalink

Regarding images:

Opera, both on desktop and mobile, has a interesting approach to loading image / object resources. Opera does not download resources which are not displayed. Iow; one can inject four image tags in a document with the same image in different sizes and just use CSS to show / hide the image suitable for the adapted style. In a responsive design only the one image fitting the appended style will be downloaded. The rest will not be downloaded in Opera.

Some argue it creates a flicker effect in some cases but I find it a very slick approach to append responsive images. There is no need for JavaScript in such an approach.

Tough; no other browser than Opera has that approach. I would like to see other browsers follow the same approach.

The same goes for fallbacks ex in a object tag: http://www.trygve-lie.com/blog/entry/svg_embed_and_performance

4 Posted by Alexander Trefz on 9 September 2011 | Permalink

I think, and i know this will be very controversial, that JS _should_ be considered for way more then adding a usability layer. When i only send data over the wire and let JS construct the page (optimal without a "template" that needs to be interpreted, but rather with a proper View-Class that does the HTML generating fast and only 1 time) you can save many bytes - especially if you have an "application" that needs content-updates or other ajaxy stuff relatively often. I am using this approach at my company atm for a widget and it works pretty well and fast. of course this brings other problems with it (i.e. SEO) but all of those problems are solvable. This approach has a whatever-first included since you probably send an HTML page for SEO with a little loader for the app in it. This allows to load something completely different for mobile or desktop or tablet. Since you send an plain HTML-page with a loader you are also serving the poor 2 and 1/2 people without JS.

5 Posted by Andrei Eftimie on 9 September 2011 | Permalink

There are already initiatives going in this direction. The most known one is probably Andy Clarke's 320 and Up: http://stuffandnonsense.co.uk/projects/320andup/

We will only see projects adopt this behaviour once thier traffic comes mostly from mobile devices.

It would be interesting to see *when* it would be more costly to have a desktop-default then a mobile-default. The cost of the problem vs the cost of the solution.

If this will happen soon enough, we will surely see a mental switch (and developers will build for mobile first).

But if the technology advances more rapidly, we might find ourselves not caring of bandwidth as much (as we are doing now for the desktop experience). If this happens first, the switch might never happen.

Interesting to see how this plays out.

6 Posted by Marko Samastur on 9 September 2011 | Permalink

Why should we need Javascript to determine if client is desktop or mobile?

I know this is a current limitation, but it's hardly one that has to be in the future as well (especially since guessing from Javascript is really awfully error-prone).

How much of needless assets need to be downloaded (and in which form) depends heavily on a website. If images are not content and can be moved to CSS, then there really is no reason why you couldn't load smaller images on phones and bigger on desktops (media queries).

It definitely sucks when images ARE content and I hope we get a better solution for that.

I won't be surprised if mobile-first will be future way of doing it, but neither will I be if it won't. Personally I expect it will depend on website and that mobile first might be slightly more common, but I also suck at making such guesses.

7 Posted by Peter Gasston on 9 September 2011 | Permalink

"Right now responsive design is graceful degradation: design something for desktop and tablet, and remove stuff for mobile." - Not always; for the site of http://pokelondon.com I used a mobile-first approach. Certainly not perfectly, and there are still many pitfalls to this approach (images being not the least of them). I wrote about this on my own blog: http://www.broken-links.com/2011/02/21/using-media-queries-in-the-real-world. Of course, having had the experience of making the site, I would certainly do some things differently the next time.

"Are we OK with serving noscript desktop users what is essentially the mobile version of our site, small images and all?" I would have to say that my answer to this in most cases is yes; what's important is the content, so if a small percentage of users don't get the full experience, I'm happy that they'll at least be able to find what they were looking for. That's more problematic for web apps, of course.

"Is the mobile version of our site the “true” one, and the desktop version only an extra layer of usability?" It depends, but my initial response would, again, be yes.

8 Posted by Jason Rhodes on 9 September 2011 | Permalink

Fantastic questions.

Is this a "real" problem that we will always have to deal with? Or is it a problem that rises out of a deficiency in markup and CSS?

*Should* markup and CSS be handling all of this logic, and be able to conditionally load resources?

9 Posted by Pietropizzi on 9 September 2011 | Permalink

You've touched on a point, that gets overlooked in the responsive design discussion: Connection speed.

One aspect of mobile is the screen size of the device (or the window), so visually changing a design to fit on a mobile screen. This is where mediaqueries are good because it is their intended use.

But then there is the network connection. We think mobile == bad connection and deliver a network optimized version. But we use the same metrics meant to determine if a user is 'screensize mobile'. Imagine using your smartphone connected via wifi to your fast broadband connection. Are you mobile then? Or the other way round: using your notebook on the go tethered to a painfully slow wireless connection. Are you not mobile then?

I came across this when redesigning my site (http://peterminarik.com/new). I was asking myself if I should include webfonts only if the screensize is above a threshold. After all that would save the mobile user about 100KB. But then again why should I rob the wified smartphone of beautiful webfonts, just because the screen is smaller?

What it boils down to: Mediaqueries are the wrong approach to classify if someone is 'network mobile'. We need the connection speed info. Is there already some way to do that?

10 Posted by Ronan Cremin on 9 September 2011 | Permalink

While I agree that it makes more sense to be mobile-first rather than desktop-first, the premise in point #5 is important, and site owners should think twice before setting out down this path: "If we want one website to serve all devices.."

This approach, where the mobile and desktop versions of a site have page-for-page correspondence, and the assumption that changing between them is merely a matter of adding and removing elements on a page is a bad way to start. Content needs to be authored with the relevant use cases in mind from the start, not merely converted. The best mobile web experiences out there usually start with the assumption that what the mobile user wants is different enough to require a fresh set of pages & flows.

11 Posted by Scott Kellum on 9 September 2011 | Permalink

Javascript is a great way to manage this issue currently but in the long term I would like to see something built into HTML that can handle different images. In my work with Treesaver we do something similar with javascript where we only load the image that is the correct size but it adds enough complexity to the markup to be annoying. http://treesaver.net/technology/

Instead I would like to see something like lowsrc where different image files can be used on the same image tag. Instead of being dependent on network speed it should be based on the container size. This effect can be faked now using background images instead of image tags. Using media queries the background url can be pointed in different directions based on the container. This also gives the added benefit that background images render more efficiently than image elements. In the end all these solutions feel like hacks until we have a spec to do things properly.

12 Posted by Mark Stickley on 9 September 2011 | Permalink

7. Yes. And the reason why is because the answer to 9. is also yes (sort of). The real answer to 9. is that there should only be one true version of our site and how it is presented shouldn't make too much of a difference so long as the content is all present and correct. The upshot of this that non-js and non-CSS3 browsers will receive the mobile version which is completely functional. People with browsers that can handle it will get an enhanced experience.

If you don't agree, ask yourself this: if it's not OK for a desktop user to have this experience, why is it OK for a mobile user? Do you value them less?

13 Posted by Matt Aitken on 9 September 2011 | Permalink

I would say that the desktop version of the site is more than an extra layer of usability, it's a different experience in a lot of cases.

I think we really need to add to the tag, similar to to control the content images that are delivered to devices.

I am in favour of responsive design though and have used the 'mobile first' methods.

14 Posted by Gilles Vandenoostende on 9 September 2011 | Permalink

I've found a way to have your cake and eat it too, that is, to build your site from a mobile-first perspective while still serving a full desktop experience to "older browsers" (read: Internet Explorer) who don't yet understand or support media-queries.

The key ingredient is to ditch regular CSS for compiled LESS (http://lesscss.org/), which allows me - through some clever coding & setup - to derive 2 separate stylesheets (one mobile first with media-queries, one desktop-only for IE) from a single codebase, using mix-ins.

Since my solution is CSS-only, noscript users will either get the IE-optimized version (provided they're on IE, and I'm willing to bet most noscript users will be), or if the noscripters are using a modern browser, they will still get the responsive mediaquery-laden version. Should they be using a browser with no javascript and no mediaquery support, only then will they fall back to the mobile version, which is okay in my book.

The process is a bit too involved for a comment, but I've written a more detailed summary of my technique on my blog here: http://blog.vandenoostende.com/2011/sensible-mediaqueries/

15 Posted by Scott Jehl on 9 September 2011 | Permalink

1. Responsive design makes sense when the content across all experiences overlaps enough that mostly presentational and behavioral differences remain. Your point may be true of many (most?) of the examples found online today, but it's not a rule.

2. Responsive is not about display:none on mobile. Conditionally load nice-to-have content on larger displays if you like (via Ajax).

3. There are plenty of mobile-first approaches to responsive images available now. Start here: http://bit.ly/g0IDAI

4, 5. Agreed See #3

6. I'd argue this choice is best made based on screen size. A tablet user would probably expect to get higher resolution imagery than she would on a small screen.

7. Yes, however, this is really only about non-media query supporting browsers like IE 6-8, which would require a JS shim like respond.js.

8. Behavioral layer, I'd say; also for loading nice-to-have assets and content relevant to enhanced experiences.

9. Maybe? I frequently see both as different interfaces to the same content or application.

16 Posted by ppk on 9 September 2011 | Permalink

As I have since 1998, I distrust browser detects, and I would not like to have a server-side component based on them that decides what content to send.

"Opera does not download resources which are not displayed."
Just tested this on Desktop and Mobile, and it's not true. Try http://quirksmode.org/css/displayimg.html

"We need the connection speed info. Is there already some way to do that?"
Yes, we need it, and no, there isn't. But eventually we will be able to do that.
Another solution would be to load an asset, check how much time it takes, and use the data to determine connection speed. I do not recommend that, but it's an option.

17 Posted by Anthony on 9 September 2011 | Permalink

Not sure why it is presumed that, "Right now responsive design is graceful degradation: design something for desktop and tablet, and remove stuff for mobile," when Ethan Marcotte's book, the bible of responsive design, advocates designing for mobile first and enhancing via Javascript.

The rest of this - in particular the purpose of Javascript and how we feel about noscript users - are interesting points for discussion.

I believe serving a mobile version by default to noscript users is not going to be a big problem as in the next few years, mobile web access will most likely dwarf pc access. This is part of a bigger question: How does the web change (if it does) when the majority of global web usage is on a small screen?

18 Posted by Alex Gibson on 9 September 2011 | Permalink

"We need the connection speed info. Is there already some way to do that?"

"Yes, we need it, and no, there isn't."

Actually there is (on Android 2.2+_ - check navigator.connection property.

More info here:

http://davidbcalhoun.com/2010/using-navigator-connection-android

We need this *everywhere*

19 Posted by Yoav Weiss on 9 September 2011 | Permalink

I believe the long term solution is not to rely on JavaScript for smarter resource loading, but to extend media queries to do that. Simply adding a "media" attribute to the base tag, or to the img tag can resolve this issue elegantly.
Adding a connection speed to media queries may also be a good idea.
Nicolas Gallagher made a proposal regarding responsive images a few months back: http://nicolasgallagher.com/responsive-images-using-css3/
I've also made a proposal on the subject:
http://blog.yoav.ws/2011/07/Simpler-responsive-images-proposal

20 Posted by Jason Grigsby on 9 September 2011 | Permalink

I’ve been working on post evaluating different techniques for handling the img tag in responsive designs. One of these days I’m going to find the time to finish it.

The question you’re asking is key. What happens when javascript isn’t turned on. But you also need to plan for some other cases like media queries on, js off. JS on, cookies not available, etc.

The best approaches to images right now are relying on a combination of features being present. JS + Cookies. JS + Media queries. Things can end up in a strange state if only one of the requirements is present (e.g., imagine the http://adaptive-images.com/ technique with media query layout, but no JS).

To your core question, is the mobile version a suitable version for desktop if people don’t have JS turned on. I think that remains to be seen.

Clients are beginning to understand that the experience doesn’t have to be pixel-perfect from device to device. But the true test will be the moment someone close to the CEO has javascript turned off and they don’t see the desktop version of the site.

21 Posted by Ethan on 9 September 2011 | Permalink

Thanks for the post, PPK. I think I'd have to respectfully disagree with a number of points you've made here. (Now, the real challenge: let’s see if I can sound remotely coherent before I’ve properly caffeinated.)

I should start by saying I think a responsible approach to web design—responsive or not—begins with progressive enhancement, which should inform every step of the design process, and not just template production. If we've done our work right, a quality experience isn't simply contingent upon access to JavaScript.

And a number of image-resizing techniques have cropped up to handle image delivery from a PE-minded standpoint. Filament Group's "responsive images" script[1] is the one I'm most familiar with, and I like it precisely because it's geared toward serving up a more lightweight image by default, but can conditionally enhance up from that baseline.

Of course, the noscript question's a valid one. That said, I don't think there's a universal answer we can apply to all sites: obviously, it's our responsibility to raise those questions to our clients at the start of the project, and make sure they understand what a JS-free experience might mean for their design. In my work, I've found that early prototyping can be a valuable design tool early in the process: letting the client experience their design on a wide array of devices and browsers can help set those expectations, as well as better inform the design process. But ultimately, if there's some concern about that JS-free experience, it might be worth exploring other options. Say, some server-side content negotiation, or the like. (Oh god what did i just type.)

Finally, I'd suggest that responsive design isn't about simply removing content from mobile users: ideally, a responsive designer makes a commitment to the content they’re designing across all these different “contexts,” ensuring that information's valuable to every reader. Luke’s “mobile first” mantra is a helpful wedge for these conversations: if a given feature isn't valuable to our mobile users, what value does it really have to the rest of our visitors?

Now, if there isn't a high degree of overlap between, say, the mobile and desktop experiences—if you find yourself simply `display: none`-ing large swathes of “mobile-incompatible” content—then maybe it's worth discussing whether a responsive approach is the right one for that project.

[1] https://github.com/filamentgroup/Responsive-Images

22 Posted by Emma Dobrescu on 9 September 2011 | Permalink

I shall also say that it depends on the project and its scope. If you target mainly mobile users, surely progressive enhancement is the way to go. That is if you have the same set of features for desktop and mobile. But there are times when you offer the mobile users entirely different options. That's why I think a strategy is crucial in the process. It all depends on the extent of the differences between mobile and desktop. Cause obviously if the differences are minimal you could get away with using JavaScript. But I found that back-end is needed to differentiate sometimes.
So wether the desktop version is only an extra layer of usability or not...that depends on your "audience". Not only because of different features, but also because of different connections. Say your target is South America where 3G data is not so popular. Then your mobile users shall have to be served a version with minimal resources to load and so on.
I don't think there are recipes in Web design and Front-end development. Responsive layouts(and I think it should be "layouts", cause it's the code and the layout that adapt, not the design) are a possibility that might or might not suit your project. I think it's us who need to be responsive to each project and adapt, understand and strategize.

23 Posted by Ric on 9 September 2011 | Permalink

I think the industry needs to come up with a better way of detecting and handling different types of devices. Screen resolution is okay, but not a guarantee. There needs to be an easy way to serve the correct content to different devices. They should know what size images they need etc.

Also, I'm not always convinced using the same site is the right thing to do. People use sites differently on different devices. This is one reason native Apps are populate as they take one aspect of something and do it well. Would a cut-down microsite be more effect for mobile use? Could you tailor your own version of a site? For example I use the Football section of the BBC website on my phone, but don't browse much else. It would be nice to be able to say I am only interested in X, Y and Z and the site hides the rest. In a way it's similar to the Chrome Webstore. I looked at the BBC Good Food app and it's a almost like a subset of the food section of the proper site. It's simple, quick and easy to use.

I believe we need to review how people use sites on different devices as much as we tackle the problems with creating them.

24 Posted by Steve Souders on 9 September 2011 | Permalink

I agree with Alex Russell that UA detection shouldn't be a always/never question. A small number of UA strings that represent a larger percentage of the population can be parsed with confidence. A combination of solutions is the answer. An approach like src.Sencha.io can be used when the UA string can be parsed with confidence. In other cases a feature-detection solution can be used.

25 Posted by Trygve Lie on 9 September 2011 | Permalink

This is quite interesting:

>> Opera does not download resources which are not displayed."
> Just tested this on Desktop and Mobile, and it's not true.

Last time I tested this Opera did not load hidden content, and I've run my own tests again [1] [2] with Opera version 10.5x and 11.5x and its like you also confirm, not the case anymore. It looks like Opera has gone away from that approach somewhere around version 11.xx.

1 - http://files.trygve-lie.com/tests/media_queries_load/
2 - http://files.trygve-lie.com/tests/svg_fallback/

26 Posted by Frans on 9 September 2011 | Permalink

@Trygve Lie

Opera sadly got rid of this behavior for compatibility purposes. Apparently lots of people were using e.g. display:none to preload images, making Opera appear slow compared to other browsers. This new behavior also seems in direct opposition to its Turbo feature.

27 Posted by Roland van Ipenburg on 9 September 2011 | Permalink

Wavelet encoded bitmaps were an interesting approach to responsiveness back in the day. But one of the issues was that it relied on the client to decide how much data would be appropriate to use. So in theory you could indeed do a request for the first 1k of the stream and get a blurry image, request an additional 1k and get an improved image, etc. But how is a browser going to determine how much of the stream the user would want to see? Wasn't this easier solved by a UI that just shows basic thumbnails which lead to their fullsize equivalents?

So, yes, in theory using JavaScript you can approach the issue in a wavelet like fashion, but the actual decision on the client to stop requesting more features/bytes won't be so sophisticated that it makes much sense to offer more than a couple of clear choices, and even then there is probably a strong bias to request as much as possible just to get around some educated guesses that turned out wrong.

28 Posted by Allen on 9 September 2011 | Permalink

I just wrote about this a few days ago, after spending a few weeks contemplating our new Square homepage redesign and refactor:

http://allenc.com/2011/09/modern-site-engineering/

CSS media queries solve a lot of the issues you list here - they detect screen sizes (and with specific widths, devices and orientation as well), and the assets specified within the query will only be fetched when the query returns true (e.g., a large image will not be downloaded unless the screen is 1900px wide).

There's another problem with using Javascript, in that mobile browsers will run them slowly. Even if both techniques are available, the CSS one is preferable to the JS one.

29 Posted by Axel Berger on 10 September 2011 | Permalink

To your point 7:
The BBC seem to be doing just that on some of their pages, essentially telling me "We do not serve people like you here, go away." Is that our message?

OTOH I saw the dreaded "screen size" in there. If you were to make that "window size", there might even be a point to it. By choosing a small window I'm telling you something, so why not listen?

As to placing images into the background. My background and colours are turned off in all but one of my browsers, it is the best and/or only way to make half the web legible. So the old rule has to stand, only put design into the background, all content HAS to be foreground. This is especially evil for buttons and such, where on e.g. amazon I have to click blindly into the area I expect them to be. Don't, please, copy that!

30 Posted by ppk on 10 September 2011 | Permalink

@Ethan
"I think a responsible approach to web design-responsive or not-begins with progressive enhancement"

I know that. You know that. Most commenters know that. I doubt that the average web developers knows that. All examples of responsive design I see online so far hide stuff from mobile. That's what inspired this post. It must change, but we have a few fundamental questions to solve.

But anyway, true responsive design is inextricably intertwined with mobile first design. The one can not go without the other. In hindsight that's obvious, but for some reason I didn't truly make the connection until reading your comment.

@Allen
"the assets specified within the query will only be fetched when the query returns true (e.g., a large image will not be downloaded unless the screen is 1900px wide)."

I must admit I made a mistake here. I though browsers didn't do it yet, but I re-read http://blog.assortedgarbage.com/?p=564 , which is the best testing report available, and it turns out you *can* use this technique already. So yes, media queries can solve issues with background images for us. But not with normal images.

@Axel
"I saw the dreaded "screen size" in there. If you were to make that "window size", there might even be a point to it."

Hmmm, have to think some more on this, but it could be you're on to something here. On mobile screen size equals window size, obviously, but on desktop it doesn't necessarily.

@general
I've been thinking more about reporting connection speed, and it strikes me that Android is doing it wrong (although it gets kudos for doing anything at all). I'm not interested in whether the user is on wifi (which can be slow) or on 3G (which can be remarkably fast). I want to know his connection speed in Kbits per second or something. Next question is: can browsers give us that information?

31 Posted by Roland van Ipenburg on 11 September 2011 | Permalink

Browsers could only give a value for what the effective speed is, not what it will be for the next response. So when I'm on mobile and move from fast Wifi to slow 3G - or the other way around - are you planning on altering my browsing experience in the middle of a session? And what for? To pick some maximum loading time a user is supposed to be willing to accept to wait and stuff as much bytes in that period to optimize the experience? Will there be some analysis of what resources are already cached in making a decision on what to do next? I think the maximum acceptable loading time varies wildly on mobile and combined with unpredictable connection speeds and caching it's not worth it to implement a significant QoS management system for responsive design.