Welcome. I'm Alex Russell. I'm a software engineer on the web platform team. And today, I'm here to tell you a little bit more about the progressive web apps that Darren mentioned earlier in the keynote. If you were here last year, you might have seen me talk about a nebulous future in which we might someday be able to install web applications. I attempted some demo gods with early service worker and push notification demos, which kind of sort of almost worked. And you'll be glad to know that I have no live demos for you today, so rest easy. So we made all these promises and what happened, right? That was all pre-release software. Nothing kind of really worked. And in the last year, we have shipped everything I talked about. Service workers, push notifications, add to home screen. It's all real today. And I think if you're a web developer, this is amazing because in Chrome and in Opera and soon in other browsers, you'll be able to use all this stuff. You'll be able to take advantage of it. We ship the tech. That's really what matters, isn't it? Is it? I think it's an interesting question because if you look at other attempts to take web content, web applications, take them offline, make them usable on mobile devices, you'll see that they kind of sort of worked out. I mean, from WinJS applications to Palm OS applications, WebOS, sorry, React Native, Firefox OS, packaged apps, Chrome packaged apps, Cordova apps from Android and iOS, we've had a lot of attempts of taking web content, putting it in a different container, and making it run offline, giving it the same capabilities that I was up here talking to you about last year. So why is this different? Is there any reason why we should think that this is going to work when those didn't? And I think that the difference, at least to me, is something that Darren highlighted earlier. It's the power of friction. The other systems that you may have used to take your web application offline embody an essential trade-off. They give you these capabilities, but they force you to change your deployment and usage model. You can't just click on a link anymore. You have to go wrap up your application, put it in the store, and as a user, you have to go to that store to download it. While the technology inside those runtimes is web-based, the end products aren't. And fundamentally, if you can't link to something, it isn't part of the web. Service workers and the features that build on them, I think, are important because they keep URLs and they keep that low-friction usage experience at the center of everything. We saw earlier that users spend a lot of time in very few native applications, but they visit many sites every month. URLs are the web's superpower, combined with a security model that puts users in control at every moment. The web reduces friction to use like no other platform in the world ever has. And a surprisingly consistent theme that we hear from user studies about mobile is that users don't really feel comfortable installing a lot of applications. Some of them worry about the kind of over-broad permission demands that some apps request up front. Some users are very worried about space, like Tal was highlighting earlier. Some users are concerned about privacy. You don't really know what the application's doing all the time. The web has earned a significantly better reputation in all of these areas. And when combined with a low-friction to build and use a website, it means that the web is how users most frequently discover and interact with new services. As we talk with developers who are trying to get users to use their native applications, we find that over and over again, they tell us that it's both hard and expensive to take a user of their service on the web and get them to use their native app. Fixu is a company that tracks native application ecosystems. And this index shows that the cost to getting a user to try out a native application using application ad ranges from $1 to $2. It goes up, it goes down, but it's still in that range and has been for the last year. It goes up from there, though. They track a separate metric that they call cost per loyal user. And that number has gone from $2 a year ago to over $4 today. OK, so let's say we had an Air Horn application. I don't know why you'd want an Air Horn application to annoy your friends, but let's just say you wanted to get somebody to use one. And what we see repeatedly is that it costs about 20% of the users who enter your funnel for every single action that they have to take. So let's say I got 1,000 of you intrigued in annoying your friends, relatives, and coworkers.  And you'd have to go find it. And you'd have to click Install. And you'd have to accept the permissions, of course, because you can't just install it. You have to download and wait. And then at the end, you get to use it. That leaves about 262 of us who are now freshly able to annoy our coworkers, friends, and families. So if you lose only 20% at each step, it's pretty much a disaster. And this is, when we talk to developers, sometimes an optimistic estimate. OK, you say, sure, sure, sure. But what if I was able to reduce that number of steps, say, by prompting users when they land on my website, or getting them to go directly to the app store as opposed to finding it someplace else? OK, sure, sure, sure. Let's look at it. You get users to click Install from wherever they land. They have to accept the permissions, download, wait, and then find and use it. We're still below 50% for total conversion rates. The web reduces the number of actions to experiencing your application to a single click. Low friction is the web's secret weapon.  Over the past year, we've seen a drum beat of companies starting to do the math and coming to the conclusion that building only native applications isn't working. You heard earlier today about Flipward's growth since they dropped the app-only strategy. And in some areas like publishing, forward-thinking companies like Vox and the Atavist are even shutting down their native apps entirely and just betting on the web. OK, so how many of you have landed on a site for the first time that puts up a modal dialogue box asking you to take a survey about how your experience is going? Right, OK, it's not just me. This is exactly the experience that many sites are giving users when they first land on their mobile sites. The message you get is roughly, you're not welcome here, even though the content is here. Please go use this other version of our service. In fact, it's gotten so bad that earlier this year the search team announced that sites that put up these sorts of full-page interstitials to encourage users to download their applications would no longer qualify as badged mobile-friendly in mobile search results. And that policy went into effect recently. While it's easy to be upset about this sort of frustrating user experience, it's perhaps more constructive to get to the root of the issue and ask if it's so annoying, expensive, and ineffective, why are so many sites still doing it? As we talk to developers and businesses, we find that the root of the issue is the amazing capabilities that I was talking about earlier. The items that have come up over and over and over again among a long list, though, are the ability for an app to work offline, to appear on the home screen, and to send push notifications even when the app is closed. Taken together, these capabilities are so powerful that it's rational as a business decision to spend the time, money, effort, and even annoyance to get users to use native applications. Developers who are trying to provide a compelling user experience on mobile have told us the same things that users have, which are that they expect access to a certain set of capabilities before they'll consider something happy. And being happy is now what it means to be competitive. So what if the web could compete? What if we could combine low friction, the incredible reach that we've just seen, and ad re-engagement? The features we've been developing as open standards over the past few years manifests service workers and push notifications, address these concerns head on. They finally let us deliver an Air Horn app in the way that starts in a tab, and if I want to keep it, then becomes more integrated with my user experience in the OS. Earlier this year, Frances Berryman and I were talking about the process of taking something that's just a web page and upgrading it to feel more like a native application. Over time, these things are on the web, they're part of the web, they run at URLs, you can link to them, you can navigate to them, you can find them in search, but they can become more than that. And if they aren't just web pages, and they aren't apps in the sense that they don't require you to build your site a totally different way or go to a store to get this thing, what are they? I mean, web, animal, vegetable, mineral, which are they? Our answer was to call these things progressive web apps. They start out as tabs, but then they stage a jailbreak with user's help that breaks them out of the tab experience and gets them onto your home screen. They get them into the launcher, they give you a splash screen. They become more than just a tab, but they do it based on our user consent. So going back to the airhorner.com upgrade process, which by the way, you can try it right now, Paul Killen built this thing, it's great. You can annoy your friends, relatives and coworkers. The prompt that comes up at the bottom of the screen is browser UI. It's something that Chrome is showing on your behalf. And it shows up if and only if the user has come to the app enough to let us think that it's probably valuable to you. We want to have reasonable confidence that it's both going to be happy, that it's going to actually do the things that an app should and that the user might get value from it. So when it's launched from the home screen, you'll note that it's relatively indistinguishable from a native application. It shows up in the task list without extra UI. It doesn't have a URL bar necessarily and they even have splash screens. So you might wonder why we would build special UI to prompt users after all it's sort of impossible for a long time to manually add sites to your home screen. You could, for instance, start by tapping on the three dot icon menu, open that up, click add to home screen manually, click add and then OK it's been added and yeah, OK. It's a lot of steps is kind of the takeaway I think. It does show up, it does work, but then the next question becomes, why isn't this just bookmarking? What's different about this process and bookmarking? After all, they're just actions that save a URL to different things, in one case my bookmark list and in another case my home screen. Why didn't we just add an option in the bookmarking flow to let you add a shortcut to your desktop as well? The key difference here is what separates apps from pages. You can book airhorner.com or you could bookmark a specific location at airhorner.com that lets you get to a foghorn. It's a different thing. And we use URLs to name many different kinds of things, in fact. On the one hand, a blog is what you might think of logically as an application, example.com for instance. You might navigate individual items with inside the blog and that's a separate entity. It's a smaller bit of the overall whole. The same blog hosts many articles, all of which get their own URL. From the browser's perspective though, these things are equivalent. URLs don't give us any hint about what the application is versus what the item is. We don't really know. They're universes under themselves. We start the process anew every single time that you load content. As users, it makes sense to bookmark individual items, but it makes a lot more sense to add the application to our home screen. One way we resolve the tension in our existing single page applications is to create common UI. We build these application shells that host all the different sorts of things that we're going to navigate around. Conceptually, this is the UI that will always load basically no matter what you do inside your application. It's the application logic and the stuff that you need to load in order to be able to show any content at all. Jeff Posnick is going to be helping us understand how to build and cache application shells in a few minutes, but the important thing to understand right now is that your app shell is the stuff that should always load no matter what. An app shell should at least boot up enough to be able to say, sorry, mate, I'm offline. I don't know what to do here. As we survey end users, they frequently tell us that what makes an app an app is the ability to work offline. And yes, many native applications do a terrible job of this, but at least you know it's the app's fault, not the platform's. Focusing on the user experience like this is very clarifying. The overall criteria for something to be happy are clear cut when you talk to users. Apps should always start up. They should always have distinct home screen icons. And apps are things that you want to invest in. They're not one-off experiences that you'll never come back to. As a result, to get the banner that I was just showing you, your application needs to meet some very specific user requirements. First, your site needs to have a service worker. And when it specifies to start URL in the web apps manifest, the URL must be something that would load using the service worker all the time, even when you're offline. Next, because you have a service worker, your site has to be served at a secure origin. Luckily for debugging, that also happens to include local host. And there are flags that you can send to Chrome at the command line that will let you whitelist other sites. But in general, that means that you have to have TLS. It's 2015. AdWords noting happened. TLS is now the baseline. If your site isn't on TLS, now's the time to start. In order to avoid the spammy behavior, we also, that we all shook our heads out earlier, Chrome doesn't show the prompt until the second time you visit an application. The required time between the visits of those navigations changed recently to be much shorter, but expect us to keep tweaking this heuristic. Our goal here is to strike a good balance between helping you optimize adoption of your application while avoiding the spamminess that I think we all cringe at a little bit. OK, so to get a great home screen icon and to have a splash screen that really works to be in a task switcher with high fidelity, you're also going to have to tell us a lot about your application. And to do that, we're going to use the web manifest format. And to tell you all about web manifests, I'd like to hand it over to my colleague Andreas Bovens from Opera. Thank you. Hi, everyone. My name is Andreas Bovens. I work for Opera Software, where I'm a developer relations lead and also product manager of Opera for Android. Now, you may be surprised you're at the Chrome Dev Summit, and suddenly there's an Opera employee talking to you. But the context a little bit for that is that Opera has been working closely with Chrome on various engine and standardization related topics. So since our engines, which about three years ago, Opera has been a very active Chromium and Blink contributor. And just to give you some numbers, I know these are commits, and commits can be small and big, but just it gives you a sort of feel. So we've done thus far more than 4,000 upstream commits to Chromium, and more than 3,000 upstream commits to Blink. So we collaborate a lot with Google on various things. So I'm very happy to be here. Thank you, Alex, and the organizers for having me. So Opera as well is super excited about progressive web apps potential to lift up the web's capabilities. So we're really excited about that, and we've been working hard on supporting them. We are excited because of a number of reasons. They're live apps, and they're part of the real open web. They're not being done somewhere in a secluded corner where something happens with JavaScript and style sheets or so, but it's really URLs that are being used, and it's the real open web. As we know it, it's an extra on top of that to enhance that experience. There's an ongoing standardization effort, which I think is very important, so that other browser vendors can also start using them, implementing them, and so on, and then we see wide adoption. And they're also a great match for budget phones. These installable web apps, they take less space on the device, and especially in emerging markets where Opera has a lot of users. This is an important concern. People are concerned about the large amount of megabytes apps take, and so progressive web apps are really a good match for this kind of use case. So in back in September, we shipped Opera 32 for Android with support for Manifest, and this may seem easy, but it was actually quite complex. It was not just a Chromium intake, and there we were. We had to do quite a bit of work on it. There was a lot of interaction required also with the Android, and the top layers, and we also had to rework our startup sequence, which had to be rewritten for making this progressive web apps work well in Opera. So a little bit about the Web Manifest. So Web Manifest stores metadata for a progressive web app. So what it refers to are icons, description, colors, and related info that lets browsers create high-quality experiences for the launcher icon, the task switcher, a splash screen, and so on. So what I would like to do is have a little closer look at some of the code for these Manifests to work.  So a link element that points to Manifest JSON file that is typically hosted in the root of your site. And this is what such a Manifest can look like. And on the right here, I will have a little demo app that I just made for the purpose of this talk. You can also check it out and look a bit at the peak of the source code. And so we're going to look which parts of the Manifest relate to parts of the interface on the right-hand side. So when I add something to the home screen right now, you still have to do this manually, but we're also working on adding this screen prompt. So you click on Add to Home Screen. You see here this word is referring to the short name in the Manifest. We use the short name because when the icon is placed on the home screen, there's, of course, not too much space. So if your app name is too long, it will be truncated. So that's why we refer there to the short name. So think about using a good short name for your app that looks nice on the home screen. Of course, also, we use one of the icons of the icons array that you've specified. When you, this is another view, so when you go to the tasks or to the application switcher, there you also see, you see it just listed as a standalone app, a progressive web app. It's just listed next to the native apps. So in this particular view, it's actually really hard to see which is the native app and which is a progressive web app, which is very exciting. It really shows you how these applications are lifted up from the browser up to the level of native apps. And so in this particular case, the bar on top shows, uses the short name again, uses an icon from our icon array, and also a theme color. So in this case, I've specified a slightly darker hue of purple just to go well with the site. Then something else, splash screens. Opera has added splash screens. You can try them out right now in the latest version. It's Opera 33. And Chrome also has them in the beta channel. And so how this works is so when you launch the application, the moment between clicking the icon and until the full page, the first view, is loaded of your web application, there is some time there. And so we use this time to show a splash screen automatically generated. For this splash screen, we use the name, so the full name of the web application, an icon again of the icons array, and a background color. That sort of indicates maybe you want to make it match with the background color of your web application that you launched later on. So this being said, there is also another coming soon splash screen member in the manifest. And then you will be able to define a custom image. But for now, you can use this one and rely on this one already as a splash screen for your application. Also worth pointing out here is that for the icon, and this is just a gotcha here, Alex stressed specifically when we were preparing this presentation, the size of the icon should be 192 by 192 to work well in the splash screen. So then let's look at those last three parts of the manifest I haven't talked about yet. The display member is quite interesting, display property. So you can choose between standalone, standalone sort of hides the browser UI and only shows the bar on top of the OS with the clock and Wi-Fi status symbol, maybe notifications, and so on, and the bottom navigation bar. So this is what most apps use. You can also go full screen. This is a more immersive experience, maybe for a reader, or maybe for a game, and so on. We'll see another example of that later on. And there is also a browser mode. You can choose. This just will open the publication in the web browser as you would normally do. The advantage of that is that you can rely on the browsers built in navigation buttons and so on. Maybe that's what you want to do for your application, and you don't want to create your own navigation around your application. Then we go back to the standalone example for a second. And what is interesting here is that the display standalone part of the manifest corresponds, you can use this with display modes in CSS. So you can make a media query that says here at media display mode standalone, and then specify conditional styles that will only be applied in standalone mode, in full screen mode, and so on. So like this, you can make small design tweaks to give an optimal experience for the user once they have added your site to the home screen. Then another interesting feature here is orientation. You can lock the orientation. And normally you don't have to set this. But for instance, in case of Air Horner, it's locked to portrait mode because you don't really, there's no point in it changing orientation when you turn the phone around. So it just stays like this. This button will work in all directions. Don't try it out during my talk because otherwise you hear a lot of sound. And then this is another example. You can also try it out. It's on GitHub. It's a little game that we made, and it uses landscape orientation. And I've also combined it with full screen. And so you get a little game that you can play and that uses this special full screen and landscape mode of the manifest. And then the last part here is the start URL. This is the URL that you want users to go to when they open the app from the home screen. What I've added here is a question mark, home equals true. This can be home equals one, or home screen equals one, or you can just leave it away. The point of it is that it allows you to track where users come from if they've opened your app from the home screen or not. So this is just a little tip you can use or not use, depending on what you need it for. Then a little something about these app installation banners that Alex talked about. Currently supported in Chrome, coming soon in Opera as well. For this application banner, your manifest needs to have a name, short name, an icon's array as well with 192 by 192 icon. And the start URL must match the service worker. What this basically means is that you need to make sure that your start URL, some content must be served there, even if the application is offline or something like that. The user must always see something. They must not get a blank page or an offline page. If all this sounds complicated and you just want to get quickly started with creating manifests, there is a manifest generator made by Bruce Lawson. You can add URL of your current site, and immediately it will generate a manifest based on the metadata that are currently in your website. You probably want to tweak it a little bit later on and deploy it and start using it on your HTTPS-enabled site. So to round up, Opera supported in a nutshell is we have service workers who landed earlier this year. We've got manifest support at the home screen prompts are coming real soon. And push notifications are also on the radar. The general story is we're really excited about this. This will come also to other browsers. Firefox is also working on service workers and push notifications and so on. And we hope to get everybody on board. And this is really exciting for us. So thank you very much. Back to Alex. Thanks, Andreas. So Andreas mentioned that there are a lot of options to think through as you build your progressive web app and put together its manifest. And I want to highlight a few tools and techniques that you can use to ease development as you go. Andreas mentioned Bruce Lawson's excellent manifest generator, but I also want to highlight Manura Lemurri's manifest validator. It saves tons of time and trouble, specifically the sorts of things where you leave an extra comment in your JSON as we found out to our chagrin earlier this week and spend an hour trying to debug it. So yes, use this. This is great. Next, you are fairly going to find yourself wanting to totally nuke the world. Clear all the cache data, blow away the service workers when you're working with a physical device. And the easiest way to do that in Chrome today is to step into the lock icon on Chrome for Android, go to Site Settings, click through, hit Clear and Reset, and then hit Clear and Reset, and then you're done. And so that is super helpful. When you refresh the page, you should get the new world started all over again. While you're working with a physical device, and by the way, it's absolutely essential to understand the performance properties of your application on a physical device because they aren't the same as they are on your four-core i7 MacBook Pro. I promise you, specifically JavaScript. So get a physical device. But when you're working with a physical device, it's sometimes a hassle to go and try and debug on the device itself. So Chrome Inspect is probably your best friend. Hook your device into USB, go to Chrome Inspect, and then you can hit the Inspect button, which will bring up the full suite of DevTools. And the forwarding for the screen is the coolest thing in the world because you can actually use your mouse and keyboard to navigate around the application on the device. You'll see the tabs show up on the device if you turn on Tap Highlighting as well. And you'll be able to get to the debugging console. You'll be able to step into your service worker, inspect the resources on the device, all that kind of good stuff. And it's worth specifically highlighting that if you are using Chrome Dev today, soon beta, you'll be able to go to the Resources tab and see on the left-hand side the Service Workers button at the bottom. This is invaluable because, as Jeffy's going to describe service workers in a minute, when you're getting through the service worker's installation flow, you need to know that your service worker is activated and that there wasn't an issue when it installed. And so this is the easiest place to get at this information. Super helpful. Next, a major challenge when you're developing progressive web apps in the recent past has been that you don't really know when that set of four criteria are all met. Each one's a little bit different. You have to have TLS. We have to think that you have TLS. You have to have a manifest that meets all the criteria. You have to have a service worker that matches all this stuff. And so getting those all lined up can be a little bit of a pain. The easiest way that I know to try to understand whether or not your site is going to trigger the banner is to see if you get the banner. But that has the user engagement check as well. There's a flag in Chrome flags that lets you bypass the user engagement check so that every single time you go to your progressive web app, that banner will show up at the bottom. It's the easiest way to verify that you've actually hit the mark. Give it a shot. Similarly, on desktop, because we haven't shipped progressive web app support there yet, you're going to need to flip a couple of flags if you don't happen to have an Android device handy on your person. And so to do that, you can go and disable the user engagement check again and then enable Add to Shelf. Both of these flags are available in dev and beta versions of Chrome today. And what you'll see if you do this is you go to a progressive web app that would meet all the criteria. And you'll get this little button at the top that lets you say Add. Don't worry about what it does right now. It's not the final thing. We're still iterating. We might not even do it. But this is the easiest way to debug that you've actually hit the mark. OK. Lastly, a few things to consider while you are building your progressive web app. First, if you go ahead and hide the URL bar, you're going to need to provide a lot of your own UI. Having a refresh bar or a way to get fresh content is essential. Because you won't have the browser's back and forward navigation, you'll also have to provide high fidelity navigation throughout your entire application. So keep that in mind when you're constructing your app. One last point on that. As Andreas mentioned earlier, the media query to help you hide and show that navigation is essential. It's a great way to not double up on that UI surface area when the browser URL bar is there the first time you load it. OK, next, another piece of missing UI will be the share thing. The share intent, the share button. In the browser's case, the URL bar. You normally just highlight the URL, copy it to your clipboard, and paste it wherever you wanted. But that's not an option that's available to you necessarily. You'll have to think about rebuilding that UI in your own full screen application. Or check out Paul Kinlan's latest blog post about how to do this on Android using the intent system. It's great. Next, we send an event. Every time we're about to show that banner at the bottom. The on before install event lets you know that we show the banner. So that's great. Helps you log it out. But also, it lets you cancel it. Let's say you're at an inopportune time, maybe inside of a checkout flow. It's not a good time necessarily to be asking the user to keep the thing to their home screen. So using the on before install event and canceling it lets you choose when to show it later. Because you can re-throw the event. If you cancel it on one page, navigate to another page. We'll send the event again. We'll keep trying until you either tell us, yes, it's fine to show it, or the user clicks away. Great. And lastly, we've heard you about deep linking. We understand that the progressive web app experience in Chrome today isn't brilliant for deep linking. But we're working on it. Changes in Chrome in the near future will allow you to focus existing tabs from the service worker when a user navigates to a page. And we're trying to figure out better ways to let you control deep linking and which version to launch in the future. We've only just started supporting progressive web apps in Chrome. And we're excited that they represent a new way for you to keep your users engaged and deliver the sort of high quality experiences without having to take your content off of the web. We think that the URL is the web superpower, and we're excited to help bring that superpower back to your applications without forcing users to go through stores. The rest of today includes a ton of talks that are going to help you understand how to implement this stuff well. There's a talk on implementing TLS by Emily Stark. And again, that's the baseline for 2015. So give it your all. And talks about service workers, how to do all this stuff with Polymer, push notifications, and application shells. So stay tuned or find these talks on YouTube in a bit. And thanks again for your attention.