起源于1993年的網(wǎng)絡瀏覽器，時至今日依然保持著請求-響應的交互機制。當用戶打算瀏覽網(wǎng)頁的時候，用戶輸入鏈接，瀏覽器便會將用戶請求的內(nèi)容發(fā)送到服務器，服務器收到請求，處理它，并響應反饋給瀏覽器?？紤]到互聯(lián)網(wǎng)的初衷就是用來查看文檔，所以請求-響應機制還是令人滿意的?？墒请S著時代的發(fā)展，用戶對于互聯(lián)網(wǎng)的需求和期望都已經(jīng)有所改變。

Ajax技術是這種演化的第一步。它完善了網(wǎng)絡體驗，允許用戶在無需刷新頁面的情況下加載新的內(nèi)容，不過它的限制在于加載新內(nèi)容依然需要用戶發(fā)出請求才能得到響應。單用戶借助這種技術來瀏覽靜態(tài)文檔體驗是很不錯的，但是在多用戶環(huán)境下就站不住腳了。并非只有網(wǎng)絡瀏覽面臨著這樣的問題。現(xiàn)如今，我們在開發(fā)APP的時候，也需要考慮多用戶瀏覽的問題。 我們希望數(shù)據(jù)連接和加載能夠如同實體一樣被用戶感受到，這是實時動態(tài)加載技術令人眼前一亮的地方。

挑戰(zhàn)

諸如Node.js和Meteor這樣用戶友好的異步框架，已經(jīng)開始廣泛地運用起這種實時網(wǎng)絡技術。在這項技術大規(guī)模推行之前，用戶的操作是非常清晰的。這些操作可以清晰地劃歸到用戶頭上，鏈接、刷新和頁面加載是清晰而明確的。單擊鏈接，頁面跳轉(zhuǎn)，內(nèi)容就biu的一聲在你眼前展現(xiàn)出來了。

當新的用戶被加入到整個系統(tǒng)中來的時候，在頁面刷新前，他們面對的系統(tǒng)中的數(shù)據(jù)內(nèi)容是完全一樣的，界面是被動的，它會隨著操作而出現(xiàn)反饋的。想象一下整個系統(tǒng)合理有效地連通不同的用戶的壓力和難度。在實時動態(tài)系統(tǒng)中，我們所面臨的不僅僅是創(chuàng)造令人欲罷不能的特性，還得處理大量數(shù)據(jù)和它們之間復雜的因果關系。

我們需要將APP以自然而易于理解的方式呈現(xiàn)在用戶面前。在實際操作中，APP只有能讓用戶易于操作理解，才能與之共鳴，讓他們注冊，并且與之互動。掌控好數(shù)據(jù)與界面之間的因果關系，不同層級數(shù)據(jù)與界面之間的交互規(guī)律，才能讓APP更優(yōu)秀。

規(guī)則

開發(fā)者能夠利用實時動態(tài)設計來打造下一代的web用戶體驗。而我們也總結(jié)出了一系列實時設計用戶體驗的設計規(guī)則。

1、聲明狀態(tài)

用戶理當知道系統(tǒng)的狀態(tài)，而系統(tǒng)也應該對用戶操作進行確認和反饋。

應用應當適當?shù)貜娀缑娼Y(jié)構(gòu)，否則系統(tǒng)的整體架構(gòu)將不夠明晰。當實時界面出現(xiàn)變化的時候，比如頁面刷新，下拉之后頂部的刷新控件能夠適時地向用戶傳達列表的連接刷新狀態(tài)。

實例：連接狀態(tài)

你的連接是否處于連接狀態(tài)？連接失效自然是不可避免的。很多外部因素可能會導致數(shù)據(jù)交換達到不符合預期的結(jié)果，導致連接失效。

圖1 修改前：用戶沒有被告知連接丟失，這可能會影響他們對APP的預期。

圖2 修改后：數(shù)據(jù)交換中出現(xiàn)提示，連通斷開，并且系統(tǒng)嘗試去修復。

實例：加載

在網(wǎng)速有限的情況下加載大量內(nèi)容時，就會很容易讓用戶陷入長時間的等待。作為一個優(yōu)秀的設計師，告訴用戶加載時間是很有必要的。

圖3：修改前：在被打斷之后，在應用加載用戶內(nèi)容時，用戶不會知道要加載的時間。

圖4：修改后：進程指示器顯示加載的內(nèi)容還有多長的等待時間。

實例：確認

對于用戶行為做出的響應，能夠顯示出系統(tǒng)正在聆聽并且關心用戶。

圖5：修改前：在刪除完成后，用戶并沒有得到反饋

圖6：修改后：在用戶完成刪除達到新界面時，會得到刪除確認。

2、預測變化

用戶需要知道操作之后接下來的會是什么。當用戶行為發(fā)生時，產(chǎn)品應告知用戶接下來會出現(xiàn)什么。

在嚴密的邏輯體系中，意外往往不易讓人接受。比如，汽車要運送乘客到目的地，汽車需要保持機械精度，確保正常運行，而在這個系統(tǒng)中，意外就是爆胎和發(fā)動機故障。與汽車類似的是，一個應用程序要以用戶友好的方式，竭盡全力幫用戶達成目的。不同于汽車的是，移動端應用使我們能夠預見并告知用戶即將到來的變化。

實例：呈現(xiàn)結(jié)果

當可能發(fā)生明顯的界面狀態(tài)變化時，需要向用戶預告變化的結(jié)果，給用戶機會來處理，并防止將要發(fā)生的意外。

圖7：修改前：當新界面出現(xiàn)的時候，視野中并沒有提示或者反饋。

圖8：修改后：當新的界面準備好加載時，系統(tǒng)會做出響應，但是不會通過自動響應來干擾進程。

實例：框架模板

顯示布局框架預示著將要跳轉(zhuǎn)到新的界面，提前切換布局填補空白。另外還有個好處，這可以使得程序看起來更有“響應式”的特征。

圖9：修改前：在屏幕加載新界面之前，用戶需要等待所有內(nèi)容加載完，之后界面突然切換過來。

圖10：修改后：頁面加載用占位符指示哪些內(nèi)容是即將出現(xiàn)的。

3、保持上下文

用戶應該知道內(nèi)容來自哪里，屬于哪里。

由于用戶無法實時監(jiān)測應用內(nèi)具體發(fā)生了什么變化，因此建立并加強應用空間感很重要。這里，空間感指的是每個界面和每個按鈕與其它部件的相對空間位置。為此，我們需要創(chuàng)建一些可信賴的標志來強化它們的存在。

實例：一致的位置

新的內(nèi)容應該出現(xiàn)在一個可預測的位置。讓用戶習慣應用內(nèi)功能導航的路徑，不要通過提供多種路徑來完成同樣的事情。

圖11：修改前：新的控件和元素出現(xiàn)在不可預料的位置。

圖12：修改后：內(nèi)容總是出現(xiàn)在一致的位置上。這時，用戶在視覺上不會感到新內(nèi)容突兀。

事例：變化過程

讓狀態(tài)的變化更加清晰明了，不要讓條目突兀地出現(xiàn)在不可預見的位置。動畫可能很大的程度上確保這一點，讓新加載的內(nèi)容正與周圍的環(huán)境融為一體。

圖13：修改前：新條目的一閃而入，會造成相鄰內(nèi)容無過渡地向下移動。

圖14：修改后：新的項目和相鄰項目之間有動畫過渡，它們的位置隨著時間的推移而變化，從而給予用戶一段時間去接受它們的變化。

實例：保持位置

當項目在不同屏幕之間來回移動時，需確保用戶返回時能回到他們進入前的相同位置。

圖15：修改前：滾動位會置重置。用戶要花費較多精力去尋找之前的位置，這樣的用戶體驗很糟糕。

圖16：修改后：之前的位置被系統(tǒng)儲存，當用戶返回時，能回到最初進入的位置。

結(jié)語

以上這些理論可以作為我們起草實時體驗時的出發(fā)點。我鼓勵所有的創(chuàng)作者去發(fā)現(xiàn)這些原理的應用范圍，但是，最重要的是要了解狀態(tài)，預知改變，并且呈現(xiàn)內(nèi)容。

延伸閱讀
《自然而流暢！聊聊常見的界面切換動畫》
《瘋狂流行的動效！究竟是交互設計還是視覺設計？》
《經(jīng)驗分享：移動應用交互動效設計》

原文地址：Percolatestudio
優(yōu)設網(wǎng)翻譯：@陳子木

本文由優(yōu)設網(wǎng)原創(chuàng)翻譯，請尊重版權和譯者成果，轉(zhuǎn)摘請附上優(yōu)設鏈接，違者必究。謝謝各位編輯同仁配合。

【優(yōu)設網(wǎng) 原創(chuàng)文章 投稿郵箱：2650232288@qq.com】

================關于優(yōu)設網(wǎng)================
"優(yōu)設網(wǎng)uisdc.com"是一個分享網(wǎng)頁設計、無線端設計以及PS教程的干貨網(wǎng)站。
【特色推薦】
設計師需要讀的100本書：史上最全的設計師圖書導航：http://hao.uisdc.com/book/。
設計微博：擁有粉絲量73萬的人氣微博@優(yōu)秀網(wǎng)頁設計 ，歡迎關注獲取網(wǎng)頁設計資源、下載頂尖設計素材。
設計導航：全球頂尖設計網(wǎng)站推薦，設計師必備導航：http://hao.uisdc.com
———————————————————–
想在手機上、被窩里獲取設計教程、經(jīng)驗分享和各種意想不到的"福利"嗎？
添加 優(yōu)秀網(wǎng)頁設計 微信號：【youshege】優(yōu)設哥的全拼
您也可以通過掃描下方二維碼快速添加：