Web網(wǎng)站通知系統(tǒng)設(shè)計(jì)

寫(xiě)在前面： 通知系統(tǒng)是網(wǎng)站信息傳播機(jī)制的重要的一部分，足夠?qū)懸淮笳聛?lái)說(shuō)明。本文只梳理設(shè)計(jì)原則，后續(xù)相關(guān)內(nèi)容會(huì)持續(xù)更新。 這里的通知包括但不限于公告、提醒或消息(不同使用場(chǎng)景下的功能定義不同)。 關(guān)于各客戶端平臺(tái)(ios、android、wp等)的通知機(jī)制，在其交互設(shè)計(jì)指南中有更詳細(xì)的說(shuō)明，大家可自行參考。

　　一、通知系統(tǒng)定義

　　通知系統(tǒng)，顧名思義即通知信息的傳達(dá)處理系統(tǒng)。目的是為了讓用戶獲得需要得到的消息及提醒并進(jìn)行處理。

　　這里的“需要得到”有兩層意思： 1、用戶彼此互動(dòng)觸發(fā)的信息流(留言、評(píng)論或者回復(fù)、私信等) 2、網(wǎng)站希望用戶了解關(guān)注的信息(系統(tǒng)公告等)

　　通知系統(tǒng)設(shè)計(jì)的原則可簡(jiǎn)單的歸納為： 1、消息傳播效率最高(獲取、處理、信息傳達(dá)、用戶反饋等效率) 2、避免產(chǎn)生騷擾(噪音、頻繁提示)

　　二、通知分類

　　不用的平臺(tái)和產(chǎn)品本身由于對(duì)業(yè)務(wù)的需求不一樣，種類也是有區(qū)別的。

　　大致可分為以下幾種：

　　三、通知邏輯實(shí)現(xiàn)機(jī)制

　　通知的邏輯精簡(jiǎn)后如下：

　　?

　　現(xiàn)對(duì)這幾個(gè)環(huán)節(jié)分開(kāi)說(shuō)明：

　　(一)通知合并

　　通知在推送之前需要進(jìn)行匯總合并，目的在于提高消息傳播處理效率;減少騷擾，降低噪音;平衡服務(wù)器壓力。

　　1)合并周期：

　　固定時(shí)間內(nèi)的消息全部匯總(24小時(shí)內(nèi)/30天等);

　　無(wú)固定時(shí)間(只要未處理/未讀即匯總)

　　當(dāng)然一般都組合著用：合并24小時(shí)內(nèi)未處理消息

　　2)分類合并

　　同種類進(jìn)行合并(如n條留言合并為1條)

　　同一發(fā)起人合并(如張三給你發(fā)來(lái)的n條私信)

　　同一時(shí)間周期合并(如24小時(shí)共收到n條評(píng)論)

　　(二)通知分發(fā)

　　通知按照規(guī)則匯總完成后，系統(tǒng)將其通過(guò)通知管道推送到用戶，以便用戶處理。

　　1)分發(fā)方式

　　分發(fā)方式與Feed系統(tǒng)類似，多采用Push方式，即在指定時(shí)間內(nèi)主動(dòng)推送給用戶。部分特定類型需要用戶請(qǐng)求(Pull)拉取未讀消息。

　　目前大部分通知優(yōu)先推送未處理通知合并后的總數(shù)，已提醒用戶已有新消息需要處理。用戶點(diǎn)擊數(shù)字后再去服務(wù)端請(qǐng)求具體的消息內(nèi)容。此種方式綜合考慮了成本、壓力和體驗(yàn)。當(dāng)然，某些極端情況下需要進(jìn)行優(yōu)化處理：如未讀消息超過(guò)1000，用戶請(qǐng)求時(shí)先推送前50條或者放入cache中等。技術(shù)童鞋會(huì)有各種手段，這里不做詳述。

　　2)分發(fā)頻率(時(shí)間)

　　分發(fā)時(shí)間主要根據(jù)消息的優(yōu)先級(jí)來(lái)做區(qū)隔：

　　3)分發(fā)管道

　　分發(fā)管道即消息通知的具體推送渠道，根據(jù)業(yè)務(wù)類型可以分為：Web、App、短信、郵件等。

　　(三)用戶處理

　　根據(jù)前文提到的分發(fā)方式，對(duì)于通知的處理在邏輯上可以分為兩層：通知狀態(tài)的處理和通知內(nèi)容的處理。

　　1)狀態(tài)的處理狹義的理解即為是否已讀(已處理)。

　　通常初始數(shù)字即為系統(tǒng)推送過(guò)來(lái)的未讀總量，用戶點(diǎn)擊數(shù)字進(jìn)入相關(guān)功能列表查閱后，讀取的動(dòng)作完成，未讀數(shù)字相應(yīng)減少。

　　有幾種情況需要變通處理：

　　若用戶未讀信息較多(m=100)，但第一頁(yè)列表只能顯示(n=10)條的話，那未讀數(shù)字即為m-n=90;

　　某些產(chǎn)品會(huì)將點(diǎn)擊等同于已讀。即用戶只要點(diǎn)擊無(wú)論是否打開(kāi)列表查看均認(rèn)為已讀。

　　這樣的處理一般用于重要級(jí)別較低的消息。點(diǎn)擊即已讀可有效降低騷擾。

　　某些重要級(jí)別較高的消息已處理狀態(tài)可以定義為用戶進(jìn)行相關(guān)操作后才為已處理，而非查閱。

　　如用戶進(jìn)行評(píng)論、回復(fù)、點(diǎn)擊忽略或點(diǎn)擊刪除等動(dòng)作時(shí)才認(rèn)為已處理。

　　2)內(nèi)容的處理狹義的理解即為用戶是否操作。

　　根據(jù)不同消息的種類和業(yè)務(wù)的需要，操作可分為：

　　處理：用戶必須點(diǎn)擊功能鏈接進(jìn)行處理。如：你的密碼過(guò)于簡(jiǎn)單，點(diǎn)此進(jìn)行修改;

　　回復(fù)：如回復(fù)私信，對(duì)評(píng)論進(jìn)行回復(fù);

　　確認(rèn)：對(duì)消息做出確認(rèn)的反饋，如某些系統(tǒng)提示可設(shè)置”我已知道，不再提示”的選項(xiàng);

　　忽略：用戶進(jìn)行忽略操作或不進(jìn)行任何操作;

　　刪除：用戶刪除本消息。

　　3)消息處理后的狀態(tài)需要統(tǒng)一。

　　消息需要標(biāo)記是否已處理的狀態(tài)，且狀態(tài)在不同的終端是打通的。

　　如：用戶在客戶端對(duì)消息進(jìn)行了查看，在web站點(diǎn)本消息應(yīng)自動(dòng)標(biāo)記為已讀狀態(tài)。

　　(四)通知回收

　　回收主要針對(duì)用戶已處理消息的操作。

　　用戶之間觸發(fā)的消息一般需要留檔保存。

　　如評(píng)論/回復(fù)/留言/私信等。產(chǎn)品可提供選項(xiàng)詢問(wèn)用戶是否超過(guò)一定周期自動(dòng)清理。

　　在部分產(chǎn)品中，還需要考慮功能的優(yōu)先級(jí)。

　　如解除好友關(guān)系或加入黑名單后自動(dòng)將刪除雙方的私信記錄。

　　系統(tǒng)觸發(fā)的消息一般設(shè)置一定的回收刪除時(shí)間。

　　如系統(tǒng)提醒、通知、公告等。過(guò)期后自動(dòng)在產(chǎn)品里刪除。物理上可以設(shè)置是否備份。

　　過(guò)期但用戶未處理消息(用戶長(zhǎng)時(shí)間未登錄但收到他人的回復(fù))可以根據(jù)業(yè)務(wù)需求來(lái)處理。

　　如未讀的私信/評(píng)論/回復(fù)永久保留等。重要未讀消息可嘗試二次推送或使用其他途徑(郵箱、APP、短信等)通知。

　　四、通知的交互方式(已讀未讀)

　　注：具體的交互需要考慮本身業(yè)務(wù)特點(diǎn)和目標(biāo)需求。特定業(yè)務(wù)可能需要強(qiáng)調(diào)，某些業(yè)務(wù)又需要考慮騷擾，故拋開(kāi)具體情境本身談交互是無(wú)恥的。

　　這里只針對(duì)一般的社區(qū)網(wǎng)站，描述一下個(gè)人所喜歡的交互方式。

　　1、新消息到達(dá)時(shí)提醒交互

　　當(dāng)新消息到達(dá)時(shí)，可以使用以下提醒方式

　　標(biāo)題閃動(dòng)

　　聲音提醒 新消息到達(dá)后自動(dòng)觸發(fā)聲音

　　氣泡+數(shù)字

　　新消息浮層

　　標(biāo)示提示

　　彈窗 ?

　　2、消息處理

　　目前消息多采用當(dāng)前觸發(fā)、即時(shí)處理類似“所見(jiàn)即所得”的交互方式。 ? 采用此方式的原有主要有： 1、消息通知位于全局導(dǎo)航，訪問(wèn)任何頻道時(shí)都可保證及時(shí)收到新消息; 2、消息在浮層中處理完畢后，用戶可繼續(xù)進(jìn)行之前的操作，不至于造成打擾; 3、因?qū)Ш矫娣e有限，需對(duì)消息種類進(jìn)行統(tǒng)一整理和規(guī)劃;(Facebook的分類為好友請(qǐng)求、私信、通知。) 4、提供歷史記錄(更多、全部消息)的入口(二級(jí)頁(yè)面) 5、標(biāo)記已讀未讀狀態(tài)，處理好消息提醒數(shù)字的關(guān)系 ? 五、防騷擾(打擾) 因消息本身業(yè)務(wù)性質(zhì)，過(guò)多無(wú)用通知?jiǎng)荼貢?huì)造成噪音，打擾到用戶。因此合理設(shè)置消息的通知頻率和渠道，以防早上體驗(yàn)和效率上的損失。 1、提供通知頻率和渠道的管理功能 如常見(jiàn)的郵件退訂管理，消息通知類型管理。 ?

　　Facebook通知設(shè)置 編號(hào) 通知渠道 通知類型 1 在facebook(web) 你參與的動(dòng)態(tài) 2 電子郵件(email) 摯友的動(dòng)態(tài) 3 推送通知(app) 標(biāo)簽 4 短信通知(message) 群組動(dòng)態(tài) 5 應(yīng)用請(qǐng)求和動(dòng)態(tài) 備注：通知渠道和通知類型可以結(jié)合在一起綜合使用。 2、增加屏蔽功能 消息屏蔽功能在業(yè)務(wù)上應(yīng)該屬于第一條中通知類型管理，當(dāng)業(yè)務(wù)模塊較多且之前關(guān)聯(lián)分散時(shí)，或者開(kāi)放平臺(tái)功能接入的第三方應(yīng)用通知時(shí)，可使用屏蔽功能。 ? ?

　　3、結(jié)合權(quán)限體系 1、功能隱私設(shè)置 使用隱私設(shè)置界定具體的接收權(quán)限、范圍等 ? 2、結(jié)合黑名單功能 使用黑名單可屏蔽指定用戶或關(guān)鍵詞的具體消息通知。 ?

　　六、其他

　　1、消息拉回： 當(dāng)用戶長(zhǎng)時(shí)間不登陸或?qū)ο⒉惶幚頃r(shí)，可使用其他渠道推送通知，已達(dá)到拉回的目的。 標(biāo)號(hào) 1 觸發(fā)條件 1)用戶長(zhǎng)時(shí)間不登陸 2 2)長(zhǎng)時(shí)間不處理消息 3 3)主要通知方式失效(被屏蔽或堵塞) 3 4)存在次要的通知方式 4 通知渠道 1)web 5 2)Email 6 3)短信 7 4)APP 8 備注 1)同步已讀未讀狀態(tài) 9 2)拉回進(jìn)行相關(guān)引導(dǎo) 10 3)控制頻率和方式，防止造成騷擾

　　2、私信與webim