通知模型
通知在交互設計中是一個比較複雜的內容，本文並未涵蓋關於它的所有細節，但我希望它可以為您提供一些清晰的方法或方向，為您的應用程序選擇正確的通知模型。
在我們開始討論通知模型之前，讓我們簡要了解一下通知是什麼以及它們由什麼組成。通知是源自針對用戶展示應用的重要信息。以下是通知的一些重要組成部分
通知模型 - 架構
來源：這是通知源自的應用程序的一部分。應用程序的體系結構可以有幾個位置來作為通知的展示，其中信息被分類，這些位置將成為通知分類的地方。
信息：這是需要用通知來傳達給用戶的消息。列如“Daenerys Targaryen發給你的朋友請求”或“Lord Varys開始關注你”。
類型：通知主要有兩種類型：信息性和可操作。這兩種類型都可以有更多的子類型，具體取決於應用程序的上下文結構。
通知標誌：這些是指示用戶注意通知的標誌。通知標誌可以像點一樣簡單，也可以對其進行計數一樣以顯示未讀通知的數量。
圓點：圓點是應用程序的可視組件，通知信息在界面上顯示。簡而言之，這是用戶將看到通知標誌的組件。請注意，圓點不一定是通知源，而只是通知表面所在的組件。圓點可以容納來自一個或多個來源的通知。
通知是應用程序與用戶交流並可能將用戶帶回應用的媒介之一。因此，它們是應用程序中非常重要的一部分。讓我向您介紹一些最流行的通知模型，以及何時使用一個更合適的通知模型。
1.通知中心
在這個模型中有一個定義的地方，所有的通知都會在這個位置上。通知中心可以是專用屏幕或彈出窗口，具體取決於可用的空間。在此模型中，所有通知都集成到通知中心，而不管其來源如何。然後，您可以從通知中心導航到通知來源。Medium使用此模型進行通知。標誌會顯示在響鈴圖標上，該圖標是所有通知的入口點。已讀和未讀的通知在視覺展示上也是不同的。以方便用戶區分它們。
Medium - 通知中心
該模型的最大優點是其靈活性。這是一個可以容納每個通知的地方，無論是什麼樣的來源。
設計建議
- 必須考慮所有不同類型的通知，並且應遵循相同的設計架構。在設計模式時，將可擴展性視為我們的主要目標是非常重要的。如果您有太多通知來源，那麼當通知信息太多時，此模型可能會開始變得有點混亂。如果有相同類型的通知，您可以將它們組合在一起，這有助於減少類型的重複。例如，“Sansa Stark和另外3人向您發送了好友請求”。確保通知中心容易發現和訪問。
什麼時候使用通知中心呢
- 你的產品需要通知，但是不能固定在任何現有的導航選項上。這可能是因為通知與產品上的現有對象不一致，或者通知不是源自信息體系結構中的任何已定義源。通知的來源可能超過了應用在登陸屏幕上所能容納的面積上限。當你時間不夠的時候。有些情況下，您需要在有時間考慮通知的所有可能場景併為每個場景找到錨之前發佈一個特性。在這種情況下，通知中心可能是你的選擇，因為它本質上非常靈活。
2.固定來源的通知
在此模型中，每個通知都固定到導航的某一個選項上，該選項很可能也是通知的來源。您的所有通知都沒有一箇中心。看看WhatApp可以獲得更好的想法。在兩個平臺（Android和iOS）上，來自聊天或調用的通知都固定到相應的導航菜單。該模型的優點在於它可以實現更多內容的可發現性。用戶現在可以直接訪問通知所傳達的信息，而無需進行多一步操作。但是這種模型不像通知中心那樣靈活或可擴展。
WhatsApp - 源固定通知
該模型在很大程度上取決於應用程序的信息架構。導航必須能夠容納所有不同類型的通知。與之前的模型一樣，此處讀取和未讀通知在視覺上也是不同的。
設計建議
- 確保每個通知都可以固定到著陸屏幕上的某個導航選項。隨著應用程序複雜性的增加，通知來源也可能會增加。在這種情況下，您可以選擇通知中心，也可以考慮混合模型的方式（即固定模型和通知中心的組合）。我們將在下一節中介紹混合模型。每個固定通知的位置應該有一個設計架構，用於它將顯示通知信息。確保您的通知符合固定點的架構。為了理解這一點，讓我們以WhatsApp為例。這裡的固定點“聊天”有一個設計模式，用於定義聊天對象的外觀。這意味著固定到聊天的任何通知都必須遵循此架構。“呼叫”也是如此。確保固件易於發現和接觸。避免使用嵌套方式。
使用固定來源通知
- 當所有通知的來源都可以在著首頁屏幕上進行顯示。您已經考慮了所有通知方案，並且可以使用現有設計模式來適應所有通知。重要的是，這些通知遵循它們所固定的通知來源的模式。
3.混合模型
該模型是兩種模型的組合。它是最常用的模型。Facebook，LinkedIn，Twitter和Instagram是一些使用它的應用。這裡，通知中心成為導航菜單中的選項之一，其可以用作不符合首頁屏幕條件的固定來源。例如，Facebook將新朋友請求固定到“朋友”選項卡，但是喜歡頁面的邀請被固定到通知中心。
Facebook - 混合模型
該模型具有兩種模型的優點，可以輕鬆適應大多數情況。雖然現在您可以將通知固定到通知中心，但仍然必須仔細考慮所有方案，並確定可以通過固定來源通知來適應的優先級。
就像固定來源模型一樣，這個模型也很大程度上依賴於導航菜單，導航菜單現在也有通知中心作為選項。
設計
- 識別和排列產品架構中最重要的信息。對它們進行排序將允許您對應該固定來源的通知進行優先級排序，以及哪些通知應該放在通知中心中。由於此模型取決於導航，因此通知的配置可根據可用的不動產進行更改。確保主要固定源和通知中心可以作為登陸屏幕上導航的一部分容易輕鬆發現。
使用混合模型時
- 您已經考慮過通知方案。您有一些通知可以固定到各自的來源，但其他一些通知無法固定到架構中的任何現有來源。您的導航中已嵌套了來源。例如，Facebook應用程序上的漢堡菜單圖標是來自其下的來源的通知的錨點，例如群組，觀察，記憶，已保存，市場等。
結論
上面提到的所有模型在通知提醒的交互設計上都很有用。決定為您的應用選擇哪種模式取決於信息架構和您想要滿足的通知類型。
原文鏈接：
https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96
作者：Shashank Sahay
