Web網站通知系統設計

寫在前面： 通知系統是網站信息傳播機制的重要的一部分，足夠寫一大章來講明。本文只梳理設計原則，後續相關內容會持續更新。 這裏的通知包括但不限於公告、提醒或消息（不一樣使用場景下的功能定義不一樣）。 關於各客戶端平臺（ios、android、wp等）的通知機制，在其交互設計指南中有更詳細的說明，你們可自行參考。

1、通知系統定義

通知系統，顧名思義即通知信息的傳達處理系統。目的是爲了讓用戶得到須要獲得的消息及提醒並進行處理。

這裏的「須要獲得」有兩層意思： 一、用戶彼此互動觸發的信息流（留言、評論或者回復、私信等） 二、網站但願用戶瞭解關注的信息（系統公告等）

通知系統設計的原則可簡單的概括爲： 一、消息傳播效率最高（獲取、處理、信息傳達、用戶反饋等效率） 二、避免產生騷擾（噪音、頻繁提示）

2、通知分類

不用的平臺和產品自己因爲對業務的需求不同，種類也是有區別的。

大體可分爲如下幾種：

3、通知邏輯實現機制

通知的邏輯精簡後以下：

現對這幾個環節分開說明：

（一）通知合併

通知在推送以前須要進行彙總合併，目的在於提升消息傳播處理效率；減小騷擾，下降噪音；平衡服務器壓力。

1）合併週期：

1. 固定時間內的消息所有彙總（24小時內/30天等）；
2. 無固定時間（只要未處理/未讀即彙總）

固然通常都組合着用：合併24小時內未處理消息

2）分類合併

1. 同種類進行合併（如n條留言合併爲1條）
2. 同一發起人合併（如張三給你發來的n條私信）
3. 同一時間週期合併（如24小時共收到n條評論）

（二）通知分發

通知按照規則彙總完成後，系統將其經過通知管道推送到用戶，以便用戶處理。

1）分發方式

分發方式與Feed系統相似，多采用Push方式，即在指定時間內主動推送給用戶。部分特定類型須要用戶請求（Pull）拉取未讀消息。 目前大部分通知優先推送未處理通知合併後的總數，已提醒用戶已有新消息須要處理。用戶點擊數字後再去服務端請求具體的消息內容。此種方式綜合考慮了成本、壓力和體驗。固然，某些極端狀況下須要進行優化處理：如未讀消息超過1000，用戶請求時先推送前50條或者放入cache中等。技術童鞋會有各類手段，這裏不作詳述。

2）分發頻率（時間）

分發時間主要根據消息的優先級來作區隔：

3）分發管道

分發管道即消息通知的具體推送渠道，根據業務類型能夠分爲：Web、App、短信、郵件等。

（三）用戶處理

根據前文提到的分發方式，對於通知的處理在邏輯上能夠分爲兩層：通知狀態的處理和通知內容的處理。

1）狀態的處理狹義的理解即爲是否已讀（已處理）。

一般初始數字即爲系統推送過來的未讀總量，用戶點擊數字進入相關功能列表查閱後，讀取的動做完成，未讀數字相應減小。

有幾種狀況須要變通處理：

1. 若用戶未讀信息較多（m=100），但第一頁列表只能顯示（n=10）條的話，那未讀數字即爲m-n=90；
2. 某些產品會將點擊等同於已讀。即用戶只要點擊不管是否打開列表查看均認爲已讀。 這樣的處理通常用於重要級別較低的消息。點擊即已讀可有效下降騷擾。
3. 某些重要級別較高的消息已處理狀態能夠定義爲用戶進行相關操做後才爲已處理，而非查閱。 如用戶進行評論、回覆、點擊忽略或點擊刪除等動做時才認爲已處理。

2）內容的處理狹義的理解即爲用戶是否操做。

根據不一樣消息的種類和業務的須要，操做可分爲：

1. 處理：用戶必須點擊功能連接進行處理。如：你的密碼過於簡單，點此進行修改；
2. 回覆：如回覆私信，對評論進行回覆；
3. 確認：對消息作出確認的反饋，如某些系統提示可設置」我已知道，再也不提示」的選項；
4. 忽略：用戶進行忽略操做或不進行任何操做；
5. 刪除：用戶刪除本消息。

3）消息處理後的狀態須要統一。

消息須要標記是否已處理的狀態，且狀態在不一樣的終端是打通的。 如：用戶在客戶端對消息進行了查看，在web站點本消息應自動標記爲已讀狀態。

（四）通知回收

回收主要針對用戶已處理消息的操做。

1. 用戶之間觸發的消息通常須要留檔保存。 如評論/回覆/留言/私信等。產品可提供選項詢問用戶是否超過必定週期自動清理。
2. 在部分產品中，還須要考慮功能的優先級。 如解除好友關係或加入黑名單後自動將刪除雙方的私信記錄。
3. 系統觸發的消息通常設置必定的回收刪除時間。 如系統提醒、通知、公告等。過時後自動在產品裏刪除。物理上能夠設置是否備份。
4. 過時但用戶未處理消息（用戶長時間未登陸但收到他人的回覆）能夠根據業務需求來處理。 如未讀的私信/評論/回覆永久保留等。重要未讀消息可嘗試二次推送或使用其餘途徑（郵箱、APP、短信等）通知。

4、通知處理交互

注：具體的交互須要考慮自己業務特色和目標需求。特定業務可能須要強調，某些業務又須要考慮騷擾，故拋開具體情境自己談交互是無恥的。

這裏只針對通常的社區網站，描述一下我的所喜歡的交互方式。

一、新消息到達時提醒交互

當新消息到達時，可使用如下提醒方式

1. 標題閃動
2. 聲音提醒 新消息到達後自動觸發聲音
3. 氣泡+數字
4. 新消息浮層
5. 彈窗提示

二、通知處理

目前消息多采用當前觸發、即時處理相似「所見即所得」的交互方式。 

採用此方式的須要考慮：

1. 消息通知位於全局導航，訪問任何頻道時均可保證及時收到新消息；
2. 消息在浮層中處理完畢後，用戶可繼續進行以前的操做，不至於形成打擾；
3. 因導航面積有限，需對消息種類進行統一整理和規劃；（Facebook的分類爲好友請求、私信、通知。）
4. 提供歷史記錄（更多、所有消息）的入口（二級頁面）
5. 標記已讀未讀狀態，處理好消息提醒數字的關係 

5、防騷擾（打擾）

因消息自己業務性質，過多無用通知勢必會形成噪音，打擾到用戶。所以合理設置消息的通知頻率和渠道，以防早上體驗和效率上的損失。

一、提供通知頻率和渠道的管理功能

如常見的郵件退訂管理，消息通知類型管理。 

Facebook通知設置



二、增長屏蔽功能

消息屏蔽功能在業務上應該屬於第一條中通知類型管理，當業務模塊較多且以前關聯分散時，或者開放平臺功能接入的第三方應用通知時，可以使用屏蔽功能。

facebook應用消息管理

新浪微博應用消息管理

三、結合權限體系

一、功能隱私設置

使用隱私設置界定具體的接收權限、範圍等微博私信設置

二、結合黑名單功能

使用黑名單可屏蔽指定用戶或關鍵詞的具體消息通知。

6、用戶拉回

當用戶長時間不登錄或對消息不處理時，可以使用其餘渠道推送通知，已達到拉回的目的。 這個要與網站總體的拉回策略相結合。

例：Facebook的好友請求確認拉回郵件：

7、總結

呃，若是你能看到這裏，真的很感謝，這篇文章斷斷續續更新了好幾天才完結，好多地方寫的不完整，還望包涵。
我原本想試圖去總結一套處理這種業務的邏輯方法，後來仍是放棄了，緣由是：

1. 具體業務要具體分析，已有的資源和現狀很重要，這個是設計的前提
2. 大的原則，如優先級、全盤考慮、預留接口、數據統計等講出來太空，還不如不說

最後，若是你以爲本文對你有用，請分享給其餘人。（請註明出處哦）

——更新——
這個是我微博：@阿狗小明，我不常常更新因此不會騷擾到你，留下地址有問題能夠私信我一塊兒討論（歡迎單身妹子騷擾）。
——再次更新——
關於Feed與通知有不少共性，會在下一篇裏面提到，感謝小雅的建議。
 

http://www.withink.net/webnotice/