 Developers want users to install their apps. But users only install apps if they install the experience, it's better. If they understand what benefits they are getting. Let's figure out a way to make both sites happy. My name is Adriana Jara, a developer relations engineer for Chrome and the web. In this talk, I take you on a journey through PWA installation. It includes new features, developer experience improvements, and the tools available to build those features that make users click the install button faster than ever. One tiny prerequisite. To invite users to install our app, we first need an installable app. So if you don't know what a PWA is, you might want to check out our course at web.dev.slashlearn.slashpwa, and then come back for the rest of the talk. Now a little spoiler alert. Which features in a specific we build to encourage installation depends on the purpose of our app and our users. So I'll walk you through our options with a live demo I built, a PWA called Rosie. Rosie is a broad counter for needing. Users save their projects and keep track of which row they are currently needing in the pattern. It also uses capabilities like app shortcuts, sharing, notifications, and more. Now let's go check out those features. Not too long ago, it wasn't possible to install a web app. These days, we are mostly over that horror. And developers have a clear path to make websites installable. To implement that basic flow, you can follow the code lab on the screen. Now the web platform is moving towards making it easier to install web apps. And as our apps become easier to install, we as developers should guide our users by creating our own custom install flow. Rosie has its own install button and tooltips to guide the user to install the app. With our very own custom install experience, we can choose when to prompt the users to install, when they are engaged and likely to keep our app. Another advantage is that we can collect metrics along the process to continue improving their experience. On the screen, there is a link with instructions to create your custom install experience. Getting to a good, installable experience for the web is important, because we do see user engagement increases when companies leverage their web experience and make them installable. That was the case for BliBli, an e-commerce site from Indonesia. With their PWA, they saw a 42% decrease in bounce rate and an increase of 10X in revenue per user, compared to their mobile site. You can read all about it with the link on the screen. The company, MichiPay, also saw an increase of 10X transactions with their PWA, compared to their platform-specific mobile apps. In their case study, linked on the screen, you can read how the PWA reduces friction for users that want to try out the application. While we are still speaking of installations, users are not used to installing websites just yet. They might be wondering what happens when they click that button. And because the web is multiplaing, and because the web is multiplaform, the installation process might look different on desktop and on mobile, and the default browser prompt doesn't explain much about your app, which makes it important to take advantage of any chance we get to give the user some context. On mobile, you can use the richer install UI to give the users a better idea of what they get when they install your app. Here are Rosé's beginnings with just the default browser prompt. And now, using the richer install UI, you configure the richer install UI via the manifest fields, screenshots, and description. Twitter also did the switch to the richer install UI, and we can see how adding those two fields in the manifest provides more context to the user and provides a space for developers to showcase their app's features. Here we have the prompt collapsed for minimal interruption and expanded once users click on it. This feature is still evolving, and we hope it will expand to other platforms. There is more information on this article and a call for feedback so you can help make this feature even better. One of the reasons we want users to install our app is that it opens new ways to engage our users. One of those features the operating systems offer is run on logging. It's been available for platform apps for a while because users want to automatically run a set of applications they always use. Typical examples are high engagement applications like email clients, chat apps, and monitoring dashboards to name just a few. Now it is available for web apps as well. And this is one of those features that we as developers can't turn on automatically for our users. But if your app falls in this category, you could help users discover the feature by adding instructions in your settings or a dialogue for users to find and toggle the option on their browsers. For more information, follow this link. Okay, with a good install flow build, let's dive on to the next step, making the installation worthwhile for users. Since it turns out that just because users can install an app doesn't mean they will. We need to build features that make users want to install the app. Our next stop is another core PWA feature, offline support. We often talk about it as a requirement for installation or a nice to have, but we don't talk about how it makes it possible to use our app in more situations. It is likely that you can't offer your entire app's functionality without an internet connection. Full offline support could take a lot of infrastructure changes and a big effort. But probably with fewer changes, maybe saving some data locally and syncing it when the user is back online, we could offer a feature or two that users can still enjoy even while on airplane mode. Rosy is a small app with a small set of data. With a few lines of code, some caching recipes, and a little local storage, the entire app's functionality is available. But providing offline experiences is not limited to small use cases. We have the really cool feature in YouTube of downloading videos and accessing them at a later time. When our connection is not the best or bandwidth is expensive. As I was saying, this feature makes it possible to use YouTube in situations where it wasn't possible before. We can catch up on videos where we are on the subway, where reception is spotty, while on our airplane or going through any spot without a reliable connection. To implement an offline experience, you will save assets locally using a cache or local storage like index TV, and use your service worker to serve the content from the storage when the user is offline, or when using the cached assets is the best option. And if you add syncing data when the user is back online, you also need to use background sync. Serving resources from the local storage tends to be faster, since we are avoiding or postponing a trip through the network. So when we use these techniques to offer an offline experience, we can also get advantages even for online users. To implement offline features, I recommend using Warbox. It is a set of libraries that will help you with configuring your service worker, storage and sync to provide an offline experience and more. Moving on to another feature that we probably talked about before, but don't always improve upon and don't often present to the user with all its benefits. Let's talk notifications. Hear me out. I know implementing notifications for web apps has not been an ideal journey, not for developers or users. But timely notifications are welcome. Think about notifications you like. For me, some of those are calendar notifications, reminders when a subscription is about to expire, and lately, I'm into board games. And I particularly enjoy a PWA called Board Game Marina that notifies me when it is my turn in a game. Just like this, there are endless use cases that users appreciate. We, as developers, can offer notification controls and guidance so users can configure notifications according to their preferences. Include dialogues or tool tips that let the user know how to turn on notifications, and that they will see the browser notifications dialogue. Also, let them know what benefits they are getting from turning on notifications, like this example from Google's chat app which specifies users will have to click on the current dialogue and once again in the browser dialogue. Rosie also uses notifications to remind users to need once a day, and it uses another good practice, that is to let users configure their notifications. For this, you can create your own notification settings in a page or menu, where the user can enable or disable notifications and where you could add more instructions on how to use the feature. I have on the screen an example of Google Chat's notification settings page. There are several ways to add notifications to your app. In general, you'll add UI elements to enable them, have a server to send the notifications, and probably use your service worker to process the notification. You can check the specifics with the link on the screen. Notifications go well with the badging API, because this API also lets users know that something is happening and they should go to our app. Using this API, you can add visual indication to your app's home icon. It might show a circle with the number of on-read notifications or it can indicate a pending task with a little dot. You can see Rosie's example on the screen. To add the little dot with the optional on-read count, you call the method setAppBatch, and to remove the indicator, you call clearAppBatch. You can call this API from the current page on your app or using your service worker. There is guidance for the different scenarios in the article on the screen. So far, we have an app with a custom install flow that works offline and provides configurable notifications. What else could we add? How about increasing user engagement by sharing with other apps and users? In Rosie, we can share our progress via a text message or create a post on social media. We could also register the app to receive data from other apps, and we could add photos to projects or maybe save a file as a pattern. To share from your app, first, the action needs to be initiated with a user gesture, like a click on a button. Then you'll check if the share function is available in the browser. And use the share method to pass your sharing data. In this example, to share text in a URL, the share method receives an object with the properties, title, text, and URL. Sharing files is also possible. Notice that now we are checking if the can share function is available. And the data object passed to can share only supports the files property. With this API, your app can share image, video, audio, and text files. Find implementation details and browser support in the link on the screen. With the WebShareTarget API, we can also register our app to be the receiver of the shared data. We start by configuring the shared target member in our manifest. For handling basic text, it would look like this. As you can see, you specify the URL to the page that will handle the shared data in the action field. I will point out here that the action page that will handle the shared data should work offline. You don't want users choosing your app and then not being available to process the data. So you might want to go back and revisit the offline section in this talk. Also notice here that the values for the fields, title, text, and URL are the same names, but they don't have to be. If you remember from when we were the ones sharing title, text, and URL are the keys in the shared object. But if instead of title, when I process it, I want to call it name, or if instead of text, I want to call it body, I can do that. It would look like this. When the app receives data, the browser opens a new window at the action URL, and here is where the naming of the fields in the manifest connect. The browser then generates a query string using the URL encoded values supplied in the manifest. So if we kept the values, title, and text, the query would look like this. If we change the values to name and body, it would look like this. Then to process the data, we use a DOM content loaded event listener in our action page and parse our query string like this. For instructions to receive files and more information, check out the link on the screen. Next feature app shortcuts. With shortcuts, users navigate directly to specific parts in our app from our icon on the device's home screen. They don't have to go through our navigation, instead they land straight to the point they have in mind, saving time and simplifying access to actions. Rosie uses shortcuts to go directly to notification settings, open the start project, or start a new project. All of this without having to go through the app's homepage. In PWAs, they are implemented via the manifest member shortcuts. It is an array where you define each shortcut by specifying their name, short name, icons. These fields will form the menu that the users see, and we also specify a description and the URL that the shortcut goes to. In general, think about providing shortcuts for actions users frequently do, depending on your app, of course. Some examples could be start a task, view orders, go to your cart, compose a post, and many more. To find the exact implementation details and browser support, follow the link on the screen. With the window controls overlay, developers can do customizations directly in their window title bar. I used it in Rosie to have the counter for the start project displayed in the bar. I really love some creative uses I seen for this feature, from controls for media players, adding some reminders directly to the toolbar, and many, many more. Check out the documentation to customize your window title bar in the link on the screen. Moving on, it is really important to be able to uniquely identify an app within a platform. And for PWAs, browsers used to rely on the app's manifest file path or on the start URL, which made life really hard for developers since they couldn't change the value of those fields without the browser treating their app like a brand new app. Luckily, the platform implemented a way that developers can uniquely identify their own apps by adding an ID to their manifest, which removes the previous restrictions, giving them more flexibility. The ID field is supported on desktop browsers right now, and support is being implemented for mobile. There are a couple of cabits to adding your ID, so go and consult the article on the screen before you add it. The web is wonderful because of its reach, because it is truly multi-platform, and now it is getting more integrated with the operating system, making it possible for users to start using your app right away and get extra features when they install it. And the feature list is growing. I didn't even have a chance to go over file handling, one of those features that are coming. File handling will allow PWAs to register as handlers for specific file types. So in menus like Open With, PWAs will show as an option. You can check more about it in this link. As I mentioned before, you are the one that knows what it is best for your users and how to invite them to keep your app on their devices. But know that once you have decided what features to build to improve your user's experience, we have created resources to help you make the experience come true. For a complete course to create a PWA from start to finish, you can visit web.dev.slashlearn.slashpwa. For basic information about PWAs, you can visit web.dev.slashpwa. Muchas gracias. Hasta la próxima.