About this talk
Push notifications on the web can be a force for good, but is that how they are coming across? We'll take a look at how push notifications permissions are being implemented and how we can do it better.
As the introduction said, like, this talk was genuinely put together in the last two days. So it's a little bit of an experiment. So I hope you'll bear with me in some respects for it, because this is the first test. It's an idea of a talk that I've had going around my head for a little while, and this is its first kind of public go. So I'm looking for feedback afterwards and I'll appreciate if things do go horribly wrong, then you'll forgive me. It's not called shruggy emoji thing. It's also not called, as Andy was suggesting earlier, Talky McTalkface, a popular decision, I think. The title I've landed on was in fact Aggressive Web Apps, and hopefully we'll see what I mean by that soon. So, first up, my name is Phil Nash. I work as a developer evangelist for Twilio. Can I ask quickly actually, who's heart of Twilio at all before? Most people, sweet. That means I am doing my job well. Cool. Then I won't tell you anything more about it. In that case, subscribe. Text subscribe to this number. Get your phones out now and text subscribe to this number. Go on, do it. It's a good idea. It's all part of the talk, I promise. It's a really great idea. You should just go ahead and do that. Just text subscribe, all one word, to this number here. I'll read it out for you if you're trying to look at the screen and your thing. It's 07403 940495. Text subscribe to that. I'll know when someone has, 'cause it'll... - [Audience Member] Is this gonna like, charge 50 pounds from my bank account? - That's a regular mobile phone number there. Boom. Okay. So, you didn't know what you were subscribing to there, and it could have been anything. It could literally have been Cat Facts. In fact, hopefully, you are receiving Cat Facts by now. And this is my opening and... Is it a good fact? I don't know. Tell me later. It's a good fact. All right, cool. Cat facts are excellent, right? And you didn't know you were gonna get cat facts. You just had me telling you to subscribe. A bit of a weird experience, possibly, and now all of those who didn't subscribe are now like, pretty disappointed that they're not seeing what facts that people are receiving. People are sharing that. - [Audience Member] One more chance? - It will actually, again, this talk was not written... It was written in a little hurry. If I do it again, you'll all get the first fact again when I come back to this slide. So, I'm just gonna save everybody that. But the important thing is, like, this is a notification. It's a push into your face of a cat fact, or basically anything. And you can say stop, right? You can actually stop this. If you do not want cat facts... In fact, if you do not want many SMS kind of marketing campaigns, you can stop this. There are industry standard words to stop SMSs coming to you from a number, things like STOP, STOPALL, UNSUBSCRIBE, CANCEL, END, and QUIT. If you have messages coming into you, try those back, and they should, if they are following industry standards, quit messaging you. And that's wonderful. You can test that out if you want, but you will lose out on the Cat Facts. But it's nice to know that there are these industry standard ways to get out of this. It's a useful thing. But it's not all terrible. Like, not all text messaging services are trying to ram marketing messages down your throats. There are useful reasons to get text messages, I think. This is not just a plug for Twilio, I promise. I've got a point in this. They do power important and useful things to you like two-factor authentication codes, estimated time of arrival alerts for deliveries, or, you know, your taxi is arriving right now. Appointment reminders, you know, things that actually are useful for both businesses and for people. And these messages are all timely, actionable, and personal. These are the ones that you want to get, and they are absolutely useful. And so this is probably definitely the point that's going to come off where you're just selling us on a text messaging API. This is a front-end meetup at this point. What's the point here? We've been sending these things as text messages. It's been my job to tell people to do that for a while. And we do this because the text message is always a ubiquitous way of reaching pretty much everybody on the globe; however, it is getting to the point that as web developers, we also have that power within our grasp, and this is what is exciting me right now. With the power of service workers and progressive web applications, we can send push notifications to users as long as they agree to them. And you might be thinking, yeah, of course we can on like, the latest version of whatever that nobody uses. But this is, and, you know, can I use my, kind of suggest the same. Like, there's not a lot of green and quite a lot of red. But the thing is, the important things are green, and you probably can't read it from there, but that says 73.26%. 73.26% of web usage via browsers are able to receive push notifications via service workers, and that, I think, is kind of amazing right now. Like, the pace of change in development is incredible. And of course on here, we're missing Edge. Edge is still red. But Edge has service workers in preview mode behind flags. We're also missing two Safaris here, but if you've been watching and keeping up with that recently, a couple of weeks ago, Safari finally kind of started making moves. And if you have WebKit Nightly, you can turn on a flag that turns out their experimental service worker support. Now, I'm not saying that includes push yet, but it's getting there, all right, and we're going to fill in these slots of red. And in a year or two, this is going to be green across the board, and it's going to be incredibly exciting for us all. But. And so, yeah. Normally in my talks, I would then kind of blast into, this is how we do it and write some code about it, and this is the code. I won't wanna go through writing the code on this. I've done that before. About a year and a half ago, in fact, I gave that first talk at Front-end London in a talk called The Web Is Getting Pushy. It did not work when I did it here. So I recommend any of the other videos, if you want to catch up on that. So I'm not here to talk about the code for it. This is the only slide with any code you'll see in this presentation. If you can see it, it's quite simple. We have an EventListener for the load on event on the window, and then if we have access to serviceWorker and navigator and the pushManager in the window, because not all service workers will have pushManagers, then we can register our serviceWorker. And once that's complete, we can subscribe to the pushManager for user-visible notifications. And when that's happened, we've got access to that, and we can send push notifications to users. But there's a problem with this code, and this all the example code that you'll see out there. It's example code I've written before. And the problem is the permission. So we ask for permission when we subscribe, which is nice. The issue is we ask for it on page load, which is horrible, right? It's like somebody at the start of a presentation demanding you subscribe to a text messaging service when you have no idea what you're going to get out of that. Terrifying, right? And it's around the web, all over the place and this is the biggest site I can think of that does it, is, let's do that again. Product Hunt. If you're on Product Hunt, it's just like, hi there! Notifications? Like, I don't know. Maybe? Chill out. But what I've got there is approve or deny, allow or block, and at the first time I turn up to this, I'm going to probably block it, or as a developer, I know if I press Escape it'll ask me again some other time. But as a user, I'm probably going to hit Block there, 'cause I do not know or do not want to know what's going on. I don't wanna pick on Product Hunt. It's just the biggest one I can think of, and it does, it also has a cat as a logo. So we get more Cat Facts for that, I think. And that could be what they're sending as well. I've never said OK to that. So we'll see if that works out. The important thing is you just don't know, right? And so it's this issue of permissions and asking permissions upfront. And we're actually getting lots of permissions on the web these days as we extend the capabilities of the browser and going into more and more deeper and deeper kind of device-based APIs. Obviously, we have notifications, but also things like geolocation. If you turn up to a website that's like, where are you, that's quite creepy as well. Media devices. If you turn up to a website and it's like, I wanna see your webcam, that's quite creepy. And then Bluetooth, midi, USB, all sorts of other sensor APIs that are coming out all kind of end up in the same permissions model, which is ask for permissions, which is a good model. But ask when you need it. And the problem, I think, in notifications and a lot of these others is that we're asking upfront. I mainly wanna concentrate on notifications for this purely because notifications are the most entrenched, because you can leave the site, and still the service can get access to you, right? Once you have left the site, the service worker remains in the browser, and you can receive those notifications. You can push whatever cat facts you want to them. Don't have a cat fact there. So, this is starting to come up in like, conversation. People are like, well, what is going on with this? This is... I was on Facebook a couple of days ago, and this was a message on the Hackathon hackers group, which is a 60,000-strong group of mostly developers, normally students and recent graduates in the US who like going to hackathons. And they're asking things like, what's up with the sudden influx of websites asking to enable notifications. And I was interested in like, all right, you've seen this. You're a developer. You must kind of have some idea that we can do this, right? And so I asked... And that's even smaller. In fact, I can't read it. I kind of asked him if he had a list of like the sites that he's seen recently that are doing this to him. And it's like, no, I don't keep track of that. All he's got is the idea that a whole bunch of websites are doing this. They're kind of abusing this power. And as I said, this is a developer in a developer forum, effectively. And I think that sucks. And if that's the experience of people who maybe understand what's going on behind the scenes, the experience of those who don't is even worse, right? To the point that you get articles like this on How-To Geek of how to stop websites asking to show notifications. And this lists in every single browser how to go and turn off all notifications from that browser. That's not just for one website. That's for all websites that potentially want to use notifications for whatever reason. Please, go out and tell your friends as well. Do not demand notification permissions on payload. On page load. It is going to put users off. It's going to put technical users off. It's going to put real users off, and it's going to ruin it for the rest of the web as well. 'Cause my worry is that these permissions, because they are little popups, right, will become the new actual popups, where people, in fact, revile and dismiss them immediately. And I do not want that, because we have so much power in these features. And the problem is, if users start to dismiss these things out of hand, if they cancel them or turn them off, then what are the browsers going to do about that? If they see that an API is not just being used but being abused, then how can we, how are they going to fix that? Because it becomes their responsibility, and it becomes, you know, a sticking point for them, because they'd like to promote these useful ways of using it, but also avoid the other side of things. And so, ultimately, when these users dismiss permissions like this by default, the web platform itself loses its power, especially when we get to that point of turning them all off for everything. I do have... So, I ask again, please, again, go tell your friends. Do not demand these permissions on page load. But I do have a bit of a suggestion which I think I'm kind of working up to suggesting to browser manufacturers as well, is that, should there be some sort of enforced interaction before we ask for permission, similar to how we deal with popups now, right? You're not allowed to use window.open unless you've had a click event beforehand. Otherwise, it gets blocked by the in-browser popup blocker. Can you imagine an in-browser permission blocker? That doesn't make any sense. But I think we should be asking for an enforced user interaction if developers continue to abuse this. If any of you in the audience go out and abuse this sometime later, I'm going to come 'round to your houses, and I will push notification you. I don't know. Yes. So that's my suggestion. I probably will try and take this to browsers at some point and be like, why are we not doing this, because it is destroying it. But there are better patterns. There are better ways we can deal with this as developers ourselves, because we want to build interactions in our sites that users want to and in fact enjoy using. So the first one is wait. Just don't, just don't do it straight-up. Wait. That's fine as well. I mean, we're also... Browsers themselves are in their implementations of the idea or progressive web apps. Also, enforcing a set of waiting periods to relevant applications before they even get suggested is that home screen icon, that add to home screen, requires whatever a browser defines as user interaction as well as the other technical concerns. So if we just wait until we believe we have the interaction of a user that will want our notifications, this is going to be much better. And then we need to contextualise it as well. And so Matt Gaunt on the Google Developer Relations Team, the Chrome Developer Relations Team, has mocked up some nice things. This is the idea of an airline where you go book a flight, and once you're done booking that flight, you know, you've made that transaction. You've already got to the end of your purchase flow. Down at the bottom, we have just a checkbox saying, hey, get notifications for flight delays? And it explains. Like, this says, get a push notification on your mobile device if there is a change or cancellation to your flight. Seems like a useful thing to have, right? That's what you want to hear. You don't want it getting buried in your overstuffed email inbox. If you got a push notification, you could be silting that out correctly. And if you go and check that box, then you get the native popup to actually ask the permission to do so. And what's quite nice here is the idea of actually like darkening the background as well so that people really pay attention to the native implementation. And so, there's this kind of double permission in a way. It's similar to certain industry standards about double opt-in in like email, that you really have to want this, but when you do, you're going to enjoy it. Unless, of course, it's obvious. like if you are building a chat application, which I know some people in the world are, it's pretty obvious that maybe notifications are a real thing that are a part of this. And Slack does this really well on the desktop. That big yellow bar across the top is saying, hey, do you want desktop notifications, when you have this open, when you have this in a browser. And that's a great idea. I actually don't have that enabled. I have an app for Slack, so it's fine, but I would use the web if I didn't have 23 different Slacks to be in. So, those are better ways of dealing with the actual asking of permissions, right? Make sure you've explained upfront what you're going to be asking about, and don't ask straightaway, because that's pushy. That's a cat fact for you. So if we actually move onto the notification itself, there's a bunch of things we can be doing with that as well. What do we get this time? I like this one. As I said at the start when we were talking about SMS interactions, and these have been going on for years, right? The best ones are the ones that are timely, actionable, and personable. And what do these all kind of mean? Like, timely is a useful thing, right? And I always, when I think about this, I think about this flow diagram which goes around Twitter every once in a while under the tweet which talks about like, every time I hear a developer claim they can build a company's entire business in a weekend, I think of this flowchart for how Slack decides to send you a push notification. And I always giggle when I see this, of course, because Slack sends me a push notification regardless. And in fact I'm pretty sure it actually looks like this. I don't know if you have the same... Yesterday, I was going home from work on Slack talking with people, and I saw the notification... I saw the messages come in, and then I locked the phone and put it in my pocket, and then got a notification about the message I'd already seen, on the same device. So I don't know if their flow chart's working, but it's certainly, it may well have been built in a weekend. I don't know. But the point, the point is that you need to be able to... You need to send these timely notifications. You need to send notifications that matter to the user, and if it's a message they've already seen, it no longer matters. It doesn't need a notification. But it also means you have to consider time of the day, and, including of that, time zones, if you are dealing with international users, which invariably you will be, because people travel. And then number of notifications. So don't wake people up in the middle of the night. There's no point in sending that push notification for the cancelled flight at three a.m. unless the flight itself is at seven. If it's the next afternoon, you can probably wait 'til morning. Number of notifications just kind of means, like, if it's a chat application, then you probably can just keep bashing the notifications in if people haven't looked at it yet. But if it is, again, delays on a flight, and it keeps moving back a minute every time, you probably don't need to send every single one of those. That's going to annoy people. Then these notifications have to be actionable. There's gotta be a reason for a user to actually receive this. For example, you know, somebody send you a message. So you can go read that message, respond to that message. Useful interaction. Your car is here, so you should go out and get into it, because they'll leave soon or start charging you, or you can check in now for your flight, a favourite of mine, because I then get the exit row, and I don't have to have my knees around my ears on a tiny little plane. And this actually feeds into the third one, personal, because all of those obviously are about me. It doesn't matter if messages were sent. Somebody yesterday genuinely sent an @channel message in a Slack. And the first thing in the message was, I'm sorry for the @channel, but. So, you know, those things... I'm sure you all have your in-company standards about when to use mass-messaging and things like that, but your car is here. It's not useful if a car is here, but your car is here. You can check in now. It's something that you can go and do. You can go and action right now. But it's also good to know when to break these rules. I don't... You know, all rules are there to be broken, eventually, and I think one great example of this, using web notifications themselves was the Guardian over the last couple of years where they've been doing very interesting stuff in terms of information within the push notification itself. And so this was best, I think, shown by their UK election push notifications earlier in the year, which also has a fascinating article about how they actually built these images on the device on the fly in the service worker. It is very worth reading and then declaring you'll never do yourself. But, this is neither a personal action, because this is going to everybody who wanted to hear this. It's not really timely, because the election results come in overnight. So they were going to do it in the middle of the night anyway. And it's not really actionable, because by this point, you can't go out and vote again. But what's really good is the kind of interactivity and the ability to at a glance find out all the information you wanted to from this one notification without actually ever having to go through to the site and read the article, because this is all it's gonna say. So, breaking the rules can be important and you've just gotta consider when the right and wrong time to do that is. Even if you're sending the best notifications in the world, people don't necessarily always want them. This is reasonable, I think. You probably do not want me to continue sending you Cat Facts once we leave this building. I won't, don't worry. But you do, if you're building an application for this, because we saw how to opt out in SMS. You text STOP or QUIT or EXIT or CANCEL, all sorts of things. In an application, you want to be able to let users opt out within your application. This is absolutely key, because the alternative is a skull emoji. Death, I think, to all the notifications, basically. 'Cause this is the Chrome settings for notifications. And right here, I've got Facebook and Google Calendar because I use two browsers all at the same time, and so I never want both of them to tell me the same thing. But right at the top here, we have the one... This is the power checkbox right here, this one. 'Cause if you turn it off, that is all notifications blocked. Terrifying. But, and death, of course, to all notifications. It's really easy to block notifications. This is the problem. It's very easy. This is a notification from a test thing, and down here is a little cog, a little settings cog. And if you click that, I get to this screen. And if you see block all notifications, you might be very tempted. You might just block the one site. You might want to block literally all of them. Kind of terrifying. The problem is it's really hard to unblock notifications like this, for users, for people. Let's go back to the SMS at the start. I told you you could send STOP or CANCEL or QUIT or EXIT. I forget all of them. But do you know what you can do to opt back in? 'Cause I don't think most people do. You actually send START, YES, or indeed, UNSTOP. That's my favourite. UNSTOP. Take it back. Control + Z. Just those three, as far as I'm aware, are the standard ones. I don't know who decided UNSTOP. But they must have just been getting them in and being like, well, somebody decided this was a good idea. You can stop them again, but I'm pretty sure if there's one thing you've learned this evening from me so far, it's that you can text UNSTOP to a number to get notifications back from them. Oh, but if you have not cancelled, or indeed, just re-got in there, there's another fact for you. Yes. This is a nice geeky one, I think, actually. And so, like I said, it's hard to know that you'd have to press START, YES, or UNSTOP. It's also very hard if you don't have a notification to come and find this screen again. In the URL bar, it is chrome://settings/content/notifications, and that actually pretty much stands for a page you have to go through to get to this. You start with Settings. You go to the Privacy and Content part of that page. You then have to click through to Content, and then you go down to Content, and you're like, then you have to find Notifications in there, and you click on Notifications, and then you get here. So if you're trying to turn things back on, it took me a while to find this earlier. So, for any regular web user, this is a pain. And I do not know how to do that in Firefox, which is actually my primary browser. So, if I can conclude about this, push notifications are awesome. There are very good reasons to use them, if you're using them for the right reasons. Don't ever trigger permissions straight away. Please, on any kind of permissions basis, always kind of give an idea to a user what they're expecting to achieve out of giving this permission, and make those notifications timely, actionable, and personal, unless you're the Guardian, which, you know, great job. But do allow an opt-out in your application so that you don't have to force users through the browser settings. Ultimately, I want us all to build progressive web apps, web apps that are gonna help people, that are gonna make people enjoy using the web, and not aggressive web apps that are just demanding people's attention and permission for things that they never knew or understood before they were asked. And there's one more fact for you, because why not? That is all I've got for you this evening. Thank you very much.