Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. I am your host and today I'm interviewing Scott Gell. Scott is a designer and a developer. He lives in Florida and he works at Filament Group. Filament Group creates websites for people like Boston Globe, Lego, like the toy company Lego, which I'm highly envious of, Global News, eBay, and more. I'm reading this directly off of Scott's site, if you can't tell, which you can find at scottgell.com. That'll be in the show notes. Scott also wrote a book that he released just in 2014 called Responsible Responsive Design. We talk a good bit about some of the content in that book in this interview. The interview is in two parts. If you haven't heard of Scott, then I'm really excited to be the one to introduce you to him. If you have, then... I'm excited to be the one to introduce you to Scott. ...you know how much value Scott has been adding to the web development community for years now. Enjoy this interview with Scott Gell and remember to subscribe to Developer Tea so that you won't miss the next episode, the second part of the interview with Scott. Thanks Scott for coming on the show today. Hey, thanks for having me, Jonathan. Absolutely. I'm glad you're here. I'm really glad because I think a lot of people who are listening to Developer Tea either have barely heard or don't know very much about what progressive enhancement really is. If you guys haven't heard Scott's name, then you probably have heard his name if you know much about progressive enhancement. This episode is mostly dedicated to the people who oddly may not know Scott's name because we're going to talk about him in a little bit. So if you haven't heard Scott's name, then you probably have heard his name if you know much about progressive enhancement. So this episode is going to talk about progressive enhancement and what you can do today to kind of adopt some of these things. And we're going to talk about Scott's book. So tell me about that first. Responsible, Responsive Design, published by A Book Apart, correct? Yeah, that's correct. It came out in November last year. Awesome. And so you talk about, tell me what, just give me kind of a rundown of what that book is about. Well, I think it's somewhat of a follow-up to Ethan's book. I think it's a follow-up to Ethan's book. Ethan Marcotte's book, Responsive Design, or Responsive Web Design. And it sort of, you know, whereas that book talked about adapting user interface layout across all the varieties of screen sizes and viewport sizes that we're dealing with and have to care about today. This book sort of starts to introduce some of the other aspects that we need to care about while we're, carrying out responsive design. So performance, accessibility, usability, how sustainable our code is over time. These are all sort of things that we need to think about as well when we're building things that work across devices. Yeah, you would say, or I would say at least, that it's kind of the hard part of web development, right? Yeah, amongst so many. But yeah. Yeah. Yeah, I mean, you know, those are pretty broad categories to mention in short like that. But yeah, you know, I think access in general is sort of the great feature of the web, right? So trying to do whatever we can to broaden that and take advantage of that feature is, you know, it's kind of what we do. Yeah, and it's hard because you mentioned on Web Ahead that I just, I told you, I've listened to before the show. You mentioned that it's more difficult because we're trying to deal with, whereas like if you were designing for iOS 7, right? You guys talked about that briefly. If you're just designing something like that works perfectly on iOS 7, then you know all of your constraints and it's all in one place. And you don't have to go very far to figure out whether or not something is going to work. Right. Whereas with the web, it could be, I mean, there could be a new device tomorrow that comes on the web that you should be building for today, which is a very weird situation to be in. Absolutely. Yeah. So, I mean, thankfully we have web standards to develop against, which I guess sort of serve as our, you know, iOS dev kit for the web. And a roadmap too, right? Yeah. Yeah, absolutely. But, you know, it's across the web, there's all sorts of versions of browsers. And devices that we're supporting at once. So it's, you know, it's really varied whether or not a particular standard is supported at all. And if it's supported properly, which is kind of another hairier concern, but very common. So yeah, it makes it difficult, but I think, you know, it makes it what it is too. It's, as Jeremy Keith says, it's a continuum rather than a platform. Right. Which is the, kind of the fundamental, understanding that you need to have to be able to start doing progressive enhancement, right? Is that continuum where you're going to fall somewhere on that continuum and, you know, you kind of have to decide where you need to and should fall. But you start, you mentioned recently that it's not the least common denominator really, but you start by building for the, what is the word for it? The least capable devices, right? Sure. Yeah. Well, I think, you know, in general, I think you can sort of assume that most services on the web have a set of core features that can be considered critical to whatever the service is that they're providing. And I think at least the way I interpret progressive enhancement is that those are the features that you deliver to everyone. They're non-optional. And you deliver them in a sort of basic way that could work on any device. And then from there, you can layer all sorts of things on top, depending on whether or not features are supported, not only in the browser, but, you know, you could introduce new features from the, from a service perspective too, depending on what kind of device or browser you're dealing with. So I think, you know, for us, it's the idea of delivering something usable to everyone and then, you know, layering on as a service. We can up to, you know, really a full and rich experience depending on what's available to us. Right. So like a fundamental web feature is that you can use a URL bar to access a particular URL, and then it's going to send back to your browser a response. Like that's a fundamental feature, but something that's not a fundamental feature might would be like the picture element, which you, you are particularly aware of because you wrote, or you have basically spearheaded the writing of PicturePhil, right? Yeah. So the, the picture element is a new HTML standard that sort of lets us negotiate between different sizes of images to, to make sure that we're not delivering too much or too little to any particular size screen. And it's an upcoming standard that's actually, it's actually landing in browsers now. So, but in order to use it today, at least to its fullest capacity, a lot of people prefer to use some sort of polyfill and that's what PicturePhil is. You're right that I started the project, but I'm, I kind of play a very minor role, if any, these days in it, I just sort of oversee this, this big chat room and watch others like, Matt Marquis and, you know, a series of other developers who are just doing loads of work every day on this, to make it really, really strong. So it's great that it's, it's taken off and I, I think it's gotten really, it's become quite solid to use. Sure. Yeah. And it's, it's awesome because, you know, I, I think that, oh, I just had a thought. I'm gonna have to edit this part out. No problem. Yeah. I was going to mention, I was actually going to look up on and find out how many people have actually worked on that at this point. Oh, okay. Yeah. Actual committers. I'm not sure. Probably. 51 contributors. Yeah. That makes sense. And then the team itself is probably 10 to 20 people who are actively. Yeah. So yeah, that, that, that project has 51 committers officially on the, on the actual repo on GitHub, Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And I'm using things like position fixed every single day. And having those kinds of things, we kind of take them for granted, but they don't work exactly how you would expect everywhere. Yeah, even in the newest browsers, position fixed is kind of a wash. Yeah, it's awful. Yeah, that's one property that we still just try to use sparingly, if at all still. It's just tricky to get right, especially with zooming into, being able to zoom on mobile devices with pinch zoom really introduces some interesting problems with that. Yeah, it's painful sometimes. Yeah. So there's this kind of looming question that I think a lot of developers who are listening to this and who have heard about progressive enhancement that they have. And I know that there's a lot of answers to this question, but I'm going to pose it to you because I know that you've probably heard it over and over and over. And it kind of centers around the idea of the 80-20 rule and trying to figure out where that 80-20 demarcation actually is. So you have developers who have a set amount of time and a set minimum requirements for the larger percentage of users so like the Chrome users and on mobile, the iOS people. Those are the two big categories that they have to focus on. And of course, this is a hard problem to solve. But often the answer is there's just not enough resources to do all the way across the spectrum. There's not enough resources to even approach that sliding scale sometimes because the minimum requirements are the enhanced, are in the enhanced. There's not enough resources to even approach that sliding scale. So you're talking about designing, basically from the business end, you're designing for Chrome first or you're designing for Chrome plus other WebKit-esque browsers or WebKit-powered browsers, rather. And so from the business perspective, it's kind of difficult because oftentimes, as developers, we're stuck in the position of saying, okay, well, now we have to justify, that either the budget needs to get bigger, or we have to justify that we can't do progressive enhancement, or we have to tell them, hey, you know, these features that you want are not essential to everyone being able to use the site, so you have to cut features. Where do you cut? Right. Yeah, a lot of questions there, actually. Let's see. Let's start with this. If you were to pick kind of the 80% and the 20% to kind of, okay, you know, we'll do that if and when we get the budget to do it, what is that 20% that you wouldn't do? Does it fall on the enhanced end, or is there some of it that could fall somewhere in the middle of the spectrum somewhere? Hmm. I don't know. I honestly feel like we don't end up having... I don't think we're going to make that trade-off a whole lot of times, but a lot of it comes with, you know, building sites this way, you know, with practice, right? Sure. The first time you approach a project with a progressive enhancement mindset may be a little harder to wrap your head around it if you're used to developing with a certain set of assumptions about, you know... capabilities in the browsers that you're looking to reach. So there is, you know, a little bit of, I guess, just learning curve there. But I think, in general, it's... building this way tends to benefit every user. And I think that's really come to the forefront in the last year or two, when performance has become this... kind of this really big focus all of a sudden. And I think that's partially because performance is so poor on mobile devices and mobile networks. But also because the tools that we have at our disposal have gotten dramatically better in the last year or two. And all of a sudden, we've been able to start analyzing the way our pages load in much deeper and, you know, more... just, you know, getting more information about how the page loads, basically. So what we're seeing is that... a sort of surprise to everyone, I think, is that progressive enhancement is not only, like, the best way to build for broad access and accessibility in general and sort of fault tolerance across browsers. It's also the best way and really the only way to guarantee that you're going to get... a lot of good results. And that's a really fast initial page load. And it's the result of the way browsers are built. That they're actually built to optimize on top of a site that's built with progressive enhancement, right? If you deliver HTML up front and the CSS that it needs to render a document without running much client-side logic, it's going to be able to render that immediately and not have to fetch additional resources. So that's one of the things that we're seeing. And then the other thing that we're seeing is that the way browsers are built is that they're not just going to be able to run a lot of JavaScript in order to, you know, populate the page on the client side or anything like that. So I think we like to flip that on its head and say, well, you know, what really are your priorities here? If Chrome is your priority, that's great. You know, that's kind of the biggest user base across popular browsers right now, I guess. But this benefits Chrome users as well, right? Yeah. Mm-hmm. Yeah. That's interesting because I think a lot of people think about it as separate concerns, right? Like they say, okay, well, we're going to go back and make sure that we do browser compatibility. Right, right. As a task, you know? Yeah. And if it's not baked into your company's thinking right from the start of a project, it's really hard to just tack it on. You know, it has to be complex. It has to be part of your mission. And I don't think that's really all that hard of a switch. Most companies' mission is to provide their service as best as they can and to the most people that they can. So it's just about, you know, thinking about those things from the beginning. You know, accessibility is a classic example of a task that's sort of tacked on at the end. You know, oh, we'll launch the site for now and then later we'll make it accessible. And, you know, it rarely happens. But often, if it does, it ends up taking more work to tack it on and sort of rebuild what you already did than it would have just to build it from the start the right way. Yeah. And it takes kind of a fundamental shift in the way that you think about the workflow, like even from the design perspective, right? Like a lot of us still work in agencies. I still work in an agency where a designer gives me like a file, you know? And like I still have to. Bring assets out of that file. And so there's a lot more responsibility for front-end developers to say, okay, like I have to take this. What is a singular perfect looking thing and turn it into an infinite number of iterations of that same thing by thinking about, you know, what is this? What happens when I squash this? Or what happens when I can't access all of the resources on this page? Or when I can't flip this thing on its side? Like how do I create that iteration as well? Right? And I think a lot of people have the misconception that you create all of those iterations like one at a time, you know? And that's just not how this works. Yeah. Well, I think, you know, there is, there should be more responsibility placed on the designers from the start to actually think about it. And I think that's a really important thing to think about how this, how the experience is going to play out on various types of screen sizes and types of input mechanisms like touch and mouse, keyboard. You know, these are all design decisions. It's not necessarily something that should be left only to developers to decide, right? Sure. Ideally, the more we're sort of one team throwing ideas back and forth throughout the whole process. Yeah. You know, the more successful the end product will be. But, I mean, I agree with you. Like at Filament, where I work, we tend to design as a first pass sort of the highest fidelity experience. We do make designs for a sampling of breakpoints just so, you know, visual viewport breakpoints just so we can see. Yeah. Just, you know, start to get an idea of how a design is going to flow and adapt across different screen sizes. But when that deliverable, so to speak, is handed over to the development team, there is a lot of decisions that are left to be determined, right? Sure. You know, how things behave, how things animate, all sorts of concerns. Mm-hmm. As well as what I think you were getting at from the beginning, which is, you know, how does this translate to a device with much lesser capabilities that can't render this design exactly as it's delivered to the development team, right? Yeah. Yeah. Yeah. And this is a problem that, you know, we've been talking about for a while. Like when we wrote our book, Designing with Progressive Enhancement. What was that? 2008 or 2010. I think it was 2010. 2010. Yeah. We talked about this a lot. We called it in that book the X-ray perspective. And it was this idea that the design team can design for not the lowest common denominator necessarily, but design for the ideal. Sure. And a developer, a seasoned developer needs to be able to know how to look at that design and break it down and sort of see through. Yeah. And then, you know, you can't just say, oh, this is the top coat of paint to the mechanics that are underneath it and say, oh, okay. You know, this particular control is actually, you know, it looks like a star rating widget, but it's actually a series of radio buttons or a select menu, you know, under the hood. And the more we build things that way from the start, it's actually a lot easier because if you want to build something like that without using a standard controller, you can't do that. You know, you can't do that with a regular component like a, you know, radio input. You're going to be writing a lot of JavaScript. And it's really hard to reproduce something as well as a browser does it natively when it's, you know, when the mapping is one-to-one like that. Right. Especially from an accessibility standpoint. It's just a whole lot to think about, you know, keyboard focus and, you know, how that roves within the component with your arrow keys and all sorts of things that just come naturally. the more we use native HTML and CSS and sort of piggyback on that. Thanks for listening to the first part of the interview with Scott Gell. The next episode will be the second part of the interview, and we'll continue talking about progressive enhancement and all of the difficult parts of actually implementing progressive enhancement on a day-to-day basis as developers. Thanks so much for listening to Developer Tea. And hey, if you're enjoying this show, please consider supporting the show by going to developertea.com frontslash donate. The smallest monthly donation is a huge help for me to be able to run this show and keep things going smoothly. Also, be sure to subscribe to this show in whatever your podcast listening application is or the RSS feed, which you can find on Developer Tea, and until next time, enjoy your tea.