RWD Podcast Episode #15 : Jeremy Keith

Responsive Web Design Podcast Feed

Jeremy Keith speaking at An Event Apart 2013 — photo credit https://www.flickr.com/photos/zeldman/8488356799/

A full set of show notes are almost ready, but in the mean-time here is a taster. To be honest though why read here when you can hit play, download or subscribe and listen to it yourself above.

Show Notes

In todays podcast we recap

• Jeremy’s background and how he stays on top of a fast changing industry
• this years responsive day out in Brighton
• Going back to fix mistakes on our approach to older projects
• Writing for the web is for everyone, and we need everyone to write for the web
• How to approach progressive enhancement in a responsive web
• The changing approach to the basics of RWD
• Focussing more upon performance and the quick wins
  • Caching
  • Gzip
  • Image processing
• The picture element
• Many many more things….

---

The chat with Jeremy Keith was great and it started off with some tips around writing.

“You don’t become an expert about something and then write about it. You write about it as you’re learning and that’s a more valuable perspective to have”.

Responsive design basics

“It’s not just about the implementation, but also about the big picture of why we’re doing it”.

“Now days we’re sold on responsive design, we don’t need to convince anyone it’s a good idea any more and it’s time to get into the detail and the nitty gritty”

It makes sense that we needed to get out head arounds the layout stuff before we turned our attention to the performance, and it seems to be a culture that is coming to the forefront now.

For a while if we saw a new website we would grab the corners of the browser and resize it to see if it’s responsive. Now days we’re looking at the network tab to see how well it performs to see if it’s a quality site.

Performance

There is some low hanging fruit for performance.

1. Gzipping – either configure on the server or a single line in your .htaccess

2. Tie for second: Moving blocking scripts to the footer. Images, run it through Image Optim to get it as small as possible.

20% rule, you need to see 20% change for the users to notice that something has happened. A site that normall loads in 10 seconds needs to load in 8s, a site that loads in 5s would need to load in 4s, a site that loads in 1000ms needs to break the 800ms mark for the users to notice it.

Performance is awesome because it’s an achievement and genuinely measurable affect. Unlike CSS where you can refactor it to improve the CSS file, but on the front end it’s exactly the same.

Progressive Enhancement

There’s a common misconception about progressive enhancement that people think “oh well I can’t use this new feature”, but instead it’s the opposite. Progressive Enhancement means that you can deliver this feature if it’s only supported in 1 or no browsers and over time people will get a better experience as new versions are released.

If you look at the core function of any website you can pretty much deliver that as part of straight HTML and have the server side do all the processing. Payments, forms, likes, sharing, emails, dashboards.

The basic task can be built, and then layer the great awesome technologies on top of that because you have a base safety net to catch those that fall through.

Offline First

Rather than go with offline first that requires all these JS api’s, Jeremy prefers to go Offline as an enhancement. Progressively enhancement would mean that if you happen to have App Cache or Local Storage then as a bonus you can save any page and access while you’re offline.

The web platform

These days people are referring to the web as a platform. Jeremy isn’t a fan of this term, but the truth is when we have an app project these days we choose whether we want to build it in iOS or Android or on the Web Platform.

An Android app can not run on a windows OS phone, or an iOS OS phone, nor can something from the iTunes app store run on a windows or android phone.

When it comes to the web though, we can build a progressively enhanced app that could work in a text only browser, or we can visit the same app with a Webkit Nightly browser

Stealthy web design

One of the pillars of RWD is fluid layout, using percentages. . For years Jeremy was pushing for liquid layouts and only he, Ethan and a handful of others were pushing this. Clients would request fixed width over liquid.

The solution?

Build it liquid but wrap it with a single fixed width CSS line for a width of 960px and you’ve got a fixed width site. Then when the client is ready for a liquid site then comment out the single line of code and it becomes fluid.

The reason for building things in a liquid was even though a fixed width is requested is because you’re building it within a robust way, you are stress testing each of you assumptions at every stage, narrow, middle, wide.

This also works when you’re retrofitting an existing site for responsive design. You can leave the container fix width and start making all of the internal components responsive. Once you’ve tested all of the individual components you can switch over the container to be fluid and add in media queries.

element

Traditionally we have always been pushing the separation of content and design yet with the introduction of the picture proposal solution we are now including image markup to directly associate with the current design (especially around the sizes declaration).

The first thing you should look at is the image itself. Is it a part of the content or is it decorative. A lot of images out there are in elements when they should be in CSS. This is often because of the build of the site itself. You might want a different image for every article but you have thousands of articles — the CSS approach would mean a thousand different background images declared in individual classes within a single CSS file which is not practical. Instead you should think about inline CSS for each particular article.

Photo sharing sites have images as content, however news sites that are using stock photography then you should not have this as part of the content (this is a case by case basis).

If it is decorative and included in the CSS then a lot of the RWD problems just disappear because the responsive image solutions can be controlled directly from within the CSS.

Conditional Loading

Images can be conditionally loaded, but things like videos are really where you see the benefits.

At the moment there’s not as much conditional loading being taken advantage of as part of the RWD approach. This is mainly due to the lack of tools, workflow and experience of learning from each others success and failure.

This is a new way of thinking, almost a new way of Information Architecture. This has a major affect on performance too, it’s not all about the overall size of the page but the speed in which the users are able to begin to interact with the content. One the core content is served and the user can begin to interact, whether that be through watching a video, reading an article, signing up, viewing a product, adding it to the cart etc then the remainder of the supporting content can be lazily/conditionally loaded through.

What’s the difference between conditional and lazy loading?

Read the full transcript

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 genu