 Hi, my name is Owen and I'm a product manager on Chrome's push notifications. So just before we get started, I feel like now would be a good time to clarify that we actually have two new features in browsers, both with the name push. I think it said that there are three hard problems in computer science, caching, naming things and off by one errors. And so I think we've fallen into the naming things trap here. So there's HTTP push, which allows servers to send down data to the client before they even expect it when rendering a page. And then we have web push notifications which are about sending notifications to our users and that's what we'll be focusing on today. So I'm super excited that we're all here in this room full of amazing web developers and I think at last count five different browser vendor teams to talk about progressive web apps. These are web apps that are reliable, fast and engaging. And I'm going to be focusing on the third point today, engaging, specifically sending push notifications to your users. So push notifications on mobile aren't anything new, but I'm really excited that we finally have access to these as web developers. I'm sure there are a number of you out there that have built great mobile web experiences and then had to wrap it in some kind of Cordova wrapper and suffer the friction of an app store just so you can get that notification capability. So our shackles are now free. We can now go ahead and do this. I think that's really exciting, especially when you look at the services and apps that have been successful on mobile and just look at the top ones and think about how many of them are fundamentally successful in part because of push notifications and we now have the ability to take advantage of that on the web and so there's a bunch of new opportunities that have emerged here that I'm excited about. And this can be really huge for business as well. For example, if we take a look at Jumia, which is a leading e-commerce company in Africa, they had a problem and their problem was that one quarter of their users were adding items to their cart, but they're not actually checking out. They were abandoning that cart. And the site tried to deal with this by sending those users emails and reminding them, but getting a user to type that email in on a tiny screen is really difficult and then the open rates on those emails were extremely low. So it's still early days, but Jumia have implemented push notification on the mobile web and they found that their notifications get a 38% open rate by users and that users that have enabled web push notifications convert on those previously abandoned carts at a nine times higher rate. And so I think these kind of results are really exciting. OK, so push notifications is this amazing new superpower that we have on the web, but everybody knows that with great power comes great responsibility. So this begs the question, what makes a great engaging notification? And so we believe that great notifications are timely, they're relevant and they're precise. And so for these penguins here, a push notification, letting them know that there's a leopard seal behind them would really change the course of their day. And so as you're designing your push notifications flows, just think about whether what you're sending is important enough to warrant an interruption. Would you want to be walking down the street and feel your pocket vibrate and really use that to guide you? And so let's break this down further. I said notifications work great when they're timely. So try and use notifications primarily for time sensitive events, especially if these are synchronous events that involve another user. For example, being sent a chat message, there's another person out there waiting for you to respond and it's something that you care about and it's important that you see it within the right time. So that's a great use case. Calendar is another fantastic use case. You're about to be having a meeting and you need to know where you're going and be reminded to go there. So timely is really key. Secondly, being precise. Notifications should contain all of the information that a user needs to understand what just happened and to take action on it if possible. And thirdly, relevant. It's important to users that the notifications they're seeing are from people that they care about and about things that they care about. OK, so let's give this a go. Here's one example notification. What do we think about this? I think this is pretty good, right? It's timely. I'm probably at the airport and I'm about to get on a plane. It's precise. It tells me my flight number. It tells me when the flight has been rescheduled to. And it's relevant. It's my plane. It's my flight. It's super important to me. So I think that's great. How about this one? Your credit card has been compromised. Well, I think this could have done better. B minus on our scale. So it's timely. It probably just happened. And it's relevant, right? It's my credit card. But it's not very precise. Which credit card? Why was it compromised? What's going on? What action do I take? And so if we reimagine this notification, we can add some extra information, let the user know that a suspicious transaction has occurred, and give them buttons that let them take action and provide feedback to the bank. OK, how about this one? Awesome chat app. You have a new message. So awesome chat app. Your notifications are not so awesome. It's probably timely. I expected a message was sent to me. But it's certainly not precise. And who can say if it's relevant, right? Who knows? So we redesign this, and we get Jake says, I hard service workers. Instantly, I think that should be an award for getting his profile picture in the most number of talks today. I think he's maybe at three or four so far. So that's a great way to redesign this. How about this one? As a side note, I think if Google does launch a self-driving car service, we should definitely call it goober. And so this one is great. It's timely. You know my car is arriving. It's precise. It's telling me where it's arriving at. And it's relevant. It's my car. I'm going to get in and drive away. And then here's probably the worst possible example I could conceive of. This is none of the above. And the risk here, really, is that if you send notifications to your users that don't provide them the value that distract them or spam them, they're going to turn off notifications. And then you're going to lose the ability to get the value from that interaction in the future. OK, so we've talked a bit about the kind of notifications which are good for our users. So now let's take a look at the flow and really how this works on a high level. So push notifications on the web is built on service workers. This is probably a theme that you're seeing emerging throughout the day. And I think it talks to how service workers are becoming this fundamental capability that allowing us to extend the platform in all of these new and interesting ways. And so once you get everything set up, which we'll go into, sending a push notification, the flow is roughly that your site first makes a network request to a push-obscription endpoint. And that's managed by the push server, which then magically wakes up the user's device and manages to fire an event into their service worker. And then that service worker runs some code and it uses the notifications API to show a notification to the user. So let's break that down a little more. The first thing that happens when a user lands on your site is you have to check if the user's already subscribed, so you know whether to show them the opt-in flow. Once you've checked, if they haven't already opted in, you just wait until it's a good time. Maybe the user has just done a search for flights and you give them a button that says, get notified when the price drops. And then once the good time comes, you ask the user to subscribe. You explain the feature to the user that they're opting into and then you eventually show them the permission request. And then once you've subscribed the client, it generates a subscription object. You'll then pass that subscription object up to your server and save it somewhere in a database. And then on your server, when you're ready to send a message, you just generate the message. You send that message to the endpoint that you were given previously. And that endpoint, essentially the push servers keep a persistent, one persistent connection open with the device. And then they use that connection to tell the device to wake up the browser, wake up the service worker. And so this part is special because it means that we're sending push notifications, but the browser doesn't even have to be running on the device. The site doesn't still have to be open. It doesn't use much power. And so it's a really great performance feature as well. And then the push message is received by the browser. And when the push arrives in the browser, it wakes up the service worker and fires an event into it. Your code then handles that event and decides what to do and shows a notification to your user. Easy, right? OK, so now let's take a look at subscribing for push and when you should prompt your users to opt in to get push notifications. So I think that this step is super important because if you're going to be successful with push notifications, you have to get users to turn them on in the first place. And so it's really important to focus on this step in the process. And I think it's important to be clear and intentional and treat this like any other part of your UX process. The key is not to just add a permission prompt on page load without thinking about it. So make sure that the user understands why they're being asked. Make sure that they understand what they're opting into. And so we'll take a look at an example of the Weather Channel. So the Weather Channel have built this page where you can choose to enable push notifications and control some options. So I think this is great because it's specific. You have this page where you know what's going on. You have all of the context that you need. And the permission request itself is user initiated. So when the user goes ahead and checks that box saying activate browser notifications, they see a permission request. No surprises, right? They're very likely to click through at that point. So that's great. And we think it's really nice how they give users options. I can opt into breaking news or government-issued alerts. If you're never sure about what users are going to want to enable, just give them options and let them decide. OK, so we've talked about this on a high level and we've talked about UX. Let's take a look at the code and how we actually subscribe for push notifications. So the first thing I said that we do is we check whether the user's already subscribed. And because these are progressive web apps, the first thing that we do is verify that service workers are available on this client. If the service worker is available, we go ahead and register our service worker. If a service worker is already registered, this will just return with the registration object of that service worker. And then we can call pushmanager.get subscription to get the existing push subscription for the user if one exists. And so now we know whether that's subscribed or not. We can store this in a cookie, use it later, or use this to decide whether to show them an opt-in flow. OK, now we're deciding to subscribe the user for the first time. So again, we're going to get the registration of the service worker that we've registered. And then we call pushmanager.subscribe. Essentially, this is setting up that connection with the push server. So it knows how to talk to this client. It knows that this service worker wants to be able to be woken up. And then there's a option here, which says user visible only true. Essentially what we're saying here is we're promising to the browser that when we send a push message down to the device and our service worker runs in the background, that the user will see something. So we'll either show them a notification, or maybe if they're already looking at the web app, then we don't need to do that. And the idea here is allowing, making sure that browsers can show that permission request saying this site wants to send you notifications, not this site wants to run in the background permanently on your device silently and use all of your battery. So that's why that exists. And then once you've subscribed, actually when you call subscribe, that will be the point where that permission request is shown to the user. And if they accept that request, the promise resolves, and we get back a subscription object, which we can then send to the server. And of course we catch the case where they deny, and we can decide what to show them in that case. So I recommend you all check out the propel sample code up on the Google Chrome section of GitHub, and this shows some great sample code to manage those subscription states, gives you a really nice API to manage them. Okay, so next, once we've subscribed, I said you get that subscription object. What is that? What does that look like? So this is how it looks. It essentially gives you all of the information that you need to identify the user to the push server so it can wake up the right device. It starts with an endpoint. This is like a magic URL. It acts kind of like the user's phone number or email address, but for push notifications there's a way of identifying and reaching out to them. It starts with the URL of the push service that this operating system uses, in our case here, Google Cloud Messaging, and then it has a long string of random letters that identify the current user to that push service. It also includes a bunch of encryption keys, and this is so when you're sending data down to the user's device so you know what notification to show, that message can be encrypted and can't be read by anyone in the middle. Okay, so let's take a look at sending that message from the server. There are two ways that you can send a notification. Firstly, there's what we call a tickle. This is essentially a push message which arrives with no data. So the service worker gets an event that says a push message arrived, but it doesn't get to find out what happened. And the second kind is push with payload. This is where you include data, you let it know what happened on the server and why it's being woken up. And if you're sending payloads, it's encrypted with the keys that we talked about earlier. And so let's take a look at actually sending those. Just before I do, it's worth calling out that the sample code I show here is for using the web push protocol. So the web push protocol is about to start working around now in Chrome, but as the standard's been evolving and the implementation has been evolving, it hasn't been the exact same implementation in older versions of Chrome. So there'll be a link at the end which shows you how to do a backwards compatible implementation, but I'm gonna focus on the future facing and what's really going to be happening from now. So when your server wants to send a push message to the user, it sends a request which looks roughly like this. It's a put request to that endpoint we were given earlier. It has a time to live, which essentially tells the push server how long should you keep trying to send this to the device for? And give up if it's taken more than two minutes. It includes a content type and encoding, and then it includes the public key and salt used to encrypt the message, a vapid signature, and the encrypted payload. I'm not gonna go too much into the details on those last encryption aspects now, but again, there'll be a link at the end which gives you the full breakdown of how this works. And at this URL, you can find sample projects to handle the encryption and message sending on the server side. We have them in Java, in Node.js, in Python. So go and take a look. This is kind of contributed by the open source community. There are contributions also from Mozilla and from Google, and there are a really great set of libraries that will get you up and running. Okay, so now we've worked out how to subscribe to the user and send a push message. But how do we receive it on the client? What does the service worker do? So in your service worker, you just add a new event listener for a push event. When that event fires, you call this magic method called wait until. So wait until, I had to look at this a couple of times, the first times I was trying this. Wait until essentially says, I'm gonna run some code for a while, it's kind of asynchronous, and I'll let you, the browser, know when I'm done. And when I'm done, you can go ahead and kill my service worker. I don't need to be kept running. So this allows us to be very performant and efficient. And you basically pass into wait until a promise, and you resolve that promise when you're finished doing the work, when you've showed the notification. So here we go ahead and we just generate a notification, and this returns that promise that will resolve when it's been shown. So the browser can kill the service worker at the right time. But actually, if you look here, this notification I'm showing basically breaks all the rules we talked about earlier, right? It's static, it doesn't say anything useful. So how do we read the payload? How do we know what was supposed to be showing the user? It's pretty simple. So you just check if event.data exists. If it does, you call .json to convert it into a JavaScript object. If it doesn't exist, then that's the point where you want to make a fetch request to your server to ask, hey, what happened? What should I be showing the user? And then once you have that data, you again just call show notification with the correct title and the body. And note in this case that we actually need to return that show notification to the event.wait until to make sure that the browser knows that we were still doing work. If you don't do this, you might notice in Chrome that you get a little notification saying, this site updated in the background. That generally happens if you resolve the promise to wait until before you show the notification. Because that's Chrome checking and saying, hey, did you show a notification? Oh, they didn't. We'll show one on their behalf to make sure the user knows. That's the user-visible-only-true thing coming into play. So we also have support for action buttons on web push notifications. These make it easy for users to complete a task without even opening the app. Here we can see that a user can confirm their reservation. You could also use this to have users like or retweet something to pay a bill, increase their bid on an auction. There's many interesting opportunities there. And using action buttons is super easy. In the show notification call, you just pass in an actions object, and you give the title, the icon, and this action string key thing that we're gonna use to recognize when the user taps on one of those buttons. So then if a user does tap on a button or on the notification, a notification click event will be fired. And that's where we'll say, hey, if the action was like, then we'll reach out to the server and let it know that it was liked. And if there's no action, then we know that they just tapped on the notification. In this case, we're just gonna open a new tab to the notifications page on the server. Okay, so we're almost there. We're just gonna wrap up now. And I don't think that we can do this talk without talking about browser support. So it's worth noting that web push notifications are already supported today in Chrome and Firefox. I was excited to see the Opera shipped web push notifications last week. Samsung browser shipped web push notifications earlier in their browser 4.0. And I read last week that the Edge team have just announced that they're currently implementing push notifications on the web. And at this point, you might be looking at that and saying that looks great, but there's maybe one missing that we care about. What do we do? And I think that there's a big takeaway here, which is that progressive web apps are fundamentally progressive. So when you invest in your web experience, you make the experience better for your users everywhere. And if you use progressive web app features in the browsers that support those features, it's gonna be even more awesome. And this actually turns out to be true when you look at the data. Earlier this year, AliExpress, a very big e-commerce company, rebuilt their site as a progressive web app. And in Safari, they saw an 82% increasing conversions on average. And that's a browser that doesn't currently support service workers in these new features. But I think it just goes to show that there's a huge opportunity in investing in the mobile web. And if you build a great progressive web app like they did, you can get that value across all of the browsers and even more value in the browsers that support these features. Okay, so we're gonna build better engagement on the web using web push notifications. We're going to send notifications that are timely, precise, and relevant. Just think about these things and ask yourself, would I wanna receive this notification? Are my users going to be delighted by this experience? We should make sure to ask for permission in context so the user knows what they're signing up to and they're likely to click through because they see the value proposition in what you're giving them. And be awesome. We have these new amazing superpowers. Use them to build awesome, amazing new experiences for your users that you're going to love, your company's going to love, and that they're going to love. And with that, I'm going to leave you with a few links where you can read more about this. We have a guide for getting started with push notifications and then some details about the encryption aspects. Tomorrow we'll have some code labs where we'll go through some of this stuff. And coming soon on Udacity, there'll be a course there so you can learn about that if you're watching from home. So thank you very much.