 Hi. I'm Pete, a developer advocate on the web team at Google. In the first video, I spent a lot of time talking about how progressive web apps are fast, integrated, reliable, and engaging. In this video, I'm going to focus on integration so that users can interact with your app in the same way that they do with all of the other apps on their device. I'm going to focus on how you can get your app on the home screen using the web app manifest, then how you can use the new payment request API to simplify payments. I want to start by talking about the center of the mobile user's world, the home screen. 80% of users have intentionally moved apps to their home screen, up 5% from last year. The top factors for this decision include how often they use the app, providing easier access, the interest in that kind of app, and interestingly, how the logo looks on their home screen. You've been able to add a bookmark URL on the home screen for quite a while, but the user experience has left a lot to be desired. It's deeply buried in the menu, which isn't always visible. And on smaller devices, you had to scroll within the menu to even find it. Then, unless the user was on the home page of the app, the link would go to wherever they created the bookmark. Imagine bookmarking a specific photo on a friend's Instagram feed. Then, every time you launch the app from that bookmark, it started on that photo. The bookmark title and icons weren't easy to change. And finally, there was no expectation from users that the app would work offline. Many of those issues can be solved with the web app manifest. The web app manifest is a simple JSON file that you link from each HTML page and tells the browser about your app. It gives you the ability to control how your app appears to the user on the home screen or in areas where they expect to see apps, what URL the app should start at, and how it should look when launched. When using the web app manifest, your web app can control the rich presence on the user's home screen with a shortened app name and a variety of icons for different screens. You can also define a splash screen that is shown when the browser spins up and is shown until the first paint happens. It's automatically built from the background color, name, and icon. The manifest is also where you define the core URL for your app, the starting point for any app launch. You can also control whether you show the URL bar. You can be launched in full screen mode and control the screen orientation for optimal viewing. I use this in an app where I display a piano keyboard. Landscape helps me make better use of the screen real estate that I have. Finally, on Android, progressive web apps behave like other native apps, switching within the task switcher. The theme color, the app bar color representing this app is also controllable. The manifest is supported by Chrome on Android, Firefox, and Opera, plus Microsoft has indicated their support for it in the Edge browser. Unfortunately, for Safari on iOS, you'll still need to use the traditional meta tags. So this is great, but we still need to fix that deeply buried add to home screen action. In some cases, the browser will automatically prompt the user or provide an indication to the user that they can add the progressive web app to their home screen. The criteria for when the user is notified differs between browsers. In order for Chrome to show the add to home screen banner, it looks for three criteria. First, the app needs to include a manifest that includes at least the name, short name, start URL, a 192 by 192 pixel or larger icon, and have a display property that includes standalone, full screen, or minimal UI. This defines the core app level experience and tells the browser exactly what to add to the home screen, what the splash screen should look like, et cetera. Second, it needs to have a service worker that provides a level of offline support. We need users to trust that these apps will work reliably no matter what their network connection is like. And finally, we don't want to prompt users in a case where it's going to feel spammy. Chrome checks to make sure that the user is engaged. So why are these seemingly arbitrary requirements necessary? Well, we feel that progressive web apps should offer a promise to the user that they'll be fast, integrated, reliable, and engaging. Let's talk a little bit about web payments. The majority of online shopping today happens on a mobile device. You can book a flight, order groceries, clothes, almost anything, and most of what's happening is happening on the web. In fact, 66% of mobile purchases are made on the web rather than in native apps. But sadly, conversion rates on the mobile web tend to be lower compared to the desktop. Mobile conversion is about one-third that of desktop. We need to fix this. We need to make the checkout flow and payments easy, consistent, and seamless. Today, unless you have an existing relationship with a site, making a purchase means filling out a checkout form. Most of the problems that lead to abandonment can be traced directly to that form. Users have to manually enter the same information every time they checkout. Name, address, billing address, phone number, pick a shipping method, et cetera. It's slow and tedious. Now, some sites try and make this experience better by splitting across multiple pages. But for users, the experience is inconsistent. Not only that, but every site has its own data entry and validation process. And different payment methods can complicate the form even more. Our first step to solving this problem has been autofill. The browser uses a number of heuristics to determine what each element is for and then automatically fill it in with the user's information. When it works, it's magical. But it isn't perfect. And sometimes it puts the wrong information into the wrong element. Autocomplete attributes are a standardized way for you to explicitly tell the browser how it should populate a given form field. The browser doesn't have to guess anymore. It knows exactly where to put my first and last name, my address, and so forth. By using the standard autocomplete attributes, accuracy is dramatically improved and users are able to complete forms about 30% faster. The nice thing about it is that you don't need to change the element ID, name, or anything like that, so it won't affect your code at all. You simply need to add an extra attribute. In this example, we're collecting credit card information. The browser knows exactly what each field is for and autocomplete can work its magic. We have a list on web fundamentals of the more common autocomplete attributes. If you want to see the full list, you can find a link there to the spec with every single attribute. Autofill gets rid of the manual nature of data entry and makes it much simpler for the user. However, it's still fundamentally based on the same kind of existing checkout flow, entering a lot of data usually in multiple pages. The web checkout process needs to be reinvented. The current checkout experience presents you with a form to fill out every single time. For users, though, the ideal experience would be that when it's time to buy, they just buy. Sites should be able to focus on creating an amazing and engaging shopping experience without worrying about optimizing a long checkout form. This is where the new payment request API comes in. When it's time to pay, the user just pays. It's a W3C standard to eliminate forms for users and standardizes payment collection for sites. It allows us to request payment information and more with a single API call. The browser simply acts as an intermediary, collecting the information we need in a consistent way, then returns a JSON object to us with the results that we can then use to collect the payment. Let's see how it works. When the user's ready to checkout, they click the checkout or buy now button, which invokes the payment request API, where you specify what data you need and show the payment request UI. Within this UI, the user can quickly provide the necessary information. For example, shipping details. If you need them, the shipping method, again, only if you need it, and their payment method. The payment method can be credit cards or one of the apps that are installed on their device, such as Android Pay. And finally, they click Pay, and it's time for you to process the payment information. The payment request API is designed to be flexible and fit your payment flow. If you only need payment info, no problem. If you need payment and shipping, it can handle that too. It's supported today in Chrome and both Microsoft and Firefox are actively working on it. To be clear, the payment request API is not a new payment method. We're not trying to build a Chrome pay or become a payment processor, gateway, or anything like that. You still need to collect the payment. It just simplifies the information request, then returns adjacent object with the results. With the payment request API, checkout forms are eliminated, making the entire checkout process lightning fast. And since the browser is actually taking care of collecting the payment information from the user, we go from end taps to one tap. Let's take a look at the checkout flow using the payment request API. To show the checkout flow, we need to create a new payment request object and pass three parameters, payment methods, transaction info, and a set of options. We need to tell the payment request all the ways that we can get paid. For example, what credit cards we accept and if we accept Android pay or not. The transaction details include the core details of the transaction, how much money, what currency, and what list items you want displayed. Keep those line items fairly high level. It isn't meant to be used as an itemized receipt. And finally, keep in mind, the payment request API doesn't do math, so you'll need to add everything up yourself. Adding shipping methods is optional. By default, payment requests will only return payment info and for some merchants, that's all they need. But you may need more. Setting these options allows you to customize the flow and collect the info that you need for your flow. We're now ready to show the payment request interface with the dot show method. The browser then determines the intersection of payment methods supported by the site and payment methods that the user has and shows the payment interface. Once the user hits pay, the dot show method responds with a promise returning a payment request object. The payment response object contains everything needed to submit a payment. For credit card payments, the response is standardized and contains card holder name, card number, expiry month, expiry year, card security code, and billing address. For non-credit card payments, for example, Android Pay, the response will be documented by the provider. We can then send that information to our payment processor to collect the payment. The UI will show a spinner while this request takes place. Then, once the payment has been collected, the complete method tells the browser the payment is complete and allows the app to notify the user of the result and close the payment interface. And that's it. You now have a seamless, easy to use checkout experience. Okay, quick summary. Make it easy to complete forms by providing the right set of auto-complete attributes that enable autofill. Progressively enhance your checkout experience with the Payment Request API. And, of course, there are plenty more ways that you can provide an integrated experience. For example, if you're a media app using the Media Session API to show what's playing and handle media-related events from the user, using the Presentation API to cast to the screen of a presentation device, sharing content to other installed apps via the native sharing widget, and more. As you build your app, remember, users expect to be able to interact with your app in the same way that they do all of the other apps on their device. Check the description for links to the slides from this video and some of the other links that I shared. Up next, we'll dive into service workers and the key concepts behind building reliable experiences.