RWD Podcast Episode #15 : Jeremy Keith

Justin Avery: Hey everyone and welcome to another Responsive Design Weekly podcast. This is episode ahh, 15. My name’s Justin Avery. I’m the curator of Responsive Design Weekly newsletter and your host for this show.

Ahh, this week we have an unofficial sponsor which is dConstruct. Ahh, dConstruct is an annual conference held in Brighton in the UK and it runs a different theme each year.

Ahh, two years ago it was Playing With the Future. Last year it was Communicating With Machines and this year it is Living With A Network.

Ahh, I’ve been to the conference twice before. Umm, and it’s not like any conference I’ve been to but it is awesome.

Ahh, the first time I went along, I remember walking out ahh, and meeting my partner Laura and she said “How was the conference?” And I remember saying to her, “Look, it wasn’t that great. It was OK.” Then spent the next two hours talking about everything that I learned about that, within the conference.

It just sort of recharges your creative batteries, I think ahh, and it lets you tackle the web world or whatever your job is ahh, the next day with yeah, recharged batteries.

Ahh, this year ahh, it takes place in Brighton in the UK on Friday the 5th of September and this week we’re super lucky to be joined with a guest instead of hearing myself, and it is the organizer of that event, Mr. Jeremy Keith. Welcome, Jeremy.

Jeremy Keith: Thank you, Justin.

Justin Avery: Umm, for those that may not have heard of you ahh, perhaps you could introduce yourself, give a bit of background about how you got into the industry, where you wound up to being today.

Jeremy Keith: Umm, yeah, so, so I guess I’m, I, I don’t, I never know what to call myself in terms of you know, what my job is. Umm, but I, I guess I’m mostly on the front end development side of things. You know?

The, bit of a jack of all trades, but more on front end development and, for many years I was a freelancer, sort of late ’90’s into early 2000’s [02:00]. Ahh, and then 2005 ahh, myself, my friends Andy Berg and Richard Rutter formed a company called Clearleft ahh, and that’s where I’ve been ever since.

So we’re coming up on almost, almost 10 years of Clearleft and, yeah, I guess I’m kind of overseeing front end development stuff at Clearleft. And it’s grown from the three of us originally to, to 19 people now.

Justin Avery: Oh wow.

Jeremy Keith: Its kind of nuts. Yeah. Yeah.

Justin Avery: Congratulations.

Jeremy Keith: Oh, it’s kind of scary actually, that much growth. But, yeah, it’s good. And, we make websites and ahh, I enjoy getting, getting stuck in on, on, front end development every now and then.

As I do less and less of it it seems these days, but ahh, certainly still you know, keeping up to speed with ahh, with where things are at. And, very much ahh, Responsive by default is, is the way of things at Clearleft.

It’s Responsive all the way with us.

Justin Avery: [inaudible 02:58]. Umm, you talked about trying to keep up, so you’re not, so much hands on these days but keeping up is a big problem I think a lot of people in the industry face. How do you keep abreast of the rapid changing industry?

And I, I think the, your role within there is kind of like the technical leads at Clearleft, at Clearleft, so how do you keep ahead of the curve and recommend where you should be going as a company, for the technical implementations and also for your clients?

Jeremy Keith: Well I, I used to feel very guilty about the amount of time I would spend, spend, as I would describe it, goofing off on the internet. All right? I, I probably should be doing some real work, but here I am you know, reading articles, clicking through links to interesting stuff.

And, and feeling bad about it because I was reading when I should be working. And I’ve come to realize actually that’s not ahh, a waste of time. In fact it can be [04:00], it can be time very, very well spent.

You know, sometimes I’ll spend an afternoon just you know, reading things on the internet and then the next week there’ll be a meeting about something, some project’s kicking off and some particular technology or technique will, will come up and I’ll go, “Oh, you know I was just reading an interesting article about that.”

And I can bring up a link to it because I’d have linked to it from my own website, for example.

So, for me, I have enough time to spend ahh, keeping up to, to date with stuff and looking into stuff. It’s also important you know, to try stuff out, to experiment with stuff, particularly the more technical stuff.

You can read about code, but until you’ve actually tried it, it’s not quite the same.

Umm, and that’s actually where personal projects come in really handy because you won’t always get the chance to try out the latest and greatest techniques on a client project for various reasons.

There might be constraints or you know, budgetary or time constraints. You just have to like, get it out the door,, but on personal projects you get to really play around with stuff.

So, I have a few different personal projects on the go and I’ve got my own website and that makes for a good kind of playground to experiment with stuff.

Umm, so just this weekend, so there’s this one website I run which is, sort of a community website around Irish traditional music and on the weekend I was playing around with ahh offline stuff, like offline storage and, and app.Cash and ahh,,, local storage and stuff like that.

So,, a bit of playing around with technologies to you know, keep my hand in and a lot of, of just reading, reading stuff. Reading blog posts and reading articles that, that people are publishing.

Justin Avery: And writing a lot of them as well. Like I know I, I, I plagiarized a bit of yours, not plagiarized. I feature some of your stuff in the newsletter, often.

Jeremy Keith: Yeah, well, you know a lot of times the easy, the best way to try and, get your head around something is to, is to try and explain it.

Umm, if you know anyone who has ever written a book about, [inaudible 05:59] about technology or something that [06:00] they’ll say that. That to actually really learn a technology, try and teach it because you will have to really understand it in order to get your, you know, in order to be able to explain it to somebody else.

And, and writing is ahh, a you know, even though it’s just on your own personal website is, is a good way of doing that, to marshal your thoughts and get them in order.

And I kind of think well, why do I find this interesting? And once you have to write it down, you have to sort of explain your self and put it into words, like I’ve, I’ve, I’ve wanted to write about this thing and then you have to explain why.

Why, why do you want to write about this? And then you, you find out what it is about it that, that, that’s interesting and ahh, yeah, writing, writing about stuff is, is really important.

And I think it’s important that people realize that when you write about something, you don’t have to be an expert in it. I mean I’m certainly not an expert in, in anything, but that doesn’t stop me writing about things.

Umm, and you kind of have to fight that voice in your head that says ahh, oh, no one’s going to want to read this. Or everybody knows this already. Right?

And just write about it anyway, because if there’s one person out there who hasn’t come across the technique you’re talking about ahh, it’s usually valuable for you to pond it out to them and say hey, I just found out this new thing. Isn’t this cool?

Justin Avery: I suppose you also offer, regardless of how many times it’s been written, a different perspective because everyone’s individual and everyone has their own opinions of things, so it’s always good to see someone else’s take on a, on a similar, on a similar topic.

Jeremy Keith: Yeah, and, and actually I, I, I’ve come to realize sometimes when you really an expert at something, you might not be in the best position to explain that something, because you take so much for granted, you’ve internalized so much …

Justin Avery: You’re in too deep.

Jeremy Keith: Yeah exactly. You actually find it hard to step back and explain the basics ahh, whereas when you’ve just discovered something ahh, you’re kind of in the perfect place to say, “Oh, check this out. This is really cool and this is why it’s really cool. And this is what I just discovered.”

And an expert might read what you’ve written and say, “Well, that seems really obvious.” But of course to other people in the same [08:00] position as you, it’s not obvious at al and, and your perspective is hugely valuable.

Justin Avery: Yeah, I find, I’ve been playing around with Grunt a little bit recently and I’ve found, writing a tutorial on how to set Grunt up, while I’m setting it up means that I won’t skip over steps.

Jeremy Keith: Yeah exactly. That’s the perfect time to write about something, so you don’t, you don’t become an expert and then write about it. You write about it as you’re learning and that’s a more valuable perspective to have.

Justin Avery: Mmm. So, with, we’ll go back to that offline storage stuff because that’s actually quite interesting, in terms of what I wanted to talk about today. More advanced Responsive Design techniques. And while some techniques may not be specifically responsive,, they’re all techniques about delivering a better way of experience.

But some of the other side projects ahh, you’ve got around, well, I don’t know if they are side projects. Like ahh, the Responsive [inaudible 08:57] for instance.

Jeremy Keith: Yeah, that’s kind of, that’s kind of a side project of Clearleft’s I would guess. I mean you know, I was, I was putting the whole thing together and, and, and putting together the lineup, it was very much a Clearleft production.

Like, like dConstruct but on a much simpler scale, you know. Smaller scale, very ahh, down and dirty you know. Not a slick production at all, but yeah.

Justin Avery: (Laughs). You lie. Well for those that didn’t go, it was a slick production.

Jeremy Keith: (Laughs).

Justin Avery: The down and dirty was the ahh, there there weren’t lanyards we had stickers we were allowed to be there.

Umm, but it was, it was a really good conference. I, I was sad to miss ahh,t he conference last year. I was still stuck in Australia. Umm, but I wonder how, how did you come up with the, so, like I said we’re looking at what some advanced techniques are in Responsive Design for some of the listens and readers.

How did you come about for the ahh, the talks, ahh for, for both years? And, and did you see a change in perspective and focus for, for this year as opposed to last year?

Jeremy Keith: Yeah, well so for the first year it was very much like [10:00] “Yeah, we should, let’s, let’s throw a day. A one off sort of thing about Responsive Design.”

Umm, the kind of constraint that was introduced was we want to keep it as cheap as possible so therefore, one of the constraints was we’ll only have speakers from within the UK so that there won’t be the travel costs of flying in people and putting people up and stuff.

Ahh, and I thought that would make it really hard to put the conference on. Actually it was really easy because there’s so many people in the UK who are able to get that we’re really, really smart and really good.

But there definitely was a kind of theme to the first year which was right from the start, Sarah Parmenter came out and said, “Look, we’re all just figuring this stuff out.” And you could almost here this (sigh).

Justin Avery: (Laughs).

Jeremy Keith: … sign of relief from the audience, like it’s not just me, you know? OK, I’m not alone. Everyone feels freaked out by all this change and ahh, it’s OK. It was kind of like a self help group. It’s like, it’s all right, you know, nobody’s figured this stuff out. We’re all figuring it out together and that’s fine.

Umm, then this year, was more like, well OK, now, it’s not about you know, getting used to the idea of Responsive Design. We’ve kind of I think, accepted it and it’s kind of the new normal. It’s more about OK, the nitty gritty. Well how do we do, how do we do work together? How do we change our processes? How do we do visual design and development in a way that makes sense in a responsive world?

So more, more nitty gritty stuff. Umm, I mean to be honest, I wasn’t, I wasn’t intending to do a second response day out at all. It, the first one was intended as a once off. And ahh, everyone had a really good time. They kept saying, “Oh, you know, will there be one next year?”

I was like, “Oh, probably not.” You know? And I was thinking well, maybe we’ll do some other event, but it wouldn’t be responsive. It would be like something else day out, you know. I don’t know. Web Performance Day Out or something like that.

But then I was doing a lot of, I guess you’d call it consulting ahh, going into companies, talk about responsive design workshop with them. You know, spend a day with developers and designers, workshopping in responsive design, and I realized that there were a lot of [12:00] people and a lot of companies who are only just beginning to get Responsive Design and they really could have done with being at that first year and really could do with going to a conference entirely about Responsive Design.

I kind of changed my mind on it and I thought, you know, maybe, maybe there is room for a second responsive day out and that’s when I decided to do it.

And, and then the subject matter, I mean, the, the way that they work, I mean you went here, you said it was kind of blocks of talks and I wanted the blocks to be related thematically, so I thought well, I definitely wanted one on process you know, workflow and stuff like that.

So then I got people like Steven Hay talking about that. And then I, I thought well we’ll have a technical bunch of talks. You know, get really nitty gritty with some technology, so I’ll have people like Rachel Andrew talking about you know, CSS Layout and stuff, but then also have a section on more, more bigger picture stuff.

You know, so it’s not just about the implementation details, but also about you know, why we’re doing it and big picture stuff.

Umm and then the big change this year was having Ethan as the keynote speaker and he really tied it together fantastically. Umm, I think it was a really fun day out.

And it still, it still had a bit of that, support group feel. You know, like we’re all going to get together in this one place and we’re all, we’re all in this together. You know, we’re all figuring this stuff out.

Ahh, but it was, it was a bit more mature I think this year. There was a bit more of a feeling of like OK, Responsive Design is, is, we’re, we’re sold on it. You know, we don’t have to convince anyone any more. Now it’s down to the nitty gritty of how do we do this stuff.

Justin Avery: So with the, with the nitty gritty stuff, is there anything that you’ve seen as in your reading and in your, your consulting that people are starting to focus on these days?

Like they’re taking the next step beyond the let’s make the goods fluid, let’s make our media fluid, ahh, and let’s put in media queries to, to resize everything in a particular viewpoint?

Like what are people that you’re talking [14:00] to these days sort of starting to focus more upon?

Jeremy Keith: Umm, well very happily I’m starting to see people focus on performance. Which, which is great I mean it’s kind of long overdue. And I guess it makes sense that we first of all had to get our heads around the, the layout stuff and all of that and then we could progress to figuring out the performance stuff.

Umm, but there’s really been an emphasis on that in the past year or two which is, which is really good to see.

I mean there’s always, we’ve always had some lone voices in the wilderness crying out that performance is really important and …

Justin Avery: (Laughs).

Jeremy Keith: But then you look at the data for how big the average website is and it’s getting bigger every year and it still is, which  is really depressing, but there, there’s starting to be a bit more of a, of a culture of performance.

Umm, you know, it’s interesting because you know, over the years of front end development ahh, there’s been phases of, of ahh, almost like what’s the first thing you do when you visit a new website?

Like, somebody links to a new website, what do you do? And I remember back in the days of , switching to web standards you know, instead of tables for layout to using CSS and stuff. The first thing you do would be ahh, you’d view source and see whether it was tables or, or you know …

Justin Avery: (Laughs).

Jeremy Keith: … [inaudible 15:09] markup and you’d validate it, right? You’d have a bookmark to validate this. And you would judge them based on you know, whether it was valid.

Justin Avery: (Laughs).

Jeremy Keith: It’s pretty ridiculous. Ahh, and, and that evolved over time and then when responsive design hit, what’s the first thing you did when you visited a website? You grabbed, you grabbed the browser windows and you started making [crosstalk 15:26].

Justin Avery: Change the view port.

Jeremy Keith: Exactly, change the view port. So for a while that was kind of the first thing people did.

And I’m starting to see now that actually what I do when somebody says oh, this is a beautiful website. Check out this great website, is I’ll fire up the ahh, you know the web inspector to have the, the resources tab open. See, let’s see how big is this in terms of file size, in terms of weight and my opinion of that website will you know, correspond fairly heavily to how weighty it.

So it’s like, Oh it is beautiful and it’s lightweight, then I think it’s, it’s genuinely [16:00] beautiful. And it’s kind of a …

Justin Avery: Extra beautiful.

Jeremy Keith: Exactly and in a kind of under the skin kind of way. But you know, you do often come across the sites that are beautiful on the outside but actually they’re only beautiful because I can, I’ve got a fast connection and I can download them that way.

So it’s good, it’s kind of a nice litmus test to see how you, what’s the first thing you do when you visit a website? You know what I mean?

You know it’s changing and for me it’s, I think the performance thing over the last year or two has become maybe the biggest factor in how I judge, I guess, I guess quality. Right? The quality of a site.

Justin Avery: It’s funny, you point out going to the, going to the network tab or the resource tab …

Jeremy Keith: Mmm.

Justin Avery: … and see the, the loading today. A friend of mine, we’ll call him a friend of a friend, has re-launched their, their company’s website or their organizations website and asked me to have a look. And I, I did the same thing, I …

Jeremy Keith: Mm-hmm. (Affirmative).

Justin Avery: … I didn’t even, I knew they would have built it responsively and I didn’t drag it, so I just opened up ahh, Crow Canary and fired up the [inaudible 17:02] and you’ve got, you can throttle now within there.

Jeremy Keith: Yeah.

Justin Avery: So you can get the 3D connection which is great. Umm, so I set it to a, a, a mobile ahh, a mobile emulator and then throttled it and it took, it was a six point, 6.8 megabyte site ahh, which took a minute, ahh, 1.3 minutes for a full load.

Jeremy Keith: Yeah.

Justin Avery: And I just, I was, I was embarrassed for them. I didn’t even worry about looking whether or not it was ahh, responsive or not. But when you, when you see things like that in terms of looking at, what would you consider kind of the low hanging fruit for performance like, where would you start with the …?

Jeremy Keith: Well, this is kind of the nice thing about performance because yeah, we can sort of go oh, looking at that, ahh that’s pretty willy. There usually are some very low hanging fruit. Like, straight away just checking is stuff being sent Gzipped, down the wireless? You know. CSS and Travel Script [18:00] and HTML is Gzipping enabled?

Ahh, and that’s such an easy win. Right? Because that’s just something you can figure on the server, or, or one line of  in your HD access file and boom, you’ve got huge increase.

Umm, after that it, it, well, I was going ot say images is the next thing, but ahh, often I’ll look at a site and I’ll see that in the head there’ll be like blocking script elements and there’ll be multiple link elements to multiple style sheets, you know, depending on the CMS that might be in use.

It’s another are where OK, you could, you could [inaudible 18:34] stuff and oyu move your script elements to the bottom, relatively simple win. Certainly the moving the script elements to the bottom is, is a very quick win.

Ahh, once again into images, it’s maybe not simple, although usually it is a matter of just thinking about this stuff and having a step in your workflow.

Like oh, I’ve made the image. Don’t forget you know, run it through ahh, ImageOptim or , or whatever tool you happen to have or just spend an extra minute you know, playing with that JPG to see how far down you can get it.

Umm, they’re mostly pretty easy wins actually ahh, with performance. I mean that won’t make it you know, super, super performant but you can, you can have an order of magnitude difference with some, with some pretty low hanging fruit usually.

Justin Avery: Yeah, those sort of things because what’s, it is, the 20% rule where they say if you can …

Jeremy Keith: Mmm.

Justin Avery: … speed, speed the site up by 20%.

Jeremy Keith: It’s noticeable, yeah.

Justin Avery: Yeah.

Jeremy Keith: Yeah.

Justin Avery: So yeah …

Jeremy Keith: Yeah then that would certainly lead to a noticeable change. Umm, I mean there’s always room for improvement, right? You can always do better.

But ahh, it’s kind of one of the nice things about performance being kind of the new, the new thing that people are paying attention to is that you get ahh, you know a genuine feeling of advancement like oh, you know, a few months ago my site was like this and I just made some simple changes and now it’s so much more performant.

It’s a good feeling that, that you have that kind of feedback. That, that there’s a genuine difference that you can make. And it is kind of different to like [20:00] oh you know, I, I re-factored my CSS or I you know, combed through my HTML and changed to using the latest techniques or the latest markups. Like it, is anyone actually going to notice you know?

It’s good that, I think it’s good to do all that stuff just for yourself and for the feeling of quality, it’s good. But it’s really nice for performance, there’s a genuine measurable effect that, that the end user is going to feel.

Justin Avery: So it still kind of a rare performance and I know you used to talk a lot about, progressive enhancement ahh, as well to sort of improve things …

Jeremy Keith: Mm-hmm. (Affirmative).

Justin Avery: … in sort of layers. Ahh, just around the performance side of things the, the low hanging fruit and you’re talking about working on your, your side project, music site …

Jeremy Keith: Mm-hmm. (Affirmative).

Justin Avery: And you were talking about getting into Offline, Offline First or offline storage. Umm, are there some more advanced techniques around were you trying to improve the performance or the, or the experience on the site?

Jeremy Keith: Umm, so, so Offline First is an interesting concept and I had got into a good discussion with Alex from Hoodie about this because ahh, I’m a big fan of making things offline, but I’m actually ahh, a fan of as you know, Progressive Enhancement, so I’m really interested in Offline as an enhancement as opposed to Offline First.

Because the issue with Offline First is that all the technologies that you would use to, to you know, deliver the Offline experience, things like local storage and all these JavaScript API’s. So if you’re going to have this, if you’re doing Offline First, you have to kind of begin with the assumption that JavaScript’s available.

Justin Avery: Mmm.

Jeremy Keith: And as a [inaudible 21:36] Progressive Enhancement guy, I’m not uncomfortable with that. So I’m really interested well how can I have my cake and eat it too? How can I have a site that can be offline, but it doesn’t rely on, for example a particular JavaScript API as a potential single point of failure?

So that’s what I was playing, it was like you know, how can I, walk the walk as well as talking the talk [22:00] here? I want to, I want to implement something that uses these offline technologies but do it in a Progressively Enhanced way.

Umm, so obviously basically if, if you know, you’re browsers not up to speed, then frankly you do need ahh, an internet ahh, connection so that you can get this, get at the content.

Umm, but I made it in such a way that OK, if you happen to have you know app.Cash and local storage ahh, then as a bonus you know, save this bookmark and come back to it when you’re in a tunnel or some other situation where you don’t have a network and you can still access this stuff.

So that’s what, well pretty much any technique that come sup, I always try and kind of see it through the lens of Progressive Enhancement. It’s like OK, how can I use this, this new technique in a Progressively Enhanced way?

Umm, particularly because I think there’s misconceptions with Progressive Enhancement, that it means, forgoing technology. It means like, oh, you can’t use technology [inaudible 22:56], you can’t use the latest and greatest ahh, API that just landed in, in you know, Chrome Nightly or something.

Where for me it’s the exact opposite. It’s precisely because you’re dealing with things, dealing with things in layers that you can start implementing stuff even if it’s only in one browser or zero browsers.

And know that it’s going to work more and more as time goes on. Umm but you’re not betting the farm on that particular technology, right? You’re not saying you have to have ahh, local storage or any of this stuff for, to access anything, but more like if you happen to have those API’s, great.

Umm, so I’m, you know, all of these things that are you know, JavaScript API’s, local storage or, or Geolocation or ahh, you know, all of these great things that are, that are in the browsers now, I’m really interested in trying all of them and using them., but always through that lens of it being an enhancement.

Because usually when you look at what a site or app is delivering, ahh and you get down to the basics of what the core task is, that’s usually something you can just deliver in plain old HTML and a lot of the complexity would actually [24:00] be on the server, right?

So, whether that’s, I need to buy something and check out with my shopping cart and pay for it or I need to you know, publish something or I need to share something, those, the basic tasks we can build to begin with and then once we’ve done that it’s like OK, now you’re sort of rubbing the hands.

OK, now what great new technologies can I experiment with and you can experiment with those great new technologies with this kind of safety net, because now you’re secure in the knowledge that well if this doesn’t work, if the browser doesn’t support it or something goes wrong with the code I’ve written?

That’s OK, it’ll fall back to the you know, boring old full page refreshes and the server doing all the work.

So, yeah progressive enhancement is sort of always my lens for any, technology. And, and the Offline stuff is, is, is a good example of that. I mean something like app.Cash, you know, for all its problems and it does have problems, ahh, for certain kinds of sites, certain kind of contents, it can be a great enhancement.

It’s like, hey, you, if you have app.Cash support, great. You’re going to be able to access this when you’re ahh, offline. If not, not. You know? It’s an enhancement.

Justin Avery: Yeah, it’s a nice little addition there.

Jeremy Keith: Yeah.

Justin Avery: So it must be, because we see there’s a ton of sites that don’t sort of take this approach and you, you go to load something and you don’t have JavaScript available or it’s just slow connection and there’s a, there’s a third party blocking script and you ahh, you’re stuck with a …

Jeremy Keith: Mmm.

Justin Avery: … white page. Umm, obviously it sounds from the sound of it,, [inaudible 25:33] that ahh, at Clearleft you would enforce this way or this approach with building websites for your Clearleft clients.

Umm, what, what, why do you think not everyone is building things in this way? So starting from the original HTML links forms posting and then layering upon layers of Ajax to do it without page loading? Like, are there reasons? Is it a technical? Is it time-based? [26:00] Is it budget-based?

Jeremy Keith: There are definitely reasons. Umm, and some of them are good reasons. Umm, I’ve, I’ve kind of been analyzing this myself trying to figure out, because to me, the thing about the Progressive Enhancement approach is that it’s ahh, it makes sense in an engineering perspective.

It’s like well, I don’t want to have a single point of failure, right? So if I’m assuming this particular bit of JavaScript must be available to everyone or else none of the contents are accessible. None of the tasks are doable.

That, that makes me really uncomfortable. I don’t like that feeling just from an engineering perspective, it’s like ahh, all my eggs are now in this one basket.

Umm, so it’s nothing to do with you know, the ethical or moral implications of providing universal access, though, you know that’s important to me.

Justin Avery: That’s still a good thing.

Jeremy Keith: Yeah, which is a very good thing, but just from an engineering perspective it’s like oh, why would you have a single point of failure? It doesn’t make sense.

But I’ve always been coming at things with the point of view of the web, right? I, I didn’t come from some other background like Computer Science and then started making websites. It was always, for me it was the web, right from the start.

This a very sort of web-centric way of seeing things. This progressive enhancement, sort of layered approach.

But if you’re coming at things from ahh, a software development background, and particularly these days where the web is now so powerful that ahh, it, it’s kind of held up in the same way as you’d hold up ahh, another platform.

We talk about the web platform right? Not a term I particularly like, to be honest, but I understand it because you can say, you know it’s a legitimate question now, that someone’s going to build you know, an app and they can say hmm, will I build it an Android or IOS or the web?

Justin Avery: Yeah.

Jeremy Keith: And that’s, and you know, even a few years ago that was a, that question would have been ridiculous. That, that’s such a ridiculous comparison, but now it’s actually that’s not a crazy thing to say. It’s like, yeah, you could, you could do it using web technologies.

Now if you’re coming from the point of view it’s a software environment like any other, then you’re going to treat web development you know, [28:00] building on the web, like you would any other, software development.

And in any other software development area, you have you know, technologies that are available to you and as long as the user has those technologies, everything’s great, and if they don’t well, they don’t get your app.

So if you’re building an IOS, if someone is running IOS they get what you’re building. If someone is running Windows Phone, obviously they can’t get what you’re building because you can’t install an IOS app on a Windows Phone, right?

Justin Avery: Mm-hmm. (Affirmative).

Jeremy Keith: But the web’s so different fundamentally to that because you know, I could come at you with a text only browser and still potentially be able to accomplish the core task of your app. Or I could come at you with the latest Chrome Nightly and be able to accomplish the task with all the bells and whistles.

And the great thing about the web is that you don’t have to choose you know, will I support this particular platform or that platform or these browsers or those browsers? You can support all of them to varying degrees. Right? By supporting the technologies, right?

Umm, so it depends on your mindset I think and if you are coming from this mindset of traditional software development where you have, it’s like you pick up a, back when software used to be sold in shops, you’d pick up a package …

Justin Avery: (Laughs).

Jeremy Keith: … and it would have system requirements, right? And …

Justin Avery: Must be a four eight six Pentium …

Jeremy Keith: Right, exactly. And so if that’s the mindset you’re coming at then it makes sense that you would not think in a Progressive Enhancement way, you’d think of it in terms of well, here’s the minimum requirements and as long as you’ve got these ahh, we’re going to get on fine together, right?

Umm, but then you’re not really making use of the web, you’re not making use of that universality, the fact that it really doesn’t matter what you have, you can, you should be able to accomplish the task to a greater or lesser degree, right?

I mean it’s not going to, the experience will not be completely different depending on what device or browser you’re using. But that’s such a strength of the web.

So for me I think a lot of reason why people don’t use Progressive Enhancement by default would be that mindset. And, and to be clear, there’s like, the end result could be the same. Like you could be looking at an app that was built in Progressive Enhancement and be looking at an app that wasn’t [30:00] and to the you know, to 90% of end users they would appear indistinguishable.

The difference is what happens in the end cases.

Justin Avery: Yeah.

Jeremy Keith: Right? The difference is what happens when something goes wrong that you didn’t foresee.

Umm, so it’s, it’s really just a matter of engineering approach and so the reason why maybe that approach isn’t so common is that ahh, the background of the, of the program or the background of the developer is not necessarily from that sort of web native kind of way. It’s from this idea that the web is another software environment like any other.

Umm, so there’s that and there can also be technical restrictions. So, I mean at Clearleft you know, the other front end developers very much on board with, with progressive enhancement as well. Umm, that’s, that’s why they work at Clearleft? (Laughs).

Umm, but I mean on a recent project, there’s a project right now ahh, that’s probably going to be built in Angular. I’m not working on it myself.

And Angular very much, I mean forget it. Progressive enhancement and Angular just, just don’t go together. It’s pretty much impossible.

Umm, and the reason is entirely technical. It’s because there’s, the client has this terrible SMS and trying to wrangle the CMS to output the mark up that we would want would just be impossible. But we can wrangle the CMS to output one script element.

Justin Avery: Ahh. OK.

Jeremy Keith: So now we can, we can take everything that we would have done on the service side, which is where we actually want the complexity to live and we can do it all on the client, but the price we pay is that now you’ve got a set of systems requirements which is, you know, must be able to run Angular.

Umm, so I mean and I’m not, I’m not saying that’s a good reason for doing it. I’m saying there are, there can be reasons like that. There can be technical constraints why people aren’t using progressive enhancement.

Justin Avery: And that’s a, that’s a fair enough ahh, raise. I, I would probably and I’m sure you guys did suggest that maybe the CMS there on probably could be upgraded or perhaps changed?

Jeremy Keith: Yeah, but this is the interesting thing when you find out, well, you always think deeper into why you know, you’re on a project and you, it isn’t being done ideally. You know, the ideal way to do it would be this, [32:00] but we’re not doing it the ideal way. We’re doing it some compromised way.

And you think why are you doing that. Well, we’re doing it because of this CMS. OK, why have they got that CMS? Well, because somebody, you know, made a decision 10 years ago that that was the right CMS and they spent a lot of money on it and so it’s, it’s, it’s not ahh, an option to, to you know upgrade it.

Somebody will lose their job if ahh, if the CMS goes. Right? Something like that.

And you keep digging, keep asking why? Why? Why? A lot of the time you know, if you dig deep enough, it comes down to very, fundamental organizational issues, like the reason why we can’t do this and the ideal way is because this company is fundamentally you know, got issues.

Justin Avery: Full order they call  it.

Jeremy Keith: Right, at a very deep level. And that’s manifesting itself in the way we’re building their latest website, but those are just symptoms of much, much deeper things.

Justin Avery: Mmm. I, it reminds, I just, I have a followup question about this, but I worked for a ahh, a utility in Australia, as a contractor at a particular time and they were having problems. We were going through it and IE8 refresh, this is how long ago it was. But yeah, they were upgrading everything from IE7 to IE8.

And the internet was breaking. They said, “Look, it’s been designed for Ie6 and it, it’s just breaking when we upgrade to IE8, so you just have to fix it so it works in IE8.”

And I said, “Well, why don’t we just take a step back. We can restructure this, rebuild it, put better code in there and then it will work across Chrome and Firefall. We don’t just have to make it work in this new IE8.”

Now, just do that. Umm, that’s all we need and then 12 months later they were moving up to the next version which, which they were stuck again. Umm, and there like little mistakes which I wish I had of sort of stood my ground a little bit more with them and just said no, I won’t [34:00] do this. Like I will do it right. Umm, it will cost you more, but it will be better for you in the long run.

I was wondering, do you have any I wish I had of done this better?

Jeremy Keith: Well, there, there, there was definitely a situation like that we had with a client. Umm, this was a good few years back now when Responsive Design was beginning to gather momentum and Ethan definitely you know, written the article.

I, I don’t know if the book was out at this point, but you know, very early on we were into Responsive Design.

We started doing it at every opportunity and doing it by default, especially on a new project where you know, it felt like there wasn’t any cost to doing it on a new project. It might be very tricky to retrofit a site to be Responsive, but if you were starting something fresh, makes total sense.

So we were dealing with a big client in the UK. Ahh, big content site and they were trying to figure out their mobile strategy. And we were saying we really pitching it. We’re like, “Look, let’s do responsive and it’ll work on IOS and it’ll work on Android and work on all these ones.”

And, and it honestly you know, it’ll be the best thing to do. And they were like, “Hmm, no. Umm, design us an IOS app.” We’re like honestly you should go with Responsive because this really did not need to be an, an native app.

Justin Avery: It was a content site.

Jeremy Keith: It was con, very much content site. And it was kind of political. This thing was like the boss got a new iPad for Christmas and so they need to have a native app. Sort of on that level of …

Justin Avery: Mmm.

Jeremy Keith: … of thinking. So ahh, we did what they said, we designed a you know, an IOS app and a couple months later they came back and they’re like, “OK, well we’d like you to design a Windows Phone app.”

We’re like, “Are you sure you don’t want a Responsive?” “Nope. Just, just design us an …” And so I think, and we ended up doing yeah, IOS. I think we designed a Windows Phone. Maybe we designed Android. I can’t remember.

And it was them maybe a year or two later came to us and were like, “Can you design us a Responsive website?” And we’re like, [36:00] “We, we said it to you …

Justin Avery: (Laughs).

Jeremy Keith: … you know, over a year ago.” And of course the reason was that they realized it just didn’t scale to keep trying to produce individual apps for each individual.

Justin Avery: Mm-hmm. (Affirmative).

Jeremy Keith: Not for the kind of thing they were producing which was, you know, it was content. I mean all these native apps were just wrappers to display you know, web content. It made total sense for it to be Responsive site, but that seemed like such a big commitment to them.

But what they realized over time was actually the bigger commitment was ahh, having all these native apps that they have to update and every time there was a new version of IOS, they needed to update the IOS app.

Justin Avery: It cost a fortune.

Jeremy Keith: And it cost a fortune, right, so they were seeing actually in the long term, it really didn’t make sense for them to have all these, these siloed ahh, views of their content and having the Responsive site made much more sense.

So finally we did get to do the Responsive site which was good, but yeah, it was frustrating. Umm, you know, when we’d been saying all along, really a Responsive site would be the way to go.

Justin Avery: It can be, it can be quite frustrating. I was surprised you didn’t ahh, just build a Responsive site and then put that Responsive site in their wrapper for the IRS.

Jeremy Keith: (Laughs).

Justin Avery: Then into the Windows and then when they came to you just went, “Of course we can do one for you. Here you go.”

Jeremy Keith: I, I have built Responsive stuff sort of by stealth in the past.

Justin Avery: (Laughs).

Jeremy Keith: You know, the Responsive would have come up in a meeting and they’d be very nervous, this was years ago obviously, not recently, but you know, they’d be nervous. They’d go, “Oh, don’t know about that. No, we don’t want to try that Responsive stuff.” 

And we’d, we would, we would say OK, OK, fine. And then we’d do it Responsively anyway because basically …

Justin Avery: (Laughs). Just don’t tell them.

Jeremy Keith: Exactly, because if it’s a new project it doesn’t actually take any more time to do it Responsively. So ahh, yeah, we just do it without telling them.

Justin Avery: I was, I was called out once though. I, I suggested we had talked about doing a mobile version, like a Mdot version of the site and I suggested Responsive and talked to the … This was, it was when Responsive was brand new.

Jeremy Keith: Yeah.

Justin Avery: Umm, and I, I was encouraging them to go that way. Is aid, “Look, this will be the future. Like this is what everyone will do.”

And they had another contractor working [38:00], not from, not from where we were ahh, who convinced the ahh, the client that people preferred to, to double tap and zoom and have more control over seeing the entire page and double tapping and zooming.

And literally said to me in the meeting, this Responsive thing is just a fad. It will blow over.

Jeremy Keith: (Laughs).

Justin Avery: Which is, it could have been a fair call at the time.

Jeremy Keith: Right, OK.

Justin Avery: You hedge your bets. You lost but, yeah. It was frustrating times.

Jeremy Keith: Yeah. But that thing of doing things by stealth though is actually, that wasn’t new to the Responsive stuff because that sounds like something I’ve been doing for years.

Like, you know, one of the pillars of Responsive Design is that you have everything as fluid, right? You’re using percentages.

And for years I’ve been saying percentages is the way to go and nobody was listening. You know, it’s like me and Ethan and a handful of other people would, would build liquid websites and everyone thought we were crazy.

But in client stuff, like I mean we would get clients saying no, no we don’t want it to be liquid. We want it to be fixed with, 960 pixels or whatever.

But when it came to the actually building, ahh, I would still build it in a liquid way or my colleagues would build it in a liquid way and then we’d have one line in the CSS that said you know, with 960 pixels.

So that in the future if they came back to us saying ahh, you know, we’d like you to take our website and somehow make it liquid and make it Responsive,, you know, we could, we could rub our chin and say, “Oof, that’s going to be hard.”

Justin Avery: (Laughs).

Jeremy Keith: And actually it’s a matter of commenting out one, one line of CSS. Boom. There you go. But again, the reason why I would build it in a liquid way even if I knew that it was going to be constrained to a fixed width goes back to what I was saying about progressive enhancement is just from an engineering perspective you’re building it in a more robust way.

You’re, you’re really kind of stress testing the whole time even if you know at the end it’s only ever going to have to live at one width, the fact that you’ve, you’ve built it, to take into account, you know, wide, narrow, everything in between [40:00], it means you test your assumptions at every stage. Right?

You don’t, you don’t get complacent about the different components you’re putting together and each component then ends up being very, very robust and, and can really you know, adapt well.

Umm, so even yeah, even if I know that this, this is never actually going to be liquid, I would still build in a liquid way just from a, yeah from an engineering perspective. It just made sense.

Justin Avery: I’ve heard a few people reading case studies or ahh, of how people have gone Responsive, that that’s a nice way to, if you’re doing a, a retrofit of a site is it start off by making all of those components. Like you said, you, you still leave your wrapper at 960 or, or, or whatever it is and then you build all those components in, fluidly.

And then at the last stage, once you’re happy that’s all working, you flick the switch, make it 100% or …

Jeremy Keith: Yeah, yeah. Definitely building up the components outward makes, makes a lot of sense.

Justin Avery: So I, I we’re coming up on our time in a bit, but two, two more questions I think for you, but, with the Responsive Images, are you, one of the things I, I looked at, with Responsive Images, in the new picture element which is fantastic.

Jeremy Keith: Mm-hmm. (Affirmative).

Justin Avery: Umm, is that we’re now putting ahh, markup relating to … So I suppose we go back a step. The whole thing we used to push is separate ahh, markup, and your design. You have your markup or you separate content from design I suppose.

Umm, but now what we’re kind of, almost doing is that we’re inserting markup into the content based upon some of the design constraints.

Jeremy Keith: Yeah and that’s certainly the case of the, you know, the Art Direction Use Case as it’s called where it’s very much, rather than it being a decision of the browser as to which is the correct size or scale of image to show to serve up, it’s very much the decision of the designer which is the [42:00] ahh, the image that makes most sense at a particular size.

Umm, fundamentally a lot of the time the question is you know, is this a content image? Does it, should it be in the mark up? Or is it actually decorative? In which case it should be in CSS. And once it’s into CSS, then a lot of Responsive Image problems kind of disappear because once you’re doing it kind of you know, mobile first and, and putting in different background images and different media queries and browsers have gotten so much better dealing with that,, it’s all pretty fine.

There are a lot of images out there that are in Image Elements that I think should be in CSS. Now the reason why they might be in Image Elements is because the way the site’s architect is you kind of have this one, one [inaudible 42:44] CSS file whereas you might want a different image to illustrate ahh, a different article. And it might be thousands of articles. Now you don’t want to have a thousand different background images.

Justin Avery: [inaudible 42:54].

Jeremy Keith: Right and your, your single CSS file so you’d have to think about you know, individual CSS. Maybe that CSS is going to actually live in the head of the document for that particular document. Umm and maybe it comes back to things like content management systems needs constraints again, asking why, why, why?

But the first why to ask is you know, why is this image in an Image Element? Umm, and if it’s genuinely content, if it’s generally, you know, if it’s a photo sharing site then it’s pretty obvious you know why, why it’s in Image Element. It is the content.

But a lot of situations I’ve found is that the images are, they’re supporting the content, but they’re not necessarily the content.

Particularly on content sites on news sites where it’s practically stock photography.

Justin Avery: Mm-hmm. (Affirmative).

Jeremy Keith: You know? If, if the image that you’re spending all this time and your Responsive Images, picture element to get right is, is you know, two guys shaking hands over a board room table, ahh, you kind of have to ask, you know, is that really the content or is that actually supporting and not even doing a very good job of supporting the content.

So yeah, I think, I think you’re right that it starts [44:00] it starts to smell a little off when we’ve got these visual design things happening inside, a structural element, and it feels like the separation of concerns  has gone a bit awry. This feels like it should be happening at the presentation layer, which is traditionally been CSS.

Ahh and I think in a lot of cases it’s true that actually the image that you’ve got there maybe should be a background image on some element and not actually a content image.

Umm, you know a lot of time it comes down to like, well what’s the alt attribute for this image? And if you’re just using a blank alt attribute because it doesn’t contain any new information that isn’t repeated you know, in the, in the text content around it, then again …

Justin Avery: It should definitely be a background.

Jeremy Keith: Right, exactly, yes. So, really sort of stepping back and seeing should this be an actual IMG element or should it be ahh, background images is the first step, to a lot of this.

A lot of times you find out yeah, no it should be in CSS, but now I’ve got a different problem which is how do I architect my CSS that I don’t have you know, all these rules clogging up my single style sheet. And that’s a whole nother problem.

But it feels like then at least you’d be solving the right problem.

Justin Avery: So with the, just say there is an image and it is content within there and we start, if we start looking at, because I look at the, I love the picture element for being able to serve the right sized image based on what the browser thinks is best suited. Umm I, I think that’s great.

When you, just say we’ve got a long article, like a long news article and you’ve got several images ahh, scattered throughout. We have the technique for lazy loading where you won’t actually load the image in until someone gets further down.

Jeremy Keith: Yeah.

Justin Avery: So who, where would you sit on the fence in terms of, that’s content and it’s part of the, the article, but it’s also [46:00] say you don’t, you don’t actually include it. You might include it as a P tag or something else with a data source attribute so that it loads in as you go further down the page.

Umm …

Jeremy Keith: I’m actually, I mean, I’m a big supporter of conditional loading, although I haven’t done that much with images. Umm, but with maybe other kinds of content. It becomes even more important with things like video that could really be clogging up you know, on a small screen.

Umm, but conditional loading in general I find is a terrific technique that’s hugely valuable for Responsive Design and kind of under-utilized.

And I think again, maybe the reason why people aren’t using conditional loading is that the processes and tools that they have in place aren’t, aren’t designed for it. It’s kind of a new way of thinking because it forces you to think about, not just content and it’s binary state of either the content is on this page or it’s not.

But now you’ve got the content that must be on the page and the content that isn’t on the page and the content that could be on the page under certain circumstances which is a whole nother way of thinking about, the way you plan your sites.

Ahh, right? In thinking well, is this vital content? No, then could it be conditionally loaded? Yeah, potentially. Umm, what’s the fall back? Well, maybe a link to a completely separate URL for that, for that content.

Umm, but that way of thinking is, is quite new, right? That’s a new way of approaching information architecture really, when you think about it.

Umm, so I think that’s the reason why conditional loading is, has, hasn’t taken off as much as I kind of think it should, because I think it’s a hugely, hugely viable technique, for performance as well, right?

It’s not just, I mean performance isn’t just what’s the total file size of everything it downloaded, but it’s the perception of it. You know, how quickly does the core content get downloaded and then what can you offload using conditional loading.

Umm, once the user’s already started interacting with the site and interacting with he site, all the perception of performance.

So, yeah, I’m actually a big fan of [48:00] conditional loading. Big fan.

Justin Avery: So in, in terms of, because we’re talking about well, trying to, looking at advanced techniques.

Jeremy Keith: Mm-hmm. (Affirmative).

Justin Avery: Before we finish off, just, what would be some of the advanced techniques that you would recommend people looking at when approaching web design, Responsive Design these days?

Jeremy Keith: It’s funny because a lot of the things I tend to tell, tend to tell people to, to look at is, is the knowledge, that’s the really simple stuff, like I, I encourage people to really go back to basics about what is the content here? What is, I want to say content and not just mean you know, copy and images and stuff. I mean like what’s the core task that users are trying to accomplish?

And you know, that will often be something like, you know, buy something, add something to a shopping cart, ahh and, and purchase it with a credit card. Or yeah, publish something to the web. Something like that.

And I encourage people to think about what’s the, the simplest way not the, not the most elegant or the most beautiful or the nicest experience. What’s the simplest way you can accomplish that with the simplest technology?

And that’s nearly always HTML. And it’s nearly always you know, either just plain old links or, or forms, right?

Umm, I encourage people to go back to those simple technologies and get that right first. And once you’ve got your ahh, shopping cart or your publishing tool or whatever it is you’re building working in a really you know, very simple ugly way using text areas and buttons and selects and these very simple techniques, that now you’re in a position to ask OK, now what advanced technology can I investigate? Because now you’ve got that actually that kind of safety net.

And it’s at that point that I kind of say go crazy because at that point you really don’t have to worry about how well supported a particular technique is or you know, any of that stuff because it’s OK if not everyone gets it. It’s OK if, if that latest and greatest technique [50:00] you want to play with doesn’t work in every browser because the core task will work in every browser.

And now you’re announcing it. So it’s more like I tell people to go back to the basics, make sure they get that right and now investigate everything. Like, go crazy. Now go out and, and look at the latest API’s, look at what you can do with, yeah the Offline stuff.

Look at what you can do with the latest techniques and JavaScript API’s with the latest CSS stuff, animations. Umm, all of this stuff and just go wild with it because now you’re in a, in a position to kind of experiment like crazy without risking you know, access to the, to the core task.

In terms of which particular things you know, people should be investigating. Umm, like I say, I’m surprised at conditional loading hasn’t really taken off as a kind of fundamental technique. Umm, there’s a lot of interesting CSS stuff that again,, I’m surprised isn’t being used more, but you know, it’s getting there.

A lot of people are now really investigating Flexbox and stuff like that. Umm, more and more people getting into SVG which is great. Umm, the Offline stuff. There’s definitely a swell it feels like there’s you know a bit of movement there.

Umm, like I say, I hope that people will use all the stuff and then in a progressive enhancement way,, but I also understand that people want to just start experimenting with it straight away, so maybe they’re going to build something that requires that stuff as an experiment. And that’s fine too, but I think on a production site you want to use it, it as an enhancement.

But, yeah, all this stuff to play with. The one I guess, you know, taking the big picture, the big, the biggest change coming down the wire will be web components. That’s, that’s kind of a big one.

Justin Avery: What’s, it’s interesting web components. I was talking with someone the other day around that and we were talking about Element Queries being the next thing to solve now that Responsive Images is done.

I was wondering is web components something which could be a [52:00] solution for that? Something which just has everything packaged within it?

Jeremy Keith: Yeah, to a certain extent. I mean, the whole idea of the web components is that it’s self contained. It doesn’t it’s not just markup, it’s markup plus CSS plus JavaScript and it’s going to need to exist kind of on its own.

Umm, so this, this idea of an Element Query where the thing just looks at its container makes total sense for, for web components. Maybe that’s how we’ll get Element Queries is kind of by the back door of, of web components.

Umm, does other [inaudible 52:30] as well in that if you look at an SVG which is a markup document, right? Like HTML and so it can contain scripts and it can contain styles, you can make style declarations inside SVG’s and those, and you can have media queries inside SVG’S.

And they’re not looking at what’s the view port, they’re looking at what’s the SVG sitting in? What’s the, what’s the view port of the SVG essentially? Right?

Umm, so these things kind of are, are out there and could creep into regular CSS kind of by the back door by showing that this is possible because we’ve already got it working in things like SVG. And maybe it will end up being in web components and kind of have to be, because web encapsulation is such an important part of web components.

Umm, so yeah, potentially, that’s a, a path to Element Queries. Umm, it’s, it’s interesting, you make comparison with, with, or you mentioned Responsive Images and saying well, now that that’s you know, that’s more or less done we can move on to, to ahh, Element Queries.

They very much feel like, history repeating itself there because you know, with, with Responsive Images we had the situation where developers the world over were saying this is what we want. We are crying out for this. You know, please give us a way of doing Responsive Images.

And the browser markers, therefore the standard makers,s aid no, too hard. We, you know, show us the use cases. [54:00] Like what, what do you mean a, every single site being built today in a Responsive way is a use case.

Justin Avery: (Laughs).

Jeremy Keith: You know it’s like real dragging of the heels and they’re saying oh, can’t be done. It’s too hard. We don’t want to come [inaudible 54:10] we want to do other cool stuff.

And then the developers really having to you know, club together quite literally and, and figure, you know, really hammer it home and really drag the browser makers into building this stuff.

And it feels like the same way with Element Queries that right now it’s like if you were to ask anybody working in Responsive site what’s the one thing you wish you could do in CSS? Right, they’d be like oh, Element Queries would be oh, such a life saver. Right? We could really truly build in a modular way, which we can’t quite do yet.

Ahh and yet, you know, it’s been brought to the browser makers, brought up to the standards by these and they’re like oh, no that’s too hard. No,we want to work on this other stuff. That’s too hard. Where are, where are the use cases?

Justin Avery: (Laughs).

Jeremy Keith: Umm, and so I do feel like it is yeah, here we go again, right? And …

Justin Avery: And so, so the last two years …

Jeremy Keith: Yes, about two years.

Justin Avery: Yeah, [inaudible 54:58].

Jeremy Keith: Two years from now we’ll have you know, ULVise will be ahh, having a, a crowd funded campaign to work on Element Queries and ahh, …

Justin Avery: To go to Google and Apple. (Laughs).

Jeremy Keith: Yeah.

Justin Avery: And Microsoft.

Jeremy Keith: Yeah, yeah. So yeah. His, history repeating itself which you know, happens a lot in, in front end development type. Do, I do see this happen.

When Ajax came along , there were all these, and this was what, 2004, 2005? All these issues suddenly came up around like ahh, but the back button doesn’t work as expected or you know, when you bookmark a page, it’s, it’s not the chains stay to the page and all this confusion.

And it’s like wait a minute, these problems seem really familiar. I remember we had this with things like frame sets or we had this with Flash movies, right?

And, a lot of things that we think of as being new problems are actually not necessarily completely new. And there’s things to be learned from looking at the past.

Justin Avery: Same problem, just a different hat.

Jeremy Keith: Yeah, yeah. Yeah.

Justin Avery: That’s awesome. All right. Well, thank you, [56:00] thank you for, for joining the podcast, on behalf of myself and the listeners, thank you for all the work you do around web standards and the writing that you do and the teaching that you do and the conferences you put on.

Umm, is there anything else that you want to ahh, pitch, not pitch perhaps just mention? Information about dConstruct? Other things that we don’t know?

Jeremy Keith: Yes, I will, I will I suppose as ahh, as unofficial sponsor of the podcast, dConstruct. And everyone should come to dConstruct because it really will be amazing. I mean it’s kind of a conference like no other. And no, it won’t have you know, code. It won’t have specific front end development techniques, but it, it will expand your mind.

Umm, and it’s a lot of fun as well. Umm, tickets are on sale now and you can go to the dConstruct website and buy one, but you can also enter discount code when you’re buying your ticket. And if you enter the discount code RESPONSIVE then you’ll get 30 pounds off the ahh, total ticket price.

Justin Avery: Hooray.

Jeremy Keith: Yea.

Justin Avery: Awesome. Ahh, thank you again, Jeremy for your time and ahh, hope to catch you at dConstruct in a couple of weeks.

Jeremy Keith: Yeah. See you then.

Justin Avery: So thank you everyone for joining us for this special edition this week with Jeremy Keith.

Ahh, next week we’ve got another special addition. We are being joined by John Allsopp, ahh, an author ahh, an original writer of The Dao of Web Design which is an incredibly amazing ahh, article he penned back in April of 2000.

So I look forward to chatting to him then and I hope everyone has a Responsive week. Cheers. Bye.