現(xiàn)如今消息通知也是一樁麻煩事，這篇文章旨在介紹幾種通知模型，幫助你的APP挑選到合適的通知模型。

通知是指源自于APP以用戶為目標(biāo)的信息片段，以下是通知的幾個重要組成部分：

來源(Source)：這是APP中生成通知的源頭。每個APP根據(jù)自己不同的內(nèi)容體系可以有多個內(nèi)容池，信息在內(nèi)容池中進行歸類，這些內(nèi)容池將會變成通知的來源。

信息(Information)：以通知為載體傳達給用戶的消息。比如說“Jesse申請成為你的好友”或者“James贊了你的推文”。

類型(Type)：通知主要分為兩類——信息類和操作類。如果你APP需要的話，這兩種都可以繼續(xù)區(qū)分子類別。

徽章(Badge)：引導(dǎo)用戶查看通知的視覺元素 ?；照吕锏闹甘究梢允且粋€簡單的點，也可以展示未讀消息的計數(shù)。

錨點(Anchor)：指的是界面中用來引導(dǎo)用戶進入通知的提示位置。簡單來說，錨點就是用戶看到通知指引或徽章的地方。錨點并不一定只能打在通知的來源，也可以打在你希望體現(xiàn)有通知的地方。錨點可以用來展示多種來源的通知，當(dāng)然也可以只展示一類。你可以這樣想，來源是信息架構(gòu)層面的概念，而錨點不過是你可以看到徽章的視覺元素。

通知是一種媒介，APP使用它與用戶溝通，讓用戶有再次打開APP的可能性。因此通知是APP中十分重要的部分。讓我來介紹幾種常見的通知模型，并說明為什么它們適合于自己的APP。

一、通知中心式

在這個模型中，把所有的通知都放在了通知心中里。通知中心可以是一個精致的頁面，也可以是一個彈窗，這取決于你的界面設(shè)計。

無論通知的來源是什么，所有的通知都被錨點到通知中心里，然后再對通知進行導(dǎo)航分類。Medium就是使用這種模型，底部導(dǎo)航中的鈴鐺圖標(biāo)會出現(xiàn)徽章，從而作為指向所有通知的入口。視覺上區(qū)分已讀和未讀通知變得尤為重要，用戶需要清晰地辨別這兩類信息。

這種方式的最大優(yōu)點在于靈活性，以一含百，即使未來有新的來源出現(xiàn)也可以應(yīng)對。

設(shè)計原則：

• 所有不同類別的通知都需要使用同一種設(shè)計模式，而且一定要考慮這種模式的伸縮性。
• 如果你有太多通知來源，可能會出現(xiàn)界面亂糟糟的情況，這時候你就要考慮將同一類的通知合并成一個組，有助于減少信息重復(fù)出現(xiàn)。例如：James與2位好友開始關(guān)注你。
• 請確保通知中心的入口容易被發(fā)現(xiàn)與觸達。

通知中心式適合于：

• 產(chǎn)品中的通知無法被錨點到任何一個已有的導(dǎo)航中?？赡芤驗橥ㄖ缓鸵延袃?nèi)容一致，或因為內(nèi)容架構(gòu)中沒有可以生成通知的來源。
• 有些來源的通知在已有頁面中無法承載。
• 當(dāng)時間很緊急，你可能很難把所有可能的通知場景該如何錨點都細(xì)想一遍。這種情況下，通知中心是一個很簡單的方案，在實際操作中也很靈活。

二、來源錨點式

這種方式中，所有的通知都被錨點到導(dǎo)航的菜單中，這些菜單也正是通知的來源。

APP中并沒有一個共有的通知中心?？聪耊hatsApp的截圖會更易理解，無論是安卓還是iOS版本，通知被錨點到了各自的來源——Chats和Calls。

這種方式的優(yōu)點在于內(nèi)容的易發(fā)現(xiàn)性，憑借通知用戶可以非常直接地獲取到信息，過程中無需進入額外的中間頁。不過這種方式的靈活性和伸縮性不如通知中心式。

這種方式高度依靠APP本身的信息架構(gòu)，導(dǎo)航本身必須可以容納不同類別的通知。和上一個模型一樣，這里也需要通過視覺設(shè)計來區(qū)分已讀和未讀通知。

設(shè)計原則：

• 確保每一個通知可以和導(dǎo)航里的菜單對應(yīng)起來。隨著你APP復(fù)雜度的增加，各個通知的來源也隨之變多，這個時候你可以考慮使用通知中心或者混合式的模型（把通知中心式和來源錨點式混合起來）。我們將在下一個段落中講到混合式。
• 每一個錨點的設(shè)計模式應(yīng)該可以承載各自的內(nèi)容，并確保你的通知適合這種錨點的設(shè)計模式。用WhatsApp舉例，錨點“聊天”本身有自己的設(shè)計模式定義了每一個聊天應(yīng)該長成什么樣，那關(guān)于聊天的通知就必須跟隨這個設(shè)計模式。“電話”也是同理。
• 確保每一個錨點都易被發(fā)現(xiàn)與觸達，盡量避免在子級頁面中出現(xiàn)錨點。

來源錨點式適合于：

• 當(dāng)所有的通知的來源可以被安置到APP首頁（包含主導(dǎo)航）中。
• 你必須仔細(xì)想一遍所有需要通知的場景，且所有的通知可以被安置到現(xiàn)有的設(shè)計模型里。通知和來源的設(shè)計模式必須保持一致，這一點很重要。

三、混合模式

顧名思義是前兩種模式的混合體，且使用最為廣泛，F(xiàn)acebook、LinkedIn、 Twitter、Instagram等一些熱門APP都在使用它。

例如：Facebook，消息中心變成了主導(dǎo)航中的一個菜單，用來展現(xiàn)哪些無法在主頁面中展示錨點的通知。Facebook把好友邀請的通知錨點在了主導(dǎo)航的好友菜單中，而把推薦用戶錨點到了通知中心。

*Facebook目前已更新：

這種模型同時具備了前兩種模型的優(yōu)點并且可以適用于大部分情況。雖然你現(xiàn)在可以把所有通知都錨點到通知中心里，但仍有必要仔細(xì)考慮一下是不是有些場景的通知更應(yīng)該優(yōu)先使用來源錨點式。

設(shè)計原則：

• 定義產(chǎn)品體系中所有的內(nèi)容池，并按重要等級排序，這樣可以幫助你列出哪些通知應(yīng)該被錨點到來源，哪些可以直接進消息中心。由于這種模型與導(dǎo)航非常相關(guān)，通知的配置方式會影響到你導(dǎo)航的設(shè)計。
• 確保主錨點和通知中心易被發(fā)現(xiàn)，并且作為主頁導(dǎo)航的一部分。

混合式模型適用于：

• 當(dāng)你仔細(xì)考慮通知的場景后，發(fā)現(xiàn)一些通知可以被錨點到對應(yīng)的來源中，但是有些卻找不到已有的來源。
• 在你的導(dǎo)航體系中，有些來源藏得比較深。舉個例子，F(xiàn)acebook導(dǎo)航中有個漢堡包餐單，當(dāng)他的二級餐單中有通知來源時，漢堡包餐單就會變?yōu)殄^點，例如：小組、視頻、那年今天、收藏夾等。

結(jié)論

上述的模型都要用在正確的環(huán)境中，根據(jù)你APP的信息架構(gòu)來挑選適合的模型，可以幫助你提供想要的通知類型。

原文作者：Shashank Sahay

原文鏈接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

翻譯：Jesse Zhou

本文由@Jesse Zhou 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash, 基于CC0協(xié)議