Hey everyone and welcome to Developer Tea name is Jonathan Cutrell I am your post and today I'm interviewing Scott Jehl 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 the toy company Lego which I am 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 Scott Jehl.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 interviews 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 you know how how much value Scott has been adding to the web development community for years now so enjoy this interview with Scott Jehl and remember to subscribe to Developer Teaso 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 and I'm really glad because I think a lot of people who are listening to Developer Teaeither have barely heard or or don't know very much about what progressive enhancement really is and if you guys haven't heard Scott's name then you'd probably have heard you probably have heard his name if you know much about progressive enhancement so this is this episode is mostly dedicated to the people who oddly may not know Scott's name because we're gonna talk about progressive enhancement and what you can do today to kind of adopt some of these things and we're gonna 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's just give me kind of a rundown of what what that book is about well I think it's somewhat of a follow-up to Ethan Marquots 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 parts of web development right yeah amongst so many but yeah yeah I mean there you know those are pretty broad categories to to mention in sure like that but but yeah you know I think access in general is sort of the 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 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 of 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 but a road map to 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 area concern yeah very common so yeah it makes it difficult but I think you know it makes it what it is too it's 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 gonna 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 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 to depending on what kind of device or browser you're dealing with so I think you know for us it's it's it's the idea of delivering something usable to everyone and then you know layering on as we can up to you know really a full and rich experience depending on what's available to us right so like a 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 are particularly aware of because you are or you have basically spearheaded the writing of picture fill right yeah so 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 landing in browsers now set 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 picture fill is you're right that I started the project but I kind of play a very minor role if any these days and it I just sort of oversee this this big chat room and watch others like Matt Marquist 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 think it's gotten really it's become quite solid to use yeah and it's it's awesome because you know I I think that I just had a thought I'm gonna have to edit this part out yeah I was gonna mention I was actually gonna look up on and find out how many people have actually worked on that at this point okay yeah actual committers I'm not sure probably one contributors yeah that makes sense and then the team itself is probably 10 to 20 people who are actively yeah so yeah that that project has 51 committers officially on the on the actual repo and GitHub which is I mean that's a that's a huge deal and I think you know it's not just it's not just things like the picture element it's not just new standards that are coming out that are important for progressive enhancements there's there's even stuff that we kind of take for granted to work properly like I use back-around size cover every single day pretty much and I'm using you know things like position fixed every single day and and having those kinds of things you know 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 it's kind of a you know kind of a wash but it's awful yeah I mean yeah we've that's that's one property that we we still just try to use sparingly if if at all still it's just it's just tricky to get right especially with zooming into being able to zoom on mobile devices with pinch zoom really you know introduces some interesting problems with that yeah it's painful sometimes yeah so there's 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 in trying to figure out where that 80-20 demarcation actually 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 like those are the two big categories that they have to focus on yeah and of course there's a hard problem to solve but often the answer is there's just not enough resources to do like all the way across the spectrum there's not enough resources to even approach that like sliding scales sometimes because the minimum requirements are the enhanced are on the enhanced side of that scale right so so you're talking about you know designing basically from the business end you're designing for chrome first or you're designing for chrome plus you know other webkit-esque browsers or a 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 we now we have to justify that 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 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 that per on the enhanced end or is there some of it that could fall somewhere in the middle of the spectrum somewhere I don't know I I honestly feel like we don't end up having to make that trade off a whole lot of times but in a lot of it comes with you know building sites this way you know with with practice right so you sure the first time you approach a project with a progressive enhancement mindset maybe 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 and in the browsers that you're looking to reach so there is you know a little bit of I guess just just learning curve there but I think in general it's building this way tends to benefit every user and I think that's that's really come to the forefront in the last year or two when performance has become this kind of this 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 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 load is basically so what we're seeing is that sort of surprised 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 really fast initial page load and it's the result of the way browsers are built that they're they're actually built to optimize on top of a site that's that's built with progressive enhancement right if you deliver HTML up front and in the CSS that it needs to 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 like JavaScript in order to you know populate the page on the client side or anything like that so 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 a kind of the the biggest user base across popular browsers right now I guess but this benefits Chrome users as well right yeah yeah that's interesting because I think I think a lot of people think about it as separate concerns right like they say okay well we're we're gonna go back and make sure that we do compare it like that we do browser compatibility right as a task you know like yeah and it just if it's not baked into your your companies thinking right from the start of a project it's really hard to just tack it on you know it has to be 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 their service as best as they can and to the most people that they can so it's it's just about you know thinking thinking about those things from from the beginning you know accessibility is a classic example of of a task that sort of tacked on at the end you know oh we'll get we'll launch the site for now and then later we'll make it accessible and it 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 then it would have just to build it from the start the right way yeah and it takes kind of a fundamental shift in 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 and like I still have to bring those bring assets out of that file and so there's a lot more responsibility for front-end Developer 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 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 what how do I create that iteration as well right and I think a lot of people have the 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 how this how the experience is going to play out on various types of screen sizes and types of input mechanisms like patch and mouse keyboard you know these are all design decisions it's not necessarily something that should be left only to Developer To decide right and sure ideally the more we're we're sort of one team throwing ideas back and forth throughout the whole process you know the more successful the end product will be but I mean I agree with you like a filament where I work we tend to design as a first pass sort of the the highest fidelity experience we do make designs for a sampling of breakpoints just so you know visual visual viewport breakpoints just so we can see just you know start to get an idea of how a design is going to flow and adapt across different screen sizes but 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 you know how things behave how things animate all sorts of concerns as well as what I think you were getting at from the beginning which is you know how does this translate to a device which with much lesser capabilities that can't render this design exactly as it's delivered to the to the development team right so yeah yeah and this is a problem that you know we've been talking about for a while like it when when we wrote our book designing of progressive enhancement in what was that 2000 I think it was 2010 yeah we talked about this a lot and 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 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 the top code of paint to the mechanics that are underneath it and say okay you know this 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 it's actually a lot easier because if you want to build something like that without using a standard 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 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 Jehl 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 Developer 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 front slash 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 DeveloperTea.com and until next time enjoy your tea