Episode 168 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Jeremy Keith (@adactio) who now works at ClearLeft to talk about the developments in the Responsive Design world, and particularly the ongoing discussions on proposed image element solutions.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #168: Secret Src with Jeremy Keith(MP3, 32:47, 31.5MB)
Episode Summary
Louis and Jeremy to talk about the developments in the Responsive Design world, and particularly the ongoing discussions on proposed image element solutions the WHATWG are looking at from various proposals.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/168.
Interview Transcript
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.” Then 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 realized 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 realizing 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 technology. 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 was as HTML5 or CSS3 as 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 realize 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 emphasized 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, it 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 OK, 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 optimizing for the devices. If we had to actually optimize 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 realize 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 neighborhood, 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 same day as I said that, all these other people in Brighton like Remi 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 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 OK, 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 Clear Left 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 pulled 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.
Louis: Fantastic. One of the other things I wanted to talk to you about was obviously there’s been a lot of talk in the past five or six weeks about responsive design, because of the whole conversation that occurred regarding responsive images. This is something that has been ongoing, because it’s one of the building blocks of responsive design back when Ethan first proposed it, the idea that you’d have fluid images. Then when people got to thinking about bandwidth, we started looking at other ways about being smarter about it, and using JavaScript to load images and coming up with all these techniques. I think the long view is always to have something in spec. In the past few weeks there has been some movement on that front, although not to everyone’s satisfaction. You had a really good breakdown of the chronology of what the events were. For anyone listening who didn’t follow that closely, can you explain a bit what the current situation is and how we got here?
Jeremy: OK. 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 not because people were taking existing desktop sites and making them responsive. They were adding styles that canceled out layout styles, linearized 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 linearized 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 OK, is this a large screen device? As you said, solving the problem right now involves hacks, essentially. Using JavaScript, using server-side detection maybe. Using cookies, maybe a cookie could be set in JavaScript and then read on the server. Then depending on the contents of the cookie, you could serve smaller or big images.
Lots of very, very clever solutions. That’s the situation now. Generally when you see developers doing something in JavaScript, hacking around the problem, that’s a good sign that that’s something that needs to be in the standard. It needs to move from being programmatic to being declarative. Either it needs to move from hacking around the JavaScript into CSS, or into HTML. You can see examples of this in the past, with things like in HTML5, a lot of the input types are stuff we used to have to hack around with in JavaScript. Having a date picker, having placeholder text in an input field. All of these things we could do in the past. We had to hack around in JavaScript. But because so many people were doing it in JavaScript, it was a sign that hey, this needs to be declarative in the specification and standardized across browsers. You saw it move from JavaScript into HTML. It’s the same thing here, where we’re solving these problems now with JavaScript, and it’s a lot tougher than it originally appeared. It really needs to move into the declarative mark-up. It needs to be standard, and it needs to work the same way across browsers. One of the issues that happened with a lot of these hacks that are really, really smart, really clever, is that the browsers started to optimize how they would download web pages by looking ahead into the source to see if there were any image elements, and pre-downloading what was in the source attribute. If you were then doing some clever JavaScript to swap out what was in the source attribute, it’s too late. The browsers have already started to download the initial image.
Louis: Right.
Jeremy: You can’t blame the browsers for doing this, because it’s actually a really smart thing to do in terms of speed and performance, which is what browsers care about. It wasn’t enough to say, “Stop doing that, you’re ruining our clever scripts.” It was always this feeling that we’re trying to solve this problem in JavaScript. We need to move it into a declarative standard like HTML. I think in the long term though, I think it does take a really big view. You’ve got something happening in the hacks, in JavaScript. It moves into being declarative or HTML or CSS. Maybe long term it could actually move into the format itself. In that it’s an image that needs to be responsive. The actual image format. Some people have been talking about that as well. You have one image that would serve it self up in different file sizes depending on the capabilities of the browsers, content negotiation.
Right now we’re in that moment of wanting to move a popular pattern in JavaScript into the declarative standard of HTML. A lot of very smart people have been working on this, a lot of people who’ve been coming up with these JavaScript hacks. People like Scott Jehl, Matt Wilcox, all these people. They went to the WHATWG and they’re not used to spending much time on those mailing lists, start talking about this stuff. The default attitude at WHATWG , generally from Hixie is, it’s not a problem. You have to prove it’s a problem to me. OK. 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, but 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 OK, 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 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 favoritism 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 favored. 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 favoritism between solutions going on.
Louis: Yeah.
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 realize 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 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 solution that Ted proposed is very good for that use case. It’s less for the art direct use case, whereas the picture solution that the responsive images group came up with, is very good for the art director 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 set of standards they’ve 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. Hixie does go throwing any old stuff into the spec in WHATWG , that doesn’t mean it’s going to happen in 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 organized.
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 standardize 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 standardized. 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.
Louis: Yeah.
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 sites, 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 mean time, 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, Matt 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 Clear Left, 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.
Jeremy: Great.
Louis: Thanks again Jeremy and have a good day.
Jeremy: You too.
Louis: Bye. And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict.
The show this week was produced by Karn Broad, and I’m Louis Simoneau, thanks for listening and bye for now.
Audio Transcription by Speechpad.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Karn Broad
