通知是指源自App內部诵棵，推送給用戶的提示信息，一般包含標題和內容兩部分祝旷，絕大部分通知均是文字內容履澳。
來源(Source)：這是APP中生成通知的源頭。每個APP根據(jù)自己不同的內容體系可以有多個內容池怀跛，當系統(tǒng)距贷、其他用戶或者用戶自己的操作引起內容池變化時便會產(chǎn)生通知。
信息(Information)：以通知為載體傳達給用戶的消息敌完。比如說“Jesse申請成為你的好友”或者“James贊了你的推文”储耐。
徽章(Badge)：引導用戶查看通知的視覺元素 ”醺龋徽章里的指示可以是一個簡單的點什湘，也可以展示未讀消息的數(shù)量长赞。（對于強迫癥患者來講，徽章就是“惡魔”）
錨點(Anchor)：指的是界面中用來引導用戶進入通知的提示位置闽撤。簡單來說得哆，錨點就是用戶看到通知指引或顯示徽章的地方。錨點并不一定只能通知來源的地方顯示哟旗，也可出現(xiàn)在你希望體現(xiàn)有通知的地方贩据。錨點可以用來展示多種來源的通知，當然也可以只展示一類闸餐。你可以這樣想饱亮，來源是信息架構層面的概念，而錨點不過是你可以看到徽章的視覺元素舍沙。
通知是App與用戶溝通的一種方式近上，提高用戶再次進入App的可能性，增加用戶的粘性拂铡，同時也有幾率喚醒那些沉默用戶壹无。因此通知是APP中十分重要的部分。常用的App通知模型主要有以下幾種：
一感帅、通知中心式
在這個模型中斗锭，將App內所有的通知都放在獨立的通知心中里。通知中心可以是一個精致的頁面失球，也可以是一個彈窗岖是，這可以根據(jù)需求及使用場景來確定。
無論通知的來源是什么她倘，所有的通知都被錨點到通知中心里璧微，然后再對通知進行導航分類。Medium就是使用這種模型硬梁，底部導航中的鈴鐺圖標會出現(xiàn)徽章前硫，從而作為指向所有通知的入口。視覺上區(qū)分已讀和未讀通知變得尤為重要荧止，用戶需要清晰地辨別這兩類信息屹电。
這種方式的優(yōu)點在于比較靈活，擴展性較好跃巡，通知中心的入口可以根據(jù)需要進行調整危号，后續(xù)即便是增加了新的通知類型，只需在通知中心內部調整即可素邪，對其他模塊沒有影響外莲。
缺點就是眾多類型的通知放在一起會略顯雜亂，最好用tab加以區(qū)分
設計原則：
所有不同類別的通知都需要使用同一種設計模式，而且一定要考慮這種模式的擴展性偷线。
如果你有太多通知來源磨确，可能會出現(xiàn)界面亂糟糟的情況，這時候你就要考慮將同一類的通知合并成一個組声邦，有助于減少信息重復出現(xiàn)乏奥。例如：James與2位好友開始關注你。
請確保通知中心的入口容易被發(fā)現(xiàn)和觸達亥曹。
通知中心式適合于：
產(chǎn)品中的通知無法被錨點到任何一個已有的導航中邓了。可能因為通知不和已有內容一致媳瞪，或現(xiàn)有內容架構中并沒有生成通知的來源骗炉。
有些來源的通知在已有頁面中無法承載。
當時間很緊急材失，你可能很難把所有可能的通知場景該如何錨點都細想一遍痕鳍。這種情況下，通知中心是一個很簡單的方案龙巨，在實際操作中也很靈活。
二熊响、來源錨點式
這種方式中旨别，所有的通知都被錨點到導航的菜單中，這些菜單也正是通知的來源汗茄。
APP中并沒有一個共有的通知中心秸弛。看下WhatsApp的截圖會更易理解洪碳，無論是安卓還是iOS版本递览，通知被錨點到了各自的來源——Chats和Calls。
這種方式的優(yōu)點在于內容極易被發(fā)現(xiàn)瞳腌，憑借通知用戶可以非常直接地獲取到信息绞铃，過程中無需進入額外的中間頁。不過這種方式的靈活性和伸縮性不如通知中心式嫂侍，一旦后續(xù)需要調整儿捧，可能各個消息來源模塊都要改動，工作量會較大挑宠。
這種方式高度依靠APP本身的信息架構菲盾，導航本身必須可以容納不同類別的通知，即所有的通知必須有與之對應的來源模塊各淀。和上一個模型一樣懒鉴，這里也需要通過視覺設計來區(qū)分已讀和未讀通知。
設計原則：
確保每一個通知可以和導航里的菜單對應起來碎浇。隨著你APP復雜度的增加临谱，各個通知的來源也隨之變多璃俗，這個時候你可以考慮使用通知中心或者混合式的模型（把通知中心式和來源錨點式混合起來）。我們將在下一個段落中講到混合式吴裤。
每一個錨點的設計模式應該可以承載各自的內容旧找，并確保你的通知適合這種錨點的設計模式。用WhatsApp舉例麦牺，錨點“聊天”本身有自己的設計模式定義了每一個聊天應該長成什么樣钮蛛，那關于聊天的通知就必須跟隨這個設計模式∑噬牛“電話”也是同理魏颓。
確保每一個錨點都易被發(fā)現(xiàn)與觸達，盡量避免在子級頁面中出現(xiàn)錨點吱晒。
來源錨點式適合于：
當所有的通知的來源可以被安置到APP首頁（包含主導航）中甸饱。
你必須仔細想一遍所有需要通知的場景，且所有的通知可以被安置到現(xiàn)有的設計模型里仑濒。通知和來源的設計模式必須保持一致叹话，這一點很重要。
三墩瞳、混合模式
顧名思義是前兩種模式的混合體驼壶，且使用最為廣泛，F(xiàn)acebook喉酌、LinkedIn热凹、 Twitter、Instagram等一些熱門APP都在使用它泪电。
例如：Facebook般妙，消息中心變成了主導航中的一個菜單，用來展現(xiàn)哪些無法在主頁面中展示錨點的通知相速。Facebook把好友邀請的通知錨點在了主導航的好友菜單中碟渺，而把推薦用戶錨點到了通知中心。
這種模型同時具備了前兩種模型的優(yōu)點并且可以適用于大部分情況和蚪。雖然你現(xiàn)在可以把所有通知都錨點到通知中心里止状，但仍有必要仔細考慮一下是不是有些場景的通知更應該優(yōu)先使用來源錨點式。
設計原則：
定義產(chǎn)品體系中所有的內容池攒霹，并按重要等級排序怯疤，這樣可以幫助你列出哪些通知應該被錨點到來源，哪些可以直接進消息中心催束。由于這種模型與導航非常相關集峦，通知的配置方式會影響到你導航的設計。
確保主錨點和通知中心易被發(fā)現(xiàn)，并且作為主頁導航的一部分塔淤。
混合式模型適用于：
當你仔細考慮通知的場景后摘昌，發(fā)現(xiàn)一些通知可以被錨點到對應的來源中，但是有些卻找不到已有的來源高蜂。
在你的導航體系中聪黎，有些來源藏得比較深。舉個例子备恤，F(xiàn)acebook導航中有個漢堡包餐單稿饰，當他的二級餐單中有通知來源時，漢堡包餐單就會變?yōu)殄^點露泊，例如：小組喉镰、視頻、那年今天惭笑、收藏夾等侣姆。
結論
上述的模型都要用在正確的場景中，根據(jù)你APP的信息架構來選擇合適的模型沉噩，可以讓通知發(fā)揮更好的效果捺宗。
原文作者：Shashank Sahay
原文鏈接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96
