Progressive Web Apps: The Breakdown

Tom Dwyer at UXDX Europe. Video: https://youtu.be/DpZZkMvgAGo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A change of title, and a thought experiment

[00:00:07] Hello, hello. Is my microphone on? Oh, yep. Everyone, I'm going to stop and tell you that there was a bit of a mistake here. What is listed here is "Progressive web apps: what's in it for the users?" Naturally, later on I changed the title to "Progressive web apps: the breakdown," because that explains what this talk is about a little bit better. As was mentioned, I'm Tom. I'm a front-end developer turned product manager at trivago, and I'm here today to talk about a subject that I expect most of the people in this room know something about: progressive web apps.

[00:00:55] Can I get a show of hands, not for the people that have heard of progressive web apps or know what they are, but for the people that haven't heard of progressive web apps or don't know what they are? Okay, two people. The reason I do that is because it is a term that has been thrown around in the industry a lot, because it's a very exciting topic. So we're going to start with something a little bit different for a conference. We'll start with a little bit of a thought experiment.

[00:01:33] I was at a PWA talk in 2015, and at the end of it I left feeling inspired, and it's that feeling that I want to zoom out to a little. This morning we're here at UXDX. It's quite early still, but I think I can say this conference is going to be pretty awesome. Seeing the speaker list, I am so proud to share a stage with these people. They're industry-leading experts. I'm just happy to be here.

[00:02:07] One thing to remember is the purpose of why we're here today: to share new ideas, to share new information. That is something that can trigger an emotion in us, an emotion to be curious, and that curiosity leads to a product, and that product is creativity and motivation. Actually, many of us, without realizing it, judge how good a conference was based on that creativity, based on that inspiration we leave with. So yes, my talk is about PWAs, but I hope at the end of this conference you leave with that inspiration. Zooming back in, this talk is about PWAs, so let's get started. PWA what? Or alternatively... he's not going to explain that. I see, yes, yes.

The worst name ever

[00:03:21] Let's start with the name, progressive web apps. I have something to tell you about progressive web apps, and I hope so, given that I'm doing a talk on it, and that is that it is the worst name ever, in my opinion. The reason I say it's the worst name ever is that, as I mentioned earlier, this term has been thrown around a lot. I've been doing PWA talks now for quite some time, and obviously with that you have to do research, you have to find insights in the industry. So I did that. I asked people: what does PWA mean to you? What is your understanding of PWA? I asked developers, product managers, QAs, designers. I asked native app developers. Basically, if I know you or if I met you, I asked you what PWA means to you, and I collected a small sample in this presentation.

[00:04:34] One person said a PWA is like a native app, but not a real one, and it's accessed through the home screen. So this is an understanding that a PWA is what we have on our home screen: the PWA is the icon I press on my home screen, and then I open the PWA, almost like a hybrid. Actually, the same person said something in between PhoneGap and a native app. If you understand PhoneGap, it's basically a web view with native wrappings. So they understood a PWA to be something in between them: a native app, but not a real one.

[00:05:11] Another person said it's a website which you can save on your home screen, and it will act like a native app. At least that's how I explain it to other people, though they don't understand much without me showing them a demo. This goes to show us that when we're understanding this term, we're learning it in a very visual way. We're learning what the identifiers of a progressive web app are, and actually, add to home screen is one of the most publicized features of progressive web apps. So we identify a progressive web app by: does it have add to home screen? Yes? PWA. And a third person said "potatoes with attitude." Well, I can confirm that it doesn't refer to potatoes with attitude, sadly.

Web apps versus websites

[00:06:10] Let's take a look at that term again, progressive web apps, and break it down a bit. Hence the breakdown, you see what I did? We're going to start with the last two words, web apps. What is a web app? trivago and Google are web apps by definition. Wikipedia and the BBC are websites by definition. What's important to remember here is that we fling these terms, web app and website, around very colloquially. I can still refer to trivago as a website, as I would refer to Google as a website. And yet the BBC can be a progressive web app, and Wikipedia can be a progressive web app.

[00:07:00] What actually distinguishes these two terms officially is that a web app is based on interactivity, meaning the sole focus of that website is interactivity. If I go to Google, the user is required to interact with the website to gain content. It requires me to enter something, and then it gives me a different set of content based on what I've entered. The same with trivago: if I type in a destination, or a different destination, it gives me different results. The content is delivered based on my interactivity. Whereas websites, Wikipedia for example, are largely informational. Their focus is information delivery. They have aspects of interactivity, a search box for example, but the core principle of that website is information delivery.

[00:07:52] The interesting point here is that the last part of progressive web apps refers to web apps, and yet websites, in the sense of this term, can still be progressive web apps. So the "web app" is not necessarily referring to websites which are heavily focused on interactivity. Hence, maybe, worst name ever.

Websites that progressively emulate apps

[00:08:16] Looking at progressive web apps again, we missed the first word: progressive. Especially in developer circles, when we see the word progressive, we immediately say progressive enhancement. But the progressive in progressive web apps doesn't necessarily refer to progressive enhancement. Yes, progressive web apps utilize progressive enhancement, but the way I like to think about it is more that they are websites that, see where this is going, progressively emulate apps.

[00:09:13] That's fundamentally what progressive web apps really are. It's not add to home screen, it's not these identifiers. The concept is that it's a website that emulates an app through a set of APIs, and there's a criteria list designed to make a website resemble a native app. And this white screen is about to change and show you that criteria list. Done. Okay, bam.

[00:09:54] The term progressive web apps was coined by Alex Russell and Frances Berriman in 2016, I believe. They said these existed before, but now they have a name. Progressive web apps did exist, they just didn't necessarily have a name, and it was because there was a revolution on the web, which meant there was a new set of APIs the web had access to that only native had previously.

The criteria list

[00:10:26] When we take a look at some of these APIs... by the way, I'm super happy that the purple and the green are really legible on the screen. I hadn't tested on this kind of monitor. These purple ones are properties of websites. Safe, meaning it has HTTPS enabled. Linkable, meaning you can share URLs with your friend. This is what we're used to with a website. Responsive: websites are responsive, or we hope they are. And fresh: you get the content immediately from the server. It's when we break this down that we can really see this big group of identifiers, or properties, that make up a progressive web app. A lot of those properties are from the web world. You probably see where this is going: the rest of them are inspired by native.

[00:11:29] Let's take a look at each one of these. Connectivity independent. That text is really small, I'm sorry. It's progressively enhanced with a service worker to let it work offline, meaning if your browser doesn't support service workers, you won't see any offline experience, but the website will still continue working. Discoverable: identifiable as applications through the manifest, allowing search engines to find them. Installable: this is what I referred to earlier as perhaps the most identifiable property, meaning that you are able to go to a website and add it to your home screen. We identify a progressive web app by that one property as opposed to the rest of them.

[00:12:26] Re-engageable: you can engage with the system UI of that device. If I'm on Android, or if I'm running iOS, whatever my operating system is, as a website I can interact with that native operating system. I can utilize push notifications, I can use the geolocation permission, I can use all of these APIs that are to do with re-engagement. I can access the native level of the device. And finally, app-like interactions. This also refers to the app shell architecture, but it also refers to, as you can imagine, app-like interactions: having swipes, having menus which you can slide through. On a website that's not a design pattern that we've seen so much of, but these are design patterns that we are able to at least implement on the web.

[00:13:33] Fulfilling this big list will make your website a PWA. But what's more, these APIs are designed to work as seamlessly as possible with the user's device, and that's really what the criteria list is designed for: to create a standard for websites to create experiences that work seamlessly on the user's device. Because, technology aside, that's what really matters. That's what users really want. They want seamless user experiences. They don't care if it's a native app or a website.

[00:14:18] If you take a look at Apple as an example: many years ago, people loved Apple devices, and we still do, I'm sure. One of the major reasons was that they could use an iPhone, or one type of device, then leave that, go somewhere else, use a completely different machine and pick up exactly where they left off. That was seamlessness. That was a great experience, and now we almost expect that from all of the services that we use.

Progressive means picking what you need

[00:14:58] What's more, if I go back a slide... whoops, no, yes. Even the website-based ones, like responsiveness: some of these are give and take. Some of these aren't necessarily required. I'll give you an example: responsiveness in a PWA is arguable. Twitter Lite, for example, is an enclosed user experience for phones. Twitter has taken the concept of PWA and decided, I don't want responsiveness. And some websites don't even utilize add to home screen.

[00:15:47] The key point here is that we go back to the word progressive. You are progressively utilizing certain APIs over time. You're not deciding, hey guys, I heard some speech about progressive web apps, we're going to make a progressive web app. No, that's not really how it works. You go back and you say, hey guys, I've got this idea. There's a big toolbox of technologies that we could use, and we can start plucking from these APIs and progressively make ourselves a best-in-class progressive web app.

[00:16:26] Hopefully now we understand the fundamental idea behind what progressive web apps mean. One thing I didn't refer to is that the criteria list I gave you is actually quoting the document which outlined progressive web apps in 2016, so it is almost a defined standard. It's just not heavily talked about. So, after me speaking for 15 minutes about what progressive web apps actually means, we have an understanding of what it means. Can we really say that's the name? They're websites that you can progressively turn into an app, and for those websites that attempt that, after reaching a minimum criteria, we name them progressive web apps.

The technical prerequisites, and six months of HTTPS

[00:17:18] We've talked at a very high level about what progressive web apps means. Let's look at the technical prerequisites: a responsive website, HTTPS and a service worker. These are the technical foundations you need. After I listened to that conference talk in 2015, a PWA talk, I left feeling like I wanted to make trivago a PWA. So I went to those prerequisites and I said, well, we have one of them fulfilled already, a responsive website. It's going to be easy, we'll do it all in a week.

[00:18:01] Then I went to the data center operations people, the sysadmins, and I said, "Hey guys, I need you to enable HTTPS. I just did it on my own site, it took me like two hours." And they said, "Yeah," and started working on it. What I didn't really think about... it took us two hours? We enabled it on trivago Poland first, and after that we enabled it on the Netherlands, France, Russia, Turkey and India, and a few weeks later we enabled it on all of our platforms. The thing that I left out here was that it took us six months. It took us six months.

[00:18:52] We made that investment knowing that, well, my own personal intention was PWA, great times, but also we got performance benefits, we got SEO benefits, we got many more benefits. The reason it took so long, namely, is because we tested every time. You can see here with trivago Poland: we tested, did it decimate our SEO traffic? Did it decimate everything else? No, it's great. We had to test iteratively. But more interestingly, that technical initiative, the technology, wasn't actually the hardest part. The technology was easy, comparably, next to communicating to all the departments in the company why we're doing this, and that was perhaps the biggest challenge. So then we had HTTPS enabled, and for that prerequisite, well, I guess you could say we had a lock on it.

Service worker and Project Meteorite

[00:19:58] Finally we come to the final prerequisite, service worker. I hadn't really mentioned service workers a great deal, so I'm just going to quickly explain. It's a technical API that allows you to control the network. It allows you to respond and give content and layout changes depending on the status of the user's connection. If they're offline, or if they have a flaky connection, you can give them a custom experience. That's the technical API. The real point, from a business and product perspective, is: how does this benefit my users and how does it benefit my business? Well, that depends on how you wrap that technical API in your user experience.

[00:20:46] We had to think about that, and we did. We decided to rely on what the service worker was designed for. We decided to make sure that our users would never see the Google Chrome dinosaur ever again. We decided to give them content when they were offline, when their connection dropped. Knowing that our goal was to kill the Google Chrome dinosaur, it seemed pretty obvious what to call the project. We called it Project Meteorite, because it was the most obvious thing in the world.

[00:21:35] We could now deliver a user experience no matter if you were in a subway, no matter if, like me, you were on the flight here. We controlled that. Now we could deliver a seamless transition of content no matter your connection, much like apps are capable of doing. For example, you're browsing trivago and you go offline. Well, instead of getting a dinosaur in the corner, you actually get reaffirmation that you're offline: hey, you're offline, let's give you a reconnect button, just in case you realize your connection's back. We actually give you content you can see. The hotel list you were looking at: you're looking at these hotels and you're offline, you can still see them.

[00:22:15] When you start interacting with that content, if we don't have it, we will give you a little reaffirmation again: you're still offline, sorry, with a nice little icon. If we do have that content, we will still give it to you. Then, if you try to click out to one of our booking partners to actually book that hotel, instead of relying on our partners to have a PWA and their own experience, we keep you in a holding page, and we trigger that redirect when the user's connection returns.

[00:22:47] To trigger that redirect, we need to use a technology called background sync. Background sync is very interesting, because it also allows us to get offline analytics, meaning we can understand what our users are doing when they're offline, and we can actually modify our experience so they get a better one when they're online. And when, in my case, you're on the plane and you weren't viewing trivago previously, you get this thing: a little maze game. This is essentially our version of the dinosaur, which then reconnects after certain times. On the phone you can tilt it. It's kind of cool, I like it. On desktop it's arrow keys. And if you know what the Konami code is, go to this page on desktop, type it in and great things happen. It wins the game, by the way.

Game over? What to do with the APIs

[00:23:52] So we were done. We had everything now. We had a responsive website, we had HTTPS enabled and we had a service worker. So, game over now? Everything's great, we don't need to do anything? Game over? No, no, just no. What now? Well, now you have to utilize those APIs. You have to find how you can bring value with those APIs. Here is a big list of them. There's a lot there, and there are even more. This is a website called What Web Can Do Today, and it is really small, so you can see... yeah. It's whatwebcando.today, and .today is a nice TLD.

[00:24:44] This lists a lot of the APIs which we always thought were only available on native, but actually we know we can use them on the web. We know we can use offline, we know we can use push notifications, we know we can use permissions, USB and NFC on the web. I like to put these APIs in two buckets. I call them immediate and abstract APIs. Immediate APIs are the ones where you look at that big list and you see immediate product value. You can have an immediate feature idea from it. For example, geolocation: if my product is Google Maps, geolocation is a very immediate API that I can understand and use immediately.

[00:25:33] Abstract APIs are the opposite. If I want to use push notifications and I am, for example, a blog, I need to think about how I wrap that API, how I wrap that technology into a good user experience. I have to think about it. But interestingly enough, those APIs are also perhaps the most innovative, because we have to think longer and harder, and therefore they may deliver the most value. What's important here is to remember that while there are a lot of APIs you can use, finding what's contextually relevant for your product is the most important thing.

[00:26:18] At trivago we've been testing these APIs. Some work and some don't, but remember, it's not the tech we're testing. Device memory detection, credentials, network information, permissions API: all of these worked. These ones did not. What's interesting here is that both geolocation and push notifications utilize the permissions API. The reason this is very difficult to use is that the user sees something very specific when a website implements something with the permissions API. What do they see? "Oh my God, get rid of it. No. Block. I don't want to see that." Do you want to know why? Because this is how it makes me feel. Get rid of it, I don't want to see it.

Design impacts

[00:27:10] Back to this API list. With the baseline in place, we have the potential to consume so many more of them, and this is where PWA changes your product: not just opening a toolbox with exciting new tools inside, but figuring out how those tools bring value. This is where PWA has multifaceted impacts. It has design impacts; it requires creativity. This goes to show one of the major reasons why developers and everyone else are largely excited. It's exciting for the entire web community, because now these APIs are available on the web, which yes, were traditionally available on native. What's exciting is that these APIs spurred creativity on native. They spurred innovation in mobile user experiences. Native had more tools to work with, and was able to find how to bring value with those tools. Now those tools are, for the most part, available on the web, which is far more accessible and far more device agnostic.

[00:28:20] When we think about the design patterns that we utilize on the web, does it make sense to copy native? I'll give you an example: the hamburger menu, very well talked about. The hamburger menu was taken from the mobile native landscape and ported to desktop web. Because of the technologies, because of design patterns, does it make sense to scale in this way? In fact, the designer of the trivago PWA echoed this sentiment. She said: "PWA is largely uncharted territory in design. It's a real opportunity for us as creative problem solvers ourselves to find its new standard. I would encourage all designers to embrace that challenge." And when I asked Laura, were there any other challenges, she said, "You have to drink all the tea the developers make you." It's true: it's a box of Yorkshire Tea, 240 bags. I wasn't going to drink them on my own. I'm not a monster.

Product, business and user impacts

[00:29:22] Then we move to the product impacts. The effect of having these APIs on your product is more than just having a new set of tools. For example, when we think of how the service worker works, we understand how we can change our site depending on what's happening with the user's connection. For the longest time on the web, we've always thought about the product life cycle with the assumption that the user is online, because that's always been the case. They couldn't access the website if they weren't online. But now we have the possibility to provide offline content, so when we're thinking about a new feature or a new user experience, we can think about how we can integrate that.

[00:30:00] I'll give you WhatsApp as an example. When you're offline and you send messages, they don't disappear. They get saved, and they get sent when the internet connection returns, and that's so seamless that we almost don't even realize it. Thinking with an offline mindset also allows us to get market reach, because seamlessness in this offline sense allows us to reach markets that may not have a good internet connection.

[00:30:31] There's also another business impact, which is the number of people involved. The trivago PWA took us five people: two front-end developers, one QA, one designer and one product person. A nice return on investment. Then we finally get to the user impact. We did add to home screen at trivago, and we found that the users that utilized it returned twice in the first two weeks, and they converted 97% better [?]. There are a lot more of these success stories: Tinder, Twitter [?], Pinterest, Uber. They all have similar stories.

More than a website

[00:31:08] So really, progressive web apps, we go back to it: it's more than a website. It's more than the ability to go offline. It's more than the ability to add a website to your home screen. It's a best-in-class website that emulates an app while retaining the accessibility and shareability of the web. I'll leave you with one more thought for tech, product and design, especially if you work in one of these areas. Take a look at these APIs. Check out the API list on What Web Can Do Today. Check out examples of people wrapping them inside user experiences. Understand why they work, understand why they don't work. Think about how these technologies can create immediate value, and perhaps even abstract value. And perhaps, more than anything, come together around a cup of tea. Thank you.