APP中的加載類型梳理與應(yīng)用場景分析

m
6 評論 18157 瀏覽 178 收藏 14 分鐘

文章針對APP的幾類加載狀態(tài)展開分析,希望能夠?qū)δ阌兴鶐椭?/p>

我們產(chǎn)品各模塊的加載樣式全部由開發(fā)自己定,結(jié)果是百花齊放,各有各的用法,前階段被領(lǐng)導(dǎo)噴了一頓。關(guān)于加載這一塊,交互規(guī)范恰好缺失,于是交互開始嘗試梳理相應(yīng)規(guī)范。本文梳理時,我查看了相關(guān)文章,我們部門也組織了討論,但感覺并沒有完全解決我的疑惑,于是在其基礎(chǔ)上重新組織,擴展了一些,也咨詢了一些前后端同學(xué),本文算是我階段性的梳理結(jié)果,拿出來和大家討論,期待完善。

加載是什么

加載是一種反饋狀態(tài),常見樣式有菊花、進度條等。用戶與產(chǎn)品的每一次互動都需要反饋,用戶依賴反饋信息,才能順利完成連貫的操作。用戶在等待反饋結(jié)果時,焦急專注的盯著界面,這時,系統(tǒng)需要告訴用戶“hi,我還活著,正在努力干活呢,別走!” 下圖摘自 Ant Design :

什么時候使用

“1s是對話中可以有的最長間隔,又因為交互系統(tǒng)的操作是一個對話的形式,所以交互系統(tǒng)應(yīng)該避免自己一方的長時間間隔,否則用戶會懷疑發(fā)生了什么。系統(tǒng)有1s的時間去執(zhí)行用戶要求做的任務(wù)或者標志出操作需要多少時間,要不然用戶會失去耐心”——摘自《認知與設(shè)計》

結(jié)合上面這句話,關(guān)于何時使用,我這么理解:如果系統(tǒng)1s內(nèi)就能完成任務(wù),可以不給加載圖標,如果系統(tǒng)1s內(nèi)不能完成任務(wù),則需要在1s內(nèi)彈出加載中的提示。

加載的邏輯

討論加載類型前,先梳理一下加載的邏輯,這有利于我們理清楚各種加載的關(guān)系??v軸為時間(請忽略圖的配色,盡力了?_?)

客戶端接收到用戶操作后,向服務(wù)端發(fā)送請求,服務(wù)端響應(yīng)然后返回數(shù)據(jù),客戶端把數(shù)據(jù)翻譯成用戶看的懂的元素。用戶從執(zhí)行操作后就一直在等待結(jié)果??蛻舳藦陌l(fā)送到接收到數(shù)據(jù)這段時間在等待結(jié)果。比較耗時的是發(fā)送接收數(shù)據(jù)以及渲染展示的環(huán)節(jié)。服務(wù)器查找時間取決于服務(wù)器性能和存儲等;發(fā)送耗時受網(wǎng)絡(luò)影響;渲染展示時間取決于前端和機器性能,知道這些,就可以對癥下藥了,誰家的孩子,誰拎回去修理,交互能做的就是配和他們的方案,選擇合適的方式,做好對用戶的宣傳。

用戶等待時容易焦慮,用戶正看著屏幕呢,于是各種加載,各種轉(zhuǎn)移注意力就上場了,穩(wěn)住用戶,別讓他離開。

  • 第一件事:告訴用戶我在工作,沒有偷懶。
  • 第二件事:轉(zhuǎn)移用戶注意力,減少用戶等待的焦慮感,可以看看漂亮有趣的加載動畫,或者瀏覽歷史的加載內(nèi)容等。

模態(tài)加載與非模態(tài)加載

模態(tài)加載

模態(tài)加載屬獨占姿態(tài),會阻斷用戶的其他操作,加載時,用戶只能眼睜睜等待。屬強勢女魔頭,老娘最美,看我;模態(tài)加載簡單粗暴,也最容易實現(xiàn),但對用戶來說卻不友好。就像點餐一樣,服務(wù)員非要等到所有菜都做好了才給端上來,客人很可能直接走人了。

模態(tài)加載一般形式是浮在頁面上的旋轉(zhuǎn)菊花,也可以根據(jù)自己品牌設(shè)計具有特色和情調(diào)的加載樣式,我們就是因為樣式混亂被領(lǐng)導(dǎo)批。

何時使用

模態(tài)加載體驗不佳,但它有其合理性和不可替代性,我根據(jù)收集的頁面,粗略歸納了幾類,應(yīng)該沒有覆蓋完全,關(guān)于技術(shù)方便的描述也不準確,歡迎留言補充和指正

1 加載的內(nèi)容必須一起呈現(xiàn)出來,否則會出問題,可能是功能未準備完全,不能夠使用,少給開發(fā)哥哥找麻煩;也可能因為丑,必須色香味俱全加雕花都做好。具體細節(jié)還需要跟開發(fā)同學(xué)仔細溝通。

2 舊命令正在處理中,當前不允許你再修改請求。如圖2的微信發(fā)紅包,系統(tǒng)正在處理發(fā)1元紅包的請求,正在準備支付頁面。此時不允許你修改金額,否則我當前處理的1元怎么辦?我魚都給你紅燒了,你突然要清蒸。如果很多人都頻繁的修改、提交,系統(tǒng)的壓力應(yīng)該會很大、也浪費了資源。這時候的模態(tài)是綜合考量后的合理處理方式。

3 初次加載,不知道結(jié)果去哪里,頁面長什么樣。如圖3,系統(tǒng)正在發(fā)送請求,還沒有收到服務(wù)器返回的數(shù)據(jù),客戶端頁不知道最終傳來的是什么。此刻用戶面對空空的頁面也確實沒有其他的事可做,此刻的模態(tài)加載可以接受,但如果請求進行時,當前頁面有內(nèi)容,且用戶操作不會對剛才請求造成影響時,需要使用非模態(tài)的加載。

如上圖,空頁面第一次加載時,使用模態(tài)加載;頁面返回數(shù)據(jù)后,再次加載則使用了非模態(tài),細分場景,體驗很舒服。

注意,如果模態(tài)加載時間較長,需要給出加載進度,長時間加載,用戶可能以為界面死了,不知道進度也會失去耐心

非模態(tài)加載

非模態(tài)加載,比較溫和,你繼續(xù)做你的事,同時我加載你要的東西,準備好了就給你。在某個角落,不干擾你做事,又不離開你視線,貼心小棉襖。讓用戶在等待的時候有事可做,不用干等,緩解用戶等待的焦慮。

何時使用

如上文提到的,當前頁面有數(shù)據(jù),用戶有事可做,且用戶行為不會影響到原來的加載請求,這時候適合使用非模態(tài)加載。常見的有上拉加載、下拉加載。加載的提示信息可以放在頁內(nèi),狀態(tài)欄 、操作欄等,位置比較靈活

非模態(tài)的加載方式,一定成都減輕了在當前頁面有內(nèi)容時,用戶的等待焦慮;在空頁面加載時效果不理想。還能再優(yōu)化一些?程序員那里還有更高階的方法。為了減少用戶感知的等待時間,系統(tǒng)可以盡早的向用戶展示信息。

Skeleton Screen/加載占位圖

還是用點餐的例子,去餐廳點餐,你點的是套餐,這就很舒服了,服務(wù)員、廚師都套餐的流程,菜品都非常熟悉。菜還沒開始做,就可以先把紅酒、蠟燭、刀叉給你擺好了。頁面也是,當用戶請求的頁面布局,我們已知時,可以先在頁面加載占位圖,等到數(shù)據(jù)回來后再陸續(xù)的填進去,給用戶加載很快的感覺。

如下圖,餓了么h5,先加載頁面布局,這時候數(shù)據(jù)還沒有返回,界面已經(jīng)開始響應(yīng)。

何時使用

Skeleton Screen 適合內(nèi)容排班比較固定或排版布局已知的頁面,先加載大致輪廓,再加載細節(jié)。使用競品時發(fā)現(xiàn),有些產(chǎn)品發(fā)布了新版本,占位圖卻沒做更新,導(dǎo)致加載前后有閃屏的感覺。所以,布局未知,布局多變的頁面,不要使用。

懶加載

當用戶請求的頁面包含大量內(nèi)容,如文本、圖片、音視頻等,全部渲染完成需要較長時間。懶加載就像餐廳服務(wù)員一樣,把菜一個一個的送給用戶,懶加載解決的是客戶端渲染展示給用戶這一環(huán)節(jié)。

從圖上看,懶加載進步一壓縮了用戶的等待時間,用戶不必等到頁面全部加載完成就可以開始閱讀(一些工具類頁面,懶加載過程不允許操作或操作無響應(yīng)),減少用戶的等待焦慮。對客戶端而言,原來3s要加載完的內(nèi)容可以拖到5s分批給,減輕了壓力。如果用戶不喜歡中途離開了,剩下的內(nèi)容可以不用渲染,少干了不少活。

懶加載的實現(xiàn)方式(摘自http://www.jianshu.com/p/4876a4fe7731

  1. ?延遲加載,比如先加載文字再加載圖片
  2. 條件加載 即符合某些條件,或者觸發(fā)了某些事件才開始異步下載
  3. 可視區(qū)域加載,僅加載用戶可以看到的區(qū)域,不可見區(qū)域不加載,當該區(qū)域可見后再加載

如下圖示例,今日頭條先加載文字,后加載圖片;高德地圖可視區(qū)域外的區(qū)域等到用戶滑動屏幕時才加載,節(jié)省流量。

綜上,懶加載更像是打著緩解用戶等待焦慮的旗號,客戶端偷懶的方法。

預(yù)加載

懶加載將原來5秒全部加載完成優(yōu)化到了2秒就可以提供部分內(nèi)容,但用戶說別人家瞬間就加載完了,你還要拖拖拉拉,5s才能加載完!這又是什么黑科技。

再看這張圖,預(yù)加載是更貼心的小棉襖,會揣摩用戶的心思,偷偷提前做準備。用戶在看A頁面時,客戶端就在準備用戶可能會看的B頁面,用戶需要時,立刻給他,然后去準備C頁面,給用戶提供無縫鏈接的感覺,代價就是服務(wù)端、客戶端都累的夠嗆,耗費用戶更多的流量。預(yù)加載一直走在用戶前面,勤快、周到。懶加載一致等待用戶發(fā)號施令,是真的懶。

如下圖,刷新今日頭條列表,詳情頁就已經(jīng)開始準備了。此刻切換飛行模式,點開文章詳情,能看到文字已經(jīng)顯示在那里了,為什么沒有圖片?機智的程序員為了給用戶省流量,確認用戶點開后才開始請求圖片。

綜上,為了能讓頁面加載流暢,達到最好的使用體驗,需要結(jié)合產(chǎn)品和場景組合使用加載方式,文中舉例的產(chǎn)品都不止使用了一種加載手段。具體實現(xiàn)方案還需要結(jié)合自己的產(chǎn)品和場景來確定。

 

本文由 @m 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 剛好解決了我的困惑,感謝分享~~

    來自北京 回復(fù)
  2. 總結(jié)的不錯~學(xué)習(xí)啦

    來自江蘇 回復(fù)
  3. 666

    來自上海 回復(fù)
  4. 核心就幾點:1為什么等待 2什么時候需要展示進度什么時候不要進度3通過交互減少用戶焦慮

    來自四川 回復(fù)
  5. 不錯不錯!

    回復(fù)
  6. 學(xué)知識,贊一個

    回復(fù)