Responsive Web Design

This is a transcript of an interview I did for the SitePoint podcast, episode 111.

• Listen to the audio of this interview.

Louis: So hello and welcome to another episode of the SitePoint Podcast. With me today I’m very pleased to have on the show Jeremy Keith. I don’t believe Jeremy needs much introduction to most of the listeners of this show. Jeremy is a web designer based in the UK, he’s the author of several books on web design, most recently HTML 5 for web Designers.

Hi Jeremy!

Jeremy: Hello.

Louis: How are you doing?

Jeremy: I’m doing very well, thank you very much for having me.

Louis: Oh, it’s an absolute pleasure. I think Kevin mentioned that he’d run into you at the .net Awards.

Jeremy: That’s right, yeah.

Louis: Right, and you expressed some interest then in being on the show, and then most recently we were discussing a few weeks ago a blog post of yours with Myles and Max and you chimed in on the comments and said hey there’s a few things I’d like to be able to clarify and get in there and talk about, so yeah, you were generous enough to offer to come on and discuss these issues.

Jeremy: Yeah, well thank you very much for allowing me on to the show.

Louis: Oh, absolutely. So the topic of discussion that drove all of this or that got us here was a blog post you wrote a little while ago called Sea Change, and it was sort of discussing your views on the role of Responsive web Design I guess in the future of the web. So do you want to just to get us started give us a rundown on what your position was and where you were coming from when you wrote that and how you felt I guess the way that we represented it might not have quite captured your views, so I’ll give you a chance to run that down.

Jeremy: Well, the blog post it’s kind of about the future, kind of about now, about how I already feel that there is a shift going on in how we build websites that essentially we’ve been building device specific websites for many years, it just happens that the devices have been desktop computers, laptop computers, and it’s only recently been getting into building device specific websites for newer devices, mobile phones, tablets, whatever. But actually what we’re hopefully moving towards is device-agnostic web development where it just adapts to whatever device the user happens to be using. And that’s kind of what I was hammering on about, I’ve been kind of hammering on about this idea for quite a while of device-agnostic development which was really what web standards were always supposed to be about anyway, it’s just now it’s finally starting to happen.

In fact this whole situation in some way reminds me of the situation maybe ten years ago when there was this shift toward web standards away from tables for layouts and font tags, and towards using CSS for presentation, separation of structure and presentation. Back then you could feel it in the air that it was an exciting time, people took a lot of convincing that this was the right thing to do, and it took some fairly high profile sites like the Wired redesign, the ESPN redesign to convince people it was worth doing, and you had things like the Zen Garden to kind of make that switch in people’s minds. And it’s a similar situation now I think that switch in people’s mind is starting to happen and Responsive web Design is kind of the first vanguard of this way of doing things.

But, I think what I was saying is—maybe I didn’t make myself clear enough in the blog post—but I think some people misread what I’m saying as “it’s okay we don’t need to worry too much about new devices like mobiles or tablets, all we need to do is take our existing desktop-centric sites and just reflow the content so it fits on smaller screens”, and that’s not what I meant, that’s not what I’m saying. What I’m saying is that the proliferation of lots of different devices, lots of different screen sizes, lots of different capabilities means that the desktop-centric sites we’ve been building for so many years just aren’t going to cut it anymore, and the solution isn’t to build a separate sub-domain for these new devices, for different users of these devices, the solution is to rebuild the site in a device-agnostic way from the ground up, which I admit is quite a painful change and there are usually political reasons why that isn’t always a reasonable option to do, but I do feel like it’s going to happen whether you like it or not. Either you can start doing it now, start changing the desktop-centric approach to web development now, or you’re going to be behind the curve in another six months, 12 months, two years, just as ten years ago it was the same situation with making that shift to CSS and separation of structure and presentation; you could either get behind it early on or you could play catch up but it was going to happen.

Louis: Right. I guess one of the things that’s interesting about this idea of Responsive web Design, and I think for the most part what you’re saying is totally sensible and we can all get behind that, one of the things that comes out is Responsive web Design is such a new set of techniques that there are still questions about it and people have been doing or attempting to respond to the issue of mobile for some time now by as you said sort of either segregating things on a sub-domain or trying to come up with a completely different layout that some people already have some preformed opinions about the best way to go about this and maybe that’s why we’re seeing a little bit more friction than what we might expect.

Jeremy: Yeah, and don’t get me wrong, I’m not saying that Responsive Design is the answer to everything and it’s the be all and end all of web development, and I agree that it is very early days and it’s a lot of experimentation going on, that’s kind of what makes it exciting. I would compare it to the situation, again, going back to earlier days in web development, I compare it to a situation with Ajax in that things started to happen and it was a very nebulous thing; around 2005, we started to see some pretty cool applications emerging like Gmail and Google Maps and stuff, and then Jesse James Garrett came along and he gave it a label, he named it by calling it Ajax, and it’s kind of a similar situation here, we’ve got something happening and Ethan Marcotte comes along and he says, okay, we’ll call it Responsive web Design, and straight away we’ve got something to call it and that helps crystallise things, people can get behind that label, but it’s still very much experimentation, trying stuff out.

I don’t want to give the impression that all the answers are there we just need to implement them, no, it’s very much still a phase of figuring this stuff out, it’s just I think it’s good that we have this label for this kind of approach which kind of goes against what has been the default approach for the last two or three years which is this idea of “oh, we just make a separate sub-domain for this kind of user and that kind of user”, that just isn’t going to scale in the long term.

Louis: Right. So is it your view that that’s never going to be the correct approach, that there’s no organisation out there or no publication out there that could benefit from designing a website specifically for mobile devices? And then I think it makes sense to say that your sort of traditional website, any website can benefit from responsive techniques because you’ll be able to adapt to a wider degree of screen sizes and devices. But are you saying that it’s never appropriate to have a site that’s focused on the mobile device with say a limited number of options and then a link back to the main site?

Jeremy: No, of course as with anything it depends. “It depends” is the answer to just about every question when it comes to web development. But, I guess what I’m getting at is up till now the default option has been you create a separate site for mobile and then only in some edge cases do you think about having one site served up to everybody that you adjust the layout for or the design for, and I’m questioning that default. And you’re absolutely right there are definitely situations where there should be a different URL for mobile users, a different subset of the content perhaps, although giving less content to mobile users, that’s something that certainly feels icky to me, but it’s more about the context than the content in those situations.

And Ethan talks about this situation. He gives the example of an event site he was building, the site for Happy Cogaoke which was the karaoke event at South by Southwest last year, and the site, the main site, in the run-up to the event was all about voting and choosing songs and you pretty much needed to be sitting down in front of a computer to use it. But then if you visited the site with a mobile device on the day of the event then you’re probably going to want to know where is the event, how do I get to it, these kinds of things, okay, so in that situation it made sense that you’d be served up something different.

But I think those are the exceptions rather than the default, and there are definitely situations where that’s absolutely what you want to do, but there’s a danger as well, there’s a danger in trying to make assumptions about people’s intent, about trying to assume context from a device, and that’s something I see happening quite a bit. So this idea: okay, somebody’s visiting on a small screen device, a mobile phone for example, then they probably — making the assumption that okay these people don’t want to have access to all our content, they just want to find out an address or they just want to get our telephone number so they can call us, I think that’s a dangerous assumption. And that assumption may have been truer in the past when mobile phones were frankly not that great at dealing with web content when people did use the web on a mobile device as just a quick way of grabbing some information while they’re in a hurry, while they’ve got their head down, while they’re on the move, but the data nowadays suggests that people use mobile phones and other mobile devices in all sorts of situations, you know, sitting at home just sitting on the sofa rather than reaching for your laptop or going to computer you might take out your mobile phone and read some blog posts, or you might be lying in bed with the iPad, that’s actually a very common use case of tablet devices and mobile devices.

So I don’t think it’s valid anymore to try and make those assumptions about people’s intent just from their device if it ever was, and it can be very dangerous to make that assumption and people can get very frustrated, you end up with a situation where people are automatically redirected to a mobile site, a mobile specific site, that has a subset of content, and they know for a fact that there’s more content there because they’ve visited the same site earlier that day on a desktop device and they’re trying to figure out how do they get to that content and hopefully there’s that link to view full website, that inevitably has to be included. So there are situations absolutely where you do want to serve up a different site essentially to mobile users, but I think that situation is in the minority rather than the majority, and I also think it’s dangerous to try and make too many assumptions about people’s intent based on their devices.

Louis: Yeah, so I think what you’re saying is that at the end of the day you really have to consider the users that are going to be using your website and not try and make any kind of generalisations; if there’s any data that the site owner has or that you as a designer have access to or if you can get out there and talk to users and find out what they want and what their contexts are when they’re using the site there’s nothing that’s going to compete with that.

Jeremy: And I have to say it works both ways as well; just as we shouldn’t be trying to make too many assumptions about a visitor to your site who happens to be visiting with a mobile device about their intent, likewise just because somebody visits with a desktop browser does not mean that they’ve got all the time in the world to sit there and wait for a page to load or that they’re not in a hurry and that they want to get to the information quickly or that they’ve got lots of bandwidth.

There’s a terrible conflation between screen size and bandwidth, we tend to assume that small screen sizes mean narrower bandwidth and large screen sizes mean plenty of bandwidth. And while it’s probably a safe bet to assume small screen sizes probably does mean we can’t rely on this person having a fast connection, the opposite doesn’t hold true, you can’t assume that just because somebody has a wide screen that they’ve got lots of bandwidth.

Louis: I guess one other thing that’s most interesting to me coming out of all this debate that’s gone back and forth about Responsive web Design is that it brings to light the fact that I guess a lot of what we see as traditional desktop targeted sites, quote/unquote, have a lot of content on them that maybe isn’t that important. People bring up the argument about a mobile site saying oh my restaurant needs a mobile site because when people are on the go they just want my address and my phone number and my menu, well people always just want your address and your phone number and your menu, and that should be the core information on your desktop site too and all this other junk and big photos of people stuffing food in their faces isn’t actually that helpful to anyone.

Jeremy: Exactly. I actually favorited a Tweet from somebody on Twitter today, he summed it up nicely, he said, “Mobile users want to see our menu, hours and delivery number; desktop users definitely want to see this one megabyte PNG of somebody smiling at a salad.”

Louis: (Laughs) exactly, right. I haven’t seen that; I must have been on a similar brainwave there.

Jeremy: Yeah, that sums it up, that actually what this more recent proliferation of devices and screen sizes and use cases actually brings up is that the way we’ve been doing traditional web design—if you can call such a young industry traditional—has always been pretty out of whack with reality, that we’ve been making a lot of assumptions for the last ten years that were not really based in any good data or any good testing with real users. We’ve been making a lot of assumptions about screen size, bandwidth, context, all these kinds of things that actually don’t hold up, and what I like about this explosion in mobile usage is that it’s really throwing into sharp relief just how outmoded our techniques have been up till now on the desktop.

So I actually think the way that people are generally approaching mobile sites when they do build these separate mobile sites they’re doing web design the right way, they’re thinking about what’s the main content, what would people want when they come to our business. And then of course the obvious question is, like you say, why do we assume that people visiting on a desktop site wouldn’t want the same stuff, the main content. So yeah, so it’s sort of a proliferation of mobile, a proliferation of devices is really showing how out of touch our traditional approach has been.

Louis: So I want to maybe move on now and talk a bit about sort of Responsive Design as a technique and where it currently stands. So that was another thing that maybe we hadn’t fully represented in the previous show when I was talking with Max and Myles. So do you see it more as say a philosophy or best practice or as just a set of tools that you can then go and use to make your websites as good as they can be?

Jeremy: Well, when Ethan defined the term he made it fairly clear, he didn’t make it a wishy-washy term, he was referring to three specific techniques which is using fluid grids, having a fluid layout, having resizable or fluent images and other media video images and so on, and then adjusting layout using media queries. Now people really focus on the media query part, and there are a lot of people that confuse Responsive web Design with media queries; they use the terms interchangeably. And actually the media queries part is probably the least interesting part of Responsive web Design, figuring out how to do a fluid layout and how to handle images and videos and that kind of context, that’s the really tough part; the media queries are pretty easy. And actually even if you don’t use media queries and you used for example a JavaScript based solution similar to Cam Adams’ JavaScript from a few years ago about serving up different layouts based on screen size, I would say that’s equally Responsive web Design, and the media queries aspect is really just a footnote of it. But people have got quite fixated on the media queries part and they’ve just started using the term interchangeably.

So I think the term is a fairly specific set of techniques as defined by Ethan, but how you then approach it can be vastly different because one way you can approach Responsive web Design is to literally take an existing desktop website that’s been made for the desktop—it’s been made in a desktop-specific way—and see how you can reflow the content to fit on a smaller screen. And you might have some success with that depending on the way it’s been coded up, like I said if it’s been done with a liquid layout to begin with you might have some luck. But that kind of approach isn’t really what I would consider best practice Responsive web Design. The correct way to approach it I think is that you start with your basic content and your basic styles to do with colour, typography, that kind of stuff, and then you add in the layout styles inside the media queries or whatever other technology you’re using to detect screen size.

So in a way this is like Luke Wroblewski’s idea of mobile first, thinking about the mobile situation first then moving up, but I think that’s dangerous as well to think specifically of mobile, it’s more like content first, you’re thinking about the content and then you’re applying the layouts. Now that approach I think is going to work a lot, lot, lot better than beginning with the desktop version and trying to make it flow nicely on smaller screens.

And if you think about what you’re doing there by just beginning with the content, applying colour styles and font styles and then applying layout styles on top of that, depending on screen width, that’s progressive enhancement, I mean that’s what we do anyway, that’s the best practice. And while as I said I think there’s a lot of stuff we’ve been doing for the last ten years on the web that’s clearly just wrong, the way we’ve been building these desktop specific sites I think we’ve been doing things the wrong way for quite a while, but progressive enhancement as an approach and a technique that’s something that’s remarkably resilient that I keep seeing again and again and again as a really good solution, not solution but a good approach to lots of new situations.

Again, to relate it back to Ajax when Ajax exploded onto the scene and there was a lot of experimentation a lot of people threw progressive enhancement out the window saying oh it’s a whole new way of doing things, we don’t need to think about that stuff anymore. But as it turns out progressive enhancement when you applied it to Ajax would result in the best possible experience for more capable browsers but still ensuring that everything worked for older browsers.

Louis: As we’ve seen recently with some of the I guess the Gawker Media redesign is the biggest example of that, people still haven’t totally glommed on to that idea even with Ajax, and that’s been six years, so I guess it might take a little while for Responsive web Design to get there.

Jeremy: Yeah, I mean we’re going to see lots of different approaches even under the banner of Responsive web Design or Content First or whatever you want to call that. And I think we’ll see an emergence of best practices over time, I don’t think — I think it’s still too soon to say what’s a best practice right now, and that’s good, there’s still lots of room for experimentation.

And it’s exciting as well, an exciting time I think; I remember when CSS was new on the scene and you could discover a really cool technique that nobody else had thought of and you could blog it on your blog and get a hack named after you or something or get a technique named after you. And this is a really exciting time to be a web developer, and I’m kind of feeling the same way that yes it’s early days and yes we’re still figuring this stuff out and nobody has the answers, but that’s a good thing, you know, it’s exciting.

Louis: Yeah, for sure. I think maybe some of the — when you think about it a lot of sort of the misunderstandings that people have about what Responsive web Design is and what’s the best way to do it, there’s so much stuff out there, I mean even if you look at the media queries gallery that we talked about briefly on the podcast with Max and Myles, a lot of the examples there do take that approach of sort of let’s have a series of fixed width sites that just adjust the layout, and they all load the same images and the same resources, so it’s basically just this full size desktop website that’s being reflowed. So what do you think is going to be the solution to — I mean do you think it’s just going to happen naturally that developers are going to kind of learn how to do this the right way or is this something that we need to be more active in and figure out a way of presenting the right way of doing this to people?

Jeremy: Well, I think like I said there’ll be a lot of experimentation, and again this reminds me of the early days of web standards, and then there will be probably some high profile site that will do it right because they have to, for business reasons they need to make sure that they’re doing it absolutely correctly so they’ll really put in the time and the effort, and there will be sort of canonical first big responsive major brand site in the same way as we had ESPN.com, the Wired redesign, you know these sites from the early days of CSS based layouts, to show us the way.

So I think we’ll have experimentation, well then yeah there will be people reflowing desktop-centric sites, it’s all experimentation, and also you’ll notice a lot of sites doing this now are personal sites, portfolio sites, that kind of thing, because that’s where a lot of experimentation’s can happen.

Louis: And there’s kind of two ways of looking at that. Some people say the reason you only see personal sites and blogs and web design agency sites doing this is because that’s the only type of content this is suited for, but then on the flip side any new technique usually shows up first in personal sites and web design agency sites because that’s where people are playing with things, CSS designs in the same place and any technique really the CSS 3 stuff we’re seeing now is mostly still on those little sites.

Jeremy: Yeah, exactly, this is where the experimentation happens. If you look throughout the history of web design it’s always been the way that you see these things happen, first on somebody’s personal site and then they get applied to commercial sites. So I’m kind of looking forward to seeing that site, maybe it’s already being made somewhere out there, and I think there really will be like this dam burst of sites once it’s been proven to work on a large scale commercial site. And you could sit back and wait for that to happen or you could try and see if we could be the ones to do it. How awesome would that be if we could be at the front of that change rather than just playing catch up?

Louis: Yeah, absolutely. I’m seeing the About.com homepage is using somewhat of a responsive design at the moment, it’s got a very, very flexible grid so it’s one example I guess of a fairly major or high profile site that’s doing this kind of thing, but they’re probably a lot more to come.

So I wanted to touch a little bit on some of I guess the technical challenges that come up when doing this kind of thing because the issue I guess isn’t so much with respect to dealing with different screen sizes because that’s something that all these responsive techniques do very well. But one thing that does come up a lot is if this is going to be your approach as an organisation or as a website designer to handling the quote/unquote mobile devices and mobile context then that implies a few other things, and like you said the association of bandwidth with the screen size or the lack of a keyboard with the screen size even isn’t a hundred percent, but it’s something that is there and people need to consider. And I guess one of the biggest challenges with Responsive web Design is dealing with that bandwidth challenge, if I need to serve an image that will look good at 1024 or 1280 and it also needs to look good at 320, the approach so far in most responsive cases has been to use a really large image and scale it in CSS, but that does pose a problem for bandwidth. And then the other issue that comes up is some of the superfluous content, so you’ve talked a little bit about lazy loading as a solution to that, so I wanted to hear what your opinions are on where we’re going with respect to these sorts of technical challenges and dealing with bandwidth issues.

Jeremy: When it comes to serving up different size media, like images, I think as with this idea when it came to layouts, instead of scaling down a desktop-centric layout to flow into a mobile site, what if we flip it on its head and start with the narrow version and then scale it up to desktop? I think that’s probably a good approach to take with media as well; instead of thinking about the large image as the default and how do we scale it down for smaller screen sizes, to flip that on its head and think about the smaller image as the default and then how do we provide a larger image for the devices that have larger screens, laptops, desktops and so on. I mean, partly that’s because the smaller screen device is going to include a whole bunch of phones that are not all that capable, we’ve got some great mobile browsers out there now, Mobile Safari and so on, but there’s also a lot of mobile phones that have kind of crappier browsers. So the safe default is to think about the lower bandwidth, think about the smaller images, think about the linearised design, and then to apply larger images, more content, multi-column layouts for the more capable browsers that are likely to be on a desktop or laptop computer. So again I think it’s about flipping it on its head.

So an approach will be that you have the smaller images by default and then using JavaScript for instance when you’re detecting screen size or bandwidth to swap them out for larger images, and some people started writing some clever scripts about this. Scott Jehl has got one on GitHub I believe about dealing with swapping out images based on screen size. And then I came across another JavaScript—I wouldn’t call it library—just a small snippet, that’s trying to actually detect bandwidth, now that’s a really tough nut to crack, I mean it’s actually pretty easy to detect screen size, resolution, that kind of stuff, that’s a solved problem, trying to figure out how fast somebody’s connection is that’s a real unknown unknown. But using some clever Ajax essentially pinging and checking the response times you can attempt to deal with that, but in general the overall approach you want to take is to play it safe with the default so the default should be the small screen content narrow bandwidth small media, and then to apply the fully blown layout large images more content only to the browsers that are capable of dealing with it, and then lazy loading is another way of doing that. I’m probably using the term lazy loading incorrectly, I know it’s a programming term to invoke something only when you need it, and I’m using it as in literally loading something in after the main content is loaded which is I should probably be saying something like conditional loading or something, but I’ve kind of borrowed that phrase lazy loading.

Louis: Well I think it’s clear to most people, and it’s something a lot of people have started doing with JavaScript either for polyfills for HTML5 or CSS3 stuff, or for just if you’ve got a lot of scripts on your page that don’t need to run right away, just delaying that a little bit to cut down on the initial loading time hit.

Jeremy: Yeah, for performance reasons anyway. And, again, this is kind of orthogonal to mobile or small screens or different devices, it’s just good performance sense to make sure your important content loads first and loads fast, and then you can let the sort of peripheral content load in in its own sweet time. I know Flickr are doing some lazy loading stuff in the background around some of the peripheral stuff on a photo page. So, again, it’s just general good practice regardless of whether you’re even thinking about different devices.

Louis: Yeah, absolutely. And you’re doing some of this on your sites with I think Huffduffer I saw one of your blog posts is you’ve introduced some conditional loading of some sidebar content. Are you doing any screen size detection for that or is it just loading after the main content?

Jeremy: Well, to begin with I simply wanted to improve performance because a lot of the stuff that was in the site first of all it wasn’t main content it was nice-to-have content, and secondly the content involved pinging out to third party sites. I mean I was doing some caching but it involved grabbing photos from Flickr, grabbing updates from Twitter, this kind of stuff, this kind of nice-to-have sort of decoration.

So to begin with it was a performance issue, I want to make sure the main content at the site wasn’t getting held up by these third party requests. This is the same problem that something like Node.js is intending to solve, that you don’t have your rendering held up by having lots of requests to different things. So it started as that and once it was done I thought well it’s a simple Ajax request, you know, once the page is loaded pull in this data and put it in this element, it was pretty easy to wrap that in one little conditional if statement which is simply “if the screen is larger than a certain amount, do this.”

Now it could be that when I do that I’m actually committing the classic error of mistaking screen size for bandwidth capability, I could be conflating the two there. But I think it’s a reasonable use there, again, I’m not claiming to have all the answers; I think it’s a reasonable use.

What’s interesting is in that situation as well is the semantics of where I’m doing it, it’s as you say it’s in a sidebar, it’s a site using HTML5 elements and it is an aside, literally an aside element. And if you look at the definition of what the aside element is to be used for it matches pretty closely to the kind of content that’s nice to have but not your main content, content that’s tangentially related to the other content around it. So it was interesting to see that mapping between the semantics of the container of the content and how I could think of the content as well as being, well, it’s not major content, it’s not vital content, it’s nice to have.

So, yeah, I think lazy loading is an interesting approach for performance reasons and can tie into this idea of smaller screens and whether or not you load that content in. Because if we don’t have options like lazy loading then the only options we have when we’re considering whether content goes on a page, is “is the content on the page or not?”, that’s it, those are your choices, yes or no, true or false, one or zero. If you do lazy loading you get to say “it depends”, you get to say “well, that content would be good to have on this page if the situation allows for it”, and that’s very useful in very early stages of site planning when you’re still in the wire-framing stage, when you’re discussing with the client. Because you know how it is, the client is going to want everything on there like “we’ve got to have this on there, that on there”, and you want to please the client but at the same time you’re taking the viewpoint of the user and you know the user just wants to get to the main content. And this kind of gives you an opportunity to say “well yeah, let’s put that content on the page if the viewport is wide enough to handle it, and let’s make sure that content doesn’t get in the way of the main content.” I mean that applies to a visual design perspective but also literally in terms of loading the content, that the main content isn’t being held up by this nice to have peripheral content.

So it’s nice it introduces this third option instead of just content being there or not, true or false, that we get this this way of saying “maybe”.

Louis: Yeah. And I guess what I like about that is it kind of gives you the option in a weird kind of way of reuniting the concept of a dedicated mobile site with the concept of Responsive web Design. Because generally speaking the difference between the two is in your Responsive web Design, I mean like to state it in a very, very simplistic way in a Responsive web Design the sidebar content gets floated below your main column, and in a dedicated mobile site the sidebar column just isn’t there, you know, in the simplest way of putting it. But, so that if you’re relying on this kind of potentially JavaScript based loading your link at the bottom of the page that says go to full site all it could do is do exactly the same thing and just load in the sidebar content and put it below, so you have this option now of I guess kind of taking the best of both worlds and working in a way that makes sense for mobile but that also provides all the content on a conditional basis when either the user wants it or we know that they can handle it.

Jeremy: Yeah, that’s a good point that you can make that decision: okay I think that the mobile user, the small screen user just wants to see this content but still give them the option with a button, a link or something to say show me more, give me the full stuff, and then load it in because they’ve specifically requested it. So, yeah, it gives you that instead of having to make that choice, instead of having to call the shot one way or the other, you get to put the power back into the hands of the user.

Louis: Alright. Well, it’s been really great having you on the show and have a chance to talk about these things and really get your views on it, you’ve got a lot to say and you’ve been blogging a lot about this stuff, but sometimes for some reason I don’t know what it is about the Internet, but on blogs and Twitter statements and positions always seem way more absolute than they actually are.

Jeremy: I have to say that I’ve been taking kind of a hard-ass approach with a lot of this stuff instead of being maybe more nuanced, but that’s partly because I like to support the underdog in a lot of this stuff.

So I remember five, six years ago I was the one saying oh you should all check out JavaScript it’s really cool now, and nobody wanted to hear it. Who’s laughing now. And for ten years I’ve been saying “oh liquid layouts are the way to go” and now I’m feeling kind of vindicated there, so I do kind of always pick the opposite of whatever the default is and kind of champion that, so because the default has become building separate sites for the mobile I’m kind of championing the opposite approach partly just to be obstinate I guess (laughter). But I do really think it is the way forward, but I should clarify once again as I said at the start it depends, it always depends.

And also the kind of sites I’m talking about are a certain type of site: the kind of sites I spend 80, 90% of my time working on which is content-driven sites where the user is there to digest information, to read something, to have an experience. There’s a whole lot of class of site that’s very different: the web app. Now you get into the whole problem of trying to define what a web app is and it’s a whole ‘nother kettle of fish and I think sometimes people define their site as a web app just as a “get out of jail free” card, “oh none of this stuff applies to me; it’s a web app.” But, I have to, for the sake of disclosure, just say that I am talking about a certain kind of site which is a content-driven site rather than maybe a task-driven site that a web app would be.

So I know I come across as maybe being very absolutist on this stuff, it’s not my intention, I do try to be nuanced to a certain extent, but I am kind of deliberately taking a hard-ass position.

Louis: Yeah, well that’s always good because at the very least it provokes discussion and gets people involved in issues because if someone reads a nuanced post they might not think about it again, but if they read something and say wait I disagree with that, let’s do some thinking! Alright, well thanks again so much for coming on the show, Jeremy, it’s always great having the opportunity to talk this stuff out and it will be great for the listeners to hear your views on this. If people want to find you online do you want to drop in some links?

Jeremy: Yeah, my site is Adactio.com and I’m @adactio on Twitter, and adactio on just about every service out there.

via adactio.com

Responsive Web Design This is a transcript of an interview I did for the SitePoint podcast, episode 111 . Listen to the audio of this interview . SitePoint Podcast #111: Responsive Web Design with Jeremy Keith on Huffduffer Louis: So hello and welcome to another episode of the SitePoint Podcast. Wit ...»See Ya