 Your users know that the word install means that it's software that's meant for their device, and you want to meet your user's expectations. So that's what you see there on the right, an app that launches from the home screen and is essentially indistinguishable from a native experience. Let's start at the beginning of the story, though. Bookmarks are the original way for users to get back to anywhere on the web they wanted to get back to. They're kind of a universal install button, and they've been available on every major browser since the dawn of the web. So a good question would be, why don't we just use that? And in a word, the answer is mobile. Of course, you can bookmark on mobile, but it never really fully made the jump. And we do see significantly less bookmark usage on mobile than we see on desktop. One reason for that is that the UI just isn't quite as convenient, and that's not just saving the bookmarks. It's also organizing and finding them as well. The second challenge that we see for bookmarks on mobile is that apps, as we just saw right now, integrated into the mobile OS in ways that are important for functionality. So for example, a lot of apps do need to tie in to, say, Android's native sharing sheet, which is what you see on the right side of this slide, where you are all shared from the Metro PWA to Twitter. And to enable a shared target, we need an OS-level entity. We need something like an APK on Android and not just a bookmark. A lot of you will be familiar with this term add to home screen. And again, you see that on the right in the Starbucks screenshot of this example. Unfortunately, add to home screen can actually mean two different things. It could mean that it's a bookmark that's being placed on the home screen or it could also mean that it's actually an integrated experience on the device. And that's why we'll be using the word install for the rest of this talk to talk about the integrated experience. And in the future, you're going to see this in the browser UI on mobile and desktop. The reason for that is install is a UX affordance that's familiar to mobile users who are used to adding content from their OS's stores, such as Play, and then finding that content again on the device through whatever the native launch surfaces are, so on mobile, usually from the home screen. Install aligns to a user's mental model for how installed it, like basically how experiences ought to operate on their device. Uninstalled web app looks and feels like every other app. And the fact that your user discovered and installed your app from the browser or from Play shouldn't actually matter when they go back to use your app again. Most importantly, the word install signals to users that the experience was meant to be great on their device. Here's a summary of how web install is different from bookmarks. Web install offers users access to web apps that are from familiar discovery and launch surfaces for their device. So install web apps can be standalone. That means they can be separate from the browser. It also means that they can be integrated into the native task switcher. And this can be a more familiar way for users to interact with apps, or it might be more suitable to certain types of tasks than tabs. Web install integrates the web apps with the device services that expect an installed app. The important thing to remember when you're asking a user to install a PWA is that with an installed app, you're telling the user that it is an experience that is meant for the device that the user is using. And that means that you need to live up to those expectations of what you design. You're going to have unhappy users. There's a good thing that we have a pattern for building experiences that do just that. Progressive web apps are a pattern for great apps that use web technology. And they have all the features and functionality users expect from a modern app on mobile or desktop. I'm sure most of you in this room are quite familiar with PWAs at this point. So I'll just cover some of the very high level background information about PWAs for those of you who maybe are new to the concept. PWAs include things like personalized content, offline mode, push notifications, and instant loading. And PWAs that install web apps do go hand in hand. You need to have a PWA in order to offer install. There are, of course, other projects that are trying to crack this problem. You can take a look at React Native, at Electron, or Cordova. And all of these are basically offering you a way to build native apps using web technology. But those experiences do depend on functionality that won't also work in the web browser. PWAs' goal is to build directly on the web. So that means you can maintain one code base, and that's going to work for visitors, both in the browser as well as for your installed users. So hi. I'm lucky enough to get to work on Santa Tracker every year, which is a fun holiday themed experience for all ages. And so we'll be using this as an example as we go along. Santa runs on basically everything with a browser, even this magical screen changing device. And so we find that folks who install to their home screens on any one of these platforms where it's supported are some of our most engaged users, coming back the most often. And on Android alone, a few years ago, we found that about 10% of all our loads were coming from that installed icon. So that's a quite nice number. This is fundamentally because when an app is installed, users will feel like it is designed for them. Users will have better engagement, more loyalty, and have a positive experience with your installed application. But of course, who are these users? Who is going to benefit from this extra power? We're the first ones to admit that it won't be everybody. The power of the web has always been that it is ephemeral. Users can move seamlessly between experiences, and so you shouldn't expect all your users to install. And to that end, there is a bit of an install funnel. This is the same as native apps or e-commerce conversions. Most strategies for optimization apply here as well. You don't want to push the user to convert too soon, or they'll leave your site running. You should only promote installed users who are frequent users or who will actually benefit from your services. Focus on features that users might care about, like smaller download size or faster access. You also want to track the right events in analytics to make sure you know what to optimize. PJ will cover this a bit later on. So promote web install on screens where the use case makes sense, including desktop, tablet, and mobile. Take this example of Spotify's CTA from a landing page. We'll also be covering more of these as we go along. So we've covered some of the what and some of the why, and I'll continue now by talking about the how of install. Your basic requirements for supporting the installable web are to have both a web app manifest and a service worker. These are actually in 2019 pretty well documented. These are the same requirements, as we mentioned, to be called a PWA. I'll mostly be covering the manifest. For the service worker, just briefly, the requirement is that you do actually load offline. If a user clicks on your app icon while they're offline and they see nothing or an offline dyno, users will have a bad time, and so will not allow you to be installed in this case. I think you'll find some great amazing content on code loads for Google on service workers online. Oops. The manifest is a simple JSON file which basically informs your user how the site acts when it's installed. You need one per app, and you need to include a link to it from every page of your site so the user can tap install anywhere. And I'm kind of trivializing it, but pretty much all modern browsers have some level of support for this file. And including it's quite simple. You simply include a link in pretty much all your pages, as I mentioned because you don't know where your user will hit install from. One of its core parts is controlling what your launcher icon will actually look like and the start page that opens when you press it. Here's what an Android experience will be. Santa Tracker has a little green icon with a short name, and you'll see something quite similar when an app is installed on desktop. The manifest also controls how your app is loaded. For games, you might choose full screen, see the example on the right, but for anything app-like, you want standalone which won't take over the target device's UI. Websites running in any mode can still use browsers APIs to later request full screen. There's a few other options here including browser, which retains the URL bar, but honestly we don't think this is that interesting and so we think these two options are what most people will end up choosing when they configure their installed PWA. The manifest itself is pretty boring. Here it is for completeness. I won't go through every field. Like I said, there's actually tons of information out there on the web. But I want to cover some important patterns. You need to include a few icons, including one which is at least 512 by 512, and remember that this isn't your site's fab icon, so you still need to include one of those. In building Santa Tracker, one thing we really discovered was that there's no implicit internationalization support. You need to serve a different manifest for every language. And on icons, the standard also now describes maskable icons. The very short version is, if you provide an icon and indicate that it's maskable, this is a signal to the platform that it can cut your icon down to safely display crazy icon types like circles, squersicles, or teardrops, making your users feel like the app was really made for them. And with this, we actually recommend not using transparency in your PWA icons at all, because the OS is handling this part for you. Of course, this is still a bit brand new, so we recommend also loading up your app in some major environments to check what the icon will look like. There's a few more things coming in the manifest which are also worth mentioning. App shortcuts have just been added to the spec. This lets an install icon provide secondary intents, perhaps through long press. I've kind of cheated here and shown you an Android example of this case. And web share target, which we'll cover more, allows an install web app to be a target for sharing. We're also just seeing a bunch of tooling around manifests, and we think that honestly going forward, nearly every tool chain will just provide you a web app manifest, and so while we're glad you're listening, this stuff is also becoming just boring enough that it's likely handled for you, which is great for us as web developers. So as I mentioned earlier, manifests are supported by pretty much all modern browsers, which leads me on to, well, the nuances, a web developer's best friend. Let's start with Android. This was the first place that install was available, and once installed, apps are first-class citizens provided by real native APKs. Importantly, Chrome on Android is actually able to prompt your users to install if your site includes a service worker and a manifest. Santa Tracker here is actually pretty ambitious. If you take a look at this animation, even during the loading screen, it pops up a little mini info bar. It's not ideal, but we'll revisit this in a bit. Regardless, if you then tap that info bar, you'll get a full-screen prompt to install. There's a few things to dissect here, while this does say at home screen, as we mentioned, we're moving away from that verbiage as we support really so many platforms now. And as I mentioned, this generates a real APK that works with any launcher and is really a first-class citizen for users like any other installed application. Another option for install on Android is something called trusted web activities, or TWA. While this has a few details to get through, fundamentally, you're writing an Android application which features a core activity provided by Chrome or actually fairly soon Firefox as well. And you're uploading it to the Play Store, so it's discoverable and promotable like any other native app. The best way to learn more here is to be go, to go and follow Google's code labs on this. Do a search for TWA code labs to find out more. We've also got an interesting option for folks who are using Manage Play with G Suite. This means if your organization signs into corporate Gmail and devices, you can simply push real APKs that load your website by Manage Play. There's quite a few steps. This video is quite long, but if you watch closely here, I've built Santa Tracker for Work which pushes Santa Tracker to all the elves in Santa's org. So while we think this is really interesting, it's also worth noting that your corporate users will actually never see the URL that's being added to their device. You're able to push any website as a real app, not just your own. Finally, and probably most interestingly, let's talk about the how on iOS. iOS has had installable web apps since the beginning, but the last few releases have really made install on iOS quite practical. Here's an example of loading Santa Tracker from the iPad. We do have to have custom icons. This is done by the iOS Meta-icon tags, which I won't really cover here. And while they're a bit of a pain, tooling can help you generate these. Apple has also previously suggested providing splash screens. Honestly, we don't think this is that important anymore. iOS 13 has brought you nice animations and fades that make sure that your website isn't just garringly dumped on the screen. We didn't want to use one in this example. And last but not least, I also want to talk about desktop. Only Chrome provides install on desktop right now, but it works well across all platforms, Mac OS, Linux, Chrome OS, and Windows. Your sites will get this little plus button and users will get a native app that lives in their launcher. The plus button will even wiggle a little bit if you do the right thing, calling attention to the fact that install is available. Thanks, Sam. I'd like to cover some of the frequently missed details that will help you acquire more installed users. So first, a lot of companies have native apps and worry about accidentally promoting the PWA to a user who already has their app. And you may want to promote your PWA, but you want to especially target the group of people that are not your native app users. Now, keep in mind that there's all kinds of reasons that a user may not have or want your native app, but might still want the web app. Storage, for example, is the number one reason that users remove apps from their device. But most web apps are tiny, and the storage that most web apps use can be dynamically purged from the browser through either a manual cache clear or in response to storage pressure. So you may want to let users know that the web app option exists, but you don't want to create any channel conflict with your native apps. So to avoid promoting your PWA install featured in native app users, you want to use the get installed related apps, just there to help. This API is going to let you see in JavaScript if the user has your native app installed. Get installed related apps is not in stable yet, but it is in an origin trial, which is an early access program. You can still use it on your site today. An origin trial might sound scary, but all it means is that you need to register online and the API will be enabled for all Chrome visitors to your site. Probably there was some slow change that will help you with that. Only. Most PWA installs today are happening from the mini info bar. The mini info bar was only intended as a temporary shim. It's not the best user experience, and since it's generated by the browser, it really has no way of knowing whether this particular moment is the right moment to present to the user the option to install. It just shows up as soon as the site passes installability criteria and a user engagement measure. You're going to want to replace the mini info bar with something better, but we're going to get to what is better the mini info bar soon, but first you need to hide it and make sure the mini info bar doesn't appear if you don't want it. And all you need to do that is to call prevent default on the before install prompt event. Make sure that you've added the UI that you need to trigger the install prompt before you do this, though, or you will literally have no installed users after you prevent default on this. So let's look at the code for a second. The relevant line is right here, event.preventdefault, and that's the critical thing for hiding the mini info bar. Most sites, it should be a very trivial change. So let's assume that you've got a UI element in the page called install button and that you're going to want to display this install button as soon as the browser signals that your app can be installed. You don't want to show this beforehand because this button won't work the way that the user would expect it to work. This element should be hidden and then enabled, and that's exactly what we do in this next line. And finally, you're going to want to capture a reference to the install event so that you can use it to prompt the user later when the user actually clicks on that install button. And now we can look at exactly how you do that. So here's how you use that saved reference. So let's imagine that you want to wait until the user has finished some important journey that's part of your experience before you prompt them. You can use this stored handle for whenever you're ready, or the user clicks on the install button in your UI to trigger the browser's UI for the install prompt. Don't forget to instrument analytics so that you can understand your user's behavior with respect to install prompts. There's really three important moments that you want to capture here if you're analytics. So the first is when that prompt is actually available, when did the site fulfill the installability criteria, and that happens with the before install prompt event, and that's what you listen for and you can set up an analytics event there. The second is the analytics for when the prompt is triggered. If you're taking the recommended approach here and you're tying that to a piece of UI inside of your web content, then this is going to be probably a click handler on some element inside of your page. And finally, when the user has actually completed the app install, you're going to want to listen for the app install event, and this is what's going to tell you that the app install was completed successfully and the user hit OK from the browser UI. So you may be asking yourself, what about iOS? And the great news here is that iOS Safari has had support for the essential PWA ingredient service worker for quite a while now, and it's easier than ever to install PWAs from iOS Safari with add to home screen, like moving to an option on the first level menu. So here's an install promotional pattern for iOS that we're going to use for Santa Tracker. Notice how this we're basically triggering a pop-up helper to help the user through the install experience from the install button, and this is the same install button that we're going to use on Android as well. So the delta between the two experiences is really quite small. So with that, I want to talk briefly about a few different UX patterns for your installed PWAs. So Santa Tracker is pretty unique, right? It already has a pretty distinct look and feel, and your site probably doesn't. It looks like regular web page. So the uncanny valley here refers to something which looks almost correct, which is ultimately just a bit off, like this almost right dino game with some very odd UI elements. If your experience doesn't match your expectation, they might be put off. So we at Google love the web, and there's now an expectation that perhaps an installed app acts and feels like it's always been that way. And this advice isn't really unique to PWAs. I want to talk about the feeling we get when we use web apps like Gmail, Spotify, or even Google Docs. When I use these apps, I almost forget that I'm on the web. How can you help your users have that same level of immersion? There's a few tips I'd like to talk through to make your site feel more native and then lose the uncanny feeling. Focus rings are where I'm going to start. These let your user know where their cursor is. Pretty basic accessibility feature, which you should keep. But the default ring is a definite tail of the web, so mix it up, and this applies to form elements as well as links. Text selection is also probably something you want to disable, especially on UI components, because it's not an expected behavior of installed applications. Personally, I'm not ever a fan of making this UI part of a page selectable, but it's especially pronounced when installed. And set a theme color. This refers to the window color of your app, as you see in this desktop version of Santa Tracker, where it's a dark blue. By default, it's from the platform, so you don't really know what you're going to get. An over scroll, which you can see happening here, is actually somewhat related, because it can mean that three contrasting colors end up showing, and in most cases, you'll just want to disable over scroll to prevent this from happening. It's a very web pattern. As an alternative, at least make sure that your HTML tag is set to a reasonable background color that's not the default white. I'll also very briefly mention safe area inset, which if you're a fan of notches on phones, let you avoid that notch and put some color or interesting content behind that area. You'll also want to think about some UX changes. I'm going to go through these fairly quickly. First, don't allow navigation outside your own site. If you do, users will get a really ugly URL bar. Make sure you always open external content in a new window. Next, think about better behavior for extended actions like select all, undo, and redo, especially if your experience is app-like. But by default, undo and redo only apply to text elements. What if you're allowing a user to reorder a list? And finally, you might want to do something different with the right-click menu, especially when installed on desktop. The default menu includes items like Save As or Cast, which barely makes sense on some web pages. And while it's bad practice to disable this right-click menu on the web, when you're installed, there's really a license to improve the user's experience by hiding these options. So I've mentioned a couple of times the different ways that you can promote your web app. And here's where we get into the examples of how exactly to do it. So keep in mind, as we go through these, that these patterns aren't intended for every kind of site. They're examples of good patterns that you can use. But try to understand your use cases and use patterns that are appropriate for you. And please always remember the rule of thumb whenever you're prompting users about anything, install or otherwise. Don't be annoying. Let's give this a try. All right, first, the header can be a good place to promote a install of your app, but you do need to be careful here. This one comes with a lot of cautions and hand waves. These are really precious pixels. And you want to use information architecture and A-B testing to determine whether it actually makes sense for you to have an install option in the header of your site. For some apps, this will be a clear and obvious win. And for other apps, it would be completely inappropriate. That will really depend on your use case. You may want to use an icon instead of text if you want to make this action button a little bit smaller. And you might also want to consider selectively promoting only two users that have engaged with you. So for example, it could be only shown to signed-in users who clearly have an interest in the product or service that you're offering. This is an example of adding an install prompt to the hamburger menu. The great thing about using the menu here for promoting your web app install is that there's already a strong signal that the user is interested in what you're offering by clicking on the menu. And I hope that this is obvious, but you don't want to block access to any important functionality in your app with the promotion here or anywhere else for that matter. You don't want to make sure that it doesn't overlay anything or clutter up the menu design or in any way take precedence over the other actions that the user might want to take by clicking on that menu. Here's an example of promoting install via a landing page. And landing pages are explicitly about marketing your product or service. And so this is really your one opportunity to go crazy, be as big as you want. But just keep in mind that all the usual best practices for creating a good landing page are going to apply here. In particular, the most essential thing about your landing page is that the user understands what the value proposition that you're offering them is. If your install pattern is getting in the way of that, then chances are you're going to lose both a potential user and you're certainly not going to encourage them to actually install. Here's an example of an in-feed pattern for promoting PWA install. The feed cards are very common these days in many types of apps, including social and news, e-commerce, basically anywhere where there's a lot of vertical scrolling and chunk information. Don't show this promotion too often. And if a user dismisses the card, please remember and respect the user's choices here. Every apps use case is a little bit different, but there's almost always some key moment of engagement in the journey when you know that the user is truly interested and understands what it is that you're offering. And that's a great moment to ask if they want to reconnect with you in the near future. The usual rules apply here. You want to always focus on the benefit to the user and use the context of the key moment. In this example, the user's just finished a game. It's a great opportunity to say, hey, do you want to play again really easily? You can find this again from your home screen. So let's recap on the principles here. Don't be annoying. Users came to your site to get something done. If you interrupt that flow or make it any way difficult for them to get the task done that they came to your site for, chances are they're just going to leave and go get it done somewhere else. Information architecture is your friend for figuring out what belongs where and that includes for promoting install. Second, remember that if the user doesn't benefit, you shouldn't be promoting it. And finally, do use the context where is the user in their journey to help the user understand what they're actually going to get out of installing your app. If you want to learn more, you can search through the fundamental site with a query promoting install. Now, investing in a great PWA and making that PWA installable does have big benefits for user engagement. To talk about these benefits in practice, Bakun, the product manager for Oyo, consumer experience, is going to join us on stage and talk about the impact installability has had for them and their team. As a little bit of background, Oyo is the world's second largest hotel chain and it has a presence in more than 80 countries, as more than 23,000 hotels. And with the rapid growth, they have basically pursued mobile web as a key demand channel. So today, Bakun is going to take you through all that's happened with their mobile web experience and how they've grown in the last year. Please welcome Bakun. Thank you, Peter. Hi, I'm Bakun. I'm product manager for Oyo, consumer experience. And I'm super excited and delighted to share the journey of Oyo mobile web as well as how focus on this channel led to rich results for us. So if we talk about the growth that we saw in Oyo mobile web, we can talk about three major interventions that were brought about. First was PWA. This was followed by the capability as well as adoption of browser installs. Finally, the integration of TWA, that is Trusted Web Activities, really led to rich results for us. With each of these key interventions, we were able to see good sizable lift and conversion as well as key capability increase. Also, our product was made more accessible to the end users. Let me take you through each of these interventions one by one. PWA was the first major intervention for us. It provided users with key UX capabilities like offline support, reliability on different networks, which was especially important for us given the markets we were present in and also better latency. Overall, we saw a conversion lift of around 2.2x while our user base also rose by 4x. We saw a latency rise of almost 75%. Our product was optimized leaps and bounds and this was one of the first major breakthroughs which really made us believe in all your mobile web. With an already optimized product in our hands, we were looking to make it more and more accessible to the end users. This is where the capability of browser installs came into the picture. From browser installs, users were already converting by around 2x as compared to PWA. Having these metrics in sight, we were actually looking to increase its adoption. This is where we started doing a lot of ABA experiments around how to have nudges across user journeys. We started making nudges on home pages and post-booking pages in which we saw adoption increase of around 1.5x, whereas we did not see any drop in PWA conversion. Finally, this May, we released Oilite, which was built on trusted web activity. It was a major breakthrough in the world of your mobile web. Users were starting to get access to OOPWA on Play Store, which was really cool. The numbers since have been incredible. We have a similar rating on Oilite as compared to native app. This showcases the importance of core capabilities like low size, easy over-the-air updates, deep linking support, full screen, and a lot of other capabilities. Overall, we were seeing a conversion lift of 3x as compared to PWA, and our conversion was similar to the native app. To summarize, each of these interventions has brought about a good growth in our channel. From MSI to TWA, our conversion has risen by around 6.6x, which is incredible. Mobile web has been the highest growing demand channel for oil over the past few months, and we have undoubtedly benefited from all the three interventions and got a great ROI out of it. Thank you. Thanks so much, everyone. Just to invite you to come on by the Sandbox. We'll be there most of the day tomorrow. Our Twitter handles are right up here, so do please reach out to us. If you have any questions, any feedback, or feel like a good public shaming.