從文章「收藏」的前後端交互過程談起

用戶在收藏之後，都會通過收藏夾再次訪問，無論有沒有對收藏夾進行細分。那麼用戶在使用過程就會關注「收藏有沒有成功 」，因而需要在交互過程中明確地告知用戶其收藏行為成功與否。反觀「點贊」，一般是用來表示認同或者批示「已閱」，對於對方有沒有確確實實收到這個「贊」，不會過於在意。除了那些有「我贊過的文章」，那個其實把點贊當作極簡的收藏夾來用。

換句話說，「收藏」是索取行為，「點贊」是給予行為。「收藏」與用戶自身利益的相關性明顯比「點贊」要強。

收藏文章的整個通信過程可以簡單概括為：

1. 客戶端發生用戶點擊收藏按鈕的事件
2. 客戶端將收藏請求（收藏哪篇文章、何時收藏的等等）發送到伺服器
3. 伺服器將相應信息保存到資料庫
4. 伺服器告知客戶端收藏成功
5. 客戶端告知用戶收藏成功（按鈕狀態變化、toast等）

當然收藏時間也可能會以伺服器收到請求或者收藏成功的時間為準，這類細節不展開討論。

在上面這個方案中，用戶和設備的交互過程中主要是等待客戶端與伺服器完成通信，而客戶端與伺服器通信存在較大的異數，或快或慢，或者成功或者失敗，或者不知道成功失敗（超時未返回數據）， 於是就需要設計好客戶端這個通信過程中的「配角」，既要反饋告知用戶當前的狀況，還能主動避免一些可能發生的錯誤。

上面所寫的主要流程，每一步都會遇到異常，進而觸發分支流程。一般由於設備原因導致的比較好處理，比如：

• 伺服器收到請求後，超時沒有回復：提示操作超時
• 無法與伺服器通信（網路問題或其他原因）：提示網路有問題
• 伺服器異常，導致保存相應信息失敗，回復客戶端收藏失敗：提示收藏失敗，過會兒可以重新試試
• 伺服器在保存相應信息時發現已經有類似的信息了（較少見，一般由多個設備登錄導致）：提示收藏成功

而由用戶行為觸發的分支流程，則需要進行細心的考量和設計，常見的異常情況：

• 用戶在通信過程中多次點擊收藏
• 用戶在通信完成之前點擊了退出或者關閉了App
• 用戶在收藏的通信過程中又點了評論或者又點了贊

為了儘可能減少讓用戶犯錯的機會，可以考慮在通信過程阻止用戶的操作，例如使用類似jQuery BlockUI的效果。澎湃新聞客戶端使用的就是這種方法，彈出一個模態的載入動畫，直到通信完成。

然而BlockUI的方法雖然避免了問題的發生，但卻對用戶造成了比較大的干擾，影響了使用體驗。尤其是當網速較快時，就會發生「閃屏」的不良體驗。

思考的再深入一點，結合具體的使用場景，用戶多次點擊收藏的原因可能是程序比較慢，用戶以為自己沒點到或者乾脆手抖、手指乾燥沒有電荷；而在收藏成功之前就退出或關閉App說明用戶當前已經放棄了收藏操作；直接去評論或者點贊說明對文章的關注度又加深了。

根據這些分析，可以針對每種分支流程做更細緻的設計：

• 用戶在通信過程中多次點擊收藏：使用非模態的通信中提示，如原位的載入動畫，避免多次點擊重複提交取消收藏

圖片來源：https://dribbble.com/shots/1426764-Submit-Button

• 用戶在通信完成之前點擊了退出或者關閉了App：中斷通信，向伺服器發送撤回收藏的請求
• 用戶在收藏的通信過程中又點了評論或者又點了贊：並行處理

設計到這裡，貌似已經優化了不少了。但是呢，上面提到的這一整套流程在網路狀況不佳時，就會讓用戶感覺程序反應比較慢，在體驗上還是有所欠缺。為了極致的用戶體驗，可以這麼搞：

1. 客戶端發生用戶點擊收藏按鈕的事件
2. 客戶端告知用戶收藏成功
3. 客戶端將收藏請求（收藏哪篇文章、何時收藏的等）發送到伺服器
4. 伺服器將相應信息保存到資料庫
5. 伺服器告知客戶端收藏成功，如果沒成功或者超時那就再發一遍請求

這樣一來用戶用起來就會非常爽了。在用戶看來，程序的反應非常快，「一點也不卡」。有人把這種設計方法總結成了「樂觀派」設計，倒是很形象，因為我們總是假設操作一定成功。不足之處是不太穩定，如果網路不好可能會造成數據丟失，直白的說法就是明明收藏成功了，去收藏夾找卻根本找不到。也就是說，不適用於跟用戶關係比較大的「收藏」，相比之下「點贊」更適合這種方式。

舉個例子，知乎App的「感謝」就是這麼搞的：不管有沒有網，點了「感謝」直接變成「已感謝」，如果退出後再進入，會發現這個「已感謝」就又變成「感謝」了，也就是數據丟失了。

不過，如果我們想想辦法，是可以利用App本地緩存實現更安全的樂觀派設計的：

1. 客戶端發生用戶點擊收藏按鈕的事件
2. 客戶端將相應信息保存在本地的資料庫中
3. 客戶端告知用戶收藏成功
4. 客戶端在後台悄悄將本地資料庫上傳到伺服器

這樣設計的好處就是，在沒網的情況下也能完成離線收藏（離線操作需要告知用戶）。壞處是不適用於有多端同步需求的場景，比如類似雲筆記、雲閱讀這種具有手機上標記、平板上閱讀的跨設備應用場景。同時App前端的開發量也比較大。對於有離線使用場景的App來說，是比較好的一種選擇。

但是如果採用了這種實現方案，那麼應用場景就會廣泛很多，將不只局限於收藏。比如悅跑圈跑完步之後，會提示「保存並上傳」，如果沒有網路，就會先保存在本地，等有網了再上傳，在戶外跑步甚至野外跑步的場景下非常適用。

______________________________

微信公眾號：DesignGB

關於互聯網產品設計，以及一些奇怪的東西