Another interview for the Sitepoint podcast.
This is a transcript of an interview I did for the Sitepoint podcast, episode 168
- Listen to the audio of this interview
Louis: Hello, and welcome to another episode of the Sitepoint podcast. Today on the show, I’m very pleased to have with me Mr. Jeremy Keith, all the way from the sunny United Kingdom. Hi, Jeremy.
Jeremy: Hi, good to be back.
Louis: It’s great to have you back. You were on the show I believe in May of 2011, and we had a pretty far-ranging conversation about responsive web design. Obviously since then, almost the only thing you hear about on the internet is responsive web design. So I thought it’d be a great time to have you back and see where things have come in the past year.
Jeremy: Excellent. Sounds good.
Louis: All right. First of all, one of the things you mentioned the last time you were on the show; you made a prediction. You said the situation reminded you of the early days of web standards, and there will probably be some high-profile site that will do it right. They’ll be the first canonical big, responsive brand in the same way as we had ESPN.com or the Wired redesign. You said that in May. In September, the Boston Globe launched their massive responsive redesign. It sounds like a pretty accurate prediction.`
Jeremy: Yeah, I think that’s exactly what happened. Now there is somebody you can point to and say, “Like that.” I’ve actually noticed it even with clients, that they’re coming to us now and pointing to the Boston Globe and saying, “How did they do that?” And, “Can we have that?” Which was exactly what it was like with the big web standards changes at the start of the millennium.
Louis: You’ve already seen this in the wild. Do clients immediately get that that’s a more attractive approach for them than going the traditional mobile separate site or app route?
Jeremy: Where I’ve seen it be convincing for clients is for clients who have tried to do separate apps for different platforms. Maybe two, three years ago they built an iOS app, and then in the last 18 months, “Oh, we need to build an Android app.” Then at some point they realised “Oh, we need to build Windows phone.” It’s those clients who are now saying, “All right, enough is enough. This is getting out of hand, and where is this going to stop?” They’re looking at their numbers and realising that this just won’t scale. It’s those clients that are the ones who are quite intrigued by responsive design and what it promises.
There’s a bit of a danger though in that responsive design has also become a trendy, buzzwordy term amongst people who don’t make websites. When it’s being used by developers and designers, that’s fine. We all understand what we mean by responsive design.
Ethan Marcotte was very, very clear when he coined the term that it was a specific set of technologies. It wasn’t a wishy-washy outlook on life or some kind of Zen Buddhist philosophy. It was specific technologies. Now that it’s really taking off in the world of marketing and consultancy, it’s being bandied around in the same way as HTML5 or CSS3, being used as terms without really understanding what the terms mean. I have to gauge when clients come and they’re talking about responsive design. I gauge “Do they know what it is yet?” Or do they actually need to talk about it a little bit more to understand what it means?
Which I’ve definitely had with terms like HTML5 and CSS3. They’re throwing these terms around, but as I quiz them more about it, I realise “Oh, actually they’re just using these words. They don’t actually know what HTML5 is, what CSS3 is.” They just know it’s trendy terms and they equate it with modern.
There is a bit of a problem there that responsive design has become one of those terms. It’s also a sign of success that, when your term gets hijacked by the marketing guys and starts to lose its meaning in certain conversations because people are just throwing words around, that’s actually a pretty good sign that you’ve hit mainstream adoption.
Louis: In terms of actual usage in the wild, I guess that’s simultaneously where you want to be and where you don’t want to be in terms of having to educate clients.
Jeremy: Exactly. It’s a double-edged sword. On the one hand you want everyone to know about this term and you want to get the word out there, but be careful what you wish for. Because when people actually start using this term to mean everything under the sun, you lose the clarity you originally had with that term.
Louis: I think for most of us in the world of web design, we can be really happy to see that this is gaining steam, especially considering the proliferation of device sizes and resolutions, even in the past year. Things have gotten a little crazy, and trying to support all of those with independently designed, special purpose sites would quickly become unmaintainable.
Jeremy: Exactly. The scale problem is the issue. It’s nice that this proliferation of devices …I think it’s actually emphasised what was already there.
Even a few years ago when you were making a website, and you were really only thinking about desktop web browsers, there was still a variation in browsers. You’ve got Internet Explorer and Opera and Chrome and Safari and all these browsers. The mantra amongst web developers was, “It doesn’t have to look the same in every browser.” It was hard to actually sell that idea, because on the face of it, these browsers didn’t seem that different. The context didn’t seem that different. I’ve got a computer, it’s got a browser on it, why can’t my website look the same in these browsers?
With the explosion of devices, different sizes and capabilities of browsers on these devices, it’s a lot easier now to say to people, “Look. You can’t expect this to look or work the same across all these different devices.”
Telling people ‘it doesn’t have to look the same on every browser’ is an easier concept to get across now because of all these devices. It was always the case, it’s just now it’s more understandable for everyone that “Okay, now I get it. The website doesn’t have one particular look, one particular feel. A website is going to look and feel different in different browsers on different devices.” That concept now is more well understood, more widely understood.
Louis: Right. I guess that’s also a double-edged sword, because now as developers we have this task of trying to maintain a site on 100 or 200 different screen sizes and resolutions, whereas before it might have been a dozen.
Jeremy: Sure, but there’s a difference between testing on different sizes and different devices and optimising for the devices. If we had to actually optimise for 200, 300 different devices then yeah, our lives would be absolutely miserable. It’s more about making sure stuff doesn’t break on any of these devices. As long as everyone’s on board with the idea that it doesn’t have to look the same across all these devices, then it’s actually not that bad. This deluge of devices isn’t the end of the world. It’s something to be welcomed.
Louis: Yeah, I noticed on your blog that you and a few others have set up a communal testing lab?
Jeremy: Yeah. So at ClearLeft, over the past year or so, we’ve been gathering devices bit by bit. It’s never enough, you can never have enough devices, but we’re trying to do our best.
I would go into these dodgy second-hand shops and buy cheap older devices that fell off the back of a lorry somewhere. Bit by bit, we were putting together a table with some devices on it so we could test stuff that we were building on those devices. Really, not enough.
I realise it’s a bit of a waste. They’re sitting there on the table most of the day and not being used when I’m not actively testing something.
I just mentioned it on my blog. I said, “Look, we’ve always had an open door policy at ClearLeft. If you’re coming by, if you’re in the neighbourhood, swing on by, use our WiFi, sit on the sofa, have a cup of tea.” That kind of thing. I just extended that to say, “Feel free to use these devices.”
What I didn’t expect—it was really, really nice—was that the same day as I said that, all these other people in Brighton—like Remy Sharp, Aegir from ministryoftype.co.uk—they started chiming in on Twitter and saying, “Oh, I’ve got this device that’s just lying here on my desk, not being used” or, “I’ve got this device that’s in a drawer. Do you want me to leave it in your office?”
I said “Yeah! The more devices the merrier.” Within about 24, 48 hours, the number of devices had doubled. Which I wasn’t planning, that wasn’t the idea when I announced it, “come by with devices.” It was just a really, really nice side effect of that.
Now I’ve actually got a pretty good collection of devices. Still, it’s never enough, you can never have enough devices, but it’s a pretty good amount. I’ve had to go out and buy a lot of power strips and a lot of USB cables to power up all the devices, keep them charged.
Now I feel like okay, this testing lab is pretty good, but now it’s no longer really our devices, it’s everyone’s devices. Anybody who wants to come by and try them out.
The reason why I’ve been blogging about that a lot is not just to let everyone in Brighton know you can come by the Clearleft offices and use our devices, but also people in other places, wherever you happen to be. I bet there’s a bit of a community of web developers, I bet they’re all feeling the same as you, which is “I don’t have enough devices to test on.” Trust me, everybody’s thinking that. If everyone pooled their resources, you could have a pretty good communal library.
One thing I didn’t do was worry too much about the legal side or insurance or stuff like that. I just decided if something happens, I’ll deal with it then. If there’s theft or something to do with warranty of one of the devices that’s sitting in our office but doesn’t belong to us, I’ll deal with that issue when it comes up, rather than try to anticipate all of the possible things that could go wrong. So far nothing’s gone wrong, and if something does go wrong I’ll deal with it then.
I think that’s also an important attitude, because this idea of opening up your doors and having a communal testing lab, that’s not a new idea, but it’s been hard for other people to get off the ground. That’s because they were trying to anticipate all the possible cases of things could go wrong. By simply ignoring the problem, it goes away.
Louis: Yeah, if only that were the case for all of our problems. I think that’s a fantastic idea, and I look forward to seeing the same sort of thing being taken up in other cities. Did you see at E3 I believe it was, Microsoft announced they’d be putting a version of IE on the Xbox? You’ll probably have to get an Xbox for your testing suite as well.
Jeremy: We don’t have a choice, really. We’re going to have to get an Xbox for the office.
Louis: It’s a business requirement now.
Jeremy: Exactly. It’s an expense.
Jeremy: Okay. The issue is mostly one of bandwidth. As in: you don’t want to be serving up big images to small screen devices. It’s wasteful.
To begin with in responsive design, that situation was happening a lot because people were taking existing desktop sites and making them responsive. They were adding styles that cancelled out layout styles, linearised your layout, and shrunk down images in CSS. Actually you were still loading all these images.
Since then I think that attitude has changed, and people are building more mobile first, as it’s called, responsive design, where you start with a linearised layout, you start with the small images. Then you build up to the larger view for desktop screens.
To start with, that by itself is already a step forward. If you’re starting with the smaller images, now your problem is not “How do I detect if someone’s on a mobile device and give them a smaller image?” Now your problem is simply, “How do I detect if someone’s on a desktop device and give them a bigger image?” Straight away, that’s a smaller problem space.
Also just the fact that if anything ever goes wrong, what’s going to happen is the user gets a smaller image by default instead of the bigger image. That’s good, and there’s a bunch of techniques around figuring out “Okay, is this a large screen device?”
The default attitude at WHATWG generally from Hixie is “It’s not a problem. You have to prove it’s a problem to me.”
Okay. Pretty sure this really is a problem, because there’s all of these developers trying to solve it. It’s really clear that this is something that needs to be fixed. Eventually Hixie was convinced of that.
What happened was somebody on the mailing list—who actually really isn’t a long term contributing member of WHATWG—said something like, “Oh, you should go over to W3C and make a community group.”
The W3C community group’s this new idea, where people can basically brainstorm around stuff, but it’s not anything to do with any official spec. It’s just a place for people to gather and come together.
The problem is that people who had come to the WHATWG took that advice as being advice from the WHATWG as a group, which it wasn’t. It’s just one guy saying this. WHATWG doesn’t have much of a hierarchy. You, me, we can all be members of WHATWG just by writing an email to the WHATWG list. It was taken as, “Oh, if you go over to the community group and work on this and then come back to us, that’s the correct way to solve this problem.”
These people went off to form a community group, Responsive Images Community Group on the W3C, and that’s where they really started hammering out a lot of this. They did a lot of great work, really good work.
First of all, figuring out the use cases, because it turns out it isn’t as simple as you first think of simply swapping out a larger image for a smaller image. Sometimes what’s shown in the image might be different. It could be a crop of the larger image. Sometimes it’s literally a smaller version of the larger image. It depends, different use cases.
Then you’ve got the issue of retina displays, where you actually want to show the image at the same size, but for some devices that image should be twice as large in terms of pixels.
They were hammering out all these edge cases, figuring out all these details, doing really, really good work. Meanwhile over at the WHATWG , other people were also doing some work.
The way that Hixie works is that he attacks his email in a big bunch at one go, and attacks an issue in one go. A few months later, he was coming back around to tackle this issue of “Okay, do we put something into the spec about trying to have responsive images?”
Ted, who works at Apple, works on Safari and works on WebKit, he heard that Hixie was going to be tackling this problem. He put forward something he’d been working on for months, which was related to the work that Apple were doing with CSS, to do with this idea of a set of images that you could list: a comma-delimited set of images, and the browser could choose which image to display based on the appropriate constraints. This is happening in CSS. A similar pattern is what he proposed for HTML, that you have this source set attribute that’s comma delimited, and you describe the parameters that trigger one image or another.
Anyway. He throws this out there. Here’s the problem. The way it looks to the outside, to the people that had gone off to form this responsive images group, they’d been told to go away, sort it out over there. Meanwhile, somebody else who appears to be an insider at WHATWG just proposes this source set thing out of the blue, and boom, a couple of days later it’s in the WHATWG HTML spec.
That’s the way it looked to the outside.
Actually that’s not the case, because all of the work that Ted was doing was informed to a large degree by the use cases that the responsive images community were coming up with. Their work was certainly not wasted. Also it turned out he had been working on this for months, it was just the timing looked pretty suspicious from the outside.
The day that this source set thing got put in the spec …it was a bad day for communication, put it that way. In the IRC channel, there was a lot of tempers firing. I was upset, because it seemed to me that Hixie had literally no knowledge of the work going on at the responsive images community group.
What they had done was they had actually come up with their own proposal that followed the pattern that’s used by video in HTML5, which essentially puts media queries into a source element, and you choose based on that.
Both solutions have their issues. Neither one is perfect. Ideally, what you want to see is both proposed solutions being evaluated on their merits.
The way it looked from the outside on the day that that source set proposal got put into the spec was, “Oh, there’s some favouritism going on here. You prefer this solution because of who proposed it. It was someone inside WHATWG , someone who works on a browser. That’s why it’s getting favoured.”
The people at WHATWG were quick to point out that just because it’s in the spec right now doesn’t mean it’s staying in the spec, it doesn’t actually mean anything. You can understand why people were upset, because it seemed to be a favouritism between solutions going on.
Jeremy: It was problematic. It was also problematic because immediately then it became an us vs. them situation. Instead of evaluating which solution was the better solution for the problem cases, people were arguing about which solution was better based on who had come up with it.
Things died down a bit, things cooled off, which is good. I think everyone began to realise that actually what we really need is a solution that works for the end users, regardless of where it comes from. This is still being discussed, and there’s some good compromise solutions coming out.
Essentially the picture element that was proposed by the responsive images group, that’s very, very good for solving what I would call the art direction use case. Which is where as a developer, as an author, I want to provide a number of possible images and a number of possible conditions. Say if the screen width is this large, I want to load this image. If the screen width is this large, I want to show this image, and that image could be a cropped version of the original image and so on.
Louis: Right. If you have a very wide banner, masthead image imagining situation here that has someone’s face in the top left, and you want to shrink that down to a square for your mobile version, then that might just not look right. Any kind of automated solution wouldn’t work. If I can, as the author, specifically crop the image myself and say, “This is the one I want,” then I have a bit more power to do that.
Jeremy: Exactly. That’s a perfect description of what’s called the art-directed use case, which Jason Grigsby has done a lot of great documentation for on his blog.
The other use case as I said is retina displays, where it’s more about the capabilities of the device, and less about the author making the decision. In the art-directed use case, it’s more “I want the browser to be smart about this.”
I’ve got these images, and they might be literally the same images but different densities of pixels. I want the browser to be smart about which one to pick. It’s less about the author’s decision and much more about the browser’s decision.
The source set solution that Ted proposed is very good for that use case. It’s less good for the art-directed use case, whereas the picture solution that the responsive images group came up with is very good for the art-directed use case but gets a little messy when it comes to the retina use case because it’s reusing media queries. Media queries aren’t quite so good at making the browser smart. Media queries are there to empower the author. So the author can specify “under these conditions, I want this to happen.” They’re less good for the algorithmic decisions that a browser needs to make.
I think ideally what we’d like to see is a combination of both, the best of both.
There’s other issues as well around how readable the syntax is, how understandable syntax is. How implementable it is, that’s obviously a big, big issue as well. It’s all well and good to dream up great solutions, but it has to be something that browser makers can do relatively quickly and easily.
I would like to see some kind of compromise between the two. They’re both smart solutions, but they’re actually for different use cases. It was a shame that things got so heated for a while and things did get very partisan and very political.
It became a political issue, more about who was proposing a solution rather than which solution was better. I think that’s died over now. I hope it’s over, and we’re back to discussing what’s the best solution.
Louis: Yeah, I think between your blog post on the issue and then Matthew Marquis wrote an article on A List Apart, which was trying to stand down from that confrontational state of affairs, while presenting his criticisms, or what he feels are the weaker points of the source set solution. Also just saying at the end of the day, what everyone needs to focus on is coming up with something that will benefit users and authors in the long run, and also as you said be implementable.
Jeremy: Exactly, exactly. The ironic thing is people have been looking at the whole situation and going “Oh, my God, this is how standards are done, it’s such a mess, it’s acrimonious, it’s horrible.” It’s actually not that bad compared to how other standards get done. It’s just that it happens in public.
WHATWG, they’re very public about how stuff gets done. It can seem pretty anarchic and messy.
Another thing to mention here is that because it’s HTML we’re talking about, it’s a bit more complicated in that you’ve got the WHATWG working on the ever-evolving HTML living standard. Meanwhile you’ve also got the W3C, who are working on the version numbers. HTML5 is what they’re working on. They take the work being done at WHATWG and they get it into a spec with a working draft and last call and all these milestones. They’re much slower to simply throw something into the spec and say, “Yeah, done, good enough. Let’s iterate on it later.” They’re much more cautious.
It’s a good illustration of how I think the two groups balance each other out. Because I like the WHATWG’s way of working. It’s fast and it gets stuff done, and they put stuff in the spec and then iterate on it, but it’s a bit too anarchic, and a bit too crazy. Meanwhile the W3C can be very slow because they’re concerned about setting stuff in stone for all time. They have to be very cautious and slow. I think the two groups balance each other reasonably well. This could be an example of that. If Hixie does go throwing any old stuff into the spec in WHATWG, that doesn’t mean it’s going to happen in the W3C. That could be the place where stuff gets revolved. It’s almost like political systems with two houses.
Louis: Yeah, it’s interesting how that evolved almost organically in this case, in a way that does mirror the way a lot of democracies are organised.
Jeremy: Right, checks and balances.
Louis: Do you feel like there’s a fairly good likelihood in this case what we’re going to end up with in browsers is going to be a compromise between those two solutions? Something that evolved from both of them at least?
Jeremy: That’s what I’m hoping. I have to admit that my inner pessimist is thinking that because browser makers carry a bigger stake than anyone else, they get to say. If in the next version of Safari it’s already got source set in there, then the attitude of WHATWG will be that’s what we’re going to standardise on. Because rough consensus, running code.
Personally I’d like to see a bit more rough consensus before we have the running code.
I suspect what’s actually going to happen is that some browser, probably Safari, will ship with their preferred solution, and that’s what’s going to get standardised. Because now it’s in a browser, that’s what counts, that’s the way it’s going to go. It may not be the best solution.
Louis: Right. Now in this case, given that we already do have some sort of fairly decent workarounds for a lot of these situations, any additional tool on the browser side does help a little bit, and can only make our lives a little bit easier. On the one side, it’s look like anything will be great to have, especially if it gets implemented and rolled out fairly quickly in a lot of different browsers.
Jeremy: Yeah, yeah. It is good that browsers are at least paying attention to the problem, but obviously they have their own biases as well. I suspect that Apple’s concern right now will be around retina images …for good reason. They’re switching to retina displays across the board, so they’re very concerned about that use case.
Jeremy: They’re probably less concerned about the art direction use case. We may see pretty good solutions for swapping out images for retina displays, but that’s not going to help us with the other use case.
Louis: Right. You mentioned earlier the potentially very broad or long term hope that potentially we could have an image format that was itself progressive with regards to things like pixel density bandwidth. Then again, that also doesn’t really address the art direction issue as it were.
Jeremy: You’re right. That’s more about different sizes, same image. Surprisingly far along, if you look at things like JPEG2000, progressive JPEGs. I guess the image is sitting on the server and has got all the data, but when the browser requests it, browser can send headers. Based on those headers you can send back a certain byte range of the image. For this browser I’m going to send back this range. Theoretically maybe you could embed multiple images in an image for the art direction use case, but yeah, I don’t know.
Louis: Right. Well, it’ll certainly be interesting to see how this plays out. As you said it’s great to see the browser makers involved and at least aware of the problem and doing something to help us out. In the meantime, there are an abundance of really, really clever workarounds and libraries and tools that have arisen, to make this as manageable as possible given the tools that we have.
Jeremy: Yeah, the Filament Group have been doing some great work. Scott Jehl, Mat Marquis. They just recently published a bunch of their tools on GitHub, called it Southstreet. It’s a lot of different tools that they use and responsive design projects around things like conditional loading and around responsive images.
Seeing as these are the guys who worked on Boston Globe, they really know their stuff. It’s well worth paying attention to their code.
Louis: Yeah. All right. Well, Jeremy, thank you very much for again taking the time to come and talk to me about this. It’s always really great to hear your views on all of this. Thanks for writing all of this stuff on your blog that helps the rest of us keep in touch with what’s going on in this world.
Jeremy: No problem, it’s my pleasure.
Louis: All right. If listeners want to find you online and they’re not already following you, in which case they’d be crazy or not web designers. If they want to find you on Twitter or on your blog, where do they go?
Jeremy: On Twitter I’m @adactio, but half my tweets will be about toast. Just a warning.
Louis: Who doesn’t like toast?
Jeremy: Exactly. It’s what Twitter is for. What I had for breakfast, that’s what Twitter is for.
On my blog, it’s also adactio.com. I’ve got a journal there, that’s the blog, and then I’ve also got a links section. In the links section I’m constantly linking to a lot of resources about responsive design. The blog sometimes talks about web stuff, but also talks about what I had for breakfast. Fair warning.
The company I work for is Clearleft, clearleft.com, and you can find a list of devices in the test lab there, and if anyone from Brighton is listening, do feel free to pop by and test on our devices.
Louis: Right, and I’d also love to know if anyone has started up there own little device test lab in their own city, love to hear about those because I think it’s a great idea.
Louis: Thanks again Jeremy and have a good day.
Jeremy: You too.