❶ App的消息通知設計：App常用通知模型
通知是指源自App內部，推送給用戶的提示信息，一般包含標題和內容兩部分，絕大部分通知均是文字內容。
來源(Source)： 這是APP中生成通知的源頭。每個APP根據自己不同的內容體系可以有多個內容池，當系統、其他用戶或者用戶自己的操作引起內容池變化時便會產生通知。
信息(Information) ：以通知為載體傳達給用戶的消息。比如說「Jesse申請成為你的好友」或者「James贊了你的推文」。
徽章(Badge) ：引導用戶查看通知的視覺元素 。徽章里的指示可以是一個簡單的點，也可以展示未讀消息的數量。（對於強迫症患者來講，徽章就是「惡魔」）
錨點(Anchor) ：指的是界面中用來引導用戶進入通知的提示位置。簡單來說，錨點就是用戶看到通知指引或顯示徽章的地方。錨點並不一定只能通知來源的地方顯示，也可出現在你希望體現有通知的地方。錨點可以用來展示多種來源的通知，當然也可以只展示一類。你可以這樣想，來源是信息架構層面的概念，而錨點不過是你可以看到徽章的視覺元素。
通知是App與用戶溝通的一種方式，提高用戶再次進入App的可能性，增加用戶的粘性，同時也有幾率喚醒那些沉默用戶。因此通知是APP中十分重要的部分。常用的App通知模型主要有以下幾種：
一、通知中心式
在這個模型中，將App內所有的通知都放在獨立的通知心中里。通知中心可以是一個精緻的頁面，也可以是一個彈窗，這可以根據需求及使用場景來確定。
無論通知的來源是什麼，所有的通知都被錨點到通知中心裡，然後再對通知進行導航分類。Medium就是使用這種模型，底部導航中的鈴鐺圖標會出現徽章，從而作為指向所有通知的入口。視覺上區分已讀和未讀通知變得尤為重要，用戶需要清晰地辨別這兩類信息。
這種方式的優點在於比較靈活，擴展性較好，通知中心的入口可以根據需要進行調整，後續即便是增加了新的通知類型，只需在通知中心內部調整即可，對其他模塊沒有影響。
缺點就是眾多類型的通知放在一起會略顯雜亂，最好用tab加以區分
設計原則：
所有不同類別的通知都需要使用同一種設計模式，而且一定要考慮這種模式的擴展性。
如果你有太多通知來源，可能會出現界面亂糟糟的情況，這時候你就要考慮將同一類的通知合並成一個組，有助於減少信息重復出現。例如：James與2位好友開始關注你。
請確保通知中心的入口容易被發現和觸達。
通知中心式適合於：
產品中的通知無法被錨點到任何一個已有的導航中。可能因為通知不和已有內容一致，或現有內容架構中並沒有生成通知的來源。
有些來源的通知在已有頁面中無法承載。
當時間很緊急，你可能很難把所有可能的通知場景該如何錨點都細想一遍。這種情況下，通知中心是一個很簡單的方案，在實際操作中也很靈活。
二、來源錨點式
這種方式中，所有的通知都被錨點到導航的菜單中，這些菜單也正是通知的來源。
APP中並沒有一個共有的通知中心。看下WhatsApp的截圖會更易理解，無論是安卓還是iOS版本，通知被錨點到了各自的來源——Chats和Calls。
這種方式的優點在於內容極易被發現，憑借通知用戶可以非常直接地獲取到信息，過程中無需進入額外的中間頁。不過這種方式的靈活性和伸縮性不如通知中心式，一旦後續需要調整，可能各個消息來源模塊都要改動，工作量會較大。
這種方式高度依靠APP本身的信息架構，導航本身必須可以容納不同類別的通知，即所有的通知必須有與之對應的來源模塊。和上一個模型一樣，這里也需要通過視覺設計來區分已讀和未讀通知。
設計原則：
確保每一個通知可以和導航里的菜單對應起來。隨著你APP復雜度的增加，各個通知的來源也隨之變多，這個時候你可以考慮使用通知中心或者混合式的模型（把通知中心式和來源錨點式混合起來）。我們將在下一個段落中講到混合式。
每一個錨點的設計模式應該可以承載各自的內容，並確保你的通知適合這種錨點的設計模式。用WhatsApp舉例，錨點「聊天」本身有自己的設計模式定義了每一個聊天應該長成什麼樣，那關於聊天的通知就必須跟隨這個設計模式。「電話」也是同理。
確保每一個錨點都易被發現與觸達，盡量避免在子級頁面中出現錨點。
來源錨點式適合於：
當所有的通知的來源可以被安置到APP首頁（包含主導航）中。
你必須仔細想一遍所有需要通知的場景，且所有的通知可以被安置到現有的設計模型里。通知和來源的設計模式必須保持一致，這一點很重要。
三、混合模式
顧名思義是前兩種模式的混合體，且使用最為廣泛，Facebook、LinkedIn、 Twitter、Instagram等一些熱門APP都在使用它。
例如：Facebook，消息中心變成了主導航中的一個菜單，用來展現哪些無法在主頁面中展示錨點的通知。Facebook把好友邀請的通知錨點在了主導航的好友菜單中，而把推薦用戶錨點到了通知中心。
這種模型同時具備了前兩種模型的優點並且可以適用於大部分情況。雖然你現在可以把所有通知都錨點到通知中心裡，但仍有必要仔細考慮一下是不是有些場景的通知更應該優先使用來源錨點式。
設計原則：
定義產品體系中所有的內容池，並按重要等級排序，這樣可以幫助你列出哪些通知應該被錨點到來源，哪些可以直接進消息中心。由於這種模型與導航非常相關，通知的配置方式會影響到你導航的設計。
確保主錨點和通知中心易被發現，並且作為主頁導航的一部分。
混合式模型適用於：
當你仔細考慮通知的場景後，發現一些通知可以被錨點到對應的來源中，但是有些卻找不到已有的來源。
在你的導航體系中，有些來源藏得比較深。舉個例子，Facebook導航中有個漢堡包餐單，當他的二級餐單中有通知來源時，漢堡包餐單就會變為錨點，例如：小組、視頻、那年今天、收藏夾等。
結論
上述的模型都要用在正確的場景中，根據你APP的信息架構來選擇合適的模型，可以讓通知發揮更好的效果。
原文鏈接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96