交互設(shè)計(jì)師作為整個(gè)項(xiàng)目貫穿始終的一根線，除了有自身對(duì)需求的理解把控以及對(duì)頁面布局的拿捏以外，充分吸取各種不同的思維方式，才能讓我們?cè)诖蚬稚?jí)的路上越走越遠(yuǎn)。

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

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

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

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

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

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

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

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

1. 整頁加載

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

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

整頁加載案例

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

案例1 彈窗

以彈窗方式來提示用戶數(shù)據(jù)交互的錯(cuò)誤，因?yàn)樾枰脩酎c(diǎn)擊操作才能關(guān)閉，所以重點(diǎn)在于讓用戶明確的知道頁面加載失敗的原因，比如因?yàn)橛脩舨僮鞑煌锥鴮?dǎo)致的取不到數(shù)據(jù)等。

案例2 toast

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

案例3 頁面提示

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

2. 分區(qū)域加載

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

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

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

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

案例1

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

案例2

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

案例3

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

案例4

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

借助以上案例對(duì)分區(qū)域加載方式的理解和啟發(fā)，在頁面內(nèi)容的呈現(xiàn)上有很多細(xì)節(jié)值得我們?nèi)ジ嗟耐魄?。我們也可以主?dòng)和技術(shù)商討加載方案，以得到更好的體驗(yàn)。

3. 自動(dòng)加載

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

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

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

案例1

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

案例2

案例3

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

4. 智能加載

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

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

案例1

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

案例2

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

案例3

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

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

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

作者：杰克蝶

來源：微信公眾號(hào)【ME網(wǎng)易移動(dòng)設(shè)計(jì)】