最近做的一個需求，有客戶反饋想把B端的表格，由滾動式加載改爲分頁加載。除了大家知道的明顯的一些體驗、內容差異，結合最近做的一些表單的小需求，做了以下整理。
本文內容針對網頁端，針對B端表單中數據的展示方式，翻頁和滾動的區別。不含移動端，不含C端的信息流場景。
一、翻頁加載和滾動加載的數據是怎麼顯示的
1、首先，先有篩選，後有數據展示（分頁、滾動）。所以，篩選過濾功能針對的是所有數據，並不僅是當前頁面展示的數據。沒有使用篩選條件，那就是全部數據。
2、無論是翻頁還是滾動，後端都需要先返回一個總的數據數。翻頁根據總數據數計算有多少頁，滾動根據總數據數知道是否有“加載更多”的按鈕。
3、交互上，對於一些表單外的操作，如批量刪除、批量已讀等，分頁和滾動都是一樣的：只能操作當前頁面的數據。即分頁只針對本頁面，滾動只針對已加載的數據。
4、當有新的數據產生時，後端會告訴前端。這時候，無論翻頁還是滾動，通過“新消息提示”的方式，手動刷新數據。
5、對於翻頁來說，無論是手動刪除單條數據，還是批量刪除多條數據，當前頁面展示哪些內容，是後端提供第n頁展示什麼內容。
基於這種邏輯：翻頁模式每頁展示10條數據，如果刪除第n頁的3條數據後，想要用第n+1頁的3條數據補齊，那需要前端再次請求後端，返回這個時候的第n頁的數據。
所以，無論是刪除單條數據，還是批量刪除多條數據，翻頁想要自動補齊，都需要請求後端返回最新的數據。
滾動不存在這個問題，因爲滾動模式沒有固定的頁。
二、體驗角度分析翻頁和滾動
翻頁適用場景：
1、內容檢索場景，例如瀏覽器搜索等對檢索需求較高的場景。
用戶對內容的檢索需求較高，需要爲用戶分批展示搜索結果，並給了用戶的時間去思考選擇自己想要的內容。
2、精準定位和帶有明確內容傾向的場景。
因爲每一頁的內容數量上都是一致的，二次進入能夠精準找到上次停留的位置及目標內容，也能夠快速找到歷史內容。相較於無窮無盡、沒有頁面感和數量感的瀑布流更合適。
3、B端產品還會有頁面數據量的控制功能，用戶能夠精準把握單頁內容的加載量。
交互方面，翻頁需要考慮，刪除第n頁整頁數據後，是會定位到第1頁，還是n-1，還是新。同理，最後一頁的情況頁要考慮。
滾動適用場景：
操作流程不易被打斷，沒有間斷的思考間隔，極易營造一種沉浸式的體驗，讓用戶有一種停不下來的感覺。
依據加載更多內容是是否需要點擊操作，瀑布流可以分爲以下兩類：
· 自動式瀑布流：即分段式瀑布流，到達某個臨界處，滑動觸發頁面加載後續內容，用戶不需要點擊操作；
· 手動式瀑布流：手動式瀑布流需要用戶手動點擊頁面底部的加載更多按鈕後才能獲得更多信息。
滾動加載的缺點
1、不能定位檢索特定信息
2、頁腳和側邊滾動條功能難用，因爲針對的不是全部內容，而是當前加載到的數據裏的
3、難以回溯已閱信息
補充
針對網上有人說的一些滾動加載的缺點，對於B端的數據列表展示，問了開發，不存在以下問題：
1、技術短板，首先其對設備硬件要求較高，長時間的在同一個頁面中加載資源內容，當前頁面會下載大量的緩存內容，頁面的響應速度就會減慢，進而影響用戶體驗，只有退出應用和瀏覽器並清空緩存才能恢復。
2、無法估算內容總量（因爲，無論翻頁還是滾動B端數據列表會返回總量）
三、綜合方案
考慮到翻頁點擊會影響體驗，有一種方案是將翻頁和滾動的點擊加載合併一起，點擊底部的加載更多，效果等同於自動翻頁。“加載更多”=“下一頁”，只是頁面不會中斷，頁碼會自動增加。
但是網上滾動，即查看已閱內容，就需要根據內容定位自動減少頁碼了。
這種方案應用的比較好的，就是長文章，比如讀書類APP，可以無限向下滾動，但是同時內容也是根據目錄定位的。