 Hi. Good morning. Morning. So my name is Owen Campbell Moore. And I work to try and make the web a more powerful platform for applications. So on the Chrome team, we believe that progressive web apps should provide an immersive and integrated experience on all platforms and operating systems. And I'm going to be telling you all about that today. But to get started, I want to tell you a story. So cast your mind back to 2012. So this is me. You can tell what I was missing in a haircut I was making up for and having a big idea. So my idea was to create a messaging app for the web. So I wanted to create something that would work across platform. It would work on all devices. I wanted to build something with JavaScript, because JavaScript was the cool thing. And I really liked the openness that the web provided. So I was really excited to build this. Actually, you can see I think my friend is a little less convinced about my idea than I was. But OK, so here I was, starting off on my journey. And as I started working on this project, I quickly ran into a problem where I found that my new great messaging site didn't work offline. And as you might be able to tell from my accent, I'm from the UK. And at the time, I was taking the London Underground a lot. And so not being able to read my messages offline was a deal breaker for me. And so this was the first struggle that I ran into. And so I looked around at all the different possible solutions. And I found something called Mobile Chrome Apps. So Mobile Chrome Apps let me take the content I'd already built, this web content, and kind of package it up into a Chrome app that users could install on their desktop or install on their mobile device. So it would still run everywhere. But it wasn't actually available on the web. And something that I didn't really appreciate at the time was that because users now had to install it to use it, about 90% of my potential users were just going to hit the back button when they land on the store page. They never even get to experience my great app. So there was a downside there, which I didn't even realize at the time. But I migrated over and everything seemed to work until I got to implementing notifications. And I discovered that Mobile Chrome Apps actually didn't support notifications at the time. And obviously, it's a messaging app that's kind of a big deal. And so again, I'm back to the drawing board. I'm looking around at the other possible options. And I find Cordova. So for those of you that don't know, Cordova is this tool that lets you, again, take some content that you've built for the web, kind of wrap it up and package it for mobile. So now in this move, I actually lost desktop support. It now only worked on mobile devices. But Cordova supported notifications. And I could still write JavaScript, so that was pretty cool. But in the process of doing this migration, something else happened. The sound in my app just stopped working. I kind of puzzled at this. And I was wondering, is it because of the way I'm shooting the audio file, because now I'm kind of bundling everything instead of serving it from the web, is there a problem there? It actually turned out to be more fundamental than that. The problem was that Cordova is based on WebView. And WebView actually is kind of fundamentally different to the browser in some ways. And it turned out that WebView just didn't support the HTML5 audio tag. So that was fairly disappointing. And I had to look into different kind of hacks to get around that. It turned out that there was a Cordova plugin for audio. So I was able to pull that into the project and get the audio back up and running. But now it's kind of getting a little hacky. It didn't feel too great. But I got past that. And I'm back to implementing my notifications. And then this happened, Java. So it turns out that although Cordova does support notifications, and that's what I'd established, I didn't realize that you actually have to implement them writing native Java code. You weren't able to write them with JavaScript. So I'm now at a point where I've set off on this journey to build something cross-platform with JavaScript that's open and works on the web. And I've built something that's not cross-platform. It just works on mobile. It wasn't all built with JavaScript. And it wasn't open. It wasn't served on the web. And so this is roughly where I ended up at the end of this journey. But I had a bunch of realizations during this process. And I learned a bunch of the problems that existed. And I was really determined to try and help solve those problems. And so the problem actually that I really ran into was that all of these issues were fundamental in web standards. And anyone here that has experience in standards would know that when you run into an issue with standards, you'd mostly back away slowly and try and go and find something else. I was young and foolish, and so I didn't do that. And so if we fast forward a year, this is where I ended up. Again, the haircut is still lacking. And in fact, if you are wondering, this is still my current employee badge photo that I carry around with me all day. And yes, if you're wondering, I do avoid walking around the campus on bring your children to work day just in case people think I'm lost. There's a good story about that. Ask me about it later. So I joined the Chrome team. And when I joined, we were really laser focused on three areas, offline. So on mobile devices, users don't have this reliable wire straight into the internet. And so it's just table stakes that sites must work reliably when you're moving in and out of elevators and through buildings and in the subway. Next was notifications. So notifications obviously on mobile unlock a whole new range of applications. So this was really important to bring to the web. And third was installability. Opening the browser and typing in a URL is really fiddly. And on mobile, the power to open your home screen and tap an icon is really important. And so we knew that we needed that on the web too. And so today I'm going to start by giving you an update on installability. So I'm excited to share with you that today what we call improved add to home screen is now launched to 100% of Chrome for Android users. So improved add to home screen integrates progressive web apps deeply into Android. So here you can see Travargo. And you can see an add to home screen banner. And when I tap add, not only do I get an icon on my home screen, but it shows up in my all apps drawer just like any other app. It shows up in the Android system just like any other app. And it integrates with Android. So when I get an email from a friend about a trip with a link to some hotels and I tap it, it just opens in the Travargo progressive web app, which is exactly what you would expect. We're also working on what we call the add to home screen modal flow. This allows sites to take more control of their install experience, provide their own upsell UI. And when the user taps on it to request that the browser show a confirmation dialogue to the user. And this is something that's coming soon. So those are just some of the ways that we're integrating the web more deeply into the Android operating system. But what about integrating the web into Android apps? So today, apps can use custom tabs, which essentially allow them to provide a simplified browsing experience for users looking at third party untrusted web content. For example, you might tap a link on an article in a social app and you'll be presented with this simplified browser showing the news article. But what about content that isn't arbitrary, content that isn't third party, and content that you trust, content that's from you? Do we still need the simplified browsing experience? And so this is the question that led us to today introducing what we call trusted web activities. So Ben highlighted trusted web activities in the keynote today, but I'm excited to give you a deep dive on it now and tell you what it is, how it works, and what it means. So on a high level, by launching a trusted web activity, any new or existing Android app or Android Instant app can include content of their own served directly from the web. So long as it's from the same developer, of course, so long as it's trusted. Now that web content is powered by the same modern and up-to-date web runtime that the PWA in the browser is. So advanced features like Service Worker and the Push API just work by default. And you don't need to use a tool like Crosswalk to bundle a whole web browser with your app just to render this web content. Now naturally, the app is able to take advantage of everything Android has to offer while the embedded web content continues to be always up-to-date, small on disk, and shared across all platforms. So for today's event, we've created a Hello World example where we embed the Polymer News PWA content that we've already built. So let's take a look. So first to get this project to work, we had to set up digital asset links. So this is how we attest that the Polymer News PWA web content is owned and served by the same developer as the app that we're building. So we set that up, and then we set up an Android manifest. And you can see here that we've taken advantage of new features in Android Oreo, like shortcuts. So now once the user opens our app, we want to go ahead and launch a trusted web activity to our site. So here, because trusted web activities is based on custom tabs, first in myactivity.java, we set up custom tabs just like we would normally. And then once the custom tab service is connected, we go ahead and launch a trusted web activity. So most of this is just boilerplate. The really important line is the one at the bottom where you can see we're launching as trusted web activity and we're passing in the URI of our site. And so that's really all it takes to get running. And here you can see what it looks like. So this is content that's loaded on the fly, powered by the same browser that the PWA runs in. And thanks to ServiceWorker, the user can browse the news here even when they're offline. And because it's an Android app, we can take advantage of great Android features like in-app billing to set up subscriptions, as you can see here. So we'll be releasing a preview of trusted web activity support in Chrome's dev channel very soon, and the full documentation will be available this Wednesday. So trusted web activities will be available through the Android support library, so other browsers will be able to support this as well. So we'd love for you to try this out and let us know what you think. So if you're like me, you're now looking at this and wondering, what does this mean for add to home screen? So in essence, improved add to home screen is still how users get your progressive web app on their device. This now just opens up new patterns for how you can integrate the web into your Android app since you can now take advantage of all of that app-like web content that you've already created. And if you do build an Android app that contains some of your web content, and instead of having users add the site to the home screen, you want them to install this app that you've built that uses the content, you can set up the appropriate metadata in your web app manifest, and Chrome will show this native app install banner instead of the add to home screen banner so your users can easily install the app straight from the site. So we're really excited about what trusted web activities means for your ability to make the most out of your web content and for the new installability patterns that it creates. Web app installability is evolving across the whole ecosystem and to tell you more about how they're improving it in Mozilla Firefox, I'd like you to join me in welcoming Andreas Bovens from Mozilla. Thank you. Hi, everyone. My name is Andreas Bovens and I work as lead product management at Mozilla. I focus on Gecko and on Firefox for Android and it's absolutely fantastic to be back here again at the Chrome Dev Summit. So let's dive straight in. For a long time, Mozilla has been very dedicated to implement support for the various technologies that power progressive web apps. We've added support for service workers and push back in Firefox 44 and we've been heavily involved in the editing and the specification and the standardization work that has gone in the web app manifest specification. However, thus far, we didn't have an implementation yet that was using the metadata that are provided by such a web app manifest. So it's my pleasure today to announce that very soon Firefox for Android will ship with add to home screen support. We're not doing this exactly the same as you might have seen in other browsers but instead we're following a batch approach. If a site is served over HTTPS and it has a valid manifest, a subtle batch is shown in the address bar and when this batch is tapped, the user gets an option to add the site to the home screen and then of course when the site is launched from the home screen, it's shown in this nice stand alone or full screen, more immersive mode, integrates nicely with the task switcher and so forth like we get to know, I've gotten to know from progressive web apps. But we didn't stop there. We went a little bit further and we tried to think a lot about how to deal with external links. External links included inside of progressive web apps. So for instance, you might have used the Twitter Lite progressive web app and of course you see it in a stream of tweets and from time to time such a tweet will link to external content. So the question is what to do with this external content? You want to signal to the user that, hey, this is not anymore within the scope, the original scope of the progressive web app, we're actually going here to an external site. So an option would be to launch the full browser and load the link there. But we found that that was not very smooth experience, it was a bit disruptive and so we decided to look at custom tabs which seems like the perfect fit for this kind of use case scenario. So what happens now is when you tap an external link in a progressive web app, install through Firefox, you will open this external content in a custom tab and it's really smooth to move back and forward between the progressive app and the external content. And Chrome has also followed a similar approach and I believe that Owen later on in this talk will cover this as well. So what is next for Firefox for Android? You can expect further improvements to add to home screen, we're not done yet, we're still trying to tweak a number of things and we're also working on support for new APIs. We're working on, well, we'll be shipping soon, background sync, we're working on payment request and we're also looking into web share and a number of other APIs. So if you want to try this out today, it's available in Firefox Nightly from Google Play. At this point, you still have to go into the settings in the advanced section and turn on support for progressive web apps. But of course, once it hits the final version, expect it to be in January 2018, this will be turned on by default. And so try it out and let us know what you think. Thank you very much. Thanks, Andreas. So now I want to tell you about what's happening in the rest of the ecosystem. So if we turn to Samsung Internet, in Samsung Internet, they've also shipped a feature that will indicate to the user when the site they're on is a progressive web app. So here you can see the normal browsing experience with the normal bar at the top of the screen. But when the site is a progressive web app, the bookmark icon changes to a small plus. And when the user taps it, they're given the option to either bookmark it or add it to their home screen. And so this is just one more great way for users to discover and install progressive web app content. And now turning to Microsoft and Windows. So Microsoft have announced that they will be listing progressive web apps in the Windows Store. And so here you can see a screenshot of jig.space. Yeah, round of applause for them. So here you can see jig.space, a progressive web app, listed in the Windows Store. This is a great progressive web app that's a platform for 3D content and works great everywhere, and especially on Windows, thanks to this new discoverability. So now turning away a little from installability and installability in the ecosystem, I want to tell you about what's going on in the new APIs that are available to allow sites to more deeply integrate with the browsers and operating systems. I want to start by talking about APIs for social web applications, like the one that I was originally trying to build. So with any social application, one of the most key features is the ability to upload photos. Now unfortunately, until now, the experience of uploading photos on the web has been a little lacking. So when you tap on a site to upload a photo, you typically get an experience something like this. Here I'm being shown a dialogue to choose an action. And my options are camera, camera, or files. I mean really like what's going on here. So if I do add, well, actually this is frankly best case scenario. This is a screenshot that I took a few weeks ago on another Android device where I was given the option of Android system, photos, gallery, and Zedge. And so this is not the most highly polished user experience. And if you do actually go ahead and tap through to pick a file, often you're presented something like this. It's a dialogue really designed for picking files from your file system, not optimized for uploading that selfie that you just took. And then if you do want to upload a second photo for any reason, naturally we're always uploading our selfies in batches. My friends seem to love these. You're back to where you started, you go through this cycle again and again of going through these dialogues. And so it's very frustrating. So I'm really excited to announce that this week, we're rolling out, oh, pfft. Yeah. This slide really, yeah. So this week, I'm really excited that we are rolling out a new image uploading experience. And so here it works just like you would expect. When I'm on Twitter and I attempt to upload a photo, it takes me straight into a gallery of my images. I can pick one, two, three, five, doesn't matter how many, hit done and we're done. That's it. Way better than before. And so this is rolling out just this week, so keep your eye out for it. And you know the best thing about this is actually for most sites, you'll just get this for free. No change is required. The only thing that it requires is that your input type equals file element on the page specifies an accept attribute. That only accepts images. Obviously if you are looking for zip files or something else, we're not gonna present this flashy new image picker. But if you just specify images, you'll just get this dialogue for free. And so this is a great time to just go and check on your site that you're setting the accept attribute on your input type equals file elements. So that's uploading images. But what about taking images? You know lots of new social applications have these rich image capturing experiences built in. So this year we've launched a new image capture API which allow you to really use the photo taking pipeline on the device. So previously you were able to get a video stream out from the camera and then take snapshots from it. But most hardware can provide much higher quality, higher resolution images via a more dedicated image photo taking pipeline. And also we now have the ability to customize things like the zoom, the ISO, the flash, all of the different aspects of the camera that we'd like to control. And so this API has two main modes for using it. One is to customize the stream coming in off the device. So for an example of that, you might be customizing the zoom and showing the preview on the screen and allowing the user to pinch and zoom. But there's also a mode where you're just setting a property when taking a individual photo. So something like flash is in it or red eye reduction is something that just happens when you take a photo, not just on the stream. And so let's see an example of using that. So the first thing that we do is we ask the device what the capabilities are of the hardware. We do that by calling image capture dot get photo capabilities and that will return an object that tells you what fill light mode options are available, what red eye reduction options are available. And then based on that, you can call image capture dot take photo and specify whatever customizations you want. So here I'm telling it that we want the flash. And if you go ahead and try this, you'll find that it works just as you'd expect. So next is the background sync API. So the background sync API allows you to guarantee the uploads complete successfully. So if you are building a messaging app or you're building some kind of a social app like Instagram, when a user wants to post a photo or send a message, you want to make sure that it makes it up to the server, even if the user's on a flaky network or offline. And you don't want them to have to sit there staring at the site as it continually retries. And so here you can see that Instagram's mobile site have implemented this. So when you go offline, you'll see a banner at the bottom of the screen telling you they are offline, but you can still post photos. If you go through the flow and you choose a photo to upload, you can then close out from Instagram and later you'll get a notification when you reconnect to the internet, telling you that your photo has now been posted. And so this is a really great pattern that you can use to ensure really reliable networking within your application. It's really easy to use. So I'll show you quickly how it works. Within your main page JavaScript context, when you realize that the user's offline and you're trying to send something, you have to store whatever you were trying to upload somewhere persistent. In this case, it's the image and the metadata you're associated with it. And you'll store it somewhere like the indexed DV or in the cache API, which actually is my favorite place to store rich data. It's a nice key value store that you can use. So first you're going to write those data to the disk and then you're going to tell the browser that you want it to fire an event in the service worker when the user reconnects to the internet. So to do that, we get a reference to the service worker registration by calling await navigator.serviceworker.ready. And then we tell it, we call serviceworkerregistration.sync.register and we give it a tag. So then later when the event is fired, we know what we're supposed to be doing, what we'd scheduled this sync for. And then in the service worker, it's really simple. You listen for a sync event. You look to see what the tag was so you know what you're supposed to be doing. And if it's upload image, you're just going to pull all of the pending images and data that you wrote to the disk and upload them to the server with a fetch request. Now there's one problem with this, which is that the browser actually doesn't have a way of knowing when you're done uploading and so it doesn't know when to kill your service worker and stop it running on the user's device. And so to solve that, what we want to do is tell the browser to wait until we're done and keep the service worker alive until our upload is complete. And so to do that, we call event.wait until and we're going to just return a promise that will resolve when the fetches are complete. And that's really everything. So next with applications, we're sending notifications these days and it's really great to be able to build really immersive notification experiences on people's devices. Here you can see again, I'm showing my British bias, a screenshot from The Guardian when they were showing live election updates for the UK election. And they made this great updating graphics that would show in the notifications and they would give me buttons to say stop or give me more information. So this is a really great experience. It's super simple to use in your service worker when you call registration.showNotification and you provide the title for the notification. You provide a whole bunch of different options for showing the notification, including an image, which is just a URL and an array of actions. In this case, I'm just showing what it would be to add a like button on the notification and that's really all there is to it. So now I want to turn from social and talk about publishing a little bit. So one of my favorite new APIs that you can use in publishing is the Web Share API. So obviously having users sharing articles and content is really important. And with the new Web Share API, you can integrate directly with the native Android sharing system. So here you can see a screen, a gif of VOOT's progressive web app running in the browser and when the user taps the share button, it shows the native Android share dialog just like you'd expect. This is simple to use. All you do when the user taps the share button, you check whether navigator.share is available in the browser and if it is, you just call it and you pass in the data that you want the user to share. So then in publishing, another important aspect is linking out to third-party content and again like Andrea showed earlier, Chrome supports this using custom tabs from progressive web apps. So any navigation that crosses the scope of the progressive web app will be shown in a custom tab. So now what about shopping and travel? So with shopping and travel, payments are obviously a really fundamental problem. The manual, tedious, slow and they involve lots of tapping and can create a really frustrating experience. So in the last couple of years, we've brought the payment request API to the web which allows the browser to facilitate the collection of checkout information from the user, especially for users that aren't signed in to your web app. The browser already knows who the user is and likely knows their email address and has their shipping information stored and so it can help provide all of those things by default. But until recently, payment request was only available in Chrome for Android but this year we're announcing that payment request is available on all platforms across desktop and Chrome for iOS. And in fact, if you use feature detection to tell if this is available and to use it, these will just, you'll get this for free without any changes required. Now using the payment request API is really easy. You instantiate a new payment request object, you tell it what methods of payment you support. Here we're just saying basic card which is used for credit cards, debit cards, et cetera and you tell it how much money you want in what currency and then eventually you go into call show on that object that you've created and you get the user's information back in response. And so this doesn't actually carry out the payment, it just gives you all of those details. It gives you the shipping address, it gives you the credit card information that you can then go and use to process the payment. Now just this week, we've now announced the ability to use pay with Google using the payment request API. So pay with Google means that any payment method that the user has supported in their Google account will now be be able to be used just in one tap via the payment request API. So this includes things like Android Pay and any credit cards that they've added to their Google account. So this is incredibly easy to use. All you do is you swap or you add another supported method of google.com slash pay. And here you can see it working when we're on a site let me just wait for it to loop back around. So when you're on a site and you're going to check out on something, you get presented with the normal payment request dialogue and then you see the new option pay with Google. And so once you choose your shipping address and hit pay, the user can now pick from whatever payment options that they have listed in their Google account and just take that payment. And so you can follow this link at the bottom to find out more and find out how to use pay with Google with the payment request API on your site. So turning away from payments, identity is another really important aspect to shopping and e-commerce sites. And when talking about identity, we need to talk about the Credential Management API. So this API means that once the user signs up somewhere on any one of their devices, you can keep them logged in across all of their devices. Now this is great, but the problem is that some browsers don't yet support the Credential Management API. That's why today we're announcing one tap sign in in every browser. So this is a new library from Google, a new library from Google based on the Credential Management API. So let's take a look at how this works. Here you can see it with Zillow and this could be any browser, even those that don't support the Credential Management API and I've never signed into Zillow previously on this device. But I can, when I'm on the login screen, I'm showing this dialogue at the bottom. I can tap a single button and now I'm signed back in with my existing account. This is really easy to use. You just call await smartlock.retrieve and you pass in what supported authentication methods you have and it just returns a Credential for the user when the user taps the button, which you can then send up to the server to start the session. Now this works really great for keeping users signed in, but if they're just on your site viewing a product or browsing flight options, there's a good chance that they've never actually signed up for your service in the first place. And so if they swap to another device to continue that session, but they've never signed up, you can't actually continue that session over. That's why today we're also announcing one tap sign up for the web. So as the name suggests, this means that you can get users signed up in just a single tap. So here you can see that I'm using Hipmunk and that I'm being prompted to sign up with an account in line. I simply tap continue. There's no jump to an account creation page. I accept Hipmunk's terms and conditions, and I'm signed up. And now I'll be kept logged in across all of my devices with or without the Credential Management API. So we believe that this will have great impact for many developers, and the early numbers that we've seen indicate that it can increase the signups for sites by two to three X. This is really, really easy to use. All you do is you call await smartlock.hint, and again, you pass in some options. It gives you back a credential as soon as the user has tapped, and you can send that to the server. You can present them with the terms and conditions, whatever you want to do from there. So that's one tap sign up and sign in, a new library from Google, and you can find it at developers.google.com slash identity today. So now I want to talk about media on the web. So with the Media Sessions API, you can now integrate your media on the web with the user's operating system and devices. And so here you can see that because I was playing some media content in the browser, I get this rich notification to control the playback of my Android device, and it comes across to my Android Wear device. Super simple to use. You just call navigator.mediasession.metadata, and you set the metadata that the user should be seeing. And via this API, it's even possible to make the media be controllable, for example, from the Google Assistant on different devices to where it's playing, which is really great. Now the media story on the web continues to get better and better thanks to new features like Media Sessions and offline video playback. Now there's so much to cover in this space that we have a whole dedicated talk to this later today, so go and check that out for more. So now to bring it back to where I started on this journey. I'm excited to say that I did the analysis a couple nights ago, and I found that I can actually build the whole original web app that I wanted to build entirely with the web in JavaScript with web standards cross-platform, which is just really amazing. Okay, and so since they did give me the stage to talk to you today, I would be remiss to not tell you about one more thing. So we've been talking a lot about mobile in the last year or two on Chrome, but today I want to give you a sneak peek of how we're starting to look at desktop. So here you can see at the bottom of the screen a YouTube icon in my shelf, showing up just like an app. And when I launch that, you can see it running in an experimental version of Chrome that can run any PWA, just like a native desktop app. Now, this isn't yet ready for primetime, but we're really excited to explore more with what we can do with it in 2018. And to close, I think that given that even Apple recently announced that ServiceWorker support is soon coming to Safari, we're truly living in a time where progressive web apps can provide an immersive and integrated experience on all platforms and operating systems. Thank you.