專案落地該如何設計載入模式？
上一期我講到了平臺規範下進度指示器的使用規範，並且結合使用者等待4秒原則與NN/g使用者等待心理模型，個人愚見搭建了一個常規的載入模型（可回顧：進度指示器(原則篇)）。
但透過長期以往對移動軟體的使用，我發現平臺規範下的進度指示器其實只是丟擲了一個引子，優秀的設計團隊早已在規範的指引下，衍生出了諸多的更新穎的載入模式。
這一期我把我調研總結出的結果分享給大家，在各行各業都打著“以使用者體驗為中心”的當下，也許可以幫助你更合理地緩解使用者等待焦慮。
想要給載入場景提升一個體驗高度，我們首先要知道為什麼應用程式的許多場景需要載入。其實無非就是因為每當使用者開啟一個新的頁面或進行了一項操作時，大量的資料需要和資料庫傳輸，這一個過程造就了等待的無可避免。
我們先來說說，當用戶開啟一個新頁面時的全域性載入。
如果按照規範的指導，全域性載入的互動形式在 Material Design 中，應該是這樣的：
按照 MD 的方案，如果在使用者理想的網路環境下，如此做其實並沒有太大的問題，載入只需在一個流暢 Loading 讀取完成後就可以結束。
但頁面載入等待時間往往和使用者本身所處的網路環境也有關，如果使用者當前所處環境網路訊號較差，我在上一篇文章中提到過，載入等待超過4秒之後使用者的焦慮情緒就會指數級上升。
所以越來越多的團隊在涉及到頁面全域性載入的場景中，開始使用骨架屏。
骨架屏的引用最開始在iOS的啟動頁中被提出，我在《聊聊載入等待的那些事 之 啟動頁》中也講到過，骨架屏給使用者的感知就像一進入一個頁面就已經加載出了頁面框架，剩下的時間只是在請求伺服器資料，給人一種頁面開啟很快的感覺。
並且骨架屏可以讓使用者在等待的過程當中，率先對當前所在頁面的樣式有一個心理預設。較 MD 規範中的全域性載入進度條方案，使用者的可控感更強。
大多數應用程式首次載入採用骨架屏解決後，會面臨資料重新整理的情況。普遍的二次載入都會採用下拉重新整理。
但下拉重新整理有個弊端，就是使用者一定要在頁面頂部下拉才有重新整理效果，不然下拉手勢優先響應的是頁面上滑動作。
iOS 考慮到了這一衝突，所以給裝置預設了一個隱形的手勢動作，使用者在非頁面頂部的位置點選屬性欄，可以立即回到當前頁面頂部。但安卓裝置並沒有這一便捷操作。
所以許多應用程式選擇在標籤欄內做動作。
以大多數應用程式首頁為例，因為首頁涉及到許多大資料演算法推送，給使用者的資料並不固定，一般會面臨手動二次重新整理的情況。所以許多標籤欄“首頁”標籤引入了在非頂部位置點選標籤回到頂部、在頂部位置點選標籤進行下拉重新整理動作的最佳化處理。
我前面提到的“全域性載入”更多是站在表現層來說的，指的是給使用者的感知是一整屏資料都在載入的情景。但對於伺服器請求來說，如果在資料量繁多的頁面採用“真·全域性載入”，可能使用者真的要等待很久……很久……
所以許多應用程式在這種情況下都採用了“懶載入”模式。
“懶載入”指的是首先給使用者展示一定量的資料（可以是x個數據量，也可以是x屏資料量，真實專案可根據具體的產品規劃決定），待使用者瀏覽完已載入資料後，再請求第二批次的資料量。
“懶載入”一般用於資料量特別多的情況下，例如淘寶這樣的大資料推送平臺，根據使用者喜愛的內容，可以推送數不勝數的商品給使用者。如果真的一次性全域性請求所有的資料，可能使用者真的要等到天荒地老了……
等待的場景可不僅僅侷限於從伺服器下載資料的時候，上傳等互動操作也是使用者經常面臨的等待場景之一。
就像前面所說的一樣，資料傳輸導致的使用者等待是不可避免的，如果在不能解決網路根本的問題，對於操作等待的最佳化方案，我發現基本所有的產品無一例外都是運用了“打發使用者等待時間”的替代方案——無法解決等待的發生，但可以讓使用者感覺等待時間好像並不漫長，甚至完全遷移使用者對於等待的感知。
例如 PC 端慣用的手法，摹客在上傳畫板和 Bodymovin 在匯入json檔案時，都選擇給使用者隨機發放名人名言或短新聞。
但顯然這樣的形式在空間侷促的移動裝置上不是非常實用，可是大部分移動端的解決方案出發點也是“打發使用者等待時間”。
在很早以前，使用者上傳的等待解決方案大都是採用吐司彈框來告訴使用者“資料正在上傳，你就等著吧”。並且大部分用於等待的吐司是沒有穿透效果的，也就是說，使用者無法穿透這個吐司彈框，對頁面進行瀏覽與其他操作，只能乾等著…
後來多型按鈕的出現完美地解決了這個尷尬的等待情景。
可能是我孤陋寡聞…第一個培養我多型按鈕互動的應用是支付寶，但是多型按鈕的誕生具體是哪裡，這個不太重要，我就不在此做過多考究了。
支付寶在使用者進行點選操作時，按鈕會由預設狀態切換到載入狀態。這個解決方案完全不打擾使用者，在等待時間較長時，使用者還可以繼續翻看當前頁面內容，打發等待的時間。
抖音有一個細節，在使用者上傳影片時，並不會讓使用者在當前頁面瞎等，而是會讓使用者回到feed流頁面，將上傳浮窗放置在頁面角落。
這樣一來不會讓使用者上傳等待時無事可做；二來可以變相增加feed流影片播放量；三來，萬一使用者在等待的過程中，刷到了好玩的作品，一個不小心又沉浸在了刷影片的場景中，APP 使用時長又增加了。這個小互動真的要點個贊。
這一點是值得市場上許多產品學習的。例如唱吧，雖然現在將業務場景開始向短影片轉移，但很難少在一些不經意的場合機敏的將使用者往短影片場景引導。在唱吧上傳音訊時，還是在使用常規的吐司彈框等待模式，讓使用者乾等很久…
這一期總結的指示器互動似乎都沒有被收錄在平臺規範中，它們都是各個設計師在設計開發的流程中獨立總結出來的。所以大家在日常的設計工作中，還是要多思考創新，站在規範的肩膀上，開創更多新穎的互動。
我憑藉著拙見總結了一些關於載入指示器互動細節，可能還有更多關於解決使用者等待焦慮的驚喜小互動還沒有總結到，在今後使用和學習中如果被我逮到了，我會再進行相關課題的討論。
作者：Howie_t；公眾號：UCD耍家（ID：ucdplayer）
本文由 @Howie_t 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議