探索不同的通知提醒模型以及如何去選擇
通知提醒模型
Medium 的讀者們，我們又見面啦。這裡是我們的功能分解系列文章的第五期：應用程式的通知提醒模型。當前，通知提醒算是一個處理起來比較複雜的功能。這篇文章不會覆蓋其所有的痛點，但是我希望可以為你提供足夠清晰的理解，並在選擇合適的應用程式通知提醒模型時，為你指明一個方向。
在我們開始討論通知提醒模型之前，我們簡要的看一下通知提醒的介紹以及它是由什麼組成的。通知提醒是由應用程式傳送給使用者的一系列訊息提示。這裡是一些其重要的組成部分。
通知提醒模型 — 圖解
來源: 應用的這部分是通知提醒的起源。一個應用的架構可以有多個由資訊分類組成的部分，並且這些部分是通知提醒的來源。
資訊: 資訊是一條需要通過通知提醒的方式傳達給使用者的訊息。比如“嫦娥妹妹請求新增你為好友”或者“康熙開始關注你啦”。
型別: 通知提醒主要可分為兩部分：通知型和可操作型。所有的型別都可根據其應用的內容有更深入的細分。
通知標記: 通知提醒提供視覺化標示來引導使用者檢視通知。這些標示可以只是簡單的點狀符號，還可以加上未讀訊息的數目。
錨點: 錨點是應用程式介面上顯示通知的視覺化元件。簡單來說，就是使用者看到的通知標記所在的那個元件。簡單來說，這個部分就是使用者在哪裡可以看到通知標記。注意，錨點不一定是通知的來源，只不過是顯示通知的位置。 一個錨點可以顯示一個或多個來源的訊息。換一句話說，訊息來源是架構/資訊層面的概念，而錨點只不過是實現層面讓你可以看到通知標記的視覺化元件。
通知提醒是應用程式用來和使用者通訊的媒介，應用程式用通知提醒向使用者傳送資訊，並且可能吸引使用者重回應用。因此，它們是一個應用程式很重要的部分。讓我來給你介紹一些最流行的通知提醒模型，並且合適去選擇最合適的模型。
1. 通知中心
在這個模型裡，會有一個明確的區域來落地所有的通知提醒。通知中心可以是一一整塊專門的螢幕或者根據目前可用空間來彈出的介面。這個模型裡，所有的通知提醒，不管其來源如何，都統一被放在通知中心。通過通知中心，你可以導航至不同通知提醒的源頭。一個有通知標記的銅鈴圖示，就是所有通知提醒的入口。已讀和未讀通知提醒有一個可見的不同是很重要的，可以讓使用者來區別他們。
Medium — 通知中心
這個模型最大的優勢在於它的靈活性。這個地方可以容納所有的通知提醒，不管是已存在或是新的來源。
指導方針
- 所有不同型別的通知提醒都需要被考慮到，並且採用統一的設計形式。當設計此形式時，很重要的一點，是要將其可擴充套件性當做我們的首要目標。
- 如果你有太多不同來源的通知提醒，那這種模型可能會變得有一些雜亂。如果有相似的通知提醒型別，你應該將它們組合起來，以此來減少重複。舉個例子，“王昭君和其他三個人請求新增您為好友”。
- 確保通知中心很容易被使用者發現並訪問到。
什麼時候使用通知中心
- 你的產品有通知提醒的需求，而這些通知無法整合到任何已有的導航選項中。原因可能是通知與產品上已存在的物件不一致，或者通知並不源自於當前資訊架構中定義的任何訊息源。
- 可能還有更多的訊息源頭無法在應用程式的首頁顯示。
- 你的時間有限。可能還沒來得及考慮清楚每一種可能的場景及相應的錨點，你就必須交付一個功能了。這種情況下，通知中心是你簡單的解決方案，並且它天生就很靈活。
2. 錨點在訊息源上的通知提醒
這個模型裡，每一個通知提醒都固定於一個導航選項，最可能的選擇是訊息源。這裡沒有一個承載所有通知提醒的中心。看一看 WhatsApp 會有一個更清晰的認識。在兩個平臺（android 和 iOS）上，來源於聊天或者通話的通知的錨點都置於其相應的導航選單上。這個模型的優勢在於它能引導使用者發現更多內容。通過這種方式，使用者可以直接訪問到通知所傳遞的訊息內容，無需多一箇中間層。但這個模型並不像通知中心那樣靈活和可擴充套件。
WhatsApp — 錨點在訊息源上的通知提醒
這個模型強烈依賴於應用程式的資訊架構。導航必須容納所有不同型別的通知。類似於前面的模型，已讀和未讀通知提醒有一個可見的不同是很重要的，可以讓使用者來區別他們。
指導方針
- 確保每個通知提醒的錨點都能對應到應用程式首頁的某個導航選項上。隨著你應用複雜度的增長，通知提醒的數目也會增加。這種情況下，你可以投向通知中心的懷抱，或者考慮一種混合模型（那就是錨點模型和通知中心的結合）。我們會在下一節講到混合模型。
- 每一個錨點都應有一個對應其所含內容的設計形式。確保你的通知契合錨點的設計形式。為了理解這個，讓我們看一下 WhatsApp 的例子。錨點“聊天”有一個設計形式，它定義了一個聊天物件看起來應該是什麼樣子。這意味著每一個錨點固定於聊天的通知提醒都應該服從這種設計形式。這同樣被用來設計“通話”的通知提醒。
- 確保錨點易於發現和訪問。避免使用巢狀錨點。
什麼時候使用錨點在訊息源上的通知提醒
- 當所有可能的訊息通知來源都可以被首頁容納。
- 你已考慮到所有可能使用到通知提醒的場景，並且所有的通知提醒都可以適用於已存在的設計形式。很重要的一點是這些通知提醒應該遵守其錨點所在的訊息源的設計形式。
3. 混合模型
這種模型是前面兩種的結合。這種模型是最常被使用的。有很多比較火的應用是使用這種模式的，如 Facebook, LinkedIn, Twitter 和 Instagram。這些應用中，通知中心變成了導航選單上的一個選項，它可以是不同來源的錨點，這些來源都不還不夠資格在首頁展示。比如，Facebook 把請求新增好友的通知錨點到“朋友”選項，但邀請點贊被錨點到了通知中心。
Facebook — 混合模型
這種模型有以上兩種模型的優點，並且可以輕易地適用大多數情況。即使現在你有能力將訊息提醒錨點到通知中心，但依舊有必要考慮所有的場景並且將它們排出優先順序，找到那些可以適用錨點於來源的通知提醒。
就像錨點在訊息源上的通知提醒模型，這個模型也嚴重依賴於導航選單，而且還有一個通知中心的選單選項。
指導方針
- 找出產品架構中最重要的那些資訊，並對其優先順序排序，這樣你才可以決定哪些錨點應放在訊息源，哪些應放在通知中心。因為此模型依賴於導航，通知提醒的配置可能會因可用空間的變化而改變。
- 確保首屏的導航中容易找到主要的錨點和通知中心
什麼時候使用混合模型
- 你有考慮過所有通知提醒的使用場景。你有一些通知提醒的錨點可以放在訊息源上，但是還有一些無法放在當前架構的任何訊息源上
- 你的架構中存在巢狀的訊息源。比如，Facebook 應用程式的漢堡式選單圖示是一個錨點，它對應於多個訊息源，比如 Groups, Watch, Memories, Saved, Marketplace 等等。
結論
以上所有提到的模型在正確的使用場景下都是很有用的。你的應用程式選擇使用哪種模型取決於產品的資訊架構和你青睞的訊息通知型別。
不要忘記點贊
10次不錯，20次更好，但50次是最好的。直接按住按鈕不放就行了。:P
希望這篇文章有助於你為應用程式選擇合適的通知提醒模型。如果你有任何的反饋，在評論中讓我們知道。
特別鳴謝
Shailly Kishtawal 的頭腦風暴。 Prerna Pradeep 在內容上的幫助。 以及 Dhruvi Shah 和 Tanvi Kumthekar 的早期反饋。
點選下面連結來檢視之前的功能分解系列文章。
- Medium Claps: Why it’s so difficult?
- Google Search Results: List View vs Grid View
- YouTube Search Query: Why doesn’t it go away?
- Designing search for mobile apps
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。