網絡故障設計總結

本文原創自news.mkq.online
版權聲明:本文爲原創文章,版權牛站科技所有
轉載請註明http://www.niuzhan.com/keji/

當你正在用微信跟朋友胡侃,在b站看紀錄片,逛虎撲懟skr。這時網絡突然斷掉,我們應該給用戶什麼樣的提示呢?最近因爲自己也在梳理類似的場景,所以這篇文章就來跟大家分享交流一下在網絡故障場景下如何給予用戶合適的提示。

所有的報錯提示/反饋都可以拆解爲兩個部分:報錯現象和解決方案。因此網絡發生故障時我們首先應該告訴用戶您當前的網絡狀態異常,讓用戶感知到這個事實,然後再提供解決方案。

目前來說,常見的報錯樣式有toast、snackbar、對話框、通告欄、界面內嵌與空頁面。最近看了一下自己之前的文章,發現都是基於組件來闡述適用場景。這種解構方式有個問題,那就是現實情況中,產品或者交互設計師都是基於場景去確定合適的組件。因此爲了更方便大家理解,這裏我不具體介紹每個組件的用法,而是以場景來定義來組件。

不提示

首先我們需要明確一個事實:不是每一種網絡故障都需要提示用戶。這裏的“不提示”其實是一個相對的說法,並不是真的不給用戶提示,而是隻有用戶執行了請求數據的操作才告知用戶網絡發生故障。支付寶就是一個典型的例子,即使斷網了,用戶基本也感知不到。只有用戶請求了新數據,纔會以toast通知用戶網絡異常。

支付寶這種高冷也是有底氣的,因爲其多數頁面都有緩存機制,用戶不用每次進入這個頁面都要去服務端請求一遍數據。類似的還有QQ音樂、咕咚,對於這些產品來說斷網並不會帶來災難性的影響。因爲斷網不影響我去聽緩存或下載好的歌曲,也不會影響記錄運動數據。所以對於此類應用來說,當網絡報錯的時候,只要用戶沒有觸發請求數據的操作,沒有必要提示用戶。

當然我們需要給緩存數據設置一個有效期,如果過了那個有效期,網絡還是沒有恢復正常,應該及時提示用戶網絡故障。

無緩存

當然並不是每一個頁面都有緩存,對於沒有緩存數據的頁面,我們有兩種方案。一種是展示空頁面,另一種是展示骨架屏(Skeleton Screen)。

骨架屏顧名思義就是展示頁面的框架,當數據請求完成時再渲染頁面。這種先佔好位置再加載數據的模式也被稱之爲佔位符,都是一個意思。

最後再說空頁面,其實空頁面的展示方案也可以分爲兩種:

1 提供“刷新頁面”按鈕;

2 提供“解決方案”按鈕;

兩種方案都有自己的道理,我個人更傾向於把兩種方案進行融合。展示“刷新頁面”的按鈕,如果用戶點擊了還是沒有辦法請求到數據,這時以snackbar的形式提供解決方案。其實解決方案都是引導用戶去系統設置裏檢查/開通網絡權限。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章