善用Axure寫PRD,2種模式6種方法解析頁面加載邏輯
有些APP的頁面經常容易出現一直轉菊花、等很久才能看到內容、圖文顯示錯位等問題,這其實是沒有妥善的設計頁面加載邏輯。本文詳解了頁面加載的2種模式和7種方法,相信對初級PD有一定啟發。
頁面加載模式
頁面加載主要有2種模式,默認是第2種,除非PD特殊說明。
- 先獲取數據再顯示頁面(預先加載下一個頁面數據,點擊后立即顯示下一個頁面的所有內容。)
- 先顯示頁面再獲取數據(點擊某個按鈕立即進去下一個頁面,然后再獲取所有控件的數據。)
頁面加載方法
以下頁面加載方法可以單獨使用,也可以混合使用。
整體加載
需要注意的是,如果該頁面是H5實現,邏輯也是相似的。
- 定義:加載完所有內容后,再展示給用戶看
- 作用:能保證內容的整體性,能系統化的閱讀所有內容。
- 交互:顯示在頁面中央,先顯示”加載中toast”,同時客戶端拉取數據,全部拉取成功后再隱藏”加載中toast”,如果拉取失敗則顯示”失敗toast”。
- 場景:某些重要頁面,比如購物車
- 注意:可能有強烈的等待感,當超過3s后讓用戶產生焦躁。
分塊加載
- 定義:根據資源類型進行先后加載。文字→圖片→語音→視頻封面→其他資源
- 作用:可以幫助用戶快速閱讀內容。
- 場景:文章閱讀頁、新聞詳情頁
- 注意:也許會丟失掉重要的關鍵信息,無法建立信息獲取的閉環。
需要注意的是,分塊本身就有先后加載邏輯。
整頁加載
- 定義:當前頁與下一頁是整頁切換的時候,可以采用整頁加載的形式。
- 作用:能保證每個頁面的完整性,體驗比較順暢。
- 場景:全屏查看多圖
- 注意:不好保證整頁的加載效率,且有可能影響瀏覽的流暢度。另外每個頁面的數據量不能很大。
分頁加載
- 定義:展示列表數據的時候,比如默認展示20條,滾動到最后的時候自動再加載20條或者手動點擊加載。
- 作用:把用戶代入無盡瀏覽模式,讓用戶一直向下滾動,不需要手動點擊下一頁。
- 場景:列表頁,比如Pinterest的首頁瀑布流
- 注意:沒有盡頭,容易迷失,不方便快速索引定位到某個內容。另外加載方式可選自動和手動點擊2種。
分屏加載
- 定義:先加載框架和文字,再加載第一屏數據,向下滾動到哪里加載到哪里。
- 作用:可以幫助用戶快速閱讀內容。
- 場景:多屏并且數據較大的頁面,比如h5電商活動頁
- 注意:也許會丟失掉重要的關鍵信息,無法建立信息獲取的閉環。
智能加載
- 定義:非WIFI網絡下,只加載內容框架以及文字,圖片視頻等只顯示占位符。點擊占位符,才去獲取真實圖片。WIFI網絡下,初始加載所有資源。
- 作用:根據具體場景來控件流量和加載速度。
- 場景:數據量比較大的頁面,比如優酷的視頻詳情頁
- 注意:不一定真實有效的命中用戶需求。
WIFI預先加載
- 定義:有WIFI的時候預先加載常用數據,緩存到本地,當沒網的時候,直接加載已經緩存下來的內容。使用了預加載+離線緩存機制。
- 作用:解決了沒網獲取數據的問題,且節約了流量。
- 場景:小說閱讀App、視頻類App。
- 注意:占用本地存儲空間,有時候預加載的內容最后用戶沒看。
最后
大家可以根據自己的業務需求,選擇適合自己的頁面加載模式和加載方法。
當然最好是在APP剛創建的時候去從全局的角度來定義該規則,其次重構客戶端的時候也可以,平常只適合修改單個頁面的規則。
相關閱讀
#專欄作家#
浪子,公眾號langzishuo,人人都是產品經理專欄作家。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
評論
收藏,以后做APP會用到。
哦。我知道了。后文里有寫
“先獲取數據再顯示頁面(預先加載下一個頁面數據,點擊后立即顯示下一個頁面的所有內容。)
先顯示頁面再獲取數據(點擊某個按鈕立即進去下一個頁面,然后再獲取所有控件的數據。)”
這兩種頁面加載方法各有什么利弊嗎?如果技術上實現難度都一樣,看上去第一種對用戶來說應該加載更快些,
各有利弊,各有使用場景。
比如后者更適合H5場景。前者適合加載很重要的頁面。
流程圖那里,當有預加載,無網絡的情況下,是否也能顯示緩存數據頁面?
如果定義了緩存。那么如果預加載成功,然后沒網絡了??梢蕴D到新頁面,顯示緩存數據。
但是我覺得一般不會這樣設計,可能會直接設置成預加載成功才能進入新頁面,同時必須網絡正常。
絕對干貨,謝謝大神的無私分享!
真心覺得很棒,感謝分享
分頁加載的自動和手動分界沒有很明顯,自動那種也是人為觸發的,其實本質還是手動,只是操作方式不同,一個是上拉加載,另一個是點擊加載。
是的,但是業務上是兩種。