Thank you. Good afternoon. And welcome. My name is Michele. 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.