移動互動設計案例:用戶端APP的通知系統設計

來源:互聯網
上載者:User

文章描述:本文只梳理設計原則,後續相關內容會持續更新。 這裡的通知包括但不限於公告、提醒或訊息(不同使用情境下的功能定義不同)。 關於各用戶端平台(ios、android、wp等)的通知機制,在其互動設計指南中有更詳細的說明,大家可自行參考。

寫在前面: 通知系統是網站資訊傳播機制的重要的一部分,足夠寫一大章來說明。本文只梳理設計原則,後續相關內容會持續更新。 這裡的通知包括但不限於公告、提醒或訊息(不同使用情境下的功能定義不同)。 關於各用戶端平台(ios、android、wp等)的通知機制,在其互動設計指南中有更詳細的說明,大家可自行參考。

一、通知系統定義

通知系統,顧名思義即通知資訊的傳達處理系統。目的是為了讓使用者獲得需要得到的訊息及提醒並進行處理。

這裡的“需要得到”有兩層意思: 1、使用者彼此互動觸發的資訊流(留言、評論或者回複、私信等) 2、網站希望使用者瞭解關注的資訊(系統公告等)

通知系統設計的原則可簡單的歸納為: 1、訊息傳播效率最高(擷取、處理、資訊傳達、使用者反饋等效率) 2、避免產生騷擾(噪音、頻繁提示)

二、通知分類

不用的平台和產品本身由於對業務的需求不一樣,種類也是有區別的。
大致可分為以下幾種:

三、通知邏輯實現機制

通知的邏輯精簡後如下:

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

(一)通知合并

通知在推送之前需要進行匯總合并,目的在於提高訊息傳播處理效率;減少騷擾,降低噪音;平衡伺服器壓力。

1)合并周期:
  固定時間內的訊息全部匯總(24小時內/30天等);
  無固定時間(只要未處理/未讀即匯總)
  當然一般都組合著用:合并24小時內未處理訊息

2)分類合并
  同種類進行合并(如n條留言合并為1條)
  同一發起人合并(如張三給你發來的n條私信)
  同一時間周期合并(如24小時共收到n條評論)

(二)通知分發

通知按照規則匯總完成後,系統將其通過通知管道推送到使用者,以便使用者處理。

1)分發方式

分發方式與Feed系統類別似,多採用Push方式,即在指定時間內主動推送給使用者。部分特定類型需要使用者請求(Pull)拉取未讀訊息。

  目前大部分通知優先推送未處理通知合并後的總數,已提醒使用者已有新訊息需要處理。使用者點擊數字後再去服務端請求具體的訊息內容。此種方式綜合考慮了成本、壓力和體驗。當然,某些極端情況下需要進行最佳化處理:如未讀訊息超過1000,使用者請求時先推送前50條或者放入cache中等。技術童鞋會有各種手段,這裡不做詳述。

2)分發頻率(時間)

分發時間主要根據訊息的優先順序來做區隔:

3)分發管道

分發管道即訊息通知的具體推送渠道,根據業務類型可以分為:Web、App、簡訊、郵件等。

(三)使用者處理

根據前文提到的分發方式,對於通知的處理在邏輯上可以分為兩層:通知狀態的處理和通知內容的處理。

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

  通常初始數字即為系統推送過來的未讀總量,使用者點擊數字進入相關功能列表查閱後,讀取的動作完成,未讀數字相應減少。

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

  若使用者未讀資訊較多(m=100),但第一頁列表只能顯示(n=10)條的話,那未讀數字即為m-n=90;
  某些產品會將點擊等同於已讀。即使用者只要點擊無論是否開啟列表查看均認為已讀。
  這樣的處理一般用於重要層級較低的訊息。點擊即已讀可有效降低騷擾。
  某些重要層級較高的訊息已處理狀態可以定義為使用者進行相關操作後才為已處理,而非查閱。
  如使用者進行評論、回複、點擊忽略或點擊刪除等動作時才認為已處理。

2)內容的處理狹義的理解即為使用者是否操作。

  根據不同訊息的種類和業務的需要,操作可分為:
  處理:使用者必須點擊功能連結進行處理。如:你的密碼過於簡單,點此進行修改;
  回複:如回複私信,對評論進行回複;
  確認:對訊息做出確認的反饋,如某些系統提示可設定”我已知道,不再提示”的選項;
  忽略:使用者進行忽略操作或不進行任何操作;
  刪除:使用者刪除本訊息。

3)訊息處理後的狀態需要統一。

  訊息需要標記是否已處理的狀態,且狀態在不同的終端是打通的。
  如:使用者在用戶端對訊息進行了查看,在web網站本訊息應自動標籤為已讀狀態。

(四)通知回收

  回收主要針對使用者已處理訊息的操作。
  使用者之間觸發的訊息一般需要留檔儲存。
  如評論/回複/留言/私信等。產品可提供選項詢問使用者是否超過一定周期自動清理。
  在部分產品中,還需要考慮功能的優先順序。
  如解除好友關係或加入黑名單後自動將刪除雙方的私信記錄。
  系統觸發的訊息一般設定一定的回收刪除時間。
  如系統提醒、通知、公告等。到期後自動在產品裡刪除。物理上可以設定是否備份。
  到期但使用者未處理訊息(使用者長時間未登入但收到他人的回複)可以根據業務需求來處理。
  如未讀的私信/評論/回複持續保留等。重要未讀訊息可嘗試二次推送或使用其他途徑(郵箱、APP、簡訊等)通知。

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

註:具體的互動需要考慮本身業務特點和目標需求。特定業務可能需要強調,某些業務又需要考慮騷擾,故拋開具體情境本身談互動是無恥的。

這裡只針對一般的社區網站,描述一下個人所喜歡的互動方式。

1、新訊息到達時提醒互動

當新訊息到達時,可以使用以下提醒方式

標題閃動

聲音提醒 新訊息到達後自動觸發聲音

氣泡+數字

新訊息浮層

標示提示

彈窗 

2、訊息處理

  目前訊息多採用當前觸發、即時處理類似“所見即所得 (WYSIWYG)”的互動方式。  採用此方式的原有主要有: 1、訊息通知位於全域導航,訪問任何頻道時都可保證及時收到新訊息; 2、訊息在浮層中處理完畢後,使用者可繼續進行之前的操作,不至於造成打擾; 3、因導航面積有限,需對訊息種類進行統一整理和規劃;(Facebook的分類為好友請求、私信、通知。) 4、提供記錄(更多、全部訊息)的入口(二級頁面) 5、標記已讀未讀狀態,處理好訊息提醒數位關係  五、防騷擾(打擾) 因訊息本身業務性質,過多無用通知勢必會造成噪音,打擾到使用者。因此合理設定訊息的通知頻率和渠道,以防早上體驗和效率上的損失。 1、提供通知頻率和渠道的管理功能 如常見的郵件退訂管理,訊息通知類型管理。 

  Facebook通知設定 編號 通知渠道 通知類型 1 在facebook(web) 你參與的動態 2 電子郵件(email) 摯友的動態 3 推播通知(app) 標籤 4 簡訊通知(message) 群組動態 5 應用請求和動態 備忘:通知渠道和通知類型可以結合在一起綜合使用。 2、增加屏蔽功能 訊息屏蔽功能在業務上應該屬於第一條中通知類型管理,當業務模組較多且之前關聯分散時,或者開放平台功能接入的第三方應用通知時,可使用屏蔽功能。  

3、結合許可權體系 1、功能隱私權設定 使用隱私權設定界定具體的接收許可權、範圍等  2、結合黑名單功能 使用黑名單可屏蔽指定使用者或關鍵詞的具體訊息通知。 

六、其他

  1、訊息拉回: 當使用者長時間不登陸或對訊息不處理時,可使用其他渠道推播通知,已達到拉回的目的。 標號 1 觸發條件 1)使用者長時間不登陸 2 2)長時間不處理訊息 3 3)主要通知方式失效(被屏蔽或堵塞) 3 4)存在次要的通知方式 4 通知渠道 1)web 5 2)Email 6 3)簡訊 7 4)APP 8 備忘 1)同步已讀未讀狀態 9 2)拉回進行相關引導 10 3)控制頻率和方式,防止造成騷擾

  2、私信與webim



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。