[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]
