交互設(shè)計師作為整個項目貫穿始終的一根線，除了有自身對需求的理解把控以及對頁面布局的拿捏以外，充分吸取各種不同的思維方式，才能讓我們在打怪升級的路上越走越遠(yuǎn)。

特別是新人設(shè)計師，有沒有這樣的感覺，在有技術(shù)同學(xué)加入的交互評審中，常會被問及一些原來沒有思考全面的細(xì)枝末節(jié)以及極端情況處理方案，比如“這個列表一次加載多少條？”“如果同時有2個用戶在爭奪最后一個名額該怎樣處理？”等等。

技術(shù)大大們的思維普遍縝密，因為他們是最終實現(xiàn)一切數(shù)據(jù)交互的執(zhí)行者。而作為交互設(shè)計師，我們很容易只注重產(chǎn)品需求和界面布局這些展現(xiàn)在用戶眼前的有形的內(nèi)容，而由于數(shù)據(jù)交互而引發(fā)的一些問題就容易被忽略。

什么是數(shù)據(jù)交互

目前，除了一些特別簡單非聯(lián)網(wǎng)類應(yīng)用（比如計算器、鬧鐘等），幾乎所有的應(yīng)用都是聯(lián)網(wǎng)應(yīng)用，而其app客戶端基本都只是負(fù)責(zé)用戶的交互與數(shù)據(jù)收集與展示，真正的數(shù)據(jù)和服務(wù)均存儲在云端。

客戶端數(shù)據(jù)交互原理示意

如圖所示，在設(shè)計具體方案時，我們會更多的注重用戶和客戶端本身的交互，至于客戶端和后端的交互則容易被認(rèn)為是只需要技術(shù)去解決的問題。

確實數(shù)據(jù)交互是技術(shù)問題，但如果作為交互設(shè)計師能有意識的在方案中思考這些問題，能夠幫助我們使方案更符合技術(shù)實現(xiàn)的需求，體驗更流暢。

數(shù)據(jù)交互在app頁面中的直接體現(xiàn)既是頁面內(nèi)容的加載方式，下面我們來了解一下主要的幾種數(shù)據(jù)加載方式：

1. 整頁加載

整頁加載 數(shù)據(jù)交互示意

整頁加載很好理解，就是在加載一個頁面時，客戶端發(fā)送一個請求，服務(wù)器返回一次數(shù)據(jù)，其特點就是一次性加載完全部數(shù)據(jù)再顯示。常運用于一些H5活動頁面、游戲、簡單網(wǎng)頁

整頁加載案例

整頁加載失敗時，常見的處理方式有以下幾種：

案例1 彈窗

以彈窗方式來提示用戶數(shù)據(jù)交互的錯誤，因為需要用戶點擊操作才能關(guān)閉，所以重點在于讓用戶明確的知道頁面加載失敗的原因，比如因為用戶操作不妥而導(dǎo)致的取不到數(shù)據(jù)等。

案例2 toast

雖然用toast形式做整頁加載失敗的回應(yīng)方式是可行的，但是筆者認(rèn)為最好應(yīng)用在頁面還有其他內(nèi)容可操作的情況下的輕量提醒更合適，因為比如右圖所示，toast提示停留時間短暫，消失后面對空蕩蕩的頁面，用戶會不知所措。

案例3 頁面提示

在頁面上直接顯示無數(shù)據(jù)展示的原因以及解決辦法是很提倡的處理方案，優(yōu)點無需贅述。

2. 分區(qū)域加載

分區(qū)域加載 數(shù)據(jù)交互示意

分區(qū)域加載即把需要加載的內(nèi)容分成不同線程同時向后端發(fā)送請求，后端也分不同線程同時/依次返回數(shù)據(jù)。

其特點是能逐步展示內(nèi)容，在這個漸進(jìn)的過程中降低用戶的焦慮心理

同時模塊間可以有關(guān)聯(lián)性，先加載父內(nèi)容，再加載子內(nèi)容。我們來看看以下案例的處理：

案例1

方案1的兩個案例都是優(yōu)先加載格式和文本等信息，消耗大且不影響頁面基本功能的圖片信息次要加載。

案例2

通過方案2我們能看到對于頁面內(nèi)容加載更細(xì)致的處理過程：格式——文本和占位圖——圖片，每一個階段的處理都賞心悅目，絲毫沒有反感。

案例3

方案3同樣也是逐步加載，但是首先加載出的格式可以讓用戶對頁面即將呈現(xiàn)的內(nèi)容有初步了解，也是增加美感，降低焦慮的一種方式。

案例4

前文提到過模塊間的關(guān)聯(lián)性，我們可以通過案例4清晰的看到數(shù)據(jù)展示上被設(shè)計過的加載順序：首先是格式，然后是用戶發(fā)布的內(nèi)容，其次是用戶信息。

借助以上案例對分區(qū)域加載方式的理解和啟發(fā)，在頁面內(nèi)容的呈現(xiàn)上有很多細(xì)節(jié)值得我們?nèi)ジ嗟耐魄谩Ｎ覀円部梢灾鲃雍图夹g(shù)商討加載方案，以得到更好的體驗。

3. 自動加載

自動加載 數(shù)據(jù)交互示意

自動加載并不是后臺自動的傳輸數(shù)據(jù)，實質(zhì)上也是用戶的一些行為觸發(fā)客戶端給后端發(fā)送請求。通常運用于2種場景：

1. 頻繁更新的內(nèi)容、有時效性的內(nèi)容
2. 相對穩(wěn)定，數(shù)據(jù)不會經(jīng)常變化的頁面

案例1

最簡單的案例就是例如推特這樣，上滑頁面看到一定位置的時候，自動提前加載后續(xù)內(nèi)容。

案例2

案例3

另外，例如開眼精選、Hyper等內(nèi)容穩(wěn)定的頁面，在進(jìn)入時，或者有數(shù)據(jù)更新時，也會采用自動加載。

4. 智能加載

智能加載 數(shù)據(jù)交互示意

智能加載的特點在于預(yù)加載，通過用戶的某個行為，或者已有的通用數(shù)據(jù)分析來預(yù)測用戶行為，并提前加載。這一點顯然是產(chǎn)品和數(shù)據(jù)挖掘的大大們需要研究的事情。作為交互能利用智能加載的另一個特點，就是根據(jù)不同網(wǎng)絡(luò)條件下載展示不同素材。

案例1

例如Pinterest從列表頁點擊進(jìn)入正文頁的過渡動畫，是將列表的小圖直接拉大成大圖，如果網(wǎng)絡(luò)環(huán)境優(yōu)，則會進(jìn)一步加載大圖并展示，如果網(wǎng)絡(luò)環(huán)境欠佳，則保持用小圖拉大的低質(zhì)量圖，以此節(jié)省資源。

案例2

如案例2所示，在Pinterest查看圖片詳情時，也會根據(jù)加載狀況先顯示低質(zhì)圖，等加載完畢后用高質(zhì)量圖替代，如此既保證了頁面功能的完整性，體驗上也不會有明顯的跳動。

案例3

同樣處理的如此細(xì)致的還有Mars，頁面跳轉(zhuǎn)很流暢，但是仔細(xì)觀察會發(fā)現(xiàn)處于不同階段的3張圖，圖片的質(zhì)量是遞進(jìn)的。

以上，為大家淺略的解讀了一下數(shù)據(jù)交互的常見方式及案例。作為交互設(shè)計師，在實際工作中并不需要對技術(shù)知識了解的多么深入，但是如果我們能夠知道技術(shù)在實現(xiàn)時的基礎(chǔ)原理，那么在實際方案中就能考慮的更加細(xì)致和全面，并且更加符合技術(shù)實現(xiàn)時的實際情況，能盡量避免交互方案與技術(shù)方案的沖突。

其實，不僅是對于技術(shù)環(huán)節(jié)，包括在與產(chǎn)品和視覺，每一個角色都有著自己不同的思維方式，正因為這些不同才能一步步將一個個縹緲的概念落為現(xiàn)實，到達(dá)用戶手中。交互設(shè)計師作為整個項目貫穿始終的一根線，除了有自身對需求的理解把控以及對頁面布局的拿捏以外，充分吸取各種不同的思維方式，才能讓我們在打怪升級的路上越走越遠(yuǎn)。

作者：杰克蝶

來源：微信公眾號【ME網(wǎng)易移動設(shè)計】