本文主要對(duì)于表象的空白頁產(chǎn)生類型進(jìn)行分析，探求背后相應(yīng)的解決方案。
目錄：
空白頁產(chǎn)生原因
空白頁解決方案
空白頁的產(chǎn)生原因大致可以分為如下三類。Null、弱網(wǎng)斷網(wǎng)、服務(wù)器異常，下面具體的解釋一下三種情況。
Null
這種情況比較常見，用戶在某一模塊的數(shù)據(jù)是空的，比如說我的B站移動(dòng)端，在收藏的話題這一塊，我沒有收藏任何話題，那么這一塊的內(nèi)容，手機(jī)向服務(wù)器請(qǐng)求數(shù)據(jù)，返回來的就會(huì)是一個(gè)空值。
弱網(wǎng)斷網(wǎng)
手機(jī)處于網(wǎng)絡(luò)信號(hào)不好或者沒網(wǎng)的時(shí)候，比如說在地下室或者飛機(jī)上，網(wǎng)絡(luò)信號(hào)沒有，這時(shí)候用戶點(diǎn)進(jìn)去某一個(gè)模塊，還是以B站舉例子，在我沒有聯(lián)網(wǎng)的情況下，進(jìn)行刷新的操作，手機(jī)因?yàn)闆]有網(wǎng)絡(luò)環(huán)境差，無法向服務(wù)器請(qǐng)求數(shù)據(jù)，“手機(jī) -> 服務(wù)器”的鏈路出現(xiàn)問題，也會(huì)出現(xiàn)空白頁的情況。
服務(wù)器異常
這種情況手機(jī)信號(hào)沒有問題，服務(wù)器的端口異常，這塊短時(shí)間不好找出相應(yīng)的案例，服務(wù)器異常的原因可能是由于服務(wù)器在升級(jí)，或者其他一些原因，“服務(wù)器 -> 手機(jī)”的鏈路出現(xiàn)問題，導(dǎo)致數(shù)據(jù)無法從服務(wù)器傳向手機(jī)，同樣會(huì)出現(xiàn)空白頁。
梳理清楚空白頁產(chǎn)生原因之后，我們來看看針對(duì)這些原因，都有哪些處理方式。
Null：用戶在某一模塊的數(shù)據(jù)是空。
這種情況下，會(huì)有兩種處理方式，一種是靜態(tài)的通過文案提示用戶，通過這樣的方式來告知用戶為什么這個(gè)頁面是白的，沒有內(nèi)容，就像剛才展示的B站的樣式那樣(上圖左)，這里沒有什么技術(shù)上或者產(chǎn)品上的問題，只是文案的內(nèi)容上會(huì)有區(qū)別。
另一種方式是引導(dǎo)用戶的行為，如上圖右展示，在知乎的個(gè)人中心 – 我的創(chuàng)作- 專欄頁面，我目前還沒有申請(qǐng)專欄，所以會(huì)產(chǎn)生空白頁，產(chǎn)生原因是null，知乎也和B站一樣，給了文案提示：還沒有內(nèi)容;同時(shí)給了一個(gè)申請(qǐng)專欄的入口，去引導(dǎo)用戶的操作。引導(dǎo)用戶這樣的解決方案可能是通過用戶反饋一步一步迭代出來的，用戶在瀏覽到專欄這一步的時(shí)候，有申請(qǐng)專欄的訴求，知乎的產(chǎn)品同學(xué)于是乎就在文案提示的基礎(chǔ)之上，設(shè)計(jì)了這樣的一個(gè)申請(qǐng)入口。
這里我們總結(jié)一下針對(duì)于null的解決方案，很顯然引導(dǎo)用戶是在文案提示的基礎(chǔ)之上通過產(chǎn)品迭代出來的，我猜測(cè)在文案提示之前，最早還會(huì)有一種更簡單的呈現(xiàn)形式，那就是完全空白放在那里，因?yàn)橛脩舻臉O大困惑，完全的空白讓用戶不知道是什么原因而產(chǎn)生的空白頁，才會(huì)出現(xiàn)的文案提示，在現(xiàn)網(wǎng)上應(yīng)該很少能看見純白的空白頁了我認(rèn)為。
文案提示的解決方案，最重要的就是內(nèi)容的呈現(xiàn)，要能通過文字或者圖形，明確地告知用戶是什么原因才產(chǎn)生了空白頁;其次就是文案及圖形的特色，對(duì)比知乎和B站兩個(gè)風(fēng)格截然不同的app，他們的文案及圖形都遵循了自己app的特色，知乎是知識(shí)分享的平臺(tái)，走嚴(yán)謹(jǐn)風(fēng);B站充斥著00后、95后、彈幕，走的是二次元的風(fēng)格。
再談一下引導(dǎo)用戶，這個(gè)功能要根據(jù)不同的模塊因地制宜，拿知乎舉例子，如果用戶的關(guān)注列表是空的，設(shè)置這樣的一個(gè)引導(dǎo)功能，讓用戶去關(guān)注一些KOL，對(duì)于促活及留存都是很有必要的。但是如果用戶的余額是空的，為零，這時(shí)候再引導(dǎo)用戶去充值，就顯得有點(diǎn)畫蛇添足了。
弱網(wǎng)斷網(wǎng)、服務(wù)器異常
弱網(wǎng)斷網(wǎng)、服務(wù)器異常，籠統(tǒng)的都可以概括為網(wǎng)絡(luò)的異常，這兩個(gè)的解決方案通常是相同的?，F(xiàn)網(wǎng)上對(duì)于網(wǎng)絡(luò)異常的解決方案如下流程圖
當(dāng)從服務(wù)器請(qǐng)求失敗的時(shí)候，無論是“手機(jī) -> 服務(wù)器”鏈路出現(xiàn)問題，還是“服務(wù)器 -> 手機(jī)”鏈路出現(xiàn)問題，都會(huì)首先訪問緩存，看看緩存有沒有該數(shù)據(jù)的緩存，若是有，展示緩存，若沒有，則展示相應(yīng)的文案提示。
最終落地到頁面，會(huì)有兩種展示形式，一是文案提示(下圖左)，二是在緩存的基礎(chǔ)上用toast提示用戶(下圖中、下圖右)。
對(duì)于哪些頁面會(huì)有本地的緩存，這里也要有注意，我們應(yīng)該把常用的頁面緩存在本地，對(duì)于不經(jīng)常用到的頁面，每次點(diǎn)開都要請(qǐng)求服務(wù)器的數(shù)據(jù)，這樣會(huì)最大限度的減少app的內(nèi)存占用。
雖然弱網(wǎng)斷網(wǎng)、服務(wù)器異常都可以歸結(jié)于網(wǎng)絡(luò)異常，但是二者的產(chǎn)生原因并不相同，用戶通過自己的操作解決空白頁的方法也就不同，弱網(wǎng)斷網(wǎng)可以人為的尋找更好地網(wǎng)絡(luò)，但是服務(wù)器異常的情況，用戶無論進(jìn)行什么操作，都無法改變現(xiàn)狀。
在這里的文案提示或者toast提示，文字信息一定要準(zhǔn)確的反映出問題的原因，比如說上圖左的文案提示，寫的就很模糊，加載失敗的原因既可以是斷網(wǎng)，也可以是服務(wù)器異常，用戶看見這個(gè)文案，在不知道他自己的網(wǎng)絡(luò)環(huán)境的情況下，用戶很可能做的是一遍一遍的刷新，但由于網(wǎng)絡(luò)產(chǎn)品的空白頁，刷新是無濟(jì)于事的，這樣不明確的文案大大增加了用戶操作的成本，不友好。
反觀中圖的文案，電波無法到達(dá)哦，雖然扎眼也無法理解，但是再讀一遍可以理解出來其中的意思，至少文案是沒有歧義的。
這里推薦右圖的文案，文案提示清晰明了，雖然提示框的形式是toast，但是他的字段內(nèi)容的指令性已經(jīng)和須知差不多了。
再說一下服務(wù)器異常的文案提示，我認(rèn)為也是有必要向用戶告知實(shí)際情況，雖然部分用戶不理解服務(wù)器異常是什么鬼，但也不能用網(wǎng)絡(luò)異常這樣的模糊字眼，可能靠譜的文案“服務(wù)器異常，您可能需要安靜的等待片刻”，至少不會(huì)讓用戶盲目的刷新或者重連網(wǎng)絡(luò)。
我在這個(gè)模塊有兩種功能性的設(shè)想，一是提示框的選取，對(duì)于這種必要進(jìn)行的操作(若不采取措施就無法使用產(chǎn)品)，我認(rèn)為是可以用須知或者選擇這樣的提示形式的。
上圖是我設(shè)想的一種弱網(wǎng)斷網(wǎng)的解決方案(隨手畫的線框圖，不要太嫌棄)，用強(qiáng)烈一些的提示框，選擇的方法進(jìn)行提示，讓用戶意識(shí)到弱網(wǎng)斷網(wǎng)會(huì)影響到自己的產(chǎn)品體驗(yàn)，點(diǎn)擊知道了返回到緩存界面，點(diǎn)擊去設(shè)置，跳轉(zhuǎn)到用戶的設(shè)置界面，去手動(dòng)更改網(wǎng)絡(luò)選擇。這樣的解決方案我認(rèn)為可以減少用戶操作的成本，也更人性化。
空白頁的產(chǎn)生方式會(huì)有很多，解決處理的方法也是五花八門，但是最精髓的一點(diǎn)，我認(rèn)為要從用戶的角度出發(fā)，空白頁展示出來的瞬間，用戶是困惑的，產(chǎn)品要解決的問題實(shí)際上是明確地告知用戶原因，并且可能的去引導(dǎo)用戶去改變這樣的情況。
以上就是類似于咪咕愛看APP設(shè)計(jì)經(jīng)驗(yàn)總結(jié)的內(nèi)容，如果想要了解關(guān)于建網(wǎng)站的基礎(chǔ)知識(shí)及手機(jī)建站教程，可直接點(diǎn)擊查看
