Related Videos

WWDC 2018

And I work in the iOS User
Notifications team.
Just a few minutes ago, my
coworkers Kritarth and Teja
[phonetic names] introduced you
to group notifications.

And in this session, we're going
to explore a little bit more
detail in-- this feature in a
little bit more detail.
And we'll learn how to use it
and how to improve the
efficiency of your notification
and how to make them better
organized.

We will start by a brief
overview of how the feature
works and how the different
parts of the UI work.
Then we'll look at the default
grouping, app grouping.

We will see how to create custom
groups for your notifications so
that you can adapt the groups to
the content of your apps.
And finally, we will learn how
to create custom summaries for
your new notification groups.
Let's start with a brief
overview of the UI of the
feature.
Notification groups collect sets
of different notifications
together and in a group, and
group them in a small stack.
This helps making Notification
Center better organized and more
efficient for the user so that
he can see more notifications at
the same time.
Without any app taking over the
entire screen and preventing
them from seeing some of the
content.
Each notification group shows
the most recent notification
that was delivered to that group
at the top.

And we call these the leading
notification.
Right underneath each group
shows a brief summary that gives
a little bit more details about
what are the notifications
included in the group.
Gives you a number for, so you
have a measure of how many
notifications are inside.
And in some cases, also some
details about the content of
those notifications.
Notification groups also help in
triaging notification.

Because for example you can
clear them, all the notification
in that group with just one
slide.
And clear them all.
But it's just as easy to expand
the group and see all the
notifications that are inside.
And read one of them at a time
and maybe clear one.
And then when you're done, you
can clear all of them, all of
the group using the group
buttons at the top.
This was a very brief overview
of the feature just to get more
accustomed to the different
parts of the UI and the
terminology.
So now allow, now let's see how
the groups work and how they are
created.
The default behavior is app
grouping.

Each app gets its own group.
And all the notifications from
that app go to that group.

This is the behavior that you
get if you don't do anything.
And you just keep sending
notifications without adopting
any new APIs.
In many situations, app groups
are sufficient, and they work
very well.
For example, as you see here in
the Podcasts app, all the
notifications are in the same
group because Podcasts sends
notifications that are very
similar.
They're notifications for new
episodes of [inaudible] the
shows.
So there's no specific
notification that is more
interesting or something that is
more important to show
differently.
As I said, as we said, it's very
easy to tap on the group, expand
it, and see the details inside
the group.
So app grouping is good.

It keeps notifications more
organized and Notification
Center more compact and easier
to use.
But many apps have more specific
content.

They may need different
organization to make
notifications more efficient.

And so we can create custom
grouping.
So in this session we will see
first the API to create custom
groups for your notifications.
And then we'll look at a few
examples of apps in iOS 12 to
explore some of the patterns
that they applied, and how they
tried to balance the amount of
content that was visible to the
user.

And the amount of content that
was grouped together to help
with the organization of
Notification Center.
So this is how you create a
group for your app.

You just set a custom thread
identifier in the notification
content.

After you've done this, all the
notifications that you send with
the same thread identifier will
be grouped together in
Notification Center.
The thread identifier can be any
string.
Doesn't matter what you said
there.

But all of the notification will
be grouped together.
You just need to be unique.

You just need a unique string
that is identifier's group.
And that is it.

You created a groups for your
notifications.
But given that it is so simple,
we need to pay attention at how
we create these groups.
And also, if you're familiar
with notifications API, you
notice that this is not a new
API.

This is an API that we
introduced in previous iOS
releases.

So it's a really existing and
current iOS.
We introduced it to, for
[inaudible] notifications and
for private notifications.
So if you already adopted this
API to support these two other
features in previous iOS
releases.

Your notifications are already
grouping today in iOS 12.
You may want to review how the
groups are created since now the
context is a little bit
different.

So it may be useful to adjust
them a little bit.
So in this example, you see how
to create a thread, set a thread
identifier on a local
notification.

And of course you can set it on
a push payload for push
notifications.

Okay. No, now let's go over a
few examples from iOS 12.
The most important thing to keep
in mind as we go through these
examples is the goal on
notification grouping.

When grouping-- by grouping
notifications we want to make
notifications more efficient for
the user.
And improve the organization in
Notification Center.

I'm sure you're familiar with
the situation where one app has
sent many notifications.

Maybe you're in a chatty,
messages conversations and
someone is sending a lot of
messages.
We want to improve that
situation by organizing
notifications a little bit
better so that the user can use
them more effectively.

Our first example is Calendar.
Depending on how you organize
your life or where you work,
Calendar may send you a lot of
notifications for event changes,
event invites.

But not all of them have the
same importance.
There are some notifications
that are sent by Calendar that
are more important than others.
And they are event alerts that
you set up when you create an
event.
Or time to leave notifications.

These are more important because
are notifications that I need to
act on right now.

If I receive a notification that
I have a meeting in 15 minutes,
I need to start walking, because
I have to go to the meeting.
But many of the other
notifications are not something
that need to be responded to
immediately.
There may be updates to share
Calendars.
There may be time changes in
other events that are later in
the day or some other day.
And so it's useful to separate
them.

So what Calendar is doing is
using the default group, the app
group, for the bulk of the
notification that it sends.
And it does that by not setting
any thread identifier on a
majority of its notifications.
Mail is a default value.
So if you don't set it, that's a
default group.
And then Calendar sets a
specific thread identifier just
for these notifications that are
more important and that it wants
to call out.

So the result is that most of
the notifications from Calendar
that are information updates
that are not something that I
need to react to immediately.
Or that I don't need to have in
reference later.
For example, to know where the
event is.

They're grouped together in one
group.
And the other notifications that
are the more important ones,
more urgent or the ones that I
need to reference maybe later to
find the meeting room, they're
separate than this other one.
So this is-- just expand and I
see what else is in my group.
And this is the pattern that we
learned from Calendar.

Separate important actional
notification from informative
updates.

Our next example is Messages.
Messages is maybe the most
straightforward notification
group's implementation.
It's pretty obvious.
Messages has conversations.

And each conversation has its
own group.
But we still, we can still learn
something important.
We can still learn a good lesson
from Messages.

Why is it that Messages separate
all these groups in different
conv-- different conversation in
different groups?
Well notifications that Messages
sends are generally from people.

From your friends, from your
family.
They're notifications that we
care about, that are important.
And second they're notifications
that usually are short-lived.

Because usually you respond
pretty quickly at a Message.
And it will go away from
Notifications Center.
So what Messages does is it
creates a thread for these
one-to-one conversation.
And it creates a separate
notification group for these
group conversation.
Just generates any group
identifier for that thread and
they get grouped together.
It can expand and see, still see
all my messages.

So what does-- what is the
lesson that we learned from
Messages?
Create groups for meaningful,
personal communications.
These notifications from
Messages are usually important.
And they live very shortly in
Notification Center.

So we can create many separate
groups for all of them.
Our final example is Mail.

And Mail shares some of the same
characteristics that Messages
has.

So they're often direct
communications with people.
They have a same, a similar
concept of threads.
Conversations.
But there is some major
differences between Mail and
Messages.
Mail can have an even higher
volume of notifications than
messages.
And on the other hand, they can
also be more long-lived.
Mail, email is usually used for
slower communications.

Something that I don't expect to
respond to immediately.
And so organizing Mail threads,
organizing Mail notifications by
thread will not be ideal.
It will create a lot of threads
in Notification Center.
And the UI to see in those
thread is not very efficient.

Mail provides a specific
dedicated UI to displaying mail
threads.

So how is Mail organizing its
notifications?
Well, first of all, Mail
provides some features to
already organize and prioritize
the emails that arrive in your
inbox.
Mail provides separate accounts.
You can have many different
accounts set up in your device.
Provides VIP.
You can set any contact as VIP.

You can create-- you can have
favorite folders.
And you can turn on
notifications for specific
threads inside your mail client.
And so it seems like the user is
already telling us which
notifications are more
important.

Which email messages are more
important and which are less
important.

And that is what Mail does.
Mail organizes notifications
first by starting with the
account group.
It creates one big account for
all the emails that arrive in a
specific account.
If I had multiple accounts, each
one would get its own group.

But then if a contact that is in
my VIP contact sends an email to
that account.

That email is separated out to a
different group because I said
that's a VIP person.

That's a contract that I want to
be informed about immediately
when it sends an email.

And if I turn on thread
notifications for some specific
threads inside of Mail, also,
those also get separated out in
their own group.
So you see that while Mail
shares some of the same
characteristics as Messages, the
approach of grouping
notification is a little
different.
Because the use of the
notification and of the app and
the content is different.
So what is Mail telling us here?
Respect the user's priorities
and organization.
Mail provides feature to
organize email and to prioritize
the content.
So we can use that to organize
notifications that Mail sends.
So now that we've seen how to
create as many groups as we
want, we'll see how to make
these groups a little bit more
clear.

By providing some bits of
information in the group.
That describes the content that
they contain.
As we see in these example of my
Notification Center from last
week.
Each group has a little short
summary at the bottom.

And it explains a little bit of
what that group is about.
For example, you see Mail says
that I have a few emails from in
my work account.
Podcasts is telling me that I
have a bunch of new episodes
that were delivered to my
Podcasts app to listen.

And News tells me I have nine
more notifications from National
Geographic.

Let's explore this one a little
bit.
If your nine notifications said
default message that we set in
groups if you don't customize
your summary.

But you can better describe your
content.
For example, if you have an app
that sends messages.
You may want to see, you may
want to say there that you're
sending nine more messages.
So how you do that?
The first thing you have to do
is to pick a summary format.
And this is a format string that
just describes your content with
a numerical placeholder.
As we see here, number, more
messages.

And then you set this format
string in the notification
category that you're going to
use to send a notification.
If you notice, the summary
format is set on the category.

Whereas the thread was set on
the notification content.
This is because categories as
you know are types, groups, of
notifications that you send that
are similar.

For example, messages has
different categories for
one-to-one conversations.

And group conversations.
And this means that they can set
different summaries for those
two categories.
That is why the summary format
is set in the category here.

And while you're here updating
your notification category for
notification groups, you can
also set this hidden previous
placeholder property which is
very similar to the summary that
we used for notification groups.
The major difference between
these two is the context in
which they're used.
The hidden previous placeholder
is not a new feature.

It's a feature that we
introduced last year in iOS 11.
And this customizes the text
that is displayed instead of the
notification when the user sets
the notification to be private.

If I set a notification to be
private, I say nine more
messages.

But then when I authenticate and
I unlock my device, I can see
the expanding notification and
the summary underneath that says
eight more messages.
And that is why the summary
format has more messages.
And the preview placeholder has
only the number of messages.

So that was the setup for a
basic summary.
But Messages for group
conversation has a more
interesting summary, where it
says the number of messages.

But also the people that sent
those messages in that thread in
that conversation.

And we cannot do that with the
formula that we just specified
because it only has a numerical
placeholder.
So what we do is we create a
different summary format that
contains a numerical string-- a
numerical placeholder and a
string placeholder.

As you see here, number, more
messages from a string.
And we will replace the second
placeholder with a list of names
that are in the notifications.
Still set the summary format in
the category.
And then we have to collect
these names.

To send these names, you set
them in the notification content
again.

Because each notification can be
sent by a different person.
And they can be different names.

So we will collect all of those
names, build them up in a string
and replace them in the summary.

Oh, this is the push payload of
course also supports summary
arguments.

And this is how the summary
looks after we collected all the
names and formatted them in the
summary argument.
The names don't need to be
unique.

You can send many notifications
with the same name.
And in this, in the Mail case,
for example, all the
notifications have the same name
because they're all in the same
account.
We will handle de-duplicating
them and will display only one
instance for each single name
that is visible.
Next example is Podcasts.

Podcasts shows us another small
detail about this API.
What is special about this
notification?
In this notification, Podcasts
is saying that there are two new
episodes available in my leading
notification Podcasts.
And the summary says that there
are seven more episodes from a
number of shows.
And what happens when I expand
this group?
What happens is that there are
only three external
notifications in the group.
Not seven like the summary said.
And in previous examples, the
number in the summary matched
the number of notifications that
were contained in the group.

So what is happening here?
Well, since Podcasts does these
bundling on notification and
they try to limit the number of
notifications they send.
When a show releases multiple
episodes at the same time.
They have these notifications
that say, "Two new episodes are
available, three new episodes
are available."
And if you sum the number, the
number of episodes in the bottom
three notifications, there were
the ones that accounted for the
summary, you can see that the
total is seven.
So let's see how the API for
this works.
It's just another property on
the notification content and
it's called summary argument
count.
And this count expresses the
number of items that summary
argument account, accounts for.
In the summary.

We will collect again as before
all the names.
We will sum up all the counts.

And we will create the summary.
And again as we can see, these
notification would have summary
argument count three, one,
three, total is seven.
And that's the summary that we
displayed.
And as everything else, of
course you can also set it in
the push payload.
The summary argument count is
optional.

Defaults to one so you can only
need to set it if you're doing
this type of bundling on
notifications.
You don't need to set it always.
Now, we are playing with words
and we are building sentences.
And when you do that, you always
need to account for different
languages and you need to
account for plurals in this
case.

Because we have numbers.
Again, another Podcast
notification.

For example, in this case.
It says, "Four more episodes."
But if I only had one more
episode, that string would need
to be different.
But the API only allows us to
set one string.
And now we need two.
You need two in English.

But if you want to start to
localize your app or if your
main language is not English,
you're writing up for a
different language.
Some languages have different
rules for plurals.
They may not have two cases.
They may have three.

And they may have cases that
apply with different rules.
So iOS in the foundation
frameworks provides support for
localizing these kind of
strings.

So you don't need to learn all
the rules.
And you don't need to know all
the languages that you're going
to translate your app to.
And it's very simple to adopt
and translate each string to
have the correct plural form.
The first thing that we need to
do to adopt this 'fix our
problem with plurals' is to
replace the literal string that
we use for the summary format,
with a localized string.
And remember here that you need
to use our special notification
API for localized strings,
because we need to store these
localized string and set it
aside.
Because in the case that the
language of the system changes
later.
If you send notifications, we
send them with the correct
localization after the system
localization change.

So after you set a localized
string here, you need to
localize the string.

And you localize the string in a
strings dict file.
A strings dict file is a
property list file that
describes a performance string
and a configuration dictionary.

In the configuration dictionary
here at the bottom, you see the
two versions of the string for
singular and plural in English.
But as I said, all you need to
do to support other languages
and different pluralization
rules is change this stings dict
file.

You create a new one.
And you see here Hebrew has
three different cases for
plurals.
And Russian has three different
ones and they're different from
Hebrew.
And you don't need to know which
one to use when.

If you use the foundation API
that we provide.
This is for the simple summary
format that we just saw.
But of course we can also format
summaries with arguments.

You see we define the format
string at the top.
We need to match the
configuration dictionary by key.
And underneath we specify the
two strings for the two
different versions.
With the numerical placeholder
and the placeholder for the list
that we're going to provide with
names.
So since we're exchanging these
format strings between apps and
the system.
These are effectively part of
the API.
So there's only a limited number
of formats that we can support.

And we need to agree on those.
And they are the ones that I
just showed you in these
examples.
The first format that you can
use is the one with one
numerical placeholder.
When you don't need the
arguments and you need to
specify an unsigned number.
And the second format that you
need, you can use is the one
with the numerical placeholder
and the string placeholder.
We will automatically detect
which string you are using and
format them correctly.
Now we're all done with the
features of notification
grouping.
But before you leave, I want to
give you a couple more tips
about notification grouping and
these API that will help you
finish the last bit of polish in
your app.
The first step is about
combining different summaries.
Since we saw that you can set
different summaries in different
categories.
And the thread group are defined
in the notification content.

That means that you can mix in
the same group notifications
that have different summaries.

And what happens when you do
that?
So there's two main cases.

If none of the summaries in that
group have any arguments, we'll
try to combine all the summaries
in the list and display them
like this.
But if any of the notification
summaries in that group have any
arguments, we're going to have
to fall back to the default
message.
The second tip is about enriched
notifications and groups.

So we introduced enriched
notifications a while ago in
iOS.

And they continued working in
with group notifications.
And when the user presses on a
group to see the enriched
notification that loads your
content extension for that
group, what happens is that your
notification will be loaded with
the leading notification.

The one that is displayed at the
top, and you receive it in
notification using the usual
[inaudible] notification API.
Once the extension is loaded,
you can load additional
notifications.
For example, the same ones that
are in the group or if you want
to display different content,
you can also load it with your
own API.

Then while your extension is
open and is running, if
additional notifications are
delivered to the same group, so
they have the same thread
identifier, they will be
delivered to your content
extension using the same did
received notification method
that you receive at the
beginning.
And lastly, if you display, if
you already displayed additional
notifications to the user by
loading them from the delivery
notifications.
Or by loading them from your own
API, you should remove them from
Notification Center.
To continue keeping Notification
Center organized and more
efficient.
I want to recap a little what we
talked about.

It was a long presentation, and
there were a lot of details.
But I only have two very
important things that I want you
to remember here.
The first one is the goal of
notification grouping.
The goal of notification
grouping is to better organize
Notification Center and help
your users be more efficient in
when they're using your
notifications.
This will help them triage them,
and will have them receiving
important information more
quickly and react better.
And the second thing I want you
to remember is to add custom
summaries to improve clarity.
As you see in my examples, for
example in podcasts or in Mail,
just that little bit of text
underneath the notification
group will help to see what else
is new in that group.
And I don't need to open the
notification group just to see
everything about the content.
The summary already gives some
information.
We will have a lab shortly right
after this session, downstairs.

We will have another lab
tomorrow morning, and we look
forward to talking to you.

And on Friday, there is another
session about notifications that
talks a little bit more about
the design aspects.
About how to think about your
notifications globally across
all the user devices and across
different systems.
Thank you very much, and I'll
see you later.

Looking for something specific? Enter a topic above and jump straight to the good stuff.