[MUSIC PLAYING]
CHRIS WREN: Hi, this is great.
Thank you for coming.
It's an honor just being
able to speak in front of you
about such important topics.
I'm glad you're all here.
Hi in the back.
So my name is Christopher Wren.
Do I have slides?
Can I have the slides, please?
They asked me to
introduce myself.
So being from the
East Coast, I'm
going to do something
I'm uncomfortable with,
which is to talk about myself.
So I'm Christopher Wren.
The little letters
after my name represent
about a decade I spent
at the MIT Media Lab
studying the interaction
between people and computers.
And then after some time,
I ended up the Google.
And only about four
years ago, I ended up
getting an opportunity
to join the Android team.
So I work on the
Android system UI.
And I've done that
for about four years.
My first release was Jelly Bean.
So that's pretty exciting.
We're all the way up
to Marshmallow now.
And today I'm going to be
talking about notifications,
which is one of the things
that the system UI team builds.
And particularly, I'm
going to be talking
about how notifications
affect people,
and how you should
be thinking about how
you're affecting your users.
So having said all
that introduction,
I'm a little nervous about
the graphic on the screen,
because I'm worried
that people will
think that, like, I'm
on the mountaintop,
and I have all the answers.
And I definitely do not.
So put that out of your head.
It's definitely the case that
I'm climbing the same mountain
as you.
The way people
use these devices,
the way these
devices are changing,
and the way we interact
with each other
while we use the devices is
all changing rapidly right now.
So we're all trying
to figure it out.
But I'm going to tell you
what I think is currently
the good stuff to do.
So let's get to it.
So the first thing,
of course, I did--
well, the last thing I did
before I got on stage here
to talk to you
about notifications
was turn off my notifications.
So because wouldn't
it be embarrassing
if I was up here
talking to you about how
not to disrupt user attention
and my phone went off?
I certainly hope I actually
remember to do that.
That was in the script.
So being at a--
ooh, don't do that.
Being at a developer conference,
obviously, we're developers,
we're thinking
about the software,
we're thinking about the
device, we're thinking
about APIs and editors.
And that was a great thing this
morning with the Instant Run.
How many like Instant Run?
You like that, yeah?
That's great, OK.
[APPLAUSE]
So obviously, our
head is in the device.
But I want you to pop
out of that a little bit.
So this talk is about
what the devices are for.
People will tell you they
can't live without their phone.
What they mean is they can't
live without the things
that the phone connects
them to-- the people they
love, the issues they care
about, the places they miss.
So this has become a portal
for us to other people
in other places.
And so that's important
for you to remember.
So this is sort of the
backbone of the talk.
There's like a sort of Maslow's
pyramid of needs, right?
So this is sort of my pyramid
of needs for notifications.
And at the-- well, the top--
but the base, the first thing,
if you can't do anything else
when you're making a decision,
I want you to ask yourself if
you're going to annoy the user.
Don't do that.
And then we walk up the pyramid.
We want to respect their
life, and their story,
and how we're fitting into it.
And we want to empower them to
do the things they care about.
We want to delight them, because
we want them to love our apps.
And at the very top, if you
can, if you can reach it
you want to help them connect
to the people they love,
and the issues they care about,
and the places they miss.
OK, so let's go through
these one by one.
Don't annoy the user.
So why don't you want
to annoy the user?
Well, first of all,
starting in Jelly Bean,
we started giving them
more and more tools
to push back against
the sort of flood
of attention-grabbing
information.
And so one thing they can
do in Jelly Bean and on
is they can block
your notifications.
And you will not know.
We don't tell you the your
notifications are blocked.
They're just sort of banned,
and they just go into the ether.
So this is, in some
ways, depending
on how your app is structured
and what your app is doing,
you're kind of
dead at this point.
You have no way to
get back to the user.
So you should be
thinking, whenever
you make a decision, whenever
your product manager says
we've got to do
this thing, I want
you to have this in your head--
that you could get banned.
If the user doesn't
know how to ban you,
or they just don't
feel like doing it,
or you haven't created
a value proposition.
the other thing they
could do, of course,
that every user knows how
to do is uninstall you.
So let's watch this poor
little ice cream guy.
There he is, my app, he's happy.
No, don't do it.
No, don't do it!
Ah!
OK, so let's just watch
that one more time.
Just let it wash over us.
[LAUGHTER]
Just watch it go.
There it goes.
It's your app.
It's gone.
OK, so don't annoy the user.
If you didn't have motivation
before, hopefully you do now.
This is a base thing.
So this is so important
that, of course,
we try to help you with this.
So one of the things we
do in Lollipop and on
is we have a mode
called Do Not Disturb.
So you don't know, as the
app, you don't know my story.
You don't know if you're
going to be interrupting
me and something
that I care about.
But I can give the
system signals.
I can say, listen, I do not want
to be bothered by unimportant
things for the next hour.
And what will happen,
from the app perspective,
is that your notification
won't interrupt the user.
It'll still be posted, it'll
still show up in the shade.
It's not like being banned.
It'll still be there.
But you have to know
that this might happen.
So that the notification
might get posted,
it might not have made the
noise you wanted it to make,
for example.
And that's a good thing.
Because if you'd made the
noise at the wrong time,
you would have annoyed the user.
So what do you need to know
as developers about this?
This is what the
system does, right?
The user has a lot of
ways to control this.
They can say-- because
all the information
channels that users use are, as
I said, they're evolving fast.
They're changing rapidly.
So they're kind of idiomatic.
Some people still rely
on phone calls a lot.
Some people use SMSes.
There's a lot of
variability there.
So the user's able
to control this
by sort of a channel basis.
And as a developer,
you need to tell us
what channel you fit in.
So this is going to be
my go-to code snippet.
We're going to be modifying
this all through the talk.
I made it nice and big,
so you can read it.
So this is the builder pattern.
Have you all using
the builder pattern?
Yes?
Builder pattern?
You should be using
the builder pattern.
Because that makes sure that
we have all the information
we need to treat your
notification correctly.
And this is all about
getting the notification
at the right place.
So this is the builder pattern.
Very basic, obviously-- you
get some icon, text, title,
and you build it, and
you get a notification.
I will try to use
NotificationCompat everywhere
in the sample.
Sometimes it doesn't
fit on the screen.
But if you're using
the builder, you
should be using
the Compat.Builder.
Because this will at least
compile and run all the way
back to four.
I don't know, is anybody
targeting four anymore?
So for all intents and
purposes, all Androids.
For features that don't exist,
it will fall back gracefully.
And then you don't
have to worry about it.
So that's nice.
So we do that for you.
So here's the meat of the thing.
So for category, very
simple-- you just there's
a builder method that
you set the category.
And you just have to
pick the right one.
That's the hard part.
So here's some categories.
So these are the
ones that relate
to that screen I showed you
before, the ones that the user
right now has direct control
over-- so alarms, reminders,
events, messages, calls.
You'll notice they're
pretty tightly defined.
So alarms are like
alarm clocks--
the thing that wakes
you up in the morning.
So you have to think
again about what
is the user going to expect
when they say they want
to be interrupted by alarms?
And make sure that you're not
going to surprise them when
you tell us that it's an alarm.
OK, and one of the most
subtle ones, I think,
is this category, message,
which sounds pretty generic--
like, oh, message, OK.
But this particularly
means synchronous messages.
So SMSes, instant
messages, things like that.
On the next page there is email,
which is asynchronous messages.
So email, we
wouldn't necessarily
consider that a
synchronous message.
And social updates,
for example, that
are undirected, like,
not a mention of me,
but, like, just
I posted a thing.
That's usually not sort
of a notification event.
And then this last
one they put up here,
there were a whole bunch
of other recommendations
in the API docs--
categories in the API docs.
The recommendation
one I put up here,
particularly because if you're
doing development for TV, then
you're already using this
to get recommendations
into the recommendation bar.
And there's no reason you
shouldn't do that on the phone
as well.
If you're going
to post something
that's recommendation-ish,
put the category on it.
So you may have noticed-- the
sharp eye may have noticed
that there were little icons.
Those aren't just my reminders,
although they do help me.
What I'll try to do
in the rest the talk
is I'll highlight everything
with the version on which it
will work.
So remember, if you use the
compact library, it'll run,
but it'll actually
exist on these devices.
So a lot of things I'm going to
be talking about are Lollipop.
And right now, this is
relatively fresh data.
It's about a quarter
of the devices
out there that we're seeing.
And then many of the other
things we're talking about
will be Jelly Bean and on,
which is, at this point,
a huge fraction.
And then, if it's
relevant to all devices,
mostly those sort
of policy things,
like when should you post
things on market with the Droid.
So keep your eye for
those little icons
if you're wondering, am I
targeting the thing that will--
this is useful for me.
That's how you know.
OK, so onto the next
chapter-- respecting the user.
So let's see.
So one of the main features
you can set in the builder
is something called priority.
And that sounds pretty good.
People usually think of priority
as where I am in the list,
and often, I
imagine, that people
want to be toward
the top of the list.
The priority is about
a lot more than just
where you are in the list.
So you'll notice
at the bottom here
there's this thing
PRIORITY_MIN, which
actually gets sort of a
different visual treatment.
So in this case, it's
a little bit gray.
That's sort of de-emphasized.
These have implications
about how the user is going
to end up being interrupted.
And I guess we should run
through a couple of those
and try to understand them.
So again, trying not disturb the
user, annoy the user, one thing
you should do is use things like
PRIORITY_LOW or PRIORITY_MIN.
And this is how you
set them-- setPriority
and there's an
enum, or a constant.
And the reason you
should not always
want to get in users'
face is because you
may have information
that's useful to them
at some point in the future.
You don't know when
to postage them.
And there have
been some studies.
You can look in the
academic research.
There was one-- I can't
remember reference right now.
Anyway, if you look
for them, you'll
find the studies
that show that people
are more receptive
to notifications
that they get at the right time.
So this is a way for you to
sort of do that on the cheap.
You post it in the
low priority bin,
so that they aren't
grabbing attention,
but the user will see
them when it's time.
So here's an example of my
lock screen, for example.
There's a chat
message from Mike.
And it looks like I
have one notification.
It turns out that I actually
have two notifications.
I have this file
upload notification.
And that was
something that the app
decided wasn't enough
to bother me about.
So this is another way
that the presentation
is key to priority.
So if you post a min
priority notification,
what you're saying is
don't bother the user.
If they go looking
in the shade, you
can present it to them, because
then they're probably bored,
they might be
picking up something.
But we don't put it
in the lock screen
because it's not
important enough
to bother you while you're
on your way somewhere else.
But the instant message, yeah,
I might want to know about that.
I want to know I missed it.
So another place that minimum
priority notifications
are going to don't show
up is the top here.
So you'll notice the status
bar has one chat icon.
There is no file upload icon.
This is another way of that
while the user is on their way
somewhere else, you
don't necessarily
want to bother them
with this update that
may be not critical.
Another way to get the user
the information they need
is to use this thing
called a set alert once,
setOnlyAlertOnce.
I don't know if
anybody's used that.
OK, so you should be using this.
So this is a situation
where, again, it's
not an instant
message notification.
It's not one that I'm going
to, like, I hear the beep,
and I pull my phone out,
and look at it right away.
It might be something
like, what's the weather,
or what's the
latest stock quote,
or how far away is something.
Those are the kinds of
things where you're not
going to alert these.
You don't have any timely
information to give them.
But you have
information they might
be able to take advantage
of if they happen to see it.
And this is a way
if, for example, you
did want to alert them
that you were posting it,
but you didn't want
to keep bothering them
while you're updating it, you
can update in the background.
So setOnlyAlertOnce says,
don't make noise again.
If you've already made
noise, don't do it again.
And then the system tracks that.
Because that's something
that would be difficult
for you to track.
This is another way
we're helping you.
OK, so this instant
message we keep seeing.
A lot of the
notifications you're
going to see on my screenshots
are from an example app.
And I have a link to
the code at the end.
And Mike Claron is my director.
So I have, in the
past, scared myself.
So I'll be working on
something, and I'll forget,
and I'll run the test app, and
look at it, and I'll go home.
And I'll come back the
next day, and I'll be like,
oh my gosh, Mike!
I missed a thing from Mike.
Or I missed a call from
whoever, or whatever.
OK so there's this notion
of stale notifications.
When we go talk
to people, we see
they'll pull down their shade.
And there will be
like 10 notifications
from this app, the most
recent of which was useful,
but the other ones
are totally not.
So you should--
this is very easy--
you should just cancel them out.
If you think that you've
posted information
that the user isn't going to
care about an hour from now,
don't show it to them.
Get out of their face.
Their attention is worth
more than your extra effort
for coding.
So you can do them that favor,
and they will appreciate it.
So that's one thing to do.
This is the alarm service.
It's, again, existed back
from the beginning of Android.
And so, in this
case, I would craft
this little
PendingIntent, which,
in this instance, the
code sort of indicates
that it may cancel
all my notifications,
so I would call
no man cancel all.
If you want to track
individual notifications,
you would just make a
PendingIntent with the ID,
for example.
So I've been talking about how
to get out of the user's way.
Sometimes you do need to
get in the user's way.
You need to alert them.
So we should talk about
that a little bit.
So this is another
situation where
the system UI is helping you.
So it used to be the case
that if you were reading
a book on Android, and
you got a phone call,
you kind of got
smacked in the face
with the resulting
activity, right?
Like blah!
So you're reading away,
and you're focused,
and all of the sudden,
this phone call comes in.
And the person who
called you didn't
know that they were going
to interrupt something.
Or maybe you were
playing a game, even.
Like you could have been
playing a game, about to get
a high score, and then blah!
So that's not good.
So one thing we
did in Lollipop is
we introduced this
idea of a peak.
So there's a peaking
notification.
So the nice thing about this
is that the user doesn't
get pulled out of their task.
So attention, sometimes,
is about focus, sometimes
about task.
And because you don't
know what task they're in,
this is something the
system will help you do.
So in this case,
in this example,
the phone call comes in.
The user gets a
chance to maybe finish
the sentence they
were reading, and then
answer it, or ignore it, or
whatever they want to do.
And what we realized
was that it was still
an interruption, if you're
reading, to hear the noise.
Even if it wasn't
a phone call, let's
say it was just an
instant message.
So you're reading, or playing
a game, and you hear, broop!
And you're like, ah, I need
to go see what that was.
Like, it might have been
something important.
And then you go see what
it was, and it turns out
it wasn't anything important.
What we did is we allowed
high priority notifications
to bubble up into the space.
So you can elect
to use the space
by setting your priority high.
This is another way in which
priority changes the way you're
presented, and making sound.
So we could have-- in fact,
one of the early designs
was to have a specific
API where you say,
I want this to be
in the Heads-up.
And instead, what we did is we
took this sort of implicit API,
because we wanted
you, the developer,
to make the conscious
decision that you're
going to annoy the user.
So if you're going
to make noise--
you have to at least make noise.
You can't show up in the
Heads-up without making noise.
So you have to make that
commitment that you're
going to annoy the user.
So you have to have that
calculus in your head,
and say, well, this possibly
could go to the user,
so I want to make sure that's
going to be appropriate.
I want to make sure that
they're happy about it.
And again, if you
annoy the user,
don't use the peak, unless you
really think it's worth it.
Because you will
get uninstalled.
So there's the
poor ice cream guy.
OK, so empowering the user.
So we're moving up
the pyramid here.
So we're going to feel a little
better about ourselves, right?
So one of the things
that you need to do
is to make sure-- notifications
are supposed to be actionable.
I'm supposed to be able to
take some action on them.
If it wasn't actionable,
then I can browse it later.
But if I need to know
and take action on it,
then it makes sense
as a notification.
And my kid already
understands this.
The tablet was out,
there were notifications.
I was like, hey, how do you
feel about notifications?
Kind of a weird
home life, maybe.
And the response was,
some of them are annoying.
I was like, oh, why?
Oh, well, I can't do
anything with them.
So you're not fooling anybody,
even the kids understand.
And particularly
in that case, there
was a notification about a game.
It was one of these
sort of farming games,
and like the squash
was ripe or something.
And there's a
notification about that.
And that was
actually appreciated,
because now it's time to
go back and do something.
The other notification
was oh, wouldn't you
like to buy that power-up?
Well, of course I would.
Click on the notification.
Turns out you can't do
that yet, because you
don't have enough beans,
or whatever it is.
So that's not actionable.
That's very clearly an ad to
pull you back into the app.
This one is at least-- I mean,
it's certainly pulling you back
into the app, but at least
it's doing the user a favor.
And even children understand the
difference between these two.
So definitely think about it.
And then we had the talk.
So that was when
we had the talk,
and we talked about how to
install and uninstall apps.
And they're installed.
So how can you empower the user?
So it turns out that
people have different-- one
thing you can do,
that we've allowed
you to do in Lollipop is to
get to this long press space.
If you have a notification
settings activity, an activity
where the user
goes, just tell you
how they want the
notifications to be presented.
Should they make noise?
Do I even want those
kinds of activities?
And you should
have one of those.
If you don't, you should.
And if you do, then
you can tell us,
and the system will surface
that in various places
where the user might
be looking for it.
Because they may not know
how to get to it in your app.
They may be in some
menu or whatever,
and may not even think about it.
But, for example,
in this case, we
surface it right
in the long press.
So they can say, I don't
like that notification.
And there's a gear.
And that gear will
appear if you do this.
So this is your manifest.
You have your settings
activity, which you already
have-- you should.
And you just have this category.
So notification
preference category,
and we'll go look those up.
And wherever they
make sense to surface,
we'll show them to the user.
And that'll take them
directly deep into your app.
And then they can
do all the stuff.
So another thing--
actually, a friend of mine
found out I was
giving this talk.
And he asked me to tell
you one thing, which
is that if you have
a settings activity
for your notifications,
which you should,
and the user
expresses some desire
about how notifications should
be handled, please save that.
Don't drop it on
the next upgrade.
Don't move it between devices.
You should definitely send it
to your server or something.
And I think the key idea there
is that any time the user
tells you or gives you
some information about how
they like or dislike
your app, that's gold.
You're never going
to get that again.
They're never going
to tell you again.
So any chance you get where
they give you their preferences,
you should definitely
treat those as something
to save and cherish.
And back it up, and restore it,
and make sure it's still there.
So if you don't have
a settings activity
for your notifications, and you
should, this is how it looks.
So it turns out
it's really easy.
I told you I was climbing
the same mountain as you.
Actually, I had never
written a preference panel,
so I learned this for the talk.
But you write some XMLs,
check-box preference.
So this in particular controls
my example app-- like,
do I want my example SMS
to make noise or not?
So this is sort of what
the XML looks like.
And then very simply, you just
pull it out of preferences.
And if it's not true,
you don't set the sound.
So that's pretty easy.
So we should be doing
this, definitely.
OK, the other way to empower
the users is to-- like I said,
notifications should
be actionable.
So obviously, you should
add actions to them.
So actions are this way to
add more than one intent
to a notification.
So normally, you would
click on the notification.
It would fire an intent.
Usually, that just
opens your app,
and drops you in the perfect
context to see the thing.
But sometimes, the user
might be able to make
a decision from the shade.
From the user perspective,
that's much better.
So in this case,
an incoming call,
I can add an action button
that lets me drop the call.
And now imagine that
this is in the peak.
It's slid down.
I'm reading, I'm playing
a game, or something.
I don't want to talk
that person-- ignore.
I didn't even have
to leave the game.
So if I had to click
on the notification,
go into the phone app, now
I'm in a different context.
I've lost my mental space back
there, I have to go back to it.
So this is something you
definitely do for the users
to give them more
choices, and give them
more actionable notifications.
And this is how you add them.
This is actually, I think,
the deprecated call,
but it fits on the slide.
So if you try to
do this, it'll tell
you to do something
else slightly different.
But the basics are the same.
You give us a
small icon, and you
miss a very tiny string,
and the pending intent
that you want to fire.
And often that pending
intent will go to a service.
It won't actually
start an activity.
It'll go to a service that will
say drop the call, for example.
And the thing you
should think about
is that the more
actions you add,
the smaller the buttons get.
So what might look
good in your language,
if you internationalize
it, might not fit.
So this is a very limited space.
So you have to sort of
craft those messages,
and think about exactly
what the actions are.
Another way to
make notifications
actionable is to give the user
the information they need.
So instead of, "you'll never
guess what Romain posted,"
show the picture.
That's the main body
of this message.
So the user should be able
to see it and take action
on it right there.
And I think this is
about building trust.
If you don't always pull
the user into your app
to perform every
action, then the user
is going to trust that when
you do pull them into the app,
that it's for a good reason.
And they're going to
have a better experience.
There's a style bullet
that started in Jelly Bean.
Again, using the
builder pattern,
you would build
your notification,
and that would render as a
small regular notification.
And then if you wanted to
have an expandable version,
then you attach a style.
So in this case,
there's a picture style,
it just wraps the bitmap.
And then there's a text example
of the same sort of thing.
You can wrap the text example.
And this is, again,
it's just sensible.
Like, I'll be there have
to click on it, right?
OK, instead.
I can pull it open and be,
I'll be there in five minutes.
Oh, great, OK--
that's fantastic.
So giving the user
the information
they need, when they need
it, so they can sort of live
their life and tell their
story, is a good way
to make the user happy with you.
OK, so this is
another little story.
So how many people
use Google Calendar?
A lot of people.
I saw, when I was
sitting back there
and I saw people [INAUDIBLE].
How many people, you've
been using it long enough
that you remember when it used
to stack up notifications?
Like you'd have
your next meeting,
and your current meeting, and
all the previous meetings.
This is a case
where-- I'm not really
going to talk about
multi-device very much.
But this is the one time we're
talking about multi-device.
It is the case that
some of our users
will have a phone,
and maybe a tablet.
And so my experience was that
I would have my phone at work,
and I'd go to all my
meetings, and dismiss them.
And then when I got home,
I got a little memoir
of all my meetings
sitting on my tablet.
I'm like, great, I
was there, thank you.
So this is something
one of the advantages
of working at Google is
I get to paratroop in
to, say, the calendar team,
and help them out by building
this global dismissal.
So this is two devices.
I get a calendar notification
independently on each one.
I dismiss it on the right one,
and the left one auto-dismisses
it.
So this is about--
remember I said every user
action is sort of precious.
You want to really value
those interactions.
And is a case of making the
most of that interaction.
I told you I was done
with it, so there's
no reason to show it elsewhere.
OK, so this is multi-device.
It's getting a
little complicated
But if you're already
creating this problem,
you almost certainly
have a server
that's causing these
events to come out.
And probably, you're using GCM.
So if you're already doing that,
then the flow is pretty simple.
The server-- there's
some event happens,
somebody creates
a calendar event.
It sends information
out to the two devices.
They post notifications.
You catch the dismiss intent.
I'll show you in a
second how you set
and dismiss pending intent.
So the person
dismisses the intent.
The application
gets that callback.
It sends a GCM
message to the server
and says, hey, it was dismissed.
And the server says, oh,
well I should send that out
to all the rest of them.
So it sends it all to
the other devices again,
and the phone says,
I already got it.
But the tablet's like, oh,
that's good information,
I'll cancel that notification
so the user doesn't
have to worry about it.
So this is how you do it.
So in your GCM-- again, if
you're creating this problem,
you're probably
already using GCM.
In your GCM handlers,
you just add
a clause that says--
you have to come up
with some API for yourself, but
"post" sounds like a good one.
And the key bit of
information here
is that the postMessage
from the server
will include some
sort of unique ID.
You heard about this
in the previous talk,
where you have the server
managing these unique IDs
so you can refer to things.
This is the same thing.
Server is going to
send down a unique ID
so that all the devices agree.
And then the devices
independently
are going to create
these delete intents.
So this is basically a
pending intent, a wrapper
around this unique ID.
And then it's going to
post the notification.
OK, so when the
notification is dismissed,
there will be some
intent service you have.
And depending intent will
fire into that service.
And you'll have
a dismiss action.
And you pull out that unique
ID, because now you have it back
in your hand.
You don't really have to
save it anywhere-- it's sort
of-- as part of this state.
OK, so then you build your
message and send it off.
Again, if you're using GCM,
there's more stuff around this,
but you probably
already have it.
So this is just a
couple lines to add.
And then, again,
back in the Received,
we already have
our post receiver,
we're just going to
add a cancel receiver.
And again, we'll
get the unique ID.
In this very simple
sample, we're
using the idea as
the notification ID.
So I can just call directly
into NoMan and say cancel that.
You could imagine
a situation where
you'd do a look-up and mash keys
or something more complicated.
OK, so the last
thing in this section
is about ongoing notifications.
So ongoing notifications
are these things you cannot
dismiss.
You sort of swipe them,
and they're stuck there.
And this sounds
like a great idea.
Like I can pin
something to the top,
and make it un-dismissable, and
then I've always got that spot.
It turns out that this
really annoys users.
So there are-- how many do we
hear-- like 1.4 billion users?
A lot of them are not like you.
And they use their
phones in ways
that you would never
have predicted.
And so there's a lot
of different workflows
that people use in the shade.
And one of them, for
example, is to just deal
with the top thing.
You deal with it, and get
rid of it, deal with it,
get rid of it.
And the nice thing is that the
next one pops up automatically,
and you get the action
buttons out in the full view.
So in some sense,
the notifications
aren't actionable until they pop
up to the top in that workflow.
Now you can always open them.
But if you've
taken that top spot
with an un-dismissable thing,
suddenly, their workflow
is totally broken.
Yes, they can pinch the
things open and do the stuff.
But you've interrupted
their workflow,
and nobody likes that.
So you've got to think really
hard about sticking something
on the top.
And there's certain cases
where you have to do it.
If you're starting a
foreground service,
you have to put one up there.
Because it will kill your
service if you don't.
Things where there is
an external obligation,
like another person
who's waiting for me--
that's an ongoing event.
That's not an ongoing
event in your app.
It's not an ongoing
event on the phone.
It's an ongoing
event in real life.
So that makes sense to
make that an ongoing,
because the risk of
dropping that, losing it,
like accidentally
swiping it away
and not being able to get back
to it before the other person
gets bored and goes
away, is very high.
But for almost
everything else, you
should prefer a
model where you can,
instead of making an
ongoing, say, oh, I don't
care about this now-- snooze.
And then post an
alarm for yourself
and if it is that important,
post it again later.
10 minutes from now,
an hour from now--
whatever makes sense.
The other thing you can
do is, if you really
believe you need to have an
ongoing notification stuck
in the shade, is either make
it lower priority, or give them
a way to bump the priority down.
So here's some examples
of ongoing notifications
that do the right thing.
They give the user
an actionable way
to get rid of the notification.
So the top one is a
music playing app.
I think it's Google Music.
And you notice that while it's
playing, you can't dismiss it.
But the user can,
once they pause it,
then they can dismiss it.
So it's this nice pattern.
The user, they know why it's
stuck there-- oh yeah, OK.
And then the bottom
one is very explicit.
This is ConnectBot-- anybody?
That's a SSH client.
OK, it very explicitly says
the way you get rid of this
is to disconnect the session.
So you should do that
stuff, or get removed.
People will definitely
remove you if you annoy them.
So, delighting the user--
this is a tough chapter.
Because once you
get the pyramid,
it really depends on what
your app does, right?
How are you going to
make your users happy
is kind of like
what you're doing.
That's sort of your thing.
But I do have one specific thing
to say about this that I've
seen by talking to people.
A lot of people turn off
sound on their phone always.
That's one thing to do.
And they just live on vibrate.
Other people have sound on.
And for those people, a lot
of them really love sound.
And they will love
to change ringtones.
They love to have this
app be that sound,
and this app be that sound.
And that way they can know.
So when their phone makes noise,
they know if it's-- sometimes
they even know it's that person,
because there's a person who
uses that app, and
nobody else uses it.
So this is another
thing I actually
learned while I was
setting up the talk.
So back in our notification
settings-- remember,
we were here, so we can
get to your settings app.
It turns out that there's
this RingtonePreference.
Does anybody use this?
It goes all the way back to one.
So you would think-- so when you
look at the notification APIs,
it just says, give us a URI.
And you're like, where am I
going to get a URI for a song?
Well, it turns out
you get it from here.
So if you just drop
this little snippet
into your preferences
panel, you'll
get this nice little dialogue.
You don't have to
do anything else.
They get to pick.
You say, please give me
notification ringtones.
Those are the short ones.
So it'll pre-filter
everything for you.
They pick one.
When it's time to
make noise, you just
ask the preference
manager, hey, give me
that string I asked for.
And it comes out
as a string URI,
and you parse it, and
pass it, and done.
You don't even have
to know about songs.
You don't have to know
about MP3s or whatever.
Just that's it.
So this is surprising
to me that it
was so simple,
because it's something
that people love so much.
And often, you don't
see it in apps.
So if you want to delight
your users, in addition
to everything else
you're doing, this
is another thing you can add on.
So last thing I wanted to talk
about is this very tippy-top.
So I'm particularly
interested in people.
I think people are
particularly important to us.
And so in the system,
we built a way for you
to help connect people.
So one thing that
happens now, one thing
that's changed in
our society, is
that this device is the way that
people get in touch with me.
But it's also the
way that everybody
gets in touch with me.
That's the problem.
It's the way that games
get in touch with me.
It's the way that politicians
get in touch with me.
It's the way my mom
gets in touch with me.
And one of those I care about.
And it's my mom.
So I can't turn this phone off.
I cannot turn it off.
Like people say, oh, I'll
just turn my phone off,
and then I can sleep.
I can't do that.
I can't do that, because
what if my mom called me
in the middle of the night?
It would be important.
I would want to get that call.
So I can't turn it off.
I can't turn the volume off.
What do I do?
What I do is I go back
to do not disturb mode.
And I don't know if you saw it
last time, so this is my phone.
Every night from 10:00
to 7:00 in the morning,
I'm in priority-only mode.
And the way I have it
set up is you can--
I don't know if you noticed this
before, I didn't mention it--
but in some of these
categories, you
can actually select what kind
of people you want to hear from.
Anyone?
Do I want all calls, or I
only want calls from people
I know, or I only want calls
from people I have starred.
So stars are things that the
system has taught people to do.
Because that's
how you get people
into your quick-dial list.
So people usually
somehow figure that out.
They're like, how do I get
that in the quick-dial list?
And somebody teaches
them how to star.
So I use stars.
And what this allows us to do
is that now my phone will not
make noise unless it's
from somebody I care about.
So that means I have
the peace of mind
that I'm not going
to miss something,
but I also get interrupted
when it's important to me.
So my attention is
properly focused.
So you have to help us.
So there's three parties
involved in this grand scheme.
There is the user, the
person who knows which
people are important to them.
And they only know that.
There's you, the
app developers, who
know what this event is about.
And then there's us,
the system, which
knows what state the
user is in, like are we
in Do Not Disturb or not?
And so you need to help us by
giving us information again.
So you need to annotate
your notifications
with the appropriate metadata
that tells us about the people.
We tried to make this
as easy as possible.
So we gave you lots
of different ways.
We accepted many
different kinds of URIs.
So in the most simplest level,
if you use telephone numbers
as an identifier, which
people do, just give us that.
That's it.
So if the person
is important to me,
it is almost certainly the case
that their phone number ended
up in my contacts somehow.
You may not have put it
there, but somebody did.
Or maybe I did.
So if that's all you have, don't
ask for contacts permission.
Just give us that,
and we'll check it.
And it doesn't hurt to add it.
If that person's not in
contacts, it won't do anything.
It doesn't matter.
And then also the same thing--
if you have an email address,
you can do that.
So if you send us mail
to URI, we'll see that.
We'll say, oh, I
wonder if that email
address is one we know
about, and we'll look it up.
The last one is
more complicated.
So if you're already dealing
with the contacts database
for some reason, if
you're social app,
and you're doing contact
syncing or whatever,
you already have tons of code
for the contacts manager.
This is a highly
abbreviated sample,
because otherwise it
would be like five slides.
But the key bits
here are when you
go do a lookup on
a contact, you have
to ask for this thing
called a lookup key.
And that's something
you normally
wouldn't have pulled out.
And once you have it,
then you hand the ID
and the lookup key to
this static function
called getLookupUri, and
that builds a URI for you.
And then you hand us that.
And the reason you
want to do that
is because the
lookup URI is more
stable to certain kinds of
rearrangements of the contacts
database.
So things might be moving
around in the contacts database.
You want to make
sure that you give us
a URI that will
actually get back
to the right person
in a stable way.
So there's all those ways
to tell us about people.
OK, so just to recap, every
single time you write the code,
NotificationManager.notify,
I want you think,
is the user going to
be happy about this,
or am I going to annoy them?
And if I annoy them
too much, how long
is it be before they
ban or install me?
OK, that's like the first thing.
But then really, you've got
to be thinking about how,
when they installed
your app on their phone,
they're sort of inviting
you into their pocket.
You're sharing their life.
And you have to sort of
be respectful of that.
And you have to
think about, well,
how am I going to
fit into this story?
And you have to give
us the information
we need to help you do that.
Because there are things
that you can't do,
like the categories
and the people.
And then I want to
make sure that you're
empowering the user.
Like no, please
don't post, you'll
never guess what weird IM
your friend just sent you.
Don't do that.
Tell them the
information they need,
give them the actions they need.
And you'll build trust,
and you'll build happiness,
and then you'll
have happy users.
And that's what we all want.
And then on the delight and
the actualization level,
help us connect
with the user, help
them connect with
the sounds they want.
And that's it.
So the source code,
all the source samples
were pulled for this thing
called Notification Showcase,
which is the worst way
to get you sample code,
because it's part
of the framework.
It's like the thing that
we use to test things out.
I believe there is an
effort afoot to making
a real sample out of this.
I'll be helping next
week, probably, with that.
So this link, for now, you
can go look at the code,
and hopefully we'll
have something,
a better story at some
point in the near future.
So thank you.
[APPLAUSE]
And I talked super fast, so we
have some time for questions,
if you have questions.
I can't see, because
the lights are glare-y.
AUDIENCE: Hi, right here.
CHRIS WREN: Ah, there we go.
AUDIENCE: My question
has to do with what
happens when the user
turns off notifications
for an application.
CHRIS WREN: Yes, so if
they ban the notification,
they just don't get delivered.
Basically, the
notification manager
will drop them on the floor.
AUDIENCE: Right,
so does GCM still
deliver the notification to
the phone, and then the phone
not show it?
Or--
CHRIS WREN: Oh, yes, yes.
AUDIENCE: --can I get
to know at the GCM level
that my push was rejected?
CHRIS WREN: So if you're
using the GCM library
to post your notifications
for you, yeah,
they'll still get
dropped on the floor.
GCM won't know, either.
Because GCM is kind of
inside your package,
so it doesn't know
anything more than you do.
AUDIENCE: No, but if it's
sent from my server, will
my sever get some kind of--
CHRIS WREN: Right, so maybe
we should follow backwards.
But my understanding of it
is that the GCM thing is
a library within your package.
So that's actually doing the
posting of the notifications.
Like they don't get
posted by Play Services.
They get posted by you.
And so I think there's
no information there.
I don't think GCM
would be able to know.
AUDIENCE: I'm specifically
asking about notification
that my back end will send
to the device using GCM.
CHRIS WREN: Oh, I see.
So the user doesn't
know about those.
That's not a user feature.
So they wouldn't block those.
That's maybe a [INAUDIBLE]
the term notification.
So the message that comes
from GCM is a back-end thing.
The user has no sort of
visibility into that at all.
Really, notification blocking
is about the UI in the shade.
AUDIENCE: Thank you.
CHRIS WREN: There was
one back here, I think.
I could sort of see it.
AUDIENCE: Thank you.
Do you have any best practices
for the watch notification?
Does it work any
different, watch?
CHRIS WREN: Watch, oh yes.
Yes, I had some slides on that,
and I ended up taking them out
because I thought I was
going to be over time.
So there's a couple
things about that.
I think a lot of the
same principles apply.
If you're wearing
a watch, you know
that the vibration is
pretty-- you can't ignore it.
So it's an even more grabby sort
of way to interrupt someone.
So you should be
thinking extra hard
about whether you're
going to annoy them.
But you should be thinking
about that anyway,
because you get some devices
that are louder than others,
and you don't really know how
annoying it's going to be.
The one extra bit is that
there's this Set Local
Only flag on the builder
that if, for whatever reason,
you're generating notifications
kind of trapped in the device--
like it's about
the device, maybe,
and there's no reason
to send it to the watch,
like USB connected, for example.
That's a great one.
You plug it in, you don't want
to see that on your watch.
So you call Set Local
Only true, and then won't
get bridged to the watch.
That's your way to sort of keep
it from getting to the watch.
AUDIENCE: Thank you.
CHRIS WREN: This
one in the middle.
AUDIENCE: So I saw [INAUDIBLE]
set the priority to minimum--
CHRIS WREN: I can hear you,
but the livestream won't.
Put it there.
AUDIENCE: So I
noticed you mentioned
trying to take
advantage of setting
the priority to something
like minimum or low,
which wouldn't
necessarily annoy users.
Would that end up leading to
lower click-through rates?
But on the other side, then you
would get your app uninstalled.
Is that sort of the trade-off?
CHRIS WREN: OK, so
I don't think so.
Because, well, like
I mentioned, there
was some academic
research-- and I'm blanking.
There was a paper by
[? Norea Oliver ?] out
of the Spanish
telecom company that
was recently at a
conference about this exact.
And I think that's the
trade off you're assuming
is that I'll lower my
click-through rates
versus annoyance.
But those things aren't linked.
It turns out that if you
present the notifications
at the right time, you
actually get a higher
click-through rate.
And this makes sense.
Do this sort of model
mental experiment.
If I'm driving down
the road, and my phone
tries to tell me to read an
article, not going to do it.
But if I'm sitting the
doctor's office waiting,
and I'm bored, oh, an article,
yeah, I'll totally read that.
So you can totally
imagine how that
would play out in real life.
They're not on a seesaw,
they're unrelated.
So I think it really depends
on what kind of content
you're posting, and exactly what
the interaction's going to be.
And you really need
to you think about it.
But it might be the case that
if you stick it in the shade
without drawing attention
to it, that they'll just
find it at the right time, the
time that's right for them.
When they pull down the
shade and they're just
sort of triaging, that
might be your golden moment.
OK I think we're-- oh,
we've got one more.
One more-- last one.
AUDIENCE: OK, yeah,
hopefully this will be quick.
Basically I'm wondering
why not tell developers
that their notifications
are being blocked by users?
So basically like user
turns off my notifications,
I might want to know, because
maybe I need that feedback
that I'm actually--
CHRIS WREN: Right, right, right.
Yeah, OK, so that's
a good question.
So how do you know if you're
annoying users before you get
blocked?
I think the reason
we don't close
that loop is we're worried
about sort of retribution,
where we don't want to--
obviously you're having
a bad time, you and the user.
We don't want to get
in the middle of that.
But I think there's signals you
can get before that happened.
You can post, delete intents.
You can post-- you
know, of course,
when they launch
your other intents.
And I think if you are clever
about watching how soon they
react to your notifications
and things like that,
you can get some soft
engagement numbers
before the bad stuff happens.
[CHUCKLES] All right,
thank you very much.
I'll be around for office hours.
[APPLAUSE]
[MUSIC PLAYING]
