From Progressive Enhancement to Progressive Web Apps

Stephanie Cox: I’m Stephanie Cox, and this is Mobile Matters. Today, I'm joined by Aaron Gustafson for Microsoft. Aaron is a web standards advocate and has been working on the web for more than two decades. In addition to working closely with the edge team, Aaron works with partners on Progressive web apps with a focus on cross-platform compatibility. He also wrote Adaptive Web Design, a seminal book on Progressive Enhancement. In this episode, Aaron and I talk a lot about the concept of progressive enhancement and how it's tied to Progressive Web Apps, the significant opportunities available for us with the use of service workers, and what's really happening with Microsoft Edge. And make sure you stick around until the end, where I’ll give my recap and top takeaways so that you cannot only think about mobile differently but implemented effectively. Welcome to the show, Aaron.

So, you've been working in the web for more than 20 years. Can you tell me how you got started?

Aaron Gustafson: Sure, so I was running a music magazine back in college–this was in the mid-90s–and I decided that I wanted to bring it from being a print thing to being a web thing. And my friend originally helped me to code that out, about 1996-ish, something like that. And then after she built the initial version, I took over and tried to figure out what else I could do with it. And so that was how I started learning to do web stuff. I learned a lot from the source. The first book I ever got on web design was called Creating and Enhancing Netscape Web Pages...

Stephanie Cox: Oh wow!

Aaron Gustafson: It's funny to look back on. But I started out doing that, just kind of for my own magazine that I was running. And then, I got my first job out of college in 1999, working for the Freedom Herald in Bradenton, Florida, and I was effectively their content management system. I would go in like eleven o’clock at night and I would take articles out of park documents and I would put them into three templates and fetch them up to the website. There was no editorial oversight as to what I was putting on the web. It was pretty crazy.

Stephanie Cox: So, you have such an interesting background on how you got into it, and it's actually kind of similar to mine. Because the first time I got really into web and web development was school newspaper, then I interned at a local paper the next summer and they're like, “Oh, you know web! You can put things on and you can use Dreamweaver,” or back then I remember using Adobe Pagemill. And like I'm like, you're letting basically a 20-year-old do this, okay.

Aaron Gustafson: Yeah, it's kind of funny. But I mean we were the only ones who knew how to do it, right? I mean we didn't have courses when I was in school, and we didn't have any classes in design, or really any computer science classes but we didn't do anything that was web-related. The only thing that we ended up doing, and all of that was related, was a course that I started to teach my friends on how to do web design. My school was such that you can actually create your own classes so they wanted me to do a web design class and that was like first thing. But, I mean so many of us from back then were effectively webmasters or–the other term–webmistresses. We just learned to do everything! I can remember doing my first full program to do the back end of a contact form. So crazy!

Stephanie Cox: Yeah it is, looking back on it now. One of the things that I know you're really big on and kind of known for is this idea of progressive enhancement. Can you explain to everyone what you mean by that term?

Aaron Gustafson: Sure. So the idea of progressive enhancement–and this was coined actually in 2003 I think by Steve at SXSW–is that you start with a universally available and accessible baseline experience. So this is something that has very few technical requirements to being able to access it the content and use the site for tasks. And then, you use the different features of the browser–you use different CSS selectors or method detection in JavaScript, or now you can actually add supports and stuff like that–to basically determine what does this project support, what I'm capable of delivering to an enhanced experience? And then you provide that better experience to people that actually take advantage of it. But ultimately, it's about creating experiences that are available and accessible to anyone no matter what device they happen to be on, the platform they happen to be on. And it really brings together a lot of the things that we as an industry, have been talking about over the last 15, 20 years–which is accessibility, talking about responsive design, talking about UX that can work for everyone,talking about inclusive design. All of these very much play into the progressive enhancement philosophy. And really, it was about kind of turning the tables on this idea of graceful degradation, which is where you built the latest and greatest browsers and then you just assume that anybody who didn't have those browsers was negative about the experience.

So you built a flashlight and you had no fallback for anybody who didn't have a flashlight. Or you block somebody from being able to access their bank account details because, God forbid, they weren't on the browser that you tested in. So progressive enhancement is sort of, I characterize it as a rejection of lazy developing. Because it's not about you as a developer, it's about actually thinking about the real people who are accessing our content and need to use our services and making sure that we provide good experiences to them.

Stephanie Cox: I absolutely love the idea that it's a rejection of lazy developing. That should be a shirt! That is absolutely brilliant. So when you think about progressive enhancement, are you seeing a lot of other companies adopt that kind of line of thinking in their business?

Aaron Gustafson: Yeah I think our medium is an interesting one in that we constantly have new people coming out to the web and starting to build for the web and we all come from various backgrounds. A lot of us self-taught, some of us now coming among other things like bootcamps, coming out of traditional computer science degrees, and there's no single curriculum that defines what it is to be a web designer or web developer. And then, at the same time, you have all of these individuals and companies who are trying to solve their own needs and creating frameworks and new ways of building things. And everything's changing so rapidly, I feel like it's sort of a pendulum swinging back and forth a bit, like as new things come about we gravitate towards the new shiny. And then, the pendulum swings the other way and we realize that the new shiny thing isn't really doing everything that we needed it do, in terms of dealing with lower-end devices or dealing with accessibility issues and that sort of stuff. And so then we start to rein it in and actually make it work for everybody. But I've seen that numerous times over the years and we certainly saw that with the development of Ajax. But, all of a sudden, everything was going to be delivered via JavaScript and if anything happened with a plug-in or your JavaScript not being delivered entirely, because of a network issue or something like that, the entire site was hosed. And that's actually happened numerous times, I remember, Gawker Media when they were still around, launched a new platform back in 2011 and when they flipped the switch for all of the sites on Gawker Media, which, for those who don't remember Gawker Media, it's effectively all blogs, right? So, this is just content sites, not even applications. But, they built their entire framework to rely on JavaScript to pull in all of the content and there was an error in the JavaScript code when they flipped the switch and turned it on for all the sites. And every site was dead! They had headers, and they had navigation that didn't work, but there was no content. Some of them had a little spinning loading icon, but nothing was ever coming. No doubt about it, embarrassing right? That's horrible. But there've been there been other examples of this over the years.

I mean, JQuery has their CDN for serving a JQuery. And there was a time when Sky–which was a big broadband provider in the U.K.–actually flagged JQuery as malware for about a day. And so every one of their customers in the UK on any site that was reliant on that copy of JQuery was basically dead in the water. And so, I think we jump in with both feet to new technologies and new approaches, and what's fun and what we get excited about showing off to our friends that we've done. But, it's not always the best thing for our users. And so, I think we need to kind of take a step back and revisit the things that we're building in order to make sure that they do work for as many people as possible.

Stephanie Cox: I can't even imagine those two situations you talked about. Like if that happened to me, I can't even imagine the amount of panic that would ensue.

Aaron Gustafson: Yeah, I mean it's crazy and there was another example that a friend of mine alerted me to on Twitter, when Google started to basically stop trusting certain Symantec SSL certificates because they had some trust issue with SSL certificates issued by Symantec before a certain day. But anyway, they put out the new version of Chrome that no longer trusted the certificates and if you were serving your–let's say your CDM for all of your JavaScripting for CSS was coming from a server with that and your normal site was on SSL too. If your normal site’s SSL certificate was fine, it would show that page, but then it wouldn't be able to load any of those assets because they weren't secure anymore. So again, the button is fragile. And I think it's important to kind of recognize the fragility and not really see it as something that needs to be overcome, but just something that needs to be considered. I mean, just stuff happens. It's not always a happy path that our users end up on and the people, those of us who we're building the web, we often have really fast connections and really high-end machines and stuff like that and we don't always take the time to think about what the experience is for our actual users.

Stephanie Cox: Well, not just experience, but in the actual conditions on which they're going to consume it. So, thinking about progressive enhancement, how does that relate to another term we've heard a lot about lately, which is Progressive Web Apps?

Aaron Gustafson: So progressive being the first word of Progressive Web Apps is actually a call out to progressive enhancement because the idea with Progressive Web Apps–or PWAs–is that they're an enhancement of an existing website. So, whatever your website is–whether it's a blog or whether it's a magazine or an actual piece of software as a service or something like that–it exists on the web and that's great. And then, the pieces of PWA, the three technical lynchpins are: Running on HTTPS, so being a secure site; The second thing is having a Web App Manifest, which sort of defines the metainformation about your site. So, icons you want to to use and that sort of stuff; Then the third piece is using a service worker to provide offline experience. But all of those pieces are effectively enhancing the baseline experience which you're having on my website. So they can enhance it through making it equal to the install, for instance. So, you can install currently on Android from Chrome and from Samsung Internet, Firefox, and Opera in the desktop world. You can install Chrome Windows and on Linux and Mac OS, you can do it as well, but I think that's still in beta. And then Edge will actually be able to do install from the browser on the desktop as well. And Microsoft also supports delivering PWAs via the Microsoft store, which also opens up a lot of opportunities for opening up operating systems as well.

Stephanie Cox: I know you just mention the three key technical components of a PWA, but what do you think the biggest feature of a PWA is that you're most excited about?

Aaron Gustafson: I mean to me, the opportunities that are available to us with service worker are pretty impressive. So for those who aren’t familiar, a service worker is the type of web worker which means it's a self-contained script that runs on it's own. And it is basically your own “man in the middle”, so you can control all network requests–anything that's being requested from your site, you can intercept that request and do something with it. And the other sort of piece of that is that it has access to Apache API. So, in a traditional browser world as a developer, you didn't really have much control over your browser or your users’ browser, rather, which actually caches information. I mean, we have ways to blast caches and stuff like that, but it wasn't fantastic. It wasn't very, there wasn't a lot of control. But with service worker, we actually have this very low-level API that lets us control what is being put into the cache, what is being pulled out of the cache. And using a service worker, you can do just a ton of different, really interesting things with your requests to the network. So, for instance, when your service worker is first installed, you could free cache all of the core assets for your site. So your baseline JavaScript, CSS, etc. Maybe your icons and things, and then those will be available offline as well. As you can set up your service worker to attempt to make a request the network, or you could make it go to the cache first and then they can get something in a cache because of the network. There are a bunch of different ways, different permutations for where these sorts of logic come in, but you can effectively provide a completely offline experience for somebody. So you mentioned the web design book that I wrote the first edition of, that is actually online for free and people can go to AdaptiveWebDesign.Info to read that. But, I turned that into a PWA and I added a service worker that basically captures the entire book offline for you, so that when the service worker installs it goes ahead and it saves all of the individual chapters, the HTML files, and saves the various images for it, and the videos and stuff like that, so that you have it to read whenever. And it doesn't matter if you're on a plane, or if you go through a tunnel, you'll always have access to that information. So there's that sort of stuff you can do. You can do things like–let's say you automatically convert all of the images on your site from JPEG and PNGs into a web-view format, which is a lot smaller in most cases, but not all browsers support WebP. Instead of doing some convoluted hoops either in markup using a picture element, or in Javascript to figure out if you can set it up in your service worker, you can actually convert those requests for work for PNG and JPEG files even within particular directories and swap them out for requests for what the return for web said. When you're on a limited bandwidth connection or a pay-per-bit connection, a meter connection, instead of loading images maybe you load an SVG file which you already have cached that's a placeholder and then you allow somebody to decide whether they want to load all of your imagery down, because they're paying for each of those graphics to be downloaded to them. So there's lots of cool things that you can do a service workers.

Stephanie Cox: I'm glad you mentioned service workers because they're probably my favorite part of PWAs, too! I just think that they're almost a little bit like the secret sauce of what makes a PWA really special and different than what we thought of as web apps in the last decade.

Aaron Gustafson: Absolutely. Absolutely. And there's a bunch of other stuff that's sort of coming down the pipe in the future. If you've taken a look at the sort of a categorization within the Project Guru APIs, which are all about bringing more desktop and traditional software development apps and native app features over to the web. So, some examples of that are share–being able to share to a PWA instead of sharing to a native app. So, we had actually an implementation of that on the Windows side, using them in our TAPIs for the Twitter PWA. So, if you've installed the Twitter PWA from the Microsoft Store, you can actually click on images or even certain movie file types within your file system and you can share them directly to Twitter from there. But those capabilities are starting to come to the web as well, which is pretty awesome. So there's a lot of stuff that we're trying to sort of bridge the gap between what you traditionally thought you needed to do native development for and bring that to the Web and really super targeted websites and applications.

Stephanie Cox: Since you brought that up, do you think that at some point PWAs and the web in general can replace what we've traditionally done in native mobile apps?

Aaron Gustafson: So, I don't think one hundred percent we’ll replace native apps and games and stuff like that with PWAs. But for the vast majority of what's out there on the web, which is more forms, a lot of spreadsheets, and things like that and just a lot of magazines and video sites and things like that, those can all be done with PWAs. In fact, Hulu is right now in the process of rolling out a PWA version of their app to replace the limits of traditional apps in the Apple Store.

And I know Netflix has done some experimentation in this space as well and there are other other media companies out there that are starting to look to PWAs as an option because they already have web teams. They've already got people who are building a great web experience for their users, and if they can make that do double or triple duty, kind of double down on that investment and enable users on any platform to use that same source code effectively to use their service, that's a huge win. And I'd also argue that from a business perspective, it's a lot easier to hire web folks than it is to hire native folks,. There's a lot more of them, and there's a lower barrier to entry to working on the web. So, there are a lot of reasons that it may make sense to migrate to PWAs, especially if you've got multiple native apps and a website and they all effectively look the same and do the exact same thing. You’re creating more work for yourself to have all of these different versions and unless there's there's some specific reason you only get a particular key interaction for your user experience in iOS when you're actually using Swift, then maybe you can make a case for it. But if what you're doing is the same thing as what you're doing on the web, then I think it just makes a lot of sense to double down on the web in that sense.

Stephanie Cox: I think you bring up a good point, though, about this idea that web developers are a little easier to hire than native because a lot of times with native–you mentioned Swift as an example–I've rarely met true native app developers that do both iOS and Android. Typically, they pick one and that's their area of expertise or sometimes they might be cross platform and do something like Zamarind or something like that. But, for the most part, web developers even though there's not necessarily a way that they're all trained the same, there's kind of the same skill set that you get with a web developer that doesn't require you. You're not usually an expert on one operating system versus another, you're just an expert on the web itself.

Aaron Gustafson: Right, exactly!

Stephanie Cox: So, if someone comes to you and says, hey I'm thinking about creating my first PWA...what advice are you going to give them or what direction do you point them in?

Aaron Gustafson: I mean I think a really easy onramp is PWABuilder.com, which Jeff Berkhoff is following up on, and it's sort of a system for helping you get started really easily.

Another recommendation is Jeremy Keith's book "Going Offline". It’s tremendously useful when it comes to understanding how service workers work and even some of the things that we kind of take for granted with newer people that they may know how promises work. But Jeremy's book actually doesn't assume that you know how promises work, so it actually walks you through how promises work and what that means in terms of the promise space architecture, the fetching cache API within service worker. And he's got a bunch of really helpful examples in there that you could put to use right away. And it's probably a two, maybe three hour read if you were to go through to do all the code samples and follow up coding it. But, it's really easy to follow along with and use it to get up to speed with what service worker can do.

Stephanie Cox: Now that you've given some advice, what is the area that you find that most people struggle with when they implement their first PWA?

Aaron Gustafson: I think that we're all struggling to figure out caching. I say this because it is sort of a tremendous opportunity and a privilege to be able to control what sort of users use this and I think that we can abuse that privilege. You know, we can cache way too much. If we were to cache absolutely every page that somebody visited, let's say a very high image site maybe like a storage site or something like that, if you're caching absolutely every asset, you're going to fill up their desk space really quickly. And that just feels abusive to me. We're given this opportunity to kind of play in the same sandbox, and if we're not playing nicely, we're going to end up causing some issues. I look back to keyword stuffing and some of the things that people used to do to try and boost their SEO rankings back in the early days of the web and how that basically ruined the accessible experience for a lot of users. So, things like display and generated content and stuff like that, they've all been used and basically those are the toys they've taken away from us and in various ways. And so, I think we need to be really careful about how we're playing with somebody's disk space. And, you know, the reality is that not everybody has half a terabyte of disk space, certainly not on their phone and definitely not on what we would consider in the Western world low end phones that a lot of people in India and China and Africa are relying on to be able to access the web. And if we want our products to truly be able to go anywhere and address as wide a potential audience as possible, we need to play nice. We need to be making really smart decisions that are always airing in our users’ favor.

Stephanie Cox: I love that you brought up the idea of not abusing caching as an example because I find that that's what happens a lot of times when new technology comes out. And I've done this myself, right? Where you get so excited about it and we do things like keyword stuffing and just really trying to take advantage of it and then big technology companies like Google. Google is a great example especially with things that they did around Mobilegeddon and some things around search. They’ve had to really slap our hands and tell us, “you couldn't make good choices, so now we no longer allow you to make choices”.

Aaron Gustafson: Yes, we got to play with all of the toys and then the toys got taken away.

Stephanie Cox: Yes.

Aaron Gustafson: But ultimately it's for the good of the web. I mean, it's not Google being a jerk about it. It's that we were abusing the privilege and we got shut down.

Stephanie Cox: Now Microsoft has been a big proponent of PWAs and made a pretty big strategic decision to make that a crucial part of how they thought about the Store and just Windows 10. So, can you talk a little bit about what is Microsoft doing around PWAs, for those that don't know, and why is that such a big deal?

Aaron Gustafson: Sure. So I want to kind of take a step back a little bit in the history of Microsoft and its relationship to the Web. I mean, they ignore A6 and that's sitting on the shelf for as long as it did. But there’s this concept that, if I remember correctly, debuted in Windows 7 and not a whole lot of sites took advantage of it, but basically what it allowed you to do is to add a particular website to your fast bar. And then, once you have that, you had the ability to do a couple of interesting things like creating shortcuts within the context menu. So, when you right click the icon you could jump immediately to portions of the website or web app, which was kind of cool. And then when Windows 8 came along, they actually began supporting HTML, CSS and JavaScript, as a means of building native apps for Windows, which, I mean, given the time, that was pretty revolutionary.

I think the only people that may have beat Microsoft to it at that point was Adobe, they were doing that through AdobeAir. And then Palm Air and their Web OS, which was entirely based on web technologies, as well. But they were the first really big operating system to say well, if you know this web stuff, then you can build software, and we're going to support that. Then, when Windows 10 came along they created this notion of hosted web apps–or HWAs as they call them, and this was before the PWA system, as a term–and the idea was that you could effectively wrap your website in a native shell, and not only that, but once you do that have it in this special web app shell, we're going to enable you to do a heck of a lot more. So they did things like removing your storage limits that you would normally have as a website within the browser. They opened up access to the WinRT API. So all of that functionality basically that's available to a native WP-based windows app in the store would also be available to your website when you installed windows and so they were smart about it they namespaced it. So, it was windows.applewwindows was the namespace, and they had all of these additional APIs that you could use to access richer interfaces within the operating system. So they'd be accessing contacts or calendars or you could even provide instructions to Cortana, which was kind of cool! And so, then PWAs sort of came along, and that term was coined. And that very much felt like a natural evolution of where Microsoft was going with hosted web apps. And so, once we got the necessary technical underpinnings to get service worker implemented and Edge and such, we shipped that as part of the hosted web app shell.

And that then made it possible for PWAs to actually be in the store and have offline experiences and stuff like that. And we've seen a couple of companies take advantage of that. So, Twitter was probably one of our earliest big names to come into the store and they actually use their PWA which used to be at mobile.twitter.com. But they're actually slowly replacing the proper Twitter.com with the PWA. But they use that mobile experience and brought that to replace their native app because that app just wasn't getting the love that it needed, it wasn't getting updated. They haven't been able to do the increased character count and stuff like that. And there were a bunch of other features that they wanted to bring to it but they didn't have a dedicated team to work with when it was native. So, they replaced their app. Uber was also basically like you know what, we can't support this Uber PWA app in the store so we're going to flip. I had a conversation with them and showed them really quickly have a particular point of view and just replace it in the store. And they were like, that's awesome. Let's do that. And so, they they just replaced it rather than removing it from the store. They went ahead and swapped out. And there've been a bunch of companies that have been looking at that as an opportunity or who now see an opportunity. Trivago wasn't in the Windows Store and they decided to come to the Microsoft Store and so they came to the Microsoft store as a PWA. And so, yeah, we're definitely all in on Progressive Web Apps and and trying to figure out how we can make them more powerful and as good of an option for building modern software as any native platform... for most things.

Stephanie Cox: Since you mention a few brands, do you have a favorite PWA that you personally love?

Aaron Gustafson: I mean, I use the Twitter one all the time, to be honest. It's a great PWA. I use it on my Windows machine, obviously, I use it on my Mac as well. I'm sort of on the Mac so I use that one, I use it on my phone, I swapped out the native Android app for the PWA, that one is fantastic. Instagram has a PWA. It does some weird things, like you can't actually use it like you would use the normal Instagram app, if you're in a large screen. So, if you're if you're on a small screen or you go into like a mobile emulator mode in your dev tools, you can actually get PWA experience of Instagram on your desktop, but otherwise you just get kind of a read-only view, which is weird, but it's pretty cool that they're doing it. I think they've (Twitter) done a fantastic job not only with the PWA itself but with that deeper integration and starting to think about how can this app do more and feel more native-like.

Stephanie Cox: So we've talked about progressive enhancement and PWAs. The last topic I want to talk to you about is Microsoft Edge. So, I know that's another part of your role at Microsoft. For everyone that's unfamiliar, can you give us just like an update on what's going on with Microsoft Edge? There's been some big news in the last few months about it.

Aaron Gustafson: Yeah, so we recently announced that we are going to be switching the rendering engine and the underpinnings of Edge over to Chromium. And that was kind of a big deal because when we moved away from IE and built Edge, we very much wanted to create a modern modern web browser. We wanted to pull out all of the old proprietary stuff that didn't make sense, all the legacy stuff. And we wanted to focus on building just a lean, mean browser, and I think we did a really good job of that. But, I mean, the reality is that there are an awful lot of developers out there and in sort of the web that are solely focused on building experiences for Chrome. And that puts every other browser–if it's Edge, if it's Firefox, Safari etc. etc.–all at a disadvantage because those developers are only coding to that one browser which honestly reminds me a lot of the old i86 days. So, we all know how that went. But, we saw this as an opportunity to participate in an open-source project that has a really good foundation and work with a company that many of us have more really good working relationship with other folks who work on the browser and to use this as a way to, just focus our time on building a great browser and great experiences for our users without having to spend so much time trying to mimic what Chrome is doing, because developers weren't paying attention to Edge. And so, I mean, my hope for it is that we end up kind of going the path that the BSCode did. If you remember back to when BSCode came out, people were like, oh gosh why? Nobody asked for this! Why why did you do that? There's already Atom, like the guys building that on Atom, why is that interesting? And then, fast forward to today, and BSCode is probably one of the top tech centers that's out there that people are using. And I mean, I don't know that Edge will be the top browser that everybody is using, but I think open source has a lot of power and I think being able to build on top of a powerful robust platform with a great ecosystem is only going to help Edge be better and help us to focus on creating great user experiences, creating better ways of interacting with the web.

And, to me, I know all of a sudden, I get to start thinking about what new features do we need to add to service workers so that we're on par with what Chrome's doing? But, I can focus on–what are sort of the next generation behaviors that I want to enable Web sites to do? And I love being able to think more forward and not have to necessarily be feeling like we're playing catch up a lot. Plus, I think there's a lot that we can bring to the Chromium project. There's been some awesome accessibility people in Chrome but not every part of Chrome is terribly accessible. The dev tools have some accessibility issues. So, we're working on bringing some better accessibility to the dev tools and make contributions in that space, as well. So I think there's a lot that we can do to help all Chromium-based browsers. It's not just about sort of grabbing the Chromium codebase and saying, OK, thanks for building this, we're going to go off over here to do our own thing. But, we're actually in it to play in the open-source world and to contribute back to Chromium so that everybody gets the improvements and we're all working together collaboratively to let that.

Stephanie Cox: I think that's one of the things to me that's most exciting about kind of where the web is headed, is the amount of collaboration that seems to be happening across all the different big tech players on really pushing the web forward. I feel like it's been really beautiful to see that happen in the last few years. I know it was happening a lot before them but not the same extent. Maybe people weren't as public about it. But to me, I'm just excited about what that means for all of us as we start to use really the best minds coming together to challenge what can the web do, how are we going to do it, how can we work together to kind of push it forward?

So, final question: If you look into a crystal ball and you look at where the future of mobile and the web is headed, what are you most excited about?

Aaron Gustafson: I think what's got me most excited is the future of, sort of, headless UI– host-based user experiences. I feel like we're just starting to scratch the surface with smart speakers, but we're not really there yet. I mean if you think about it, none of the smart speakers yet can actually be used as a browser. But once you have the ability to actually ask Siri, Alexa, Cortana, whoever to read from the web, that opens up a whole new way of interacting with the stuff that we've built.

Stephanie Cox: After I interviewed Jeff Burtoft on last week's episode, he recommended that I talked to Aaron and I'm so glad I did everyone. He has so much insight into what's really happening on the web and has a really great perspective on how we should think about the user experience. Now, let’s get to my favorite part of the show where we take the education and apply it to your business. There are so many great insights from my conversation with Aaron that can really help transform how you think about mobile. Let's drive into my top three takeaways.

First, I previously mentioned how PWAs are really an evolution of technology and it was great to hear another layer of that history and story from Aaron in regards to progressive enhancement. Prior to my conversation with Aaron, I honestly hadn’t heard the term progressive enhancement before even though I've probably been using some of the concepts behind it for a while. I absolutely loved how he said progressive enhancement is basically the rejection of lazy development- how awesome is that? It really needs to be on a t-shirt. And he's right everyone, all of us should be using progressive enhancement when we think about designing any experience because we truly need to make sure it’s accessible to everyone regardless of their device, operating system, location, etc. It also means that we have to have a shift in our mindset, that some of us previously had been thinking about developing for the latest and greatest, or the largest percentage of our users and we don't worry about the rest. Whereas progressive enhancement really challenges us to find ways to bring an exceptional experience to literally everyone and I believe that's the bar that we all need to be striving to achieve.

Next, one of the benefits of PWAs compared to native mobile is really the skillset that that's needed to develop a PWA. Let's think about native mobile app development for a second. You typically have a separate development team for iOS than Android and it's rare to find one that does both. And as Aaron mentioned, it's actually a lot harder to find native mobile app developers than it is web development talent. Now on the flip side, there's a large pool of talented web developers out there that you can use to develop a PWA. And personally I think this is one of the most overlooked benefits of Progressive Web Apps. Don't get me wrong. There's a ton of functionality related benefits that are truly changing the future of mobile and web but we can't underestimate the importance of being able to use a web developer for a PWA and the impact that can have on your business, especially since most of us already have web devs today.

Finally, if your business isn't into high gaming. I'm talking a high-end gaming everyone-then it's time for you to start developing your first PWA. No more excuses. In fact, if you already have an existing native mobile app and a web property that basically does the same thing. It's time to start there. Develop one PWA to replace both of them. You're going to get all the benefits of a PWA with less upkeep required.

Now, here's my challenge for the week. If you haven't personally used a PWA yet, then it's time to immediately go experience one. I recommend taking a look at the PWAs for Twitter, Pinterest, Starbucks just as a good starting point. They do a really great job of the PWA experience. Now, there are countless PWAs out there that exist for a number of major consumer brands and that number is growing literally every single day. So try one out as a consumer, see what you think of the experience. I bet it's going to cause you to want to build your first PWA.

I'm Stephanie Cox and you've been listening to Mobile Matters. If you haven't yet, be sure to subscribe, rate, and review this podcast. Until then be sure to visit Lumavate.com and subscribe to get more access to thought leaders, best practices, and all things mobile.

From Progressive Enhancement to Progressive Web Apps

Episode Information

Stephanie's Strong Opinions

Find us at:

Stay Up-to-date On All Things Digital

See Lumavate in Action

Meet with one of our experts to see how easy it is to centralize your product data, manage digital assets, and create digital product experiences. Trust us…you’re going to be wowed.