Ben: Hey, everyone, welcome to PodRocket. Today, Kaelan and I are here with Aaron Gustafson, who works on PWAs and accessibility at Microsoft. How are you, Aaron? Aaron Gustafson: Not doing too bad. Thanks for having me. Ben: Yeah, well, we're really excited to talk to you today. Maybe you could give us a brief overview of some of the things you're working on at Microsoft, maybe a quick overview of your career, and we can go from there. Aaron Gustafson: Quick overview of my career is a little bit of a tall order for trying to hit our timeframe here for podcast. So I work at Microsoft, I'm officially on sort of the more evangelism side of things for the web. So I'm on our ecosystem team within developer experiences for the Edge browser. But I have kind of been working in and around the standards, world for web standards for quite a long time. I used to be one of the managers of The Web Standards Project back in the day, and I am currently the editor in chief for A List Apart, which obviously has had a lot of intersections with The Web Standards movement over the years. And, yes, I work on Web Standard stuff, specifically around PWAs a lot of the time, although I kind of view everything through an accessibility and inclusive design lens. So that kind of factors into a lot of the stuff that I do. Aaron Gustafson: And when I'm not doing PWA, and standards work, I'm often working in the space of diversity, inclusion, allyship and belonging, trying to sort of build a more inclusive Microsoft and sort of create the sort of company that we want to be working in and create safe spaces for people. Ben: Awesome, well, a lot to unpack there. Maybe we could start with PWAs, just in case folks aren't familiar, like, "What's a PWA?" And why should people be building them? Aaron Gustafson: That's the $10 million question. What's a PWA? So PWA stands for progressive web app, I think a lot of people get hung up on the app portion of that, and defining what is a web app is really very subjective. I think Jeremy Keith has a good way of framing it, it's a lot like defining brunch. It's one of those things that's kind of hard to put a specific definition on. So I tend to get people to focus on the progressive end of it and to think of it as sort of a... It's a website that's enhanced, and it's enhanced in a number of ways that could be for installation, it could be for better performance, better offline handling, any of the number of ways that you can experience it. So better UX overall. But really, it's just sort of the best in class for building for the web today. Ben: I'll admit, it's been a few years since I've looked at anything related to progressive web apps, but like, my vague memory is that, essentially, you have a web application, and you can create like a... I think it's like a manifest file or something that spells out some additional properties and functionality. And then on Android, not sure what the deal is with iOS, but on Android, you can then... I guess, not sure if it's download or whatnot, but you can save that app to your home screen, and it kind of becomes a hybrid of a website and a native app. Is that still accurate? And maybe you can expand on... Aaron Gustafson: Yeah, I'd say it's expanded a lot since then. So Chrome was, and specifically Chrome on Android, was sort of the first platform to really pick up on a lot of the technologies for PWA. But many of these things have been around for quite a long time. So you mentioned the web app manifest, that is sort of the representation of how you want your website to appear within the context of the host operating system, whatever that is. And so that's one of three sort of technical, I don't know, technical requirements for having a PWA. You've got the web app manifest, kind of at a lower level than that you need to be on HTTPS, because if you're not hosting securely, a lot of the API's that you want to have access to are not going to be available to you. Thankfully, that's become a lot easier to do than it used to be back in the day. Then you have the ServiceWorker, which helps you to manage your networking, offline experiences, improving performance, and all that sort of stuff as well. Aaron Gustafson: So installation, sort of the add to homescreen experiences which you're describing for Android, that was sort of the first pass. And there is a way of doing that. I mean, I've been working on the web and mobile for a really long time, so I remember back when iOS actually didn't have apps, apart from the ones that were natively built in. And we actually had to create web apps to put something on your homescreen. So the add to homescreen concept for the web has actually been around for quite a long time. And yet, oddly, at least as of today, Apple does not currently support the web app manifest, it was all meta attribute or meta tag rather values that were pulled in to create sort of that experience. So I think it's like Apple touch icon and those various meta tags. Aaron Gustafson: But that's sort of evolved, and even in Edge, the previous version that was sort of built on an overhaul of the IE engine, we supported installation of a PWAs there. But now, the Edge has moved to Chromium, we have insulation on desktop as well on Windows, on Mac. When we eventually go with the final release of the Linux version of Edge, that will be there as well. And all Chromium browsers have that functionality, Samsung Internet has that. And also sort of since that time, the various app catalogs specifically play the Microsoft Store and Samsung Internet, or Samsung's rather, App Store all also carry PWAs and allow them to be installed just as though they were native apps. Aaron Gustafson: So there's sort of a lot more distribution options now for PWAs, and they can really act as a wholesale replacement for where you are making investments in C++ or Kotlin, or whatever, you were doing some sort of compiled app, you no longer have to do that and can actually meet your needs just doing web tech. Kaelan: Impressive. They've been around for quite a while, as you said, but I haven't really seen them take off as much as other newer web technologies. What would you say the barrier of entry for PWAs are right now? And I guess how does that inform what you're working on in Standards? Aaron Gustafson: I think that the barrier to entry is not very high at all, and I think people... I think part of it is there are some misconceptions that were basically reinforced by the way that PWAs first came about. So Ben mentioned Android and because Android was one of the first places that this happened, people thought, "Oh, it's mobile only." People thought that it was specifically a Google technology, which it hasn't been, a lot of the stuff in the web app manifest actually existed from the days where Mozilla had their Firefox OS and the web apps that were being used there. And in fact, web as apps has existed as a concept for quite a long time, I think Windows 8 had apps you could build using web tech, Adobe AIR way back in the day, which was the Adobe Integrated Runtime, you could use either web or flash to build apps. Aaron Gustafson: Certainly Web OS, all of these things, you could have web apps even before the days of sort of the packages that would take a website and convert it into an application. So I think there's sort of, I don't know, this long standing misconception that this is a mobile-only thing, or that it's really hard to do, or that we need to create bespoke experiences for different operating systems, which I don't disagree with wholeheartedly, but I think a lot of people tend to get caught up in this idea that they need to create something that is very quote, unquote, native, I don't really like using that term, but to that operating system, it has the look and feel of that operating system. Aaron Gustafson: When I would argue that it's probably more important to have consistent brand experience across a variety of different platforms, because I know a lot of people who live in sort of a hybrid world where they might have an iPhone, but then have a Windows machine and then have another device that might be Android, maybe their television is Android based or something like that. And within the same application, if you were to have a vastly different UI, in all of those contexts, you might then have to relearn that and all those different contexts, and it'd be better to have a consistent brand experience across all of that. And if you can achieve that user experience and brand experience that you want using web tech, why not go all in on that? I think that's certainly what we've seen some companies embracing Twitter, for instance, they ended up replacing their Windows app, which was a UWP app in the store with the PWA fairly early on after they launched the lite version of Twitter, which was their PWA experience. Aaron Gustafson: Then the PWA actually ended up taking over their .com site, so now it's all the same experience and they can kind of control that, rollout new features and everything all in one place without having to kind of jump through all the hoops to get updates to a variety of different platforms where you're relying on spinning up API's and then implementing those in each of the different frameworks or languages that you're having to do it. Get it put into the store, get it distributed, all those sort of things. Whereas on the web, it's just instantaneous that you would get those changes out there, which is why I think we're seeing a lot of companies like Twitter and Lyft and Uber has made investments here, Trivago, Starbucks, yeah, lots of companies are embracing PWAs now. Ben: I'm curious, when you initially mentioned some of the benefits of a PWA, performance was one of the things you mentioned. And typically, traditionally, people, I think, felt that in order to get a top-performing app, you kind of have to go native and hybrid, or apps built with web technologies are often slightly worse or significantly worse for performance. So are there maybe some things people don't know about PWAs or your tools in that PWA toolkit that'll let you build a highly performant application? Aaron Gustafson: I think it all comes down to what your needs are for a specific site. I don't think there's... There's general things like having a good offline experience, and catching as many resources as you can up front, especially things obviously, that people are going to need. I think it comes down to also thinking about how am I architecting my app, and sort of what is the impact of that on the overall user experience? Because I think a lot of folks nowadays are really going for that thick client where they've got this huge JavaScript library that they're loading into the thing, and that may not... It has a lot of improvements for developer experience, but not necessarily for user experience, and I think there's a strong trade off there. Especially when you consider the sort of long tail of devices that may be lower powered, especially as you start to stretch across the world, or just even into more rural areas in like the United States where we are, right, or at least where I am. Aaron Gustafson: So being able to have something that's going to be performant everywhere sort of requires us to actually think about performance in more of a holistic sense, and make design decisions and architecture decisions that are supportive of that, and that don't prioritize developer convenience and developer ergonomics over that end user experience. So I think kind of once you've gone down that path, which is more of a philosophical approach, then you can begin to see like, "Okay, how do we go about making this the best experience, the snappiest experience?" I know Airbnb, they just did a talk at PWA Summit and they were talking about integrating things like haptic feedback, which not a performance thing, but gives it more of kind of that traditional app feel, right? Something you don't see on the web that often. Aaron Gustafson: But they also have things like page transitions that they're experimenting with, which is sort of a new experimental thing where you can actually identify elements that are going to be consistent between pages and allow the browser to kind of adjust what's happening as you're moving from one experience to another, to create that more sort of seamless flow that a lot of people immediately reach for a single-page app framework in order to achieve because they want to have that native-like experience. And other ways that are starting to come about that we can do that natively within the browser without having to throw a ton of extra JavaScript at it, which ends up clobbering performance, as much as we might like to think that that would improve performance, it does not. Aaron Gustafson: And I mean, the other thing to think about is that there are a lot of folks who don't download apps, specifically because they're so large and PWAs can be like a fraction, like a 10th or smaller than the equivalent as a binary app downloaded from an app store. I think that's another thing to consider, how quickly can I get people into this experience? I don't know, how little of their resources can I take up in order to remain a part of their life and their experiences? Because if it comes down to do I keep this app or do I keep these photos of my kid? The app is going to go, right? That's just the reality. So the more we can kind of be aware of how people are using their devices and consume as little as possible, really, it's sort of that that same idea, and not to be gluttonous about resources and how much we want to take for ourselves and start to think about how we can put our apps on a diet, I guess. Kaelan: So you're a spec writer at W3C and you've talked a lot about the direction that you think the web is going, can you talk about what you're currently working on? If it's not a secret, that is. Aaron Gustafson: Sure. No, no, no, no. I'm pretty transparent about a lot of the things that I'm working on. I am an editor on the web app manifest spec, so that, as we talked about, kind of defines what the app looks like in the context of the OS. My prideful moment about that is I helped to land something called shortcuts, which allows you to define sort of the long press or forced touch on your app icon to have a couple of quick actions that you could take from a web app. So that's within the manifest now, and I'm pretty proud of that. But I also work on the image resource spec, which is consumed by the web app manifest as well as notifications. And I think the payment request API uses as well, and that sort of defines how we can put images into JSON documents and what sort of fields we need for that from an accessibility standpoint, from a processing standpoint, and so on, and so forth. Not necessarily a super sexy spec, but something that's an important underlayment to a lot of what's going on in that space. Aaron Gustafson: Then I also work on something called the app information supplement to the manifest, which is concerned with how do our PWAs show up in app catalogs? So that includes things like being able to define a description, to have screenshots, to have a rating, using the IARC rating system, categories. One of the things that I'm working on right now is being able to include pointers towards the policies that affect your app. So things like your terms of use, your privacy policy, accessibility statement, that sort of stuff. So that can be consumed by an app catalog, and then used to create your product page, which should hopefully help with distribution and stuff like that. Aaron Gustafson: I've also got a couple of other things that I've been working on, I've been trying to pitch the ServiceWorker folks on an update to the cache API, to actually give us some visibility into things like, "Okay, how long has this resource been stored in the cache? How big is it? When was the last time it was accessed?" That sort of stuff, so that we can actually get a little bit more particular about how it is that we're managing our caches within the context of a ServiceWorker. So we can, for instance, if we've got really big files that haven't been accessed in six months, let's go ahead and purge those from the cache so we can keep our footprint lower, right? That sort of stuff. As opposed to the sort of... I don't know, I would consider it like a sledgehammer approach that we have for cache management within ServiceWorker right now, which is basically like, "Okay, I'm only going to allow up to 50 images in this image cache that I've designated. And once I've got that 51st one, I'm just going to throw away the first one that I stored." Aaron Gustafson: Well, that first one may be needed. So you've just thrown away something that could have been accessed on every page, because it was your logo, for instance. And that happened to be the first image that was cached. So I think we need to have some smarter tools for how to manage that. And we can see that stuff in dev tools today, but it's not exposed to us as developers on an individual implementation basis, because you may have a specific user who spends a lot of time in one portion of your app, so those are the more critical assets to them, then what's happening over here. So you can't kind of take the one-size-fits-all approach, you want to create kind of a tailored performance for individual users, and that would allow that. Kaelan: I see. I remember cache being a very common pain point when the ServiceWorker spec first landed, especially when I tried it. Sounds like you're working on a lot of foundational stuff. My question, is it hard to write specs for features that are consumed by other teams? That sounds like a lot of interoperability that's required. Can you give us some insight and how that works, I guess, behind the scenes? Aaron Gustafson: Sure. I mean, every spec's a little bit different in terms of how it sort of germinates. But we start out by usually writing an explainer that proposals, "Here are the use cases that we're trying to solve for, here are some approaches that we considered, here's the approach that we're recommending, and here's why. Here's what that would look like." And then if that gets picked up moving into sort of a standards body, a lot of times what you're doing is you're authoring that document to try and explain how in sort of generalized terms, how to implement X, Y and Z features. So for instance, in terms of looking at this policy piece that I'm hoping to add to the app info spec, I'm looking at that and I'm saying, "Okay, here is this enumeration of different policy types. Here's a good way of modeling that within the manifest in an extensible manner that's easy to parse." It's knowledge that you start to gain as you work with more browser vendors, because I am not someone who's on engineering during the implementation in the spec. So I have to write things that are consumed by those engineers. Aaron Gustafson: Then you break down the steps for processing that particular thing and try and be as explicit as possible. In a lot of cases, it's figuring out where you need to reference another spec or something like that in order to tell people what it is that they're dealing with. And thankfully, there's some pretty good tooling within the W3C to help you to author those things, or to find cross references to other specs and things like that, like if you're trying to figure out what is the URL format that I'm working with, or what have you. So that is how you end up starting out. And then it's a lot of learning by talking to the other people who are working on the spec will say, "Oh, a way that you probably should approach that as doing this, or if you reference this other spec, you can see they approached a similar problem in this way. It'd probably be good to align those." Or those sorts of things. Aaron Gustafson: So a lot of it becomes... You take an initial stab at it and then you get sort of iterating feedback from other people who are involved in the standards process to kind of help you to improve that and align it with existing specs or make sure that it's as prescriptive as necessary for implementers to make sure that everybody is able to build interoperable implementations on the other end. If that makes sense. Hopefully that answers your question. Kaelan: Yeah, great. Like most things, I guess, more communication works. Aaron Gustafson: Yes, yeah, we use GitHub a lot. Kaelan: So as an employee of Microsoft, and also someone who contributes to W3C, as you mentioned earlier, Edge recently switched to Chromium, and I know that the number one conversation in the web community when that was published was the fact that we're getting less competition between browsers. I'm kind of wondering is that something that concerns engineers at Microsoft? And what do you think about competition in the browser space? Aaron Gustafson: Yeah, I think that is something that is concerning, and certainly something that a lot of us thought about. I mean, I very much mourned the move of Opera, for instance, to Chromium a couple years back as well. And I had serious concerns about our move to Chromium, not necessarily that I didn't think that it was the right approach for Edge, but from that standpoint of, oh, gosh, what does this mean in terms of standards? I think it does present some challenges for the standardization process, which currently requires multiple interoperable implementations, which I think, and I'm not 100% sure, but I think it's two now that they've adjusted it to. It was three, I thought at one point, but it does shift the balance of power a little bit in that sort of paradigm, where for whatever reason, if certain other browsers decide not to support something, or implement something, it can basically stall that technology being able to roll out more broadly, which it's a double edged sword, because I totally get why people would say, "You know what? We're not really big fans of the spec." Aaron Gustafson: I mean, I remember going through this with Web Sequel back in the day, where Internet Explorer and Firefox basically pushed back against that and said, "We need something that's not based on another piece of software." SQLite, in that case. And then IndexedDB was proposed, and there was that really squishy time in the middle where you couldn't reliably use Web Sequel, but IndexedDB had zero implementations. And so it was kind of like, "Okay, well, what do we do? We need to solve this problem." And I do think that there is... I don't know, I feel like there's a challenge there in terms of trying to figure out what is or what should be on a standard track versus what should be something that only one browser engine, which may have multiple organizations working within it, contributing to it, which Chromium does. Aaron Gustafson: I mean, in the PWA space, we've got, obviously, Microsoft, Google, Intel is working in that code, Samsung is working in that code. So we do have a lot of companies that are sort of weighing in on proposals to add features to the web platform, and it's not like it's that one team can kind of run roughshod over everything. There is a lot of discussion about who's supportive of this and who's not. I do feel, and this is just me speaking as me, not me speaking as a representative of Microsoft, I do feel like there's probably going to need to be some adjustments to the way that we approach the standardization process, simply because the reality on the ground is that not all browsers are resourced similarly, in terms of their engineering teams and stuff like that, and there's only so much capacity. Aaron Gustafson: So it's entirely possible that there may be something that, let's say Mozilla, for instance, is really in favor of, but they don't have the bandwidth to take it on in the next six months or a year or something like that. Does that mean it should be held back from moving in a standards track? I would argue no, even though we don't have a second interoperable implementation. I mean, I guess the standards process would require that it wait to be quote, unquote, finalized and become recommendation until then. And maybe that just doesn't end up mattering quite as much whether something has made into recommendation status or not, or whether it's okay to have it be a pretty far along working draft, or something of that nature. Aaron Gustafson: But I think the goal of having things get to the point of being a recommendation is really that that ideal state, and I think if we achieve consensus, that should be pretty good, that people can feel secure in working with that technology so that they can move forward, even if the experience may not be borne out in all browsers right away, they have the sense that will eventually be supported in other places. Kaelan: So sounds like you want more flexibility, essentially? Aaron Gustafson: Yeah, I think we probably will need some greater flexibility. We're still trying to figure all that stuff out as to how that ends up playing out. But I will say that we end up with a lot of conversations in the Chromium space, and certainly in the W3C space as well, where we're having conversations in and among all of these different browser manufacturers around things that may not be on the plate, or even the backlog for some of the browsers that are participating. Ben: I'm curious to learn a bit about Project Fugu. Can you tell us more about that? Aaron Gustafson: Sure. Project Fugu is codename for sort of a group of enhancements to the web, and the reason that it's called Project Fugu, if folks aren't familiar with what Fugu is, that's blowfish, or Porcupine fish, depending on where you are. But Fugu, when you make sushi out of it, you have to be very careful in the way that you cut it, because if you cut it wrong in the swimbladder, if I remember correctly, it will make it poisonous and can kill you. So it's one of those things that it's kind of a catch all for things that are very high risk, shall we say, for features that we will be adding to the browser. I would say some more so than others, things like file system access, right? That's a pretty... Being granted that permission is a big responsibility. So we need to be really cautious about how we're approaching some of that stuff. Some of the other Fugu features, I would say, are probably not quite as scary as that. But yeah, that's kind of become the overarching, umbrella term for a lot of these sort of next gen app API's and such. Ben: Yeah, I'm curious, more on that point, how you think about security overall with features like that, I feel like one of the great advantages of the web, and I guess maybe this is a false sense of security I have, I feel like I can kind of go to any website, and as long as I don't download anything, or grant camera access or microphone access, it's unlikely a... I trust the sandboxingsecurity of Chrome, Safari, of the major browsers and Edge. As soon as you kind of go down this road of starting to give more and more API access, obviously very useful to developers and certain applications, but it presents much more risk to the user. So how do you think about kind of that balance and ways maybe to allow some of these APIs while protecting users who may be less savvy? Aaron Gustafson: Yeah, I think that certainly in my work, and I try and encourage this and everybody else, is to think from that sort of privacy preserving and security preserving stance first. I think a lot of people who are working on these specs are coming from that perspective. So making sure that access requires a permission, that being able to initiate a request to a particular API requires user interaction, those sorts of things, building awareness within the browser for things like when your camera is on, when your microphone is on. Another proposal that I have that I'm hoping to make some traction on over the next year is sort of a first-run experience, or first-run permissions prompt and so the idea is that within a PWA context, when you install, your website becomes reparented it to its own window, which is its app window, right? And in that context, you may not, or you may, have already been granted a certain number of permissions. Aaron Gustafson: Often, when we build apps that have particular permissions, think about a communication tool like what we're using right now, we've got camera and microphone access that are required for this. If this were a PWA, then they could potentially define those as the permissions that they're going to... That are like, high need, basically, things that are... I wouldn't go so far as to call them absolute requirements, but these are the things that if you're going to participate in the core experience that this app is providing, you're probably going to need to provide these, right? And then there's sort of the nice to have stuff. Aaron Gustafson: In the approach that I'm taking to it, I would like to see us enumerate that in the manifest, and then when the app gets reparented, have a window come up that basically enumerates those various permissions that are being requested. And regardless of what you have granted or denied before, you'll be represented with those permissions, and then you can make the choice as to whether you want to grant it or whether you want to deny it, or have that prompt you later when it actually wants to access that thing. So users would still be in control, but it sort of gives an app a chance to re-request potentially that information, because it's so core to the experience of the app. Aaron Gustafson: And I see that sitting side by side with the existing permissioning models. So apps can kind of have their really core permissions that they need for their app and sort of their nice to have things. For instance, maybe Maps decides that they don't need geolocation absolutely for their product, because you may not be using turn by turn directions, or you may not want to look at yourself on the map. And so we can wait to use that until we actually need it and the user says, "Oh, no, I do want to get turn by turn directions while I'm driving, then you need my location." And we'll ask for it at that point. Aaron Gustafson: I think we also need to be smarter about how long we're granting permissions for, sort of creating better auditing experiences for permissions as well. So things like maybe auto resetting permissions when you haven't accessed a site after X months, right? Those sorts of things. I had another proposal that I put together that was basically like time limited permissions, where I as a developer could say, "I only want this permission for the session," and then go ahead and reset it. And that would be a way that we could be a little bit more upfront with our users that, "Hey, I don't want this forever. You want to use my store locator, that's fine. You only have to give me this permission for this session, and then it goes away." Which, incidentally, is what Safari, at least on mobile, I don't remember about desktop, but that's what it does, it resets it every time you relaunch the site, even if it's been granted before. Aaron Gustafson: So I think getting a little bit better about how we're approaching permissioning. I know for file handling, for instance, in a tab, I believe it is only allowed for the session. And I think there was some talk about if you've installed that PWA to grant the file handling for the life of the PWA while it's installed, because you've taken that extra step to say, "I want to install this, I trust this to the point where I want it to be at least temporarily on my computer." And therefore, once you grant the permission, rather than it kind of pestering you over and over again, it can just keep it for the length of time that it exists on your device. Kaelan: When talking about permissions, my first thought was permission fatigue. I'm wondering if that's like on the radar of W3C or... Aaron Gustafson: Yeah, I think it's on everybody's radar honestly, is trying to figure out how do we do permissioning better, because it really is the sort of thing where you're playing whack-a-mole, very much like pop ups in the days of old. And you even have some sites, thankfully, not a whole lot of them, but some sites where they won't even render any content until you grant them permission to your location or something like that, which is just bizarre to me. So I think we need to figure out a better approach to that, something that sort of forces developers to take the right approach to permissioning. I think we're seeing some of that with some of the quieter notification approaches that Chrome and Edge have implemented. I'm not sure if that's been implemented elsewhere, too, but I know they're sort of based on website reputation, which includes how many times people have dismissed the prompt for notification capability. They basically make that just become a little bug in the omni bar or something like that. Aaron Gustafson: So I think those sorts of mitigations are going to reduce that fatigue. And I'm hopeful that things like being able to ask for permission, multiple permissions at the same time will help with that as well. So that you're not doing kind of... I mean, I'm sure all of us at this point have probably had that experience where you open up a new app, and you just get that rapid fire permission, permission, permission, permission, permission requests, which I'm all for just in time permissions when you're actually using a feature that requires that permission, but so many apps don't do that, and they ask for a bunch of permissions at once anyway. And so it just becomes this sort of annoying, whack-a-mole situation. Kaelan: Just curious, which Fugu API are you most excited for that's coming up? Aaron Gustafson: Oh, gosh, I don't know. I mean, I feel like some of the file handling stuff is really interesting. I think being able to declare a web app to be a file handler for a particular kind of file is really cool. I'm also really intrigued by the contact picker. It's something I've been thinking a bit about was, how do we how do we expose address book to websites in a very privacy preserving way where users are in control of whose information and what information we share? Because I remember, certainly this happened since then, but I distinctly remember Path when that app came out on iOS, and it had access to your address book, and the first thing it did was basically hoover up your address book and send it up to their server and now they have all your contacts. And we can't have that sort of thing on the web, that is just a recipe for disaster. Aaron Gustafson: So yeah, I'm intrigued by a lot of that stuff that's going on. I think URL handling is interesting, being able to basically route requests within a browser back into your PWA. That's kind of a cool idea. And we've already had things like registering protocol handlers in JavaScript, but now that's something that you can also define in your web app manifest. So there's some neat things like that. I'm super in love with things like share target, I find that to be a really awesome tool. And in fact, I use that on my own website, even though my site's a blog, it's a PWA, and I have a share target for it that I use just for myself so that I can basically take any web page and share it to my PWA, and it pre populates a forum that creates a link blog entry for me in GitHub. And that sort of self-service PWA is pretty amazing that I can create that workflow just by adding five lines to my manifest is really awesome. Ben: You mentioned earlier a lot of what you do also focuses on DEI, diversity, equity, inclusion efforts, I guess, both at Microsoft and maybe within the web at large. So how does some of the things we've already talked about whether it's PWAs or web standards, tailor in with that focus on diversity and equity and inclusion? Aaron Gustafson: I think there is a movement within the standards community, but certainly within the work that we're trying to do to make sure that we're building a web for everyone and to create more opportunity. And that's what kind of had me excited about progressive web apps early on is that I saw it as a way of being able to reach beyond. So you think about something like a WhatsApp, for instance, right? Before they were acquired by Facebook. They were huge when it came to messaging and effectively, they were just a encrypted messaging app. And those at the time, were a dime a dozen in the iOS App Store, right? I think when I checked it, there was something like 2,700 encrypted messaging apps that were available in the App Store. Aaron Gustafson: So I kind of was thinking on that and thinking about what is it that made them so valuable to Facebook? And it was the fact that they had so many users, and why did they have so many users? Well, they were embracing a diversity of platforms, they were on Series 60 devices, they were in all these places that weren't just the shiny black rectangles that we have in our pockets that are the latest and greatest devices with high end specs, and awesome cameras, and all that sort of stuff. And I think by creating an app experience that can be used by more people, we automatically create more opportunity to have more customers and to build more value. So with my business hat on, when I'm thinking about things like accessibility and inclusion, that is what I'm thinking about, right, creating more opportunities for these people to come and use our product or our service. Aaron Gustafson: But I don't think we'd get there without having a plurality of people working on these products. So if your team all looks one particular way, and comes from one particular background, and a handful of schools, y'all are going to have... Even though you may have had different life experiences, y'all are going to have kind of a perspective that is shaped by that and that is reinforced by the experiences that you've had collectively, right? And so when we design for people that look like us, we exclude people that don't look like us, or when we design for people who have experiences we do, we exclude people who don't have those experiences, or have who have different experiences, different concerns. Aaron Gustafson: So I try to think about things like people's safety, I try to... And Eva PenzeyMoog has a great book called Design for Safety that just came out, I highly recommend folks look at that. But it talks about how we've approached all of these technical ideas, considering only the happy path, not how they could be used for abuse, or gaslighting, or what have you. And we need a diversity of perspectives on our team to catch that stuff early so that we create products that are actually working for the broadest number of people around the world. And so that's why I've gotten super involved in sort of the diversity, inclusion, belonging, etc., space is because not only is it the right thing to do, not only is the talent out there equally distributed, even though the opportunity to showcase that talent isn't, to sort of paraphrase Tatyana Mack. Aaron Gustafson: But I think until we have teams that are actually representative of the customers that we either have, or that we aspire to have, we're not going to be creating products that are actually useful for those people. So that's why I'm super passionate in that space, and try to bring that into all of the work that we're doing. And I feel like we're getting there in the standard space, as with many areas in computer science, it is heavily populated by white and Asian males, but I think that's changing. Kaelan: Yeah, often, it seems like a chicken egg problem. I've tried many times, for instance, to argue to PMs, like, "Oh, we should make sure our app loads fast in all these other countries besides the US." But then they say, "Oh, well, we don't have customers outside of the US." Well, maybe we would if it loaded faster. Aaron Gustafson: No, absolutely. And I think to kind of look back in history a bit, A List Apart, when... This is way back in the day. When we no longer served our CSS layouts to Netscape 4, all of a sudden, our Netscape 4 numbers shot up, because the experience was not great, it turned out that we were artificially suppressing the number of people who could use our site well in Netscape 4. And I think we see that all over the place where folks just aren't considering the experiences that they're creating, and how can we build something that's going to work for as many people as possible, because a portion of those people are potentially going to spend money on our products, and are going to keep us employed and help us to make our product even better? Aaron Gustafson: So why not try and reach them? And that's why I'm super intrigued by things like collaborative design. That's something that has existed for a long time in the disability community where they have the saying nothing about us without us, where you really want to get folks from those communities to be involved in the process of creating your application or your service in order to make sure that you're meeting their needs and catching potential problems early on. Kaelan: You mentioned A List Apart. Could we talk a little bit more about that? It's probably the number one design blog from the early days of internet that I remember, so incredibly influential. When did you start editing for A List Apart? Aaron Gustafson: I have kind of gone off and on with ALA for a number of years. My first sort of foray into working at A List Apart was I think, somewhere between 2005 and 2006. I initially came on as a copy editor after meeting Jeffrey Zeldman at South by Southwest. And I was kind of helping out with things there, then he realized that I would be super helpful in sort of a technical editor space, so I moved into that. And I was one of the technical editing team members along with Dan Mall and Matt Markey and a bunch of other awesome folks for quite a long time and then just got so busy with work that I didn't have the time to commit to it. So I took a break and left ALA for a couple of years. Aaron Gustafson: And then, gosh, I guess it was 2017, maybe 2018, somewhere in there, Jeffrey reached out to me and asked if I'd be interested in coming back and coming on as the editor in chief, and that was just kind of like, clouds parted, sun came out. The experience, it was pretty amazing to be asked to do that, and such a huge privilege, but such a huge responsibility as well. And so since sort of taking over A List Apart, I've been really focused in very much the same way as we were just talking about increasing the diversity of our voices, making sure that we have more representation in our illustrations, that we are more approachable to people from more backgrounds and who've had different experiences and making sure that our pieces are reflective of the reality out there. Because as I would go around speaking and doing workshops and stuff like that, I saw a huge diversity in the people that were coming to those workshops that were doing the roles, especially in government and education and stuff like that. Aaron Gustafson: But those were not the voices that we were hearing from in articles, so wanted to make sure that we were doing outreach to other communities and trying to engage with more people globally as well. And it's all a process, but I feel like we've been making some good strides in that area. Ben: So, Aaron, it's been great talking today and learning about all these interesting projects you're involved in. I'm curious, for folks out there who want to learn more about PWAs, what's the best way to get started? What's the best way to learn about that platform? Aaron Gustafson: Yeah. So I think if people want just like a really quick and dirty, how do I get a PWA stood up, pwabuilder.com is a great resource, you can actually plug in your URL and it will help you build out a web app manifest, it will help you to pick a ServiceWorker from one of a couple of recipes. And honestly, you could get a PWA stood up in about 15 minutes using their resources, which is pretty amazing. Aaron Gustafson: There are a couple of good books out there on PWAs. I definitely recommend Going Offline by Jeremy Keith and Progressive Web Apps by Jason Grigsby, those are two fantastic books. And then if folks are interested in really tucking into sort of the philosophies that I've been talking about in terms of reaching more people and sort of building more robust web experiences, I wrote a book called Adaptive Web Design. The second edition of that came out a couple of years ago. But unlike a lot of tech books, it's more philosophy based than strategy and sort of technical-approach based, so it has a little bit longer legs, will live on your shelf for a lot longer and be useful for longer than most tech books. Aaron Gustafson: The first edition of that's also available online for free, but the second edition I totally rewrote and I think is a lot better for it. It integrates accessibility into every step in the process, as opposed to keeping it as a distinct chapter, which I think made the book much stronger. Ben: Great. Well Aaron, thanks so much for joining us. Aaron Gustafson: Yeah, thank you all very much for having me. It's great to talk to you. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket.