通知をグループ化する

(音楽)

(拍手) こんにちは　ようこそ iOS User Notificationsチームの ミケーレです

先ほど同僚が グループ通知をご紹介しました このセッションでは 少し詳しく この機能について説明します 内容は 基本的な使い方や 通知の効率性を高める方法 整理方法などです

まずはこの機能の概要や インターフェイスについて お話しします そして Appグループ化 さらにカスタムグループ化 Appのコンテンツに 適用するためのグループです

最後に カスタムサマリを ご紹介します

まずは概要をご説明します

通知グループとは 様々な通知が１つに まとめられたグループです これによりNotification Centerが 整理され ユーザ側の効率性が 高まります 特定のアプリケーションからの 通知が 画面を占領することも なくなります

最新の通知は通知グループの 一番上に表示されます これをトップ通知と呼びます

その下には サマリが表示され グループに含まれる通知の 内容を示します ここにはグループに含まれる 通知の件数が表示され 通知内容の詳細が 表示されることもあります

通知グループは 情報選別にも役立ちます 例えば グループ内のすべての通知を ワンスライドで消去できます

グループを展開し すべての通知を見るのも簡単です １つずつ読んで １つずつ消去できます 読み終えたら トップのボタンで 一括で消去することも できます

インターフェイスや専門用語に 慣れていただくために 概要をごく簡単に ご説明しました では グループの仕組みを 見ていきましょう

デフォルトの Appグループ化では アプリケーションごとに グループが作られます すべての通知がそこに入ります 初期設定のままで 新しいAPIを使わなければ 通知はそこに送られ続けます

多くの場合 このグループ化機能で十分です 例えば Podcast Appの通知は すべて同じグループに入ります Podcastの通知は どれも似ており エピソードの到着を 知らせるものです 興味深さや重要度は どれも同程度なので 区別して 表示されていないのです

グループをタップすると 展開して詳細を確認できます

Appグルーピングによって 通知を整理でき Notification Centerを 見やすくできます しかし アプリケーションの 内容によっては より効率的な通知の方法が 必要でしょう そこでカスタムグループを 使います このセッションではまず カスタムグループを作るための APIを見ます そして iOS 12での例を いくつか紹介します

その中で実際のパターンや どのように情報量を調整したか 詳しく見ていきます さらに どのように 整理されたかも見ましょう

グループの作成方法を ご説明します 通知コンテンツ内に スレッド識別子を設定するだけです

この設定をすると 同じスレッド識別子で送った通知は Notification Centerで グループ化されます

スレッド識別子は 何でも大丈夫です ですが すべての通知が グループ化されるので グループを特定する 一意の文字列が必要です これでグループが 作成されます しかし作成自体は簡単ですが どのように作るか 注意が必要です

このAPIは 新しいものではありません 以前のiOSで導入したもので 現在のiOSにも存在します 導入したのはリッチ通知と プライベート通知のためです ですので この機能を使うために APIを使用していたなら iOS 12で 通知は グループ化されます

ですが文脈が異なるので グループがどのように作られるか 見てみましょう

スレッドの作成方法の例を スライドでご覧ください もちろんプッシュ型に 設定できます

では iOS 12の例を 少し見てみましょう

ここで 最も重要なのは 通知のグループ化の目的です グループ化の目的は 通知の効率性を 高めることです そしてNotification Centerを 整理することです 誰かから大量のメッセージが 送られた場合などに アプリケーションから 大量の通知を受けることがあります これを解決するために 通知を少し整理して 効率性を高めたいわけです

最初の例はカレンダーです

ライフスタイルや 勤務先によっては カレンダーから多くの通知が 送られてくるでしょう しかし 重要度はまちまちです 一部の通知は 他の通知よりも重要でしょう 例えばイベント作成時に 設定したアラートや 出発時刻を知らせる 通知などです すぐ行動する必要があるので これらの通知は重要です “15分後に会議”と 言われたら 歩き出さないといけません しかし多くの通知は すぐに対応する必要が ないものです 共有カレンダーの更新や 後日のイベントの 時間変更かもしれないからです これらを区別できれば 便利です デフォルトでは カレンダーからの通知はすべて １つのグループに まとめられます スレッド識別子を設定しなければ そうなるのです デフォルト値はnilで デフォルトグループに入ります

そこで カレンダーは 重要度が高い通知には 特定のスレッド識別子を設定します

結果はこうなります

カレンダーからの 通知の大半は すぐに対応する必要のない 更新情報です 後で参照する必要も ありません このような通知が グループ化されます 一方 重要度や緊急度が 高い通知や 後で参照したい通知も あるでしょう これらは区別されます

このグループを展開すると 他の通知も確認できます

カレンダーで学んだことは 次のとおりです “対応を要する重要な通知を 更新情報と区別する”

次の例はメッセージです

メッセージは 最も分かりやすい例かもしれません メッセージでは会話ごとに １つの通知グループが作られます

単純に見えますが ここに大事な要素があります メッセージはなぜ 会話ごとにグループを 作るのでしょうか？ メッセージからの通知は 通常 友人や家族から 送られるものです 関心が高く 重要度も高いと言えます また これらの通知は 大抵短命です 通常 すぐに返信するため Notification Centerから すぐに消えます

つまりメッセージは １対１の会話に対し １つのスレッドを作成し グループ会話には 別の通知グループを作成します スレッドに対して グループIDが生成され グループ化されます

展開すると すべてを閲覧できます

メッセージから学んだことは 何でしょうか？ “意義ある連絡の グループを作る” メッセージからの通知は 大抵重要で Notification Centerに とどまるのは短時間です だから多くのグループを 作るのが適しています

最後の例はメールです

メールとメッセージには いくつか共通点があります 直接的なコミュニケーションに 使用され― スレッドのコンセプトにも似た 会話を有します

しかしメールとメッセージには 違いもあります メールの方が 通知の数がずっと多く 通知が保持される時間も 長くなりがちです

通常 Eメールは ゆっくり やりとりされ すぐに返信されるとは 限りません そのため 通知を スレッドごとにまとめるのは 理想的ではありません Notification Centerが スレッドだらけになり とても非効率的です そこでメールには 特別な インターフェイスを使用します 具体的な整理方法を 紹介します

メールにはすでに 受信メールに優先順位を つける機能が備わっています

そして 複数の メールアカウントを設定できます 重要な連絡先を追加する VIPの機能もあります お気に入りフォルダの作成や 特定のスレッドに対して 通知をオンにすることもできます

ユーザにとって どの通知が 重要なのかは明らかです 重要度によって区別するのが メールの仕組みです メールはまず― アカウントごとに 通知をまとめます アカウントごとに １つのグループを作成します 複数のアカウントがあれば それぞれ作成されます

ですが VIPに登録されている 連絡先からのEメールは 別のグループに分類されます なぜならVIPからの Eメールは すぐに知りたい 情報だからです

特定のスレッドに対し スレッドの通知をオンにすると 通知は別のグループに 分類されます

メールとメッセージには 共通点もありますが グループ通知の方法は 少し異なっています アプリケーションの使い方や 中身が違うからです

メールで学んだことは 何でしょうか？ “ユーザの優先順位を 尊重する” メールには 優先順位を つける機能があります それを利用して 通知を整理するのです

ここまで 通知グループの 作成方法を見てきました

次は グループの概要を 表示することで 中身を分かりやすくする方法を ご紹介します グループの内容の説明です

私の先週の Notification Centerを見ると それぞれのグループの下に サマリがついています メールは 仕事用アカウントへの 着信を知らせています Podcast Appは エピソードの到着を 知らせています

Newsには ナショナル ジオグラフィックから ９件通知が来ています

詳しく見てみましょう サマリを カスタマイズしない場合 デフォルトメッセージが 送られます しかし もっとうまく 中身を説明できます 例えば Appに メッセージを送信させる場合 ９件のメッセージを送ると 通知させたいはずです その方法は？

まず サマリの フォーマットを選びます コンテンツの件数を示す 数字のプレースホルダがあり “％u more messages”と なっています

次にこのフォーマット文字列を 通知を送るための 通知カテゴリに設定します

お気付きかもしれませんが サマリのフォーマットは カテゴリに設定されます なぜなら カテゴリの用途は 通知のタイプやグループに 似ているからです 例えばメッセージでは “１対１”や“グループ”に対して カテゴリが設定されます だから異なるサマリを 設定できるのです ここでも カテゴリに設定します

ここで通知グループの 通知カテゴリを設定しますが 隠しプレビューの プレースホルダも設定できます これはサマリの設定と 似ています 大きな違いは 使われるコンテキストです 隠しプレビューは 昨年iOS 11で導入された機能です 通知を非表示にした際に 代わりに表示されるテキストを カスタマイズできる機能です 通知を非表示にすると “９件の メッセージ”と表示されます そしてロック解除すると 展開された通知と“８通”という サマリを確認できます サマリフォーマットは 多くのメッセージを表示し プレビュープレースホルダは 数のみを表示します

サマリの基本の設定を ご説明しましたが グループ会話の場合は 少し特殊です メッセージの 件数だけではなく スレッド内の差出人を 表示させることができるのです

しかし先ほどの方法には 数字のプレースホルダしか ありません そこで異なる サマリフォーマットを作成します 数字のプレースホルダと― 文字列のプレースホルダを 含むフォーマットです “%u more messages from %@”のように表示されます そして ２番目のプレースホルダを 名前のリストに置き換えます

カテゴリで サマリフォーマットを設定し リストの名前を取得します

名前を送るには 再度名前を設定します 送信者の名前は 様々だからです

すべての名前を取得し 文字列として構築し サマリ内で置き換えます これはプッシュされた情報で サマリの引数をサポートします

名前を引数に入力すると サマリはこのようになります

名前は一意でなくてもよく 同じ名前で多くの通知を送れます そして 例えば メールの場合は― すべての通知が 同じ名前になります 重複が排除され 名前ごとに １つのインスタンスが表示されます

次はPodcastの例です Podcastの通知には 特別な機能があります

何が特別なのでしょうか？ この例でPodcastは ２話の新着エピソードがあると トップ通知で言っています

そして サマリによると ７話のエピソードがあります 展開してみましょう

グループには ３つの通知しかありません ７ではありません 前例では サマリで表示される数が グループ内の通知の数と 一致していました

なぜでしょう？

Podcastは 複数の通知をまとめて 通知の数を制限しているのです 複数エピソードが 同時にリリースされる場合 “３つの新着エピソードが あります”などと通知されます

他の３つの通知にある エピソード数を足すと サマリのとおり ７になります

ではAPIを見てみましょう

これはsummayArgumentCountという プロパティです 数字が意味するのは サマリに追加される アイテムの数です

先ほどと同様に すべての名前を取得し すべての数を合計し サマリを作成するのです ご覧のとおり― 通知の数は３ １ ３なので 合計は７になります これがそのサマリです

他と同様 プッシュ型の 情報の中に設定できます

この設定は任意です 通知をまとめたい場合以外は 必ずしも設定する必要は ありません

次は 言葉を組み合わせて 文章にまとめてみましょう 文章にまとめる際は 言語の違いを 把握する必要があります 数字を扱うので 複数形に注意が必要です

再びPodcastです 例えば “4 more episodes”とあります エピソードが１つの場合 単数形の文字列が必要ですが APIでは１つしか 設定できません

しかし英語では 文字列が２つ必要です アプリケーションを ローカライズする場合や 使用言語が英語以外の場合 異なる言語を使うでしょう 複数形規則は 言語によって異なり 形が３つある場合もあります 規則が異なることもあります iOSのFoundation フレームワークは 文字列のローカライズに 有効です すべての言語や規則を 把握する必要はありません とても簡単に それぞれの 言語の文字列を複数形に 翻訳できます

まず始めにすることは― サマリフォーマットに使う リテラル文字列を ローカライズされた文字列に 置き換えます

その際 特別な通知APIが 必要になるのでご注意ください 他言語の文字列を 分けて格納するためです 後で システム言語が 変更されると ローカライズされた文字列で 通知が送られます

ここで設定したら 文字列をローカライズします それには .stringsdictファイルを使います .stringsdictファイルは プロパティリストで― フォーマット文字列や 辞書を定義します ご覧のスライドの下の方に 英語の単数形と複数形 ２つの文字列があります しかし言語を変更するために 必要なのは .stringsdictファイルの 変更だけです ご覧のヘブライ語では 複数形に関して ３つの形があります ロシア語にも ３つの形がありますが Foundation APIを使えば 詳しく知る必要はありません

これは 簡単な サマリフォーマットです 引数を使えば サマリを 設定することも可能です トップにフォーマット文字列を 定義しています キーごとに構成辞書を マッチさせる必要があります 下では ２つの形に対して 文字列を設定しています 数字のプレースホルダと 名前リストの プレースホルダです

アプリケーションと システムの間で フォーマット文字列を 交換しています 事実上APIの一部で 扱えるフォーマットの数は 限られています

例の中で紹介した フォーマットがそうです １つ目のフォーマットは 数字のプレースホルダを使います これには引数が不要で 割り当てられた数字が必要です

２つ目のフォーマットは ２つのプレースホルダを 使います どの文字列を使うか検出し 正しいフォーマットにします

通知のグループ化については 以上ですが 通知のグループ化とAPIについて あと何点か ご紹介します アプリケーションを 洗練させるコツです

１つ目のコツは 異なるサマリの組み合わせです

異なるサマリは 別々のカテゴリ内に設定でき スレッドグループは 通知コンテンツ内に定義できます つまり 同じグループ通知に 異なるサマリを設定できるのです 何が起こるでしょうか？ ２つのケースがあります グループ内のどのサマリにも 引数がない場合 すべてのサマリは このように表示されます しかし 通知のサマリに 引数が設定されている場合 デフォルトメッセージに フォールバックします

２つ目のコツは リッチ通知と グループについてです 少し前にiOSに導入された リッチ通知は グループ通知でも 引き続き使えます コンテンツExtensionを持つ リッチ通知を見るには ユーザはグループを タップします すると通知が トップ通知と ともに読み込まれ トップ通知は didReceive通知APIによって 受信されます

読み込まれたら 他の通知を 読み込むことができます グループ内の通知や 他のコンテンツも 読み込めます

Extensionの起動中に 追加の通知が届き 同じスレッド識別子だとします その場合 最初に 使用されたメソッドで コンテンツExtensionに 届けられます

最後です APIなどから 通知を読み込むことで すでに表示した追加の通知が 届くことがあります その場合は通知を取り除き Notification Centerを 整理してください

内容を おさらいしましょう たくさんお話ししましたが 覚えておいてほしいのは ２つだけです １つ目は 通知のグループ化の目的です 目的は Notification Centerを整理し より効率的に 通知を 使えるようにすることです 情報を選別すれば 重要な情報を早く受け取り 対応することができます

２つ目に 覚えておいてほしいことは カスタムサマリの追加です Podcastなどの例を 思い出してください 通知グループの下の サマリを見れば 何が新しい情報か分かります 通知グループを展開して すべて見る必要はありません サマリで確認できるのです

このセッションの後 すぐにラボを開きます 明朝もラボがありますので ぜひお越しください 金曜の通知についての セッションでは デザイン面からお話しします あらゆるデバイスや システムで 通知をどう使うか考えます

ご清聴 ありがとうございました (拍手)