[譯] 爲 APP 設計通知提醒

• 原文地址：Designing notifications for apps: Explore different notification models and when to use which
• 原文做者：Shashank Sahay
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Ryden Sun
• 校對者：pkuwwt sanfran1068

探索不一樣的通知提醒模型以及如何去選擇

通知提醒模型

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 的早期反饋。

點擊下面連接來查看以前的功能分解系列文章。

1. Medium Claps: Why it’s so difficult?
2. Google Search Results: List View vs Grid View
3. YouTube Search Query: Why doesn’t it go away?
4. Designing search for mobile apps

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。