Push Notifications: Totally Tooling Tips (S3, E3)


Push Notifications: Totally Tooling Tips (S3, E3)

[MUSIC PLAYING]

ADDY OSMANI: So my friend's son does this really cute thing
where they install games on their phone.
And then for weeks after, they keep
getting notifications saying that their village is
under attack.
Can you do that on the web?
MATT GAUNT: Now you can.
ADDY OSMANI: Now you can.
How?
MATT GAUNT: Basically what happens
is you register your service worker.
You then ask it to subscribe these to push message.
Shows a little dialog saying, do you
want to allow this to happen, yes or no?
So hopefully then the kids won't actually
enable this at that point.
But if they do, then at that point,
you'll get a special token.
So that user– send that to your server.
Keep it.
When you want to trigger a push notification,
you can then use that endpoint, send it a specific request.
And that will basically wake up the service worker
on that user's device.
[? Go call. ?] There's a push message.
What do you want to do about it?
At that point, you can just show a notification.
You can go back to the server and say, hey,
what was this for?
You show your notification, and then you
can respond to click events.
ADDY OSMANI: Nice.
MATT GAUNT: So that's literally the whole enter and flow,
start to finish.
ADDY OSMANI: So can push notifications,
with the push API, can they show me images?
Can I include content in there?
What can I include?
MATT GAUNT: So you can do Title– title text.
You can do body text.
You can have an image to the side of the notification.
And you can also do buttons now as well.
So you can actually add two buttons
that you can respond to.
ADDY OSMANI: So I can show an image
showing that my village is on fire but also a button to–
MATT GAUNT: Extinguish the fire or watch it burn.
ADDY OSMANI: Watch it burn?
MATT GAUNT: I don't know what you're into.
ADDY OSMANI: This got very dark very quickly.
MATT GAUNT: It's also interesting,
because now we're looking at doing native notifications
for Mac, which is really nice, because it
means that we get rid of our own notification center thing.
We're now going back into native notifications and their
[? trades ?] and whatever else goes with it.
ADDY OSMANI: And push notifications
are not a Chrome-only thing, right?
MATT GAUNT: No.
So they're in Chrome and Firefox at the moment.
I think other browser vendors, once they
start doing service worker, they can
start looking at it as well.
ADDY OSMANI: Sweet.
MATT GAUNT: There is some bad stuff with Chrome.
And since we use GCM, so we have some proprietary bits.
ADDY OSMANI: What's this GCM?
MATT GAUNT: GCM– good point– Google Cloud Messaging.
ADDY OSMANI: OK.
MATT GAUNT: I've been drinking the Kool-Aid for too long.
So there's some proprietary bits you have to do for that.
But again, there's new specs that
are coming out with the old.
Wipe all of that out, because the moment
you have to go into Google Developer Console,
you have to register for an API key.
All that's going to go away.
So you just have one API, one set way
of doing this that all the browser windows going
to then take and use.
It's going to be so much better.
ADDY OSMANI: If I'm correct, we have
a codelab on push notifications as well people can check out.
MATT GAUNT: Yes, which is well worth doing, because that one
is regularly kept up to date.
I think my old blog post at this point
has probably seen better days.
ADDY OSMANI: So basically you're saying
don't visit your blog under any circumstances?
MATT GAUNT: No, that's just a blanket
rule for all of my content.
But yes, that's what I'm saying.
But yeah, there is a blog post, and it'll step you
through all the guides.
And it also goes through GCM and how to set all that stuff up.
So yeah, go check that out.
ADDY OSMANI: Oh, and if someone wants
to simulate push notifications, DevTools lets you do this,
I think.
MATT GAUNT: Does it?
ADDY OSMANI: Yes, it does.
MATT GAUNT: Mm.
Oh, is that the bell icon?
ADDY OSMANI: It's the bell icon.
MATT GAUNT: Yes, and you can do that
from service worker in tools.
ADDY OSMANI: Cool.
[MUSIC PLAYING]

Push notifications for the web — LazyWeb #3


Push notifications for the web — LazyWeb #3

[MUSIC PLAYING]
push.eu/en» rel=»nofollow» >Push notifications are coming to web apps,
and one best practice that just became an anti-pattern.
I'm Rob Dodson.
This is LazyWeb.
[MUSIC PLAYING]
Chrome 42 hit Stable this weekend.
With it comes a number of new features.
push.eu/en» rel=»nofollow» >Push notifications let users opt into timely updates.
Install Banners prompt users to save pages
to their home screen.
Permissions let you know if you can use an API.
Fetch acts as a replacement for XHR,
and it even includes support for ES6 classes.

Jacob Kaplan-Moss, keynote from this year's Pi Con
breaks some of the dichotomy that developers
are either 10X badasses or completely terrible.
Removing these assumptions helps us better address
problems like impostor syndrome and work
to improve potentially toxic work environments.
Critical relative URLs are now an anti-pattern.
Tweeted by Paul Irish this week, the practice of leaving off
the protocol from a URL is now discouraged,
as it can possibly lead to man-on-the-side attacks similar
to the one that hit GitHub.
The new recommendation is to always request
an asset over HTTPS if it is available on SSL.
Check to see if your site is mobile friendly.
A recent article on the Google Webmaster's blog
indicates that starting immediately,
Google search will add labels next to sites that it considers
mobile friendly.
The criteria includes such things
as making sure that users don't have to zoom to read the page,
and links that are spaced far enough apart.
You can use the mobile friendly test
to ensure your site meets the bar and skill up
over at Web Fundamentals.
Learning Git can be tough.
A look at Stackoverflow reveals over 53,000 Git
related questions.
But help is on the way.
First Aid Git is a searchable index
of the most commonly asked Git questions.
Curious how to undo a change that you've just
pushed to Master?
You can find that answer and more, or submit a pull request
to add to the index.

60 frames per second is the target for a smooth web
experience, but it's easy to fall off the fast path.
Paul Lewis and Cameron Pittman show you
how to optimize the four major areas of your app– Response,
Animate, Idle and Load, a.k.a.
RAIL– in this free six part Udacity course.
Blast Jank Invaders and master dev tools
all while learning the secrets to a faster web app.
That's it for this week.
I'll leave you with a JavaScript screensaver.
As always, thanks for watching.
[MUSIC PLAYING]

Push Notifications on the Open Web to increase engagement (100 Days of Google Dev)


Push Notifications on the Open Web to increase engagement (100 Days of Google Dev)

Push notifications are now available on the open web through a new set of web APIs and Michael van Ouwerkerk, an engineer on the Chrome team is going to show you how to add them to your web app so that you can vastly increase the engagement you have with your users.

100 Days of Google Dev / 100 developer videos over 100 days / #GoogleDev100

Subscribe to the Google Developers channel at:

Firebase Cloud Messaging Push Notifications using the Android, PHP, MYSQL PART 1/2


Firebase Cloud Messaging Push Notifications using the Android, PHP, MYSQL PART 1/2

Firebase Cloud Messaging (FCM) is the new version of Google Cloud Messaging (GCM). In this tutorial we take a look at implementation of the push notifications.

Second part:

Firebase console:

Additional dependencies:
compile ‘com.google.firebase:firebase-messaging:9.0.0’
compile ‘com.squareup.okhttp3:okhttp:3.2.0’

Github project:

☑ Visit fb page:

Increase Engagement with Web Push Notifications (Chrome Dev Summit 2015)


Increase Engagement with Web Push Notifications (Chrome Dev Summit 2015)

[MUSIC PLAYING]

OWEN CAMPBELL-MOORE: Good morning.
I hope that all of you can understand me today,
and maybe I'll get some help with translation
from my friends over at the side.
So my name's Owen Campbell-Moore,
and I'm here to talk about web push notifications,
and I'm a product manager on the Chrome team
and I have a clicker.
OK, so the outline for today.
First we're going to be talking about what
are web push notifications and why they important?
And then we'll go on to talk a bit about how do they work,
and how can you implement them on your site?
And then we're going to wrap up with a sneak peek
into the future of these features
and some of the new things that we
have coming down the pipeline.
But before we start with what these are,
I think it's important to take a step back and ask ourselves,
what's the context in which these features exist?
So this is something that we've been talking about a lot
today, the idea of the reach that the web has; and this
is something we've really come to realize in the last year.
Here you can see in numbers the average monthly unique users
for the top 1,000 apps versus the top 1,000 mobile websites.
And you can clearly see that the top mobile websites have,
on average, 2.5 times the number of monthly unique users
that the top native apps do.
But the struggle is, how do we take these monthly unique users
that we have on the web and convert them
into weekly active users or even daily active users?
And this is especially difficult in contrast to native apps,
which really take advantage of the capabilities
of these mobile devices, like push notifications.
So this is the question that we also
ourselves– how can we take this amazing reach that the web has
and combine it with the engagement capabilities
of these mobile devices, like push notifications?
Is this even possible?
And so I'm going to try and answer
that with a demo, which I know is everyone's favorite way
of answering a question.
And the thing to note about this demo
is that this was recorded earlier this week
running in Chrome Stable on my phone on a local host server.
Nothing that you see here is pre-release or experimental.
This is all in production and working today.
You could go off and build this this weekend
and ship it to your users on Monday.

So let's imagine– OK, in that case,
I'm going to just describe for you what you would have seen.
Demo gods, man.
Let's give a round of applause for the demo gods, please.
[APPLAUSE]

OK, so what I was about to show you is an experience
that I pulled together where I was going to go online and look
for some concert tickets in San Francisco,
and I was going to see that a band I really like
was listed on the site but that they hadn't yet announced when
that concert was going to be.
But the site had this new, amazing feature using web push
notifications where I could opt in
to receive a notification when the concert dates are
announced, allowing me to buy a ticket
to go and see that concert.
So I would have clicked through to accept the permission
to receive notifications from this site,
and then you can imagine that I close off the site,
Chrome is not running.
And weeks or months later, I'm kind of stood in a coffee shop,
I pull out my phone, and I see a notification.
It's from that ticketing website,
and it tells me that the tickets are now available on sale
for that band that I love.
And now I'd be able to buy those tickets
and get the best tickets before anyone else,
and I get to show that off to my friends.
So that's really cool.
So I think this is really the key here.
It's that web push, we believe, allows
you to take the reach that you're able to get on the web,
like we saw with all of those monthly actives,
and combine it with the engagement features
of your mobile devices, like push notifications.
And I think this is really amazing,
because when you think about some
of the most prominent experiences on mobile today,
many of them are social, and messaging,
and experiences where you really need this kind of low latency
notification as an enabler.
And so that's been restricted just
to native apps in the past.
But now we can build those kind of social and messaging
experiences on the web, amongst many other experiences
like the ticketing demo.
And so to talk a little more about the potential
of these features and why we all really need
to pay attention to them, I'd like
to have you all join me in welcoming Nate Schloss
from Facebook to the stage.
[APPLAUSE]

NATE SCHLOSS: [INAUDIBLE]

Cool.
My name's Nate Schloss and I'm a software engineer at Facebook,
and I worked on Facebook's web push implementation
and I also work on Facebook's use of new JavaScript
technologies and new things that are available in the browser.

So as a mobile first company, the mobile web
is a key part of our overall strategy.
Like you've heard earlier today, mobile first
does not mean native only.
You can't have a complete mobile strategy
without investing in both the mobile web and both native.
And many people might think, all right, great.
You're investing in the mobile web,
but maybe that's taking away from a lot of the growth
in native, or maybe you're investing a lot in native
and that's going to hurt the mobile web.
But that's not what we see.

The mobile web is growing and it's
growing at a similar rate to what we see on native.
When we see native grow a lot, we also
see mobile web grow at the same time,
and when we see a lot of people really
engage with the mobile web, that helps native just as much.
This is especially true in emerging markets.
In places like India where the barriers to download an app
are very high, and it's hard for people to go through the steps.
The mobile web is even more important,
and it's often people's primary interface
for interacting with Facebook, and similarly
with the web overall.
The desktop web is an area of continued strategic importance
to Facebook.
Many people still use the desktop web
as their primary way to interact with Facebook,
and it's an area we need to continue
to make a great experience and overall to support and develop
really well.
And there are a lot of features on native
that we haven't been able to bring to the web.
The web is great for many things, but up until recently
it's been at a huge disadvantage to native, especially when it
comes to reengagement.
One thing we've known that it is very
impactful on native for a long time is push notifications.
It's great for people– they can see when they're missing out
on information, click on it, and get exactly
to where they want to go.
So we really wanted to bring push notifications
to the web for a long time, and we implemented
a proprietary push notification integration
with both UC and Opera mini and it's been great.
We saw a lot of the same wins for users and Facebook
that we saw in our native apps.
We know that push is great, and we
know that people want it and they want it on the interface
that they use the most.
So just because somebody uses the mobile website
the most doesn't mean they should miss out
on all the great options that they get from push.
So when we heard that Firefox and Chrome and others
in the web standards community were working
on a standardized way to do web push notifications,
we were really, really excited to [? new ?] implementation
using that as well.
And we shipped a really great implementation on mobile,
and we're going to ship our desktop implementation really
soon as well.
And as we saw in other interfaces,
when we ship web push notifications,
we see really, really great growth engagements.
It's great for users because they get the notifications
on the interface that they're using,
and it's really great for Facebook
because people come back to the site
more and are able to engage.
And this is a chart that shows the increase
in monthly active users as a result of doing web push
notifications on desktop, and as with any really great growth
chart it just goes up and to the right.
So there's just a lot of advantages
from being able to do web push.
And we're not the only company that's
been able to see such really great growth
wins from web push.
To talk a little bit more about that,
Owen's going to come back up.
[APPLAUSE]

OWEN CAMPBELL-MOORE: Thanks, Nate.
So we're going to try the demo once more.
I think the northern monkeys have gone and tried
some technical jiggery and we hope– OK.
Yeah!
OK.
So now let's imagine that I've gone on this concert website,
I'm looking to buy some tickets to go and see a great band.
I notice Methodical Tactic, they're
one of my favorite bands, but I don't see
any upcoming concert announced.
But I do see a new option saying that I
can get notified about future concerts
by them in San Francisco.
So I'm going to go ahead and tap Notify Me.

And this shows the local host or the website that
would be in production [INAUDIBLE]
sent me notifications.
That's great.
So now I can leave that site, and I can even
kill Chrome entirely and forget that I was ever there.
Now in a couple months time, I could be in my coffee shop,
I notice my pocket vibrate, and there
I have a notification appearing.
And with one tap, I'm back in and I'm
able to buy the tickets for the concert.

[APPLAUSE]

And now back to where we were.
So it's great to see these kind of results
from Facebook taking advantage of features like this,
but it's not just Facebook.
Here's a stat from Beyond the Rack,
which is an online shopping company.
They released web push on their site,
and they saw a 50% increase in repeat visitors
within three months.
So this just goes to show how impactful this can be.

So this is all pretty awesome, right?
But how does any of it work?
So in that demo, you noticed that Chrome wasn't running,
the site wasn't open, and yet somehow it
was able to run some JavaScript, download some resources,
and show a notification.
Like, how is any of that even possible given
what we have today?
And the answer?
Magic.

OK, so maybe it's not magic.
But I think the theme of this summit
is that whenever you see something
and you think, how could this possibly work?
Like, I just don't understand.
The answer is almost always, Service Worker.
So it turns out that Service Worker is this amazingly
powerful new primitive.
But when we normally think about Service Worker,
we think of something like this–
it's a kind of small JavaScript file
that we can keep on the user's device,
and then when a network request is made to our origin,
an event is fired into it that we can grab
and we can generate our own response
and send it back down to the page.
How does that help with push notifications?
The answer is that we can actually
flip this diagram around.
And if we flip this diagram around,
we can imagine a flow in which our web server sends a request
to a push service– in Chrome's case this is Google Cloud
Messaging, which keeps a persistent connection
open with the device.
Now with that persistent connection you can say,
hey, device, go and wake up this Service Worker.
So Chrome starts running, it starts the JavaScript context,
and it fires a push event into it.
And so in this way, the Service Worker
is this amazing primitive that's giving us this ability
to do event handling in the background
on the user's device, but in a very controlled way.
So the event fires, it's able to show the notification,
and then we can kill it again immediately.
So these things don't stick around, they
don't take up your battery, but they really
provide a new bunch of possibilities for us
as browser vendors and for developers to see
what we can do with them.
So it'll be really exciting over the next year
to see all of the cool new APIs and functionality we
can enable websites to have using this new primitive
of Service Workers.
OK, so we've talked a lot on a high level,
but this is a developer conference, right?
So let's see some code.
So here we're going to talk through subscribing
for push notifications.
So this is on the site.
When I tap that Notify button, the first thing
that I need to do is have the site setup
with the push service registering the Service Worker
so it knows how to wake it up later.
So I start by assuming that the Service Worker is already
installed on the device.
I'm able to call navigator Service Worker ready,
which returns a promise which will resolve
when it has the registration of the Service Worker
ready to use.
And then with that registration, I
think we'll push manager dot subscribe,
and what this is doing, in Chrome's case, is sending
a message to Google Cloud Messaging saying,
hey, I'm a Service Worker, this is my identifier,
and you should know how to wake me up later.
And you can see here that we're passing
in user visible only true.
Now what does that mean?
Essentially, the way that the push system is designed today,
you could send a push message to the device,
have this push event firing your Service Worker,
and you could run something in the background.
You could start mining bitcoins, you can do whatever you want
and just not tell the user that something's going on.
And obviously that would be bad for our users,
and we don't want that to happen.
So what you're saying here by specifying userVisibleOnly true
is that you're committed that when a push event is fired
on your Service Worker, you're going to make
a change that the user can see.
So they know that your site runs in the background.
You're going to show a notification.
So in this case, it makes sure that sites are only
running when users know that they're running
and that you're using push to deliver notifications,
not just to send an hourly push to take up
cycles on their computer.
So once this resolves, we're going
to get back a subscription.
So this comes back from GCM and is essentially an identifier
for the Service Worker.
And then this is a function that you'll write yourself
that just sends that subscription up
to your back end, and then later you'll
be able to use this to send a request to GCM
in order to send the push down to the device.
OK, so that's subscribing to receive push notifications.
Now let's talk through how we actually receive the push event
and show the notification.
So this is the diagram I showed you earlier about how the web
server sends the request to the push server, which wakes up
the Service Worker.
Now, it turns out this is only mostly true.
And the detail here is that when the Service Worker
event is fired, it actually doesn't have any context.
It's not given any payload or any data from the push message.
So this means that the Service Worker wakes up without context
and doesn't know what it's supposed to be displaying.
So the first thing that you need to do is send a fetch request,
or a network request back to your server in order to say,
hey, I'm awake, what notifications
am I supposed to be showing to this user?
So let's take a look at the code for how this works.
So here we're in the Service Worker code,
and this is our event handler for our push message.

So when the push event fires, the first thing we do
is we get this event, and so this line is kind of magic.
So event will wait until– it basically
says, hey, I'm running in the background in my Service
Worker.
You need to keep me alive.
You need to wait until this promise resolves.
When this promise resolves, I'm done.
You can go ahead and kill me.
This is how we get the performance benefits
and how we make sure that it doesn't
keep running in the background on the user's device.
So the developer calls event dot wait until, it then
makes a fetch request to its server
to work out what notifications it's supposed to be showing.
It parses that into a JavaScript object,
and then using that result from the server,
it's able to use the show notification API
and pass on the information provided by the server,
and that is what actually shows a notification on the device.

So it's been really awesome over the last few months
to see a bunch of developers adopting this new capability
and exploring different UX that they can build with it.
And I think it's interesting to share some of those lessons
that we've all learned together about how
to build a good experience with push notifications.
Now some of these lessons came over from native
and some of them are entirely original to the web.
So here's the one that I think is the most important thing.
Make sure that you're sending notifications
that users care about.
Now as this is a new kind of communication channel
with users, I think the first thing that a lot of us
think is, great, I'm going to vibrate that pocket whenever
anything happens and take all my email
and send it to them as push notifications.
Now I think it's important first to ask
yourself is what I want to send them both urgent and important,
because if it's not urgent you probably
don't want to be taking them out of their context,
vibrating their pocket, and disturbing them.
And if it's not important but it is urgent,
then it's also not something that you probably
want to disturb them for, unless you
think that it's very likely that they're
going to be interested in it.
So take, for example, that there's a live stream starting.
This is urgent– it's starting right now, right?
But do they have any interest in this live stream?
Is it a topic that they care about?
If yes, and you think that there's a high probability
that they're going to go and click and watch
that live stream, then it's probably a good notification.
If you're not sure or they might not be interested,
sure, it's urgent, but it's actually not
important to the user.
And the best examples of push notifications
are those that are both urgent and important,
like an incoming chat message from a friend or your vehicle
has arrived outside the building and you
need to go and get in it.
So those are the kind of experiences
we really want to be building.
And another thing to remember about this
is that Chrome makes it really easy for users
to disable notifications from sites that they find
are using it spammily.
So if you start sending notifications too aggressively,
users are going to disable it and then
you'll never be able to send them more notifications
and take advantage of this new stream.
So use it carefully.
The next thing is not requesting permission on page load.
So the story here is we first shipped
this capability back in May, and in about June, I
was landing on a blog and I saw a permission request pop up
and it said, hey, this site wants
to send you notifications.
And at first I was like, oh, this is so awesome.
A feature that I built is real, and people are using it!
How cool!
And then the next week, the same thing happened.
I landed on a site and this permission popped up.
And I went, hm, I actually don't even
know what they want to send me notifications about,
and I don't even really know what the site is yet.
I haven't had a chance to take a look around.
So I think the key here is not to forget that the lessons
that we've learned about general UX.
Make sure that users understand what you're asking and why.
In this case, I think Twitter have
done a really good job of this, where
if you go in the direct messages panel on desktop
you see a new section that says, would you
like to receive notifications for new messages?
And in the ticketing example earlier
there was a box that said, do you
want to get notified when these tickets go on sale?
And then when the user clicks enable notifications,
it will notify me.
There's a lot of context and they understand why they're
being asked to give permission.
So it's really important to make sure
that we remember those lessons when building permissioning
flows because the permissioning flow is a first class
flow within our site.
Just because the UI is being shown by the browser
doesn't mean that we can forget the UX that
leads through that process.

The next thing is making permissions controllable.
So this is, again, back to the fact
that we've made it easy for users
to disable notifications from sites they don't want.
But you don't want them to do that.
You want them to first go into the settings on the site
and try and control what they do and don't want.
So here, Facebook have done a great job
of letting you go in and say, I want notifications
for when I'm tagged in a photo, but not when someone
comments on one of my photos.
And this is a great example of control
that you should be giving your users.

So this is a really meaty topic now,
de-duplicating with native.
So you can see an example here of notifications.
Imagine I installed the Ticket Now app and I'd
been on the Ticket Now website and accepted this permission
request.
Well, now we're in this difficult world
where I might get notified twice– once from the app,
and once from the website.
And this is a problem that we're trying to solve
and there's no ideal solution today.
And we're looking for suggestions and ways
that the browser can help you do this, and new tricks
that we as developers can use to do this.
But the best advice that we have today to deal with this
is two things.
Firstly, you can use a kind of heuristic that says,
if the user's logged in on two different platforms,
don't send notifications to both of those platforms
if the device looks really similar.
If it has the exact same screen resolution,
it's probably their same mobile phone
and you don't want to send it to both.
So be careful about that.
And the second thing that you can do
is when the user taps Turn On Notifications in your site,
you can actually fire an intent into the native app
on the device.
And so if the app is installed, it'll open up the native app
and you can in there say, hey, notifications are turned on,
you can control them in this way within the native app.
And if the app isn't installed, you
can specify the URL that the user
should go to to complete this opt in process.
So again, this is an open area that we're working on
and we're looking for feedback and new ideas as we go.
But these are some of the best practices
we would suggest at the moment.

OK, next is refocusing existing windows.
So when you get a notification on mobile from a native app
and you tap on it, it takes you to that app
and the app takes you to the exact page
that you're looking for.
This is great.
Now, on the web, if you do this naively,
you'll just end up creating new tabs and new tabs,
and then in the tab switcher you'll
see pages and pages from the same site,
especially if you're doing a low latency use
case like messaging.
So the key here is to refocus the existing page that's
already looking at the site.
So if you already have a window open on the device which
is on the site, you should navigate that to the new page
and focus it.
So let's look through exactly how you do that.
First, in the Service Worker, you
can use the clients.matchAll API to get
a list of all of the active windows
that your Service Worker controls on the device.
And then if there is at least one of these clients,
you're going to go ahead and send a post message to it
saying, hey, navigate to this new URL,
and you have to receive that post message on the other side
and actually do the navigation and then focus that client.
And if it turns out that you didn't have any windows open,
you can just go ahead and open a new window.

The next thing is to make sure that you're
summarizing your notifications.
No one wants to open their notification panel on Android
and see that one had sent them 15 different notifications
all for different chat messages within the same thread.
So you should always think, when you're
showing your notification, you should use the API to find out
what notifications are already showing,
look at how to group them and summarize them the best,
and then replace the one that you have currently
showing with the summarized notification
that groups up all of the interaction that's
happened since.
And the last tip I want to share is a throwback
to Jeff's talk, which was earlier today
and you can find online on YouTube,
about loading instantly.
So when the notification is there,
you've got to run in the Service Worker in the background,
right?
That doesn't mean you can just download the notification
contents and show it.
You can also download all the resources to show that page.
Which means when the user taps on it,
if you've built your app shell correctly,
the page can load instantly and the content in the page
can load instantly, and you get this amazing experience.
And it works even if they're offline.
So if they get a notification saying they have a message,
and then they go into a tunnel, they
can still tap on that notification
and get to that message immediately, which
is an amazing experience.

OK, so we've talked about what these web push notifications
are and why they're important.
We've talked about how to do them,
and how to build a good experience with them.
So finally, I want to talk about what's next.
What's coming down the pipeline?
The first thing I'm really excited about
are custom actions.
So here you can see this notification includes a My
Custom Button.
So you could set this to say whatever you like, and you
can do what you like when the user taps on it–
open a new page or just send a network request,
change the contents of the notification.
So you can imagine being able to build entire experiences that
work within notifications.
So imagine you've gone on an auction website
and you've set a bid on a product
and then you get a notification saying, hey, you've
been outbid, but there's a button on it that says,
increase my bid to x dollars.
This means that user can just tap that.
They don't even need to go back to the site.
You can say great, done, they can swipe it away,
and you've built this entire flow
all within the notifications.
I think this is really powerful and something
that we're all going to get to play around with.
This is available in Chrome Dev today,
so you can start playing around with it.
And the next thing that I'm really excited about
is payload.
So earlier you'll remember that I
said that when the push message is received in the Service
Worker, you have to make a network request back
to the server to find out what happened.
So this is changing with payload support.
And what this basically means is that your site
is going to be able to include some data, basically
serialized JSON, with the push that it sends to the Push
Service, and then that'll be sent down
and included when the event is fired on the device.
So you'll know immediately what you're supposed to do,
and you don't need to make the request back to the server
like you did before.

OK, so to wrap up, since May of this year
Chrome, for both Android and all of the desktop platforms,
has supported the new web standard, designed together
by Mozilla and Google and others in the web designers community,
that enable web push notifications based
on Service Workers.
Web push is really fundamental to this idea of progressive web
apps, and Service Workers are providing
this new, fundamental capability on the web
like we've never seen before.
And web push is making real business impact to companies
like Facebook and Beyond the Rack today,
and we can't wait to see what you build with it next.
Thank you.
[APPLAUSE]

Deep user engagement with web push notifications – Google I/O 2016


Deep user engagement with web push notifications – Google I/O 2016

push.eu/en» rel=»nofollow» >Push notifications aren't something that are new.
They've been around on native platforms for pretty much ever,
but they're new on the web.
And it's a powerful feature that we
think is going to be really useful,
but we need to be responsible about how
we're going to use it.
So I'm going to talk about some of the ways
that I'm going to ask you to be responsible with using it
and some of the ways that we're going
to be responsible in using it.
Jumia is a big company in Africa.
They're the leading e-commerce company there.
And they were seeing a lot of people come to their site,
go shop on mobile, and then they would abandon their cart.
And so their way to try and get people
to complete their purchase was to send them an e-mail.
Well, one, getting them to actually give them
their e-mail address didn't work so well.
And two, if they did, nobody was opening the e-mails.
So they decided that they were going to try
using Web push.eu/en» rel=»nofollow» >Push Notifications.
So they added Web push.eu/en» rel=»nofollow» >Push Notifications recently.
They're seeing a 38% open rate on their Web push.eu/en» rel=»nofollow» >Push
Notifications.
So think about that compared to e-mail.
It's right there.
People are seeing it.
Oh, hey, you abandoned your cart.
There's something in here.
Do you want it?
OK, so that's good.
But they're seeing a nine times higher conversion
from people who are getting Web push.eu/en» rel=»nofollow» >Push Notifications.
So it's working phenomenally well for them.
There are lots of other companies who are doing it,
but that's just one.
So let's take a look at what makes a notification engaging–
what's useful.
Users want to have notifications and– there
is a point to the seal.
I'll get to it in a sec.
Users want to have notifications that are timely,
that are relevant.
They want things where they can say, hey, look.
I'm going to look at this and not necessarily have
to open the app, but make a decision
and do something without having to open it.
And that are day altering.
So for these penguins, getting a notification
that their mortal enemy is going to try and eat them
is nearby– kind of helpful.
This is a day altering thing.
So as you start to build notifications,
ask yourself one big question, is it important enough
to warrant an interruption?
Is this something that you want to get at your desk
when you're at the office?
Maybe you're at home with family having
dinner or out with friends.
Is it important enough to warrant an interruption?
And if it's not.
Think about ways that you can give users
options to be able to say, well, I
want these ones, but not these ones.
So I think there are three key things that
make a good notification.
So let's take a look at those.
The first one is it's timely.
I feel like I need it right now.
I want to look at it.
I want to go, OK, yes.
This is a notification that I'm going to do something with.
Think like calendar notification.
Hey, I should probably be on stage.
That would be a great calendar notification.
Thankfully, I got that one.
Synchronous communication.
So I've got a chat going on. [? Allo ?] [? Allo ?].
That is a perfect use for somebody
sitting there waiting for that notification or that response
for you.
Don't send them things that they're not going to reply to
or that will fix themselves.
So oh, hey, I'm backing up your files.
Who cares, right?
Users don't care about that kind of thing.
So keep it timely.
The next one is be precise.
Notifications aren't e-mails.
You can only fit so much text and one image
in a notification.
Give them information that they can look at,
figure out how they want to use it, and act on it.
And the next one is it's relevant.
Tell them who it's from, what it is specifically
that they should care about in this particular thing.
If it's a chat notification, tell them, hey,
you got a chat notice from this person.
And here's what it says.
And the other little bit on this one
is if it's already on screen, don't
show a notification for it.
Imagine a chat app, again.
We seem to have a lot of those.
It's easy to keep going back to those examples.
If the user's already in the chat app,
they don't need to see, oh, they just
got a message because they probably already saw
the message.
And there's one special one for web.
And this one doesn't really apply for native applications
because you're probably already working offline.
But for web apps, make sure that whatever
you're sending to the user is going to work whether they're
online or offline.
I live in New York City.
So sometimes, I have a cell signal in the subway
or in the station and sometimes I don't.
But I definitely don't have it in the tunnels.
So if I look, and I get a notification,
and I click on it just as I go into a tunnel and lose it,
that's a useless notification to me.
I'm going to throw it away.
I'm going to get cranky at you.
And I'm not going to be a happy user.
So let's try a few notifications and see how they work.
Flight UA875 is delayed.
New departure time, 7:35.
All right.
This one's good.
It's timely because I'm probably sitting
there waiting for a flight.
And I want to know that my flight is there.
It's precise because it's telling me what I need to know.
It tells me the new flight time.
It tells me who it's from.
And it tells me where I'm going in terms of the flight number
and all that kind of stuff.
So this is a good one.
I like this one.
Credit card.
Your credit card has been compromised.
And yet, not so good, right?
I get a new credit card probably every couple of months
because, somehow, my credit card's been compromised.
So this one, yeah, it's timely.
But it's not precise.
I don't know what credit card number– or what credit
card it is.
I don't know if, maybe, just a whole bunch of credit card
numbers were stolen or somebody's cloned it.
I don't know what's going on.
Well, it's relevant because it is telling me
it's my credit card.
But with a few small changes, we can make this one useful.
So did you make a $1 million purchase
at Dr. Evil Inc with VISA 1234?
It's relevant.
I know which card it is.
It's timely.
And it tells me what's going on.
And I've also added these action buttons to be able to say,
yes– this was me– or no– this wasn't me.
I'm nice.
I'm sweet.
I'm innocent.
I didn't do that.

Google+.
Jane just posted a new message.

Yeah, I'm not a big Google+ user so I probably don't care about
this all that much.
But it's not timely because it's just a message.
It's just something going up.
There's no action that I'm going to take on this.
Yeah, it tells me who it's from, but what
am I going to do with this?
There are ways, and Google+ does have some really good,
relevant, timely, precise notifications,
but this isn't one of them.
Awesome Chat App.
You have a new message.
Hmm, yeah, no.
So it's timely because, yes, it's synchronous communication.
Somebody's sitting there waiting for it.
But it's not precise.
I don't know what the message is.
And I don't know who it's from.
It could be some spam bot.
It could be my mom.
It could be anybody else.
I don't know.
If it's my mom, I'm probably going
to look at it, depending on my mood.
Maybe it's a coworker and I need to reply to this.
So with a little change, Jake, says,
I heart service workers– probably something
he'd actually say.
So yes, now it tells me who it's from.
It tells me what he's saying.
I can then choose to reply to this or not– ignore it,
however I want.
Goober.
Your self driving car has arrived at 123 Any Street.
I like this one.
It's timely because my car has arrived.
I'm going to be going somewhere, so it's good on time.
It's precise.
It tells me what it is that's arrived and where it's arrived.
And it's relevant.
Yup, I asked for a car, so, good.
So this is a good one.

Super Cool App.
Thanks for installing me.
How many people have seen apps like this or notifications
like this?
Yeah, yeah.
Love these, don't you?
Eh.
You're going to have lots of ways
and already have lots of ways, hopefully,
to monetize your users.
Don't use notifications as a way to monetize your users–
or just be like, hey, I'm still here.
C'mon.
Please, come visit me– not going to make your users happy.
They're going to say, go away.
And they're probably not going to do
it as politely as I just did.

Questn– new, imaginary social network.
Mary has just answered your question.
This one's pretty good.
It could be a little bit better.
It's timely because I've got the information
that I know somebody has answered my question.
It's precise.
It tells me who and what's happened with it.
Now, it could be a little bit more precise
if I got the answer, right– if I knew what the answer was.
But it's a notification– maybe I asked a long question
and Mary gave me a long answer.
So I want to balance those kinds of things.
So clicking that would take me directly to the question.
So now that we know what makes a good notification,
let's take a look at how it works.
I'm going to give you the high level overview to start.
And then, we'll dive into the actual code
and get really fun and technical.
Notifications are built on service workers.
So all the stuff that you're used to with service workers,
today– if you've started playing with them,
you're going to need to use that technology.
So that means your site needs to work on HTTPS,
and you need to set up that service worker on the page
and register handlers for it.
And then, what happens is your page says,
hey– or your application– so your server, which
is that example.com, sends a notification to an endpoint–
and we'll dive a little bit deeper into endpoints
later– sends that to the browser.
The browser gets it, gives it to the service worker.
And the service worker shows the notification.
So let's walk through the flow of how a user gets subscribed.
So the first thing we want to do is
check to see if the user already has a subscription– if they're
already subscribed to notifications
so that we can update any UI on our page–
because we want to be able to give users
a way to say, yes, I want these or, no, I don't want these.
So we want to check to see if they're subscribed.
If they aren't subscribed, we're going to ask them to subscribe.
They'll subscribe.
Yay.
Awesome.
And we're going to get a subscription ID.
And this is sort of like the address
that we're going to use to send the notification to the user.
And then, we send that up to our server.
And we save that in our server.
So that way, we can get to that user later.
We know how to address them.
For sending a message, on our server,
we say, great, I want to send a message to this user.
And so you go and generate the message.
And you send it up to the endpoint.
And the endpoint goes, OK, great.
I just got this message for this user.
[INAUDIBLE]
I'll send it over there.
But I want to talk about endpoints for one sec.
Endpoints are pretty cool in that, right now,
there are essentially only two of them.
We'll start to see more as other browsers support notifications.
But right now, there's one for Firefox
and there's one for Chrome.
And what they do is they act sort of
as a clearinghouse for all of the message that goes through.
So that way, your web app doesn't
have to sit there and listen to your app, and your app,
and your app, and your app.
By keeping it through all one central channel,
it means that we can keep the user's browser
from killing their battery.
You don't have to have service workers resident in memory
the whole time.
The browser just handles all of that stuff.
And most of the platforms have good notification delivery
services already.
The one for Chrome on Android is built on FCM or– GCM– FCM
I guess it is.
So it means that you can get those things very easily done
with low power consumption.
So then, in the browser, when the notification comes in,
the message comes in.
We go, oh, great.
Browser's got it.
And the browser spins up the service worker.
It says, OK, this message goes to that service worker.
And it spins up that service worker.
The service worker handles the message
and shows the notification.

That's the flow.
Let's do it.
There's a little bit of setup that we
need to do for the endpoints.
For Chrome– unfortunately, right now,
Chrome doesn't support the Web push.eu/en» rel=»nofollow» >Push Protocol.
It's coming.
So there's a little bit of extra work
that we have to do for Chrome, today.
This will go away, probably, in the next three to six months.
I'm going for three months, probably.
But I'll give myself a little buffer space.
And this will continue to work after that,
but the Web push.eu/en» rel=»nofollow» >Push Protocol just means you have one thing to do.
So you need to go in to the cloud console,
create yourself a new project, and enable Firebase Cloud
Messaging.
It may still be labeled as Google Cloud Messaging.
And then, you need to get the project ID
and you need to get an API key.
And just write those down.
Put them around for later.
Then, we need to go into the manifest
and add the project ID to the gcm_sender_id at the bottom.
Again, this is only for Chrome, only for the next little while.
But this tells Chrome, when it gets a message, who
that message should go to– which service worker should
get that message.
So you just need to add that one little bit.
Setup for Firefox.
Awesome.
Done.
So Firefox uses the Web push.eu/en» rel=»nofollow» >Push Protocol already.
So there's nothing special that you need to do.
And one of the cool things about the Web push.eu/en» rel=»nofollow» >Push Protocol
is that you can talk to any other endpoint
without ever having used it before.
So when Opera spins up theirs, you
won't have to go and set any project up or anything
like that.
You can just go communicate to it, right away.
If Microsoft sets it up, if Safari sets it up,
if they're using the Web push.eu/en» rel=»nofollow» >Push Protocol,
you don't have to do anything.
You just have to do a little bit of– create a signature that
says, hey, this is who I am.
So if there's any problem, you know how to get a hold of me
later.

It helps if I hit the right button.
So let's talk about how we subscribe users and unsubscribe
users.
So checking for subscriptions– this
is something that we want to always do.
We're doing progressive web apps.
So we want to do this progressively.
Check to see if service workers are actually supported.
If they are supported, we go and get the registration.
And in the registration, we call the pushManager API.
pushManager API, and we say, get the subscription,
to see if the user has subscribed or not.
If the user's subscribed, we'll get something back
in that subscription.
If the user hasn't, that will be null.
And we can use that information to set some browser
UI so that we can say, oh, yeah, you're already subscribed.
Thanks.
Yay.
Or, you're not subscribed and, please, subscribe.
Then, to actually do the subscription,
we're going to say, service worker, registration, get
subscription, and get that registration.
And again, we grab the pushManager and subscribe.
And we need to say userVisibleOnly true.
What that does is that says, hey,
if we're going to send a notification,
we must show something.
That is to prevent people from sending
tons and tons of notifications that
are going to wake up that service worker
and keep the service worker alive
the whole time, draining people's batteries,
and make sure that you're doing something
useful with each notification.
So when the user then hits yes, I want to subscribe,
we get back the subscription object.
This subscription object is an object
that we can do unsubscribe on.
It's got some information about how to contact the user.
And we need to take that and send that up to our server
because, again, that's the address to go talk to the user.
But if the user does deny the permission or the user
is like, no, I don't want notifications from you,
we just want to make sure we handle that gracefully.
The subscription object is when you JSONify it.
This is what it looks like.
And there's a couple of things that I'll
point out specifically in here.
The first little bit is the first bit of the URL.
So that tells you, when you send a notification to the endpoint,
where that goes.
So in this particular case, I did this in Chrome,
so this is going to send to android.googleapis.com/gcm/send.
The second bit is my unique ID.
If you think about it as sort of like an email address–
the first bit is the domain, the second bit
is my name or whatever the case is.
And then the second bit here is keys.
These are the user's public keys.
If you're going to send any kind of data in your message,
it has to be encrypted.
And the reason for that is we want
to make sure that, from your server to the end user,
no matter who the endpoint is, they can't see it.
So if you send something up to a Chrome user,
Google has no idea what that message is.
There's no way we can see it.
Firefox can't see it.
Whoever else is running those endpoints,
there's no way for them to be able to see it.
So messages must be encrypted when you're sending them
back and forth or when you're sending them out to the user.
So when do we prompt users?
Generally, we don't want to do it on page load.
The page loads and all of a sudden you
get a, hey, do you want to subscribe?
This site wants to send you notifications.
That feels spammy.
That feels annoying.
I don't know what kind of notifications
you're going to send me.
I'm going to tell you to– insert not appropriate stage
words here, right?
So we want to make sure that users
understand what's going on.
If, for whatever reason, you decide
that doing it on page load is the right approach for you,
JalanTikus has done it, and they've done it well.
What they do is, on the page load, they dim down the page,
they put a dialog, and they tell the user what kind
of notifications they're going to send,
and they give them the choice there.
So they're preprompting the user.
They've done this well.
If you're going to do it on page load, this is the way to do it.
Don't actually just straight up prompt and be like,
hey, subscribe because they're going to hit no.
The Weather Channel has done, probably, I think,
the best job of all the places that I've seen.
So the Weather Channel has a specific page for signing up
for notifications.
And they do it in a specific, contextual, and user
initiated way.
They've tied the subscription– or signing
up for notifications– to what users want.
So they have a place where it says, hey, activate
browser notifications.
They tell the user what kinds of notifications
they're going to get.
And so when the user goes and says, hey, yes, I
want these notifications, and they
ask for the subscription object and that permission dialog pops
up, you already know that the user
is going to say, yes, to that.
If the user sees that without any contextual information–
they don't know what kind of notifications
you're going to send or why you're even
sending notifications, they're going to hit block.
Now, if they hit block, the only way to be unblocked
is for them to go into the browser settings
and change their browser settings, and unblock you.
How many people think they could get their family
and friends to go into their browser settings
and unblock something?
Not going to happen.
So we want to be really careful that we don't accidentally
get our users to go block our sites.
So we don't want to surprise them.
Ask them first, then do the dialogue–
the permission prompt.

The other thing about weather.com–
they give users lots of options.
I can say, hey, I want breaking news or government issued
alerts.
They've got all sorts of other things.
And I can choose the ones that I want
so I'm not getting every single thing that they send out,
which is probably going to get a little bit annoying.
So how do we unsubscribe a user?
If the user says, nope, I don't want this anymore, rather than
them going and finding a way to hit
block because, with every notification that pops up,
there is an opportunity for them to hit the dialog
and be like, block, I don't want this anymore.
We need to make it easy for them to unblock.
So again, we've seen some of this code
before, service worker, registration,
get registration, get subscriptions,
get the subscription again.
And then, we call subscription.unsubscribe.
And that unsubscribes the user.
So that does it on the browser side.
But the thing that we have to now do
is go update our server because we have to tell our server,
don't bother sending to this user
anymore– because if we try and send it
to an endpoint and the user's unsubscribed,
we're going to get, essentially, no, don't know that address.
Sorry, go away.
And it's just going to fail.
So we just want to make sure that we're not
sending annoying messages to the endpoint.

We've got some sample code up on our Github repository that
walk you through a lot of this process of how
to sign the user up.
Some good practices there.
It's a good place to start.
It's not something that you necessarily
want to use in production code, but it's a great place
to start.
So when we want to send a message.
When we want to get a message out.
Remember that JSONified endpoint subscription thing?
Keep this in mind, because we're going to need this.
There's the endpoint and the keys.
There are two different types of messages that we can send.
One is called a Tickle– that has no data,
and the other one is Payload– with data.
Tickles aren't really all that useful,
but you might want them if you don't have a lot of stuff
that you're ever going to send.
Most likely, you'll be sending with data.
So we need to encrypt those messages.
So we take the keys that we got in the subscription.
Those are the user's public keys.
We take our Payload.
We do some AES128 encryption on it, sign it with our keys,
and we suddenly get an encrypted message.
Now, I could probably spend the next 20 minutes
plus the next talk walking you through how
to do the encryption.
And it's not fun.
And I wouldn't recommend that you do that yourself.
So we have another block of some sample code that you can use.
Firefox has one as well.
I'd actually recommend you use the Firefox one
because the Firefox one supports both FCM, right now,
and it supports the Web push.eu/en» rel=»nofollow» >Push Protocol.
And they've said they're going to keep maintaining it
as a library as opposed to ours just being some sample code.
So check those guys out.
Use that.
It's probably a little bit easier to go.
So to send a message via Firebase Cloud Messaging–
they changed the name late in the game
after I started rehearsing– makes it all a lot much
more fun to make sure you're saying the right thing.
We do a POST message.
Both the Firebase Cloud Messaging and Web push.eu/en» rel=»nofollow» >Push Protocol
use a REST API.

So for that, we're just going to do a POST to the URL
that we got earlier.
We're not going to use that extra string bit.
That's one of the key differences here.
We use an authorization key.
That's the API key that we got from the cloud console.
We then have to include our public encryption
keys and the salt that we use to encrypt the message.
So we're doing [? public ?] [? private ?] key encryption.
And then the message that we want to send.
You don't have to include the time-to_live,
but the time-to_live is useful.
That says, I want this message to be delivered
within the next 120 seconds.
If it's not delivered in 120 seconds, abandon it.
So imagine my phone is turned– well,
my phone is in the back turned off, right now.
So I wouldn't get that message because it
would exceed the 120.
So that's just how long the endpoint
should try to deliver the message to your device.
Then the registration ID and the raw_data.
The Web push.eu/en» rel=»nofollow» >Push Protocol is pretty much the same.
Instead of doing a POST request, we do a PUT request,
and we use the whole endpoint.
So we put the whole endpoint up in there.
And instead of putting the time-to_live inside the data,
we put the time-to_live as a header.
We then have to say, hey, our Content-Type
is an octet-stream because our content is actually
binary data encoded.
And we give it the encoding type so that we know, hey,
this is all good.
And then, we need to include our public keys,
just like we did before.
Here's the message.
Great.
And finally, we need to include the authorization bearer.
We're using a protocol called Vapid.
And Vapid– I really wanted to have some fun photo,
but I couldn't find anything that worked and would
be somewhat appropriate.
But Vapid essentially says, hey, I
am a server that is sending to you, endpoint,
and I am a real person.
If I'm sending bad messages, here's
how you can get a hold of me later.
And so it just is a way of signing these messages to be
like, yes, I'm not trying to cause a denial of service
attack or give you bad stuff.
And then, finally, the last little bit
is the encrypted payload.
So we stick that on the end.
So when we handle the message coming in,
we need to add an EventListener to our service worker.
So in the service worker, we want an EventHandler
that listens for a push.
And we're going to wrap everything in a waitUntil.
The waitUntil– some people get a little bit–
and even I got a little confused with it
several times on why I'm using it,
and what's going on and, especially,
all the wonderful brackets.
waitUntil tells the service worker
that you want it to keep working, stay alive,
until the promise that's inside it returns.
And you must have shown a notification at that point.
The reason that you want to do that is, say, for example,
in your notification, you get some data that's come in,
and you need to save that in an IndexedDB database,
or you need to save that somewhere.
Or maybe you need to go and do a FETCH request.
Well, you don't want the service worker to shut you down
because the service worker's like, well, I
think you're done.
You don't need to work anymore, before you've
shown the notification or before you've
saved what you need to do.
waitUntil tells the service worker,
you need to stay alive, stay alive until I'm done with you.
So then self.registratio n.showNotification.
And that says to the notification, hey,
I want to show a title, and a body, and a message, and a tag.
Well, that's not exactly the most exciting notification
in the world, right?
And it kind of goes against everything
we talked about earlier in terms of notifications
because it's pretty boring.
It doesn't tell me anything I need to know.
So what about that payload stuff?
How do we get that?
Well, what we do is say, event.data.
And if there's data in the payload that gives us
the data– and we can say .json or whatever to turn it
into some kind of format that we want to handle.
If there's no data, there are still some things we can do.
And we only got data in Chrome 50, I think it was.
So you might need to do some other things.
In that case, you could use a FETCH
and go get something back from the server.
In fact, in terms of data size, you can only have about 4K.
I think it's just a couple of bytes over 4K.
So if you're actually trying to send something more meaningful
down and you want to make sure that the page works offline
or you've got a new email and that kind of thing,
it might be more than 4K.
So in that case, you might use FETCH, here,
to go get that stuff.
And then, once you've done that, you
can then call the notification and say, notification.title,
body, icon, and tag.
The tag is there.
What the tag does is that allows you to group similar messages
so that, if you've got three messages that
come in with the same tag, only one
message with that particular tag will show.
So that way you can group messages together.
You don't have multiple things.
Or, you could have three messages
if they have different tags.

One of the other things that you can do
is make it easy for the user to complete
a task without actually having to open your app by adding
action buttons.
So action buttons you can think of as, hey, I
want to like this, or retweet this,
or I want to confirm or cancel reservations.
Maybe for– I wrote their name down
because I keep forgetting it– JalanTikus who has the shopping
cart thing, hey, do you want to just finish your shopping cart?
Yes, take it straight there.
No, I want to abandon it– and just throw it out.
Or maybe, it's yes, save it for later.
I don't have time to check out now.
So giving users an ability to be able to do additional things
in their notifications.
So to add an action, we just need
to add this actions attribute to our notification,
and we need to supply a couple of things.
The action.
And this is just for us, internally,
so we know what the user clicked;
a title, so that you get something that's going on;
and then an icon, what image that you want.
For any time both on here or on the icons that you're
using within your notifications, I strongly
recommend that you cache those with your service worker.
That way, they're always going to show up.
If the user goes and clicks on– gets a notification just
as they're going into that subway tunnel
or whatever place where they have no network connection,
you want to make sure that they're not
seeing a notification that they don't know what it is.
So having that title there is really important.

So the user just clicked on like, or they clicked on yes,
or they clicked on something, how
do we know what they clicked on?
Well, we need an EventListener in our service worker
that listens for notificationclick.
And the notificationclick says, hey, you
clicked on this, great.
And in the event, we can look at .action,
and that's going to tell us whether they clicked
on an action.
Or, it'll be blank if they didn't click on anything–
so they clicked on the main part of the notification.
If they clicked on that, it'll get that.
So they clicked on like.
In that case, event.waitUntil– again,
because we want to keep the service worker alive
while we go do our thing.
And I just did this one as a FETCH.
And I was like, hey, go like this notification.

Maybe they clicked on the main thing
and you just want to open a web page.
So then, you can say clients.openWindow,
and open the web page that they're using.
So a nice way of getting them into your app.

Would be a nice if we can get notifications
to dismiss across all devices.
How much fun do you have when you come home
and you look at your tablet or a phone or something else
and there's dozens of other notifications showing?
You can do that with the notificationclose event.
So by listening for the notificationclose event,
you can say, OK, great.
When that happens, I'm going to go
get the data out of my notification and do a fetch
and close that.
In this particular case, one way you
can do it is by, when you send your notification down,
you add an ID attribute to each notification
so that you know what user clicked.
And when they closed it, you're good to go.

I blew through that.
I talked a little fast.
I hope not too bad.
So you can build really great engagement with users
by using push notifications.
It's not terribly hard to do.
If you start building things with a service worker–
if you've used a service worker before,
you don't have to go all crazy, and make everything work
offline, and do the whole progressive webapp piece.
You can add push notifications to any website, today.
As long as you're using HTTPS, you can get notifications
added.
As you build out your notifications,
make sure that your notifications are precise,
that they're timely, and they're relevant.
Do that.
Do I want to be disturbed by that?
Don't tell your bosses about notifications
that you think you're going to not want
so that they get great ideas.
We want to make sure that we keep good control over them–
keep them really solid and helpful to users.
Ask permission and context.
Don't do it on page load.
Don't go and just do it completely randomly.
Make sure the user understands what they're
doing so that you ask them first and then do
the permission dialog so that they know why
that notification dialog that says,
this site wants to send you notifications, is showing up.
We don't want to lose them if they block things.
And finally, the last one.
I always like to close this, be awesome.
Build stuff that's fantastic.
Build stuff that's really great– that you're
going to like, that your users are going to like,
and we're all going to like.
So with that, there's a few things here that you can use.
There's the Web push.eu/en» rel=»nofollow» >Push Notification
Getting Started Guide.
This getting started guide– and there's
a Codelab that does this same thing, I believe,
in the Codelabs area.
So if you want to go try writing some Web push.eu/en» rel=»nofollow» >Push
Notifications in a Codelab, you can do that today.
If you're really kind of curious about how the encryption
stuff works, we do have a post up about that.
Some of these links are kind of long.
But if you go to developers.googl
e.com/web/updates and look for the data,
it explains all the stuff you need to do.
It's not terribly complex, but I'm just always afraid
that, if I screw one thing up, I'm going to leak everything.
And security scares me because I just don't want to be that guy.
And then finally, the last one is the Vapid Spec.
That explains how to go set up the authorization
key so that, when you send your message to a Web push.eu/en» rel=»nofollow» >Push Protocol
server, that message gets through,
the browser's all good.
So with that, I will say, thank you very much.
I hope you've all had a wonderful I/O. Thank you.
[APPLAUSE]

[MUSIC PLAYING]