通知是應用程序與用戶交流並可能將其帶回應用程序的媒介之一。因此，通知是應用程序的重要組成部分。接下來本文將介紹一些最流行的通知模型，以及什麼時候應該使用其中的一種。

通知可能是一個複雜的要素。這篇文章沒有涵蓋關於通知的所有細節，但我希望這篇文章可以為你提供足夠清晰的指導，以便為你的App選取正確的通知模型。

在我們開始討論通知模型之前，讓我們簡明扼要的說一下什麼是通知以及他們是由什麼組成的。通知是源自針對用戶的應用程序的信息。以下是通知的一些重要組成部分：

Notification Models — Schema

• 來源（source）：通知的來源屬於應用程序的一部分。應用程序的架構可以有幾個對信息進行分類的存儲桶（bucket），這些存儲桶將成為通知的來源。
• 信息（information）：通過通知傳達給用戶的信息。例如“Daenerys Targaryen請求添加為好友”，“Lords Varys 關註了你”。
• 類型（type）：通知主要分為倆個類型:信息型（informational）和可操作型（actionable）。這兩個類型可以有其他的子類型，這取決於應用程序的背景。
• 通知角標（notification badge）：這是可以將用戶引導到通知的可視化指示物，可視化指示物可以是點，也可以是未讀信息的數量。
• 錨點（anchor）： 錨點是應用程序的可視化組件，將通知顯現在界面上。簡單來說，這是一個用戶可以看到通知角標的組件。註意，錨點不一定是通知的來源，而只是將通知顯現出來的組件。一個錨點可以容納多個來源或一個來源的通知。可以這樣想，來源更多是在架構/信息層面，但是錨點是你可以看到通知角標的可視化組件。

通知是應用程序與用戶交流並可能將其帶回應用程序的媒介之一。因此，通知是應用程序的重要組成部分。接下來讓我來介紹一些最流行的通知模型，以及什麼時候應該使用其中的一種。

1. 通知中心(Notification Center)

在這個模型，所有的通知都在一個被明確好的地方。通知中心可以是一個單獨的界面或是一個彈窗，這取決於可利用的空間。在這種模型中，所有的通知，不管他們的來源，都被放在通知中心。然後，你可以從通知中心導航到通知來源。

Medium用的就是這種通知模型。一個帶角標的鈴狀圖標是所有通知的入口。已讀和未讀通知在視覺上有所不同以便用戶能夠區分它們，同樣是很重要的。

Medium — Notification Center

這種模型最大的優點是靈活性。通知中心是一個可以容納所有通知的地方，無論是來自現有來源的通知還是新的通知。

準則

• 必須全面考慮所有不同類型的通知，並且應該遵循相同的設計模式。在設計模式時，將可拓展性視為我們的主要目標是極為重要的。
• 如果有太多的通知來源，這種模型在有太多通知時就會看起來有點凌亂。如果有同類型的通知，你可以把他們分組，減少重覆。例如“Sansa Stark以及其他三人請求添加為好友”。
• 確保通知中心的可發現性以及易使用性。

何時使用通知中心

• 你的產品需要通知，但這些通知又無法被放到已有的導航選項中時。可能是因為這類通知與產品上的現有對象不一致，或者這類通知不是源自信息架構中任何已經定義的來源。
• 當通知來源多於應用程序主屏幕所能容納的時候。

2. 固定來源通知(Source Anchored Notifications)

在此模型中，每個通知都固定到導航選項上，該導航選項也很有可能也是通知來源，沒有為你的通知準備單獨的中心。

可以參考一下WhatsApp：

在Android和iOS兩個平臺，聊天和通話的通知被放置在各自的導航菜單。這個模型的優點是可以使更多的內容被髮現，用戶可直接到達通知所傳達的信息，無需添加中間環節的麻煩。但是這個模型不像通知中心那樣靈活，以及具備可拓展性。

WhatsApp — Source Anchored Notifications

這個模型重度依賴於應用程序的信息架構。導航必須可以容納不同類型的通知。並且像前一個模型一樣，已讀和未讀通知在視覺上有所不同是很重要的。

準則

• 確保在主屏幕中每個通知都對應一個導航選項。隨著應用程序複雜性的增加，通知來源的數量也可能會增加。在這種情況下，您可以選擇通知中心模型，也可以考慮使用混合模型（這兩種模型的結合）。我們會在下一部分講解混合模型。
• 每個錨點都應有一個它所容納的內容的設計模式。確保你的通知符合錨點的設計模式。為了理解這條，我們可以以WhatsApp為例。這裡的“聊天”錨點有一個設計模式，用於定義 “聊天”這一對象是什麼樣的。這就意味著任何被放置在“聊天”得通知都應遵循這一模式。“通話”同理。
• 確保錨點的可發現性以及易使用性。避免使用嵌套的錨點。

何時使用固定來源通知模式

• 當所有可能的通知來源都可以容納在主屏幕上時。
• 你已經考慮了所有通知的方案，所有的通知都可以被歸納到現有的設計方案中。這些通知必須遵循其被規定好的來源的方案，這一點很重要。

3. 混合模型（Mixed Model）

這個模型是前兩個模型的結合，是最被廣泛使用的模型。Facebook, LinkedIn, Twitter和Instagram這些受歡迎的應用程序都在使用這種混合模型。這種模型中，通知中心變成了導航菜單的一個選項，可用作那些不需要出現在主屏幕上的通知來源的錨點。例如，Facebook把新好友請求放在“朋友”標簽中，但是喜歡頁面的邀請被放在了通知中心。

Facebook — Mixed Model

這種模型具備著前兩種模型的優點，並且可以輕鬆應對大多數情況。儘管現在你可以將通知放到通知中心，但是仍然必須仔細考慮通知的所有方案，並給哪些通知可以被放到特定來源的通知排出優先級。

就像特定來源模型一樣，此模型也嚴重依賴於導航菜單，而且現在該菜單還加上了通知中心這一選項。

準則

• 確定產品架構中最重要的信息並將其分類。分類可以使你優先處理哪些通知應該被放到錨點，哪些應該放進通知中心。由於此模型取決於導航，因此通知的佈局可以根據可利用的空間進行調整。
• 確保主要的錨點和通知中心可以被輕鬆的發現。

在以下情況下使用混合模型

你已經充分考慮了通知方案。一些通知可以被放到它們各自的來源，但是其他的一些通知則不能放置到架構中的任何現有的來源。

在導航中有嵌套的來源。例如，Facebook上的漢堡菜單就是一個通知錨點，可放置一些其他的通知來源，例如小組，收藏夾，那年今天，活動等。

結論

上面提及的所有模型在特定的情況下都是很有用的。決定將哪種模型運用到你的app上取決於信息架構和你想滿足的通知類型。

原文 ：https://uxmag.com/articles/designing-notifications-for-apps

原作者：Shashank Sahay

編譯作者：hubiabia；公眾號：插畫鴨

本文由 @hubiabia 翻譯發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議