隱藏在背後的交互設計

交互設計最重要的兩個因素：信息互動

1.信息

人們天天面對那麼多信息，在雜亂的信息中篩選出對用戶有價值的，呈現給用戶，幫助用戶作選擇，指引用戶完成任務。信息的篩選直接影響着用戶使用，在用戶須要的時候沒法提供有用的信息，將致使任務沒法進行下去。因此信息是交互設計師須要關注的第一要素。

2.互動

有了信息後，就須要設計用戶如何與這些信息進行互動了。信息的分類、佈局將影響用戶與信息的交互。用戶獲取信息後，作出了反應，採起了行動，應用也須要有來有往地給予足夠的反饋，來協助用戶完成任務。

 

以上2要素，都是從用戶直觀感覺上去體現的，也就是說每每是表如今用戶界面上。咱們能夠把它稱之爲「看得見的交互設計」。

具體的形式包括：

信息架構：把篩選好的信息進行分類，經過頁面來承載這些信息，而且把信息（頁面）的層次規劃好

界面設計：把信息在一個頁面上進行佈局

流程設計：把一個任務中涉及的頁面信息串聯起來，使任務造成一個線性流的關係

以上三個關鍵點，是對交互設計師的基本要求，不少狀況下，非專業人員也能作得7788，但還有一部分的交互設計，並非直觀能看到的，也許用戶會輕微感覺到，但他總在不經意間使用戶使用得更加流暢。咱們能夠把它稱之爲「看不見的交互設計」。而這些看不見的交互設計，也是初級交互設計師容易忽略的。

 

現在移動互聯網發展迅速，移動產品對這些看不見的交互設計更爲注重。由於移動應用的使用場景、網絡環境、使用心態都與用戶在使用web產品時有着大大的不一樣。因此在瞭解這些看不見的交互設計時前，須要對移動應用的情景有必定的瞭解。

1.使用場景

用戶在使用移動產品，有可能會在戶外人多的公衆場合使用，這時候須要特別注意移動應用設計的隱私安全。

用戶有可能在家裏、在牀上、在廁所，用着各類姿態使用產品，因此對交互的便利性和容錯性要特別注意

2.網絡環境

網絡環境是「看不見的交互設計中」很是關鍵的一點。用戶會在2G、3G、wifi甚至無聯網的狀況下使用產品，因此對於各類網絡環境進行合理的交互設計是移動產品交互設計師須要考慮的重中之重

3.使用心態

產品的存在是爲了解決用戶的問題，而移動產品是用戶的貼身工具，當用戶須要時，能馬上開始運做，須要快速、直接、有效，用戶不喜歡等待。有研究結果表示：

 

在移動產品這種特殊的環境下，「看不見的交互設計」會相較於web產品更爲重要，特別是針對網絡環境和用戶等待的體驗須要特別注意

下面將展開討論一下「看不見的交互設計」

總的來說，能夠歸結爲三大點：

1.加載機制

2.刷新機制

3.緩存機制

 

 

加載機制

一般狀況下，咱們使用的絕大部分是網絡App，他的工做原理是這樣的

用戶在客戶端的界面上進行操做，客戶端發送請求到服務器，服務器處理請求，返回數據給客戶端，並顯示給用戶

其中，客戶端和服務器的交互過程，用戶是感知不到的，而他確實會耗費時間，在不一樣的網絡環境下耗費的時間也會有所差別，如何讓用戶在這段時間裏有友好的體驗呢？這時候「加載過程」起了做用。

 

加載過程的關鍵能夠總結爲：

1.讓用戶感知產品正在努力爲他運做

2.讓用戶有基本的心理預期須要等待的時間長短

3.讓用戶在無聊的等待中得到更多樂趣

 

進度條是一個針對加載過程很好的設計

動態的加載進度表示產品正在工做，總進度和當前進度能讓用戶及時瞭解狀況，讓用戶能根據這些信息預判時間，有了心理預期

有趣的進度條設計or在加載過程當中展現一些功能介紹提示（經常使用於遊戲）能有效減小用戶等待時的焦躁心理，也能有效地提升用戶的容忍度

 

進度條是web產品時代的產物，還有另一種加載設計，就是加載圖標

因爲移動產品請求的數據量並不大，因此進度條每每會在一瞬間就完成了，在這種情境下，簡化了加載的設計，不少移動產品轉而使用加載圖標來表示加載過程

以上爲兩種比較經常使用的加載方式，下面將具體介紹他們與移動產品結合的用法

 

頁面加載機制

移動產品的信息都是經過頁面來承載的，頁面的加載方案設計是交互設計師面臨的一個重要難題

方案一：單頁面總體加載

這種加載比較簡單，通常運用在頁面內容比較單一的狀況下，因此直接一次性加載完全部數據後再顯示內容

 

單頁面加載失敗的狀態也比較好處理

 

方案二：單頁面分塊加載

這種方案的特色是，能讓用戶逐步看到內容，在這個漸進的過程當中下降用戶的焦慮心理

其中又能夠分爲，模塊間有關聯性的，先加載父內容，再加載子內容

如優酷，先把欄目加載出來，再加載各欄目的內容

模塊間沒有絕對關聯性的，可獨自加載各自模塊內容，根據請求的速度不一樣分別顯示。這樣處理有必定概率讓用戶在沒徹底刷出數據的狀況下就能找到本身須要的功能，如大衆點評、淘寶客戶端

 

框架固定，內容更新的，可先把框架顯示出來，再把各模塊的數據各自加載顯示，如各類iOS自帶應用，雲音樂

 

這種分模塊加載的須要特別注意加載失敗的狀態，畢竟每一個模塊都提示加載失敗，點擊重試是很挫的一件事，能夠根據信息的優先級來決定哪些數據失敗了採用默認狀態，哪些數據採用失敗提示

 

方案三：跨頁面加載

父頁面&子頁面 or 同一app內，頁面間字段能夠複用的，在加載子頁面時不須要從新加載新數據

 

 

方案四：預加載

這種加載方式的特色是，在加載一個頁面內容的同時，預測用戶的下一步行爲，併爲他下一步須要使用的頁面加載內容，使得他在下一步的操做中能馬上獲取信息而不須要加載等待。

預加載提供給用戶無縫的產品使用體驗，使得用戶在使用產品的過程當中更直接流暢，沒有被打斷的感受。

具體的例子有：

在瀏覽圖集的時候，當看到第一張的圖片時，就自動後臺加載第二第三第四張圖片，用戶瀏覽完第一張圖片切換到第二張時就不會有加載等待的過程

在瀏覽新聞列表時，就把每篇新聞的內容在後臺進行預加載，用戶選擇看某篇新聞時，能馬上閱讀到內容

 

可是這種方案須要面臨不少的問題，最直接的是流量問題，由於會自動跑掉不少用戶可能根本用不上的數據流量，因此通常狀況下能夠設定在wifi環境才採用這種加載模式。又或者設定加載規則，只把主要內容預加載，而部分次要內容能夠在用戶真的用到的時候才加載，例如預加載新聞正文的狀況，能夠只加載文本信息，圖片信息等到用戶進入內頁才加載。這種預加載與分塊加載結合的方式也廣泛運用在各個場景。

另外，預加載也須要時間的，他只是不在客戶端顯示給用戶，默默在後臺運做而已，須要特殊考慮未加載完用戶就使用到那些信息的狀況，因此在作預加載設計時須要同時考慮另外一種適合該狀況的普通加載方式。

預加載須要根據具體的場景來進行設計，設定好信息優先級，綜合考慮各類類型信息的具體大小流量，總體考慮預加載的方式，這些都是須要通過精心分析思考的。

隨着網絡環境的發展，預加載將成爲之後產品廣泛的加載方式，他提供給用戶的無縫使用體驗大大地提高了產品的可用性。

 

操做加載機制

除了頁面的信息須要加載，頁面內的操做也是須要經過給服務器發送請求記錄的

方案一：加載層

進行一個操做後，彈出模態的提示層，告知用戶正在加載。

採用模態的提示主要是防止用戶在該過程當中進行其餘操做，致使當前加載出錯。因爲採用模態的提示，而且有可能由於網絡緣由致使長時間處於加載狀態，建議提供一個「關閉」的操做，停止本次加載，恢復App可用狀態。加載失敗時可在當前浮層變換爲失敗提示。

模態提示層是最穩妥的方式，但他會使用戶在使用過程當中有打斷的感受。

 

方案二：控件自身加載狀態

這種方式是把操做加載的狀態與控件的樣式結合起來了，對某個控件進行操做後，控件變換爲加載狀態，此時控件不能重複操做

因爲這種加載方式是控件的自身狀態，不影響其餘操做，因此用戶也能夠對頁面進行其餘操做，可能會致使同時有多個請求的狀況，增長了加載失敗的風險，這也算是這種方式的弊端，不過這種極端狀況不多出現。請求失敗後，可配合Toast提示告知用戶失敗的緣由。

 

方案三：後臺加載

用戶在操做後，客戶端馬上反饋操做成功，而後把請求放到後臺與服務器交互，這一過程用戶不須要了解，不須要等待，在正常狀況下體驗是很是棒的。

可是在極端狀況下會出現一些莫名其妙的情況，因爲是後臺記錄請求並與服務器交互，因此實際請求是否成功客戶端是不說明的，所有以操做成功來顯示，這就會致使用戶誤覺得操做成功了，但實際上下次來看發現沒有成功。因此這種加載方式是須要根據具體使用場景來權衡使用的，對於一些重要的操做，建議仍是使用模態的方式加載，對於一些小操做，如點贊、訂閱、關注，可採用後臺加載的方式。

 

 

刷新機制

刷新機制也是設計師很容易忽略的問題，合理的刷新機制能讓產品使用起來更流暢

廣泛狀況下，刷新機制有如下三種：

方案一：手勢刷新

經過手指在屏幕上的左劃右劃上劃下劃達到刷新的目的，也包括一些瀏覽器產品的自定義手勢，如橫折折勾，進行刷新

最多見的下拉刷新也屬於手勢刷新的一種

 

方案二：點擊刷新

經過點擊一個按鈕達到刷新數據的目的，可是現在刷新按鈕的存在已經成爲一種過期的表現，何況在手機那麼小的界面上還須要爲刷新按鈕騰出空間，會挺費勁的。不過避免形式主義，用得恰到好處纔是設計的精髓，這種刷新方案仍是按需使用吧。

 

方案三：自動刷新

根據設定好的規則，如時間、事件規則自動向服務器獲取新數據並替換舊數據。使用自動刷新須要根據場景來考慮是否合適

場景一——對於頻繁更新的內容、有時效性的內容，用戶在一個設定的時間沒有使用，則可考慮在下次使用時，自動刷新，把新的內容推送給用戶

相似微博、新聞這種具備時效性的產品，用戶在24小時內未打開產品，則在下次打開時幫用戶自動更新Timeline

場景二——對於一個相對穩定，數據不會常常變化的頁面，能夠考慮設定時間規則，在後臺爲用戶默默更新數據並替換舊數據

 

 

緩存機制

「緩存」這個詞在web時代也常常聽到，但在移動產品上，他的重要性獲得了很好的重視

一張圖解釋什麼是緩存和緩存的做用

「緩存」就是把已經加載過的數據保存起來，並在下次須要重複使用的時候，不須要向服務器加載，直接獲取本地數據

我理解的「緩存」可以下分類

臨時緩存經常使用於一個功能頁面內，保存各欄目的緩存。同一個功能裏會把子功能分爲多個欄目進行劃分，每一個標籤欄目下的內容在本次使用中均可保存爲臨時緩存，在該功能裏切換欄目，不須要從新加載數據，使用緩存顯示。對於用戶來講，使用時達到了無縫切換瀏覽，對於服務器來講，在短期內數據不多會有更新，因此在通常狀況下能知足用戶的正常需求，並達到體驗優秀

臨時緩存的清理機制是：退出該功能模塊就清除以前的緩存。也就是說下次進入該功能模塊，須要從新獲取一次數據

不少時候咱們都會用到臨時緩存，由於那些信息真的不是那麼重要，並且不須要常常反覆查看，那對於那些咱們常用並且常常須要反覆查看的信息，咱們就會採起固定緩存保存在本地，方便下次翻閱時不須要再一次向服務器請求數據了

其中又會細分爲可手動清理的緩存，和不可手動清理的緩存

第一種是咱們最多見的緩存，幾乎全部產品都採用這種緩存方式。平時用戶瀏覽文章、圖集加載的數據就以這種形式緩存在本地，下次看回這篇文章、圖集時就不須要加載了。用戶也能夠手動把這些緩存清理了，釋放空間。

而對於某些特殊場景，例如一些相對固定的數據，咱們不肯意一開始就打包進App裏，這樣會佔太大容量，形成產品包很大，也不肯意每次進入頁面都向服務器加載這些信息，那怎麼辦？解決方法就是咱們能夠只加載一次就永遠存在本地了，這樣安裝包也不會大，之後也不用加載了。

例如一些頁面的背景圖，相對固定不常更換，因此在用戶首次進入該頁面時就加載背景圖並保存在本地，這種緩存是不可清理的，下次再進入該頁面就讀取本地緩存顯示便可。

這種緩存方案使用得不多，由於場景太少，具體使用場景還有待開發。

 

對於這些保存在本地的緩存，都是會佔空間的，手機的容量是有限的，那產品是經過怎樣的方式清理緩存的呢？

你們熟知的有手動清理，通常App都會在「設置」裏提供一個清理緩存的功能，一鍵把空間釋放。除此以外，App最好要設計自動清理機制。

能夠經過兩個維度來設計這個機制。

時間

經過設定一個固定的時間，或者根據用戶使用週期靈活設定時間來清理緩存。每一個產品的場景不一，用戶使用頻率不一，設定這個機制的時候就須要結合實際狀況考慮了

容量

通常是設定一個容量上限，採用堆棧的設計原理進行緩存清理，溢出堆棧的舊數據將自動清除