移動(dòng)端相較于PC端的交互動(dòng)作——即手勢操作相較于鼠標(biāo)鍵盤輸入設(shè)備操作，是存在相當(dāng)大的不同的。以下筆者將從四個(gè)部分展開講述。
在iOS系統(tǒng)出現(xiàn)之前的時(shí)代，是單點(diǎn)觸控的電容屏和觸控筆和手機(jī)端物理鍵盤對PC端的粗暴移植和復(fù)刻，有的移動(dòng)端設(shè)備甚至復(fù)制了PC端笨重的QWERTY鍵盤，那時(shí)移動(dòng)端的輸入設(shè)備基本和PC端是可以一一對應(yīng)的。
qwerty鍵盤+觸控筆
但在喬布斯主導(dǎo)的iOS系統(tǒng)和手勢操作系統(tǒng)出現(xiàn)后，我們已經(jīng)無法簡單把移動(dòng)端的手勢操作與PC端輸入設(shè)備簡單對應(yīng)了。移動(dòng)端設(shè)備的交互方式也從此開始與PC端的交互方式分道揚(yáng)鑣，漸行漸遠(yuǎn)。
被喬布斯拋棄的觸控筆和物理鍵盤帶來了移動(dòng)端交互革命
我們先來回顧一下PC端鼠標(biāo)針對UI控件的幾個(gè)主要交互動(dòng)作：
Hover，有時(shí)候也被稱為“MouseOver+MouseOut”，PC端用戶可以用鼠標(biāo)指針移過UI控件時(shí)，UI控件的交互反饋來推測UI控件的操作方式。
某些位于某種UI控件之上的Hover動(dòng)作可能會讓鼠標(biāo)指針產(chǎn)生不同形態(tài)的變化，如鏈接會變?yōu)槭中停d入新內(nèi)容會變?yōu)樯陈?，可操作文字?nèi)容變?yōu)楣ぷ至?，Q&A變?yōu)閱柼柕鹊?。鼠?biāo)指針形態(tài)的改變是對當(dāng)前懸停位置內(nèi)容的一種指示。
有些UI控件本身會對鼠標(biāo)的Hover行為產(chǎn)生反饋，此時(shí)不光鼠標(biāo)指針會發(fā)生相應(yīng)的形態(tài)變化，UI控件本身也會根據(jù)預(yù)先定義產(chǎn)生不同形態(tài)的變化。
熟悉CSS的朋友可能記得文字鏈接的幾種定義：link; visited; hover; active; 其中的hover就是針對鼠標(biāo)懸停于自身時(shí)自己的樣式呈現(xiàn)。
Hover交互的用戶端觸發(fā)條件：移動(dòng)鼠標(biāo)指針。
Hover 交互
有時(shí)候也被稱為“Active”、“Action”、“MouseDown+MouseUp”，是鼠標(biāo)點(diǎn)擊UI控件后釋放點(diǎn)擊的一套交互行為。
這個(gè)過程中，用戶點(diǎn)擊和釋放的坐標(biāo)點(diǎn)是一致的，沒有移動(dòng)行為。系統(tǒng)在判定用戶的交互動(dòng)作是“Click”動(dòng)作后，提供用戶點(diǎn)擊的UI控件本身應(yīng)該提供的交互反饋或系統(tǒng)層級反饋。
Click交互一定是發(fā)生在Hover交互之后的，Hover是Click的前置動(dòng)作，因?yàn)椴话咽髽?biāo)指針懸浮到UI控件之上，是無法完成對目標(biāo)UI控件的點(diǎn)擊行為的。
Click交互的用戶端觸發(fā)條件：移動(dòng)鼠標(biāo)指針Hover目標(biāo)UI控件，然后按壓物理按鍵。
Click交互
PC端雖然判斷鼠標(biāo)點(diǎn)擊的事件監(jiān)聽機(jī)制是同樣的，但無論是蘋果的OSX系統(tǒng)還是微軟的Windows系統(tǒng)，都默認(rèn)把鼠標(biāo)右鍵點(diǎn)擊交互反饋留給了ContextMenu——即系統(tǒng)菜單。
此時(shí)，系統(tǒng)或應(yīng)用收回了對右鍵反饋的控制權(quán)，鼠標(biāo)右鍵點(diǎn)擊激活的是系統(tǒng)菜單，用戶需要再次點(diǎn)擊菜單選項(xiàng)來對當(dāng)前UI控件進(jìn)行更多操作。
Right Click交互的用戶端觸發(fā)條件：移動(dòng)鼠標(biāo)指針Hover目標(biāo)UI控件，然后按壓物理按鍵右鍵。
Right Click交互
Tap交互也叫Soft-touch，中文一般稱為“輕敲”，是鼠標(biāo)指針Hover于某UI界面元素后，在鼠標(biāo)操作區(qū)（或觸控板外設(shè)）上快速輕敲以實(shí)現(xiàn)與界面元素間的互動(dòng)，普通的windows系統(tǒng)鼠標(biāo)可能不支持此操作。
Tap交互
Tap交互針對的UI界面元素一般是界面級控件，如操作區(qū)放大縮小、進(jìn)入程序選擇界面等。
Tap觸發(fā)條件：Hover于界面元素，輕敲鼠標(biāo)操作區(qū)，沒有物理按壓行為。
Drag交互中文一般稱之為“拖拽”，是鼠標(biāo)指針Hover于某UI控件后，用鼠標(biāo)按鍵或其他方式觸發(fā)UI控件進(jìn)入拖拽狀態(tài)后，通過移動(dòng)鼠標(biāo)指針的位置來將UI控件拖移至指定位置，然后通過松開按鍵或其他方式解除控件拖拽狀態(tài)。
Drag交互
拖拽狀態(tài)需要UI控件本身支持拖拽功能才能激活。所以有時(shí)候通過鼠標(biāo)指針的變化來指示指定UI控件是可拖拽的。
拖拽狀態(tài)觸發(fā)條件：Hover于界面元素，按住鼠標(biāo)按鍵或快捷鍵激活拖拽狀態(tài)，拖拽完成后解除拖拽狀態(tài)。
Scroll交互是指鼠標(biāo)指針Hover于指定界面后，用鼠標(biāo)滾輪或輕劃動(dòng)作來實(shí)現(xiàn)界面內(nèi)容滾動(dòng)顯示。
Scroll狀態(tài)觸發(fā)條件：Hover于界面元素，滾動(dòng)鼠標(biāo)滾輪或上下輕劃鼠標(biāo)操作區(qū)。
這個(gè)動(dòng)作中文一般稱為“平移”，是指鼠標(biāo)指針懸停在某個(gè)UI控件上方時(shí)，可以通過在鼠標(biāo)二維平面和屏幕之間建立一種映射關(guān)系，來實(shí)現(xiàn)在UI空間內(nèi)的卷屏效果。
平移
這個(gè)動(dòng)作是Mac的OSX等操作系統(tǒng)支持的蘋果專用鼠標(biāo)提供的基于鼠標(biāo)Hover交互的交互方式，如果我們把觸摸板外設(shè)也作為鼠標(biāo)的變體和延伸的話，筆記本的觸摸板也提供這個(gè)交互方式。
Pan交互觸發(fā)條件：Hover于指定控件，二維平面內(nèi)輕劃鼠標(biāo)操作區(qū)實(shí)現(xiàn)。
Zoom交互分為放大（Zoom In）和縮小（Zoom Out）操作，一般是鼠標(biāo)指針Hover于指定界面或UI控件，通過鼠標(biāo)按鍵或快捷鍵激活Zoom狀態(tài)，縮放完成后，再通過釋放按鍵解除zoom狀態(tài)。
Zoom交互觸發(fā)條件：Hover于指定控件，通過鼠標(biāo)按鍵或快捷鍵激活Zoom狀態(tài)，二維平面內(nèi)輕劃鼠標(biāo)操作區(qū)實(shí)現(xiàn)Zoom效果，然后釋放按鍵解除Zoom狀態(tài)。
以上就是PC端鼠標(biāo)能夠?qū)崿F(xiàn)的主要交互行為。
看過了PC端鼠標(biāo)和界面元素的主要交互方式，下面讓我們來總結(jié)一下PC端鼠標(biāo)交互的最顯著的一些特性：
熟悉CSS的朋友可能知道頁面層級有一個(gè)z-index的屬性，它標(biāo)示了指定頁面元素在頁面層級中的深度，數(shù)值越大，越是處于更上層的層級，數(shù)值越小，越是處于更下層的層級。但不論是應(yīng)用內(nèi)的元素，還是應(yīng)用本身，包括系統(tǒng)桌面元素，都不能超越鼠標(biāo)指針?biāo)趯蛹墶Ｊ髽?biāo)指針?biāo)趯蛹壚碚撋鲜钦蕖?/p>
鼠標(biāo)層級
不管用戶是否在使用鼠標(biāo)操控屏幕元素，只要是添加了鼠標(biāo)外設(shè)且支持鼠標(biāo)操作的PC設(shè)備，從始至終都會有一個(gè)鼠標(biāo)指針永遠(yuǎn)停留在屏幕的某處，你用或不用，它就在那里。
雖然鼠標(biāo)投影于二維屏幕坐標(biāo)系內(nèi)的點(diǎn)和幾何意義上的點(diǎn)一致，即這個(gè)點(diǎn)沒有面積，僅是數(shù)學(xué)意義上的點(diǎn)，但屏幕二維坐標(biāo)可以粗略定義這個(gè)點(diǎn)的位置。
我們看到的“箭頭”、“手型”、“工字梁”、“移動(dòng)”顯示樣式是真正意義上的鼠標(biāo)指針的化身，鼠標(biāo)指針的樣式會根據(jù)所處元素的屬性而改變。
鼠標(biāo)指針的形態(tài)
鼠標(biāo)的行動(dòng)軌跡
PC端鼠標(biāo)的這個(gè)特性深刻影響了PC端鼠標(biāo)的交互行為，也是它和移動(dòng)端手勢交互的重要區(qū)別。
在PC端，鼠標(biāo)操作想要跟某個(gè)控件交互，首先要把鼠標(biāo)指針從當(dāng)前所在的點(diǎn)移動(dòng)到目標(biāo)控件顯示區(qū)域，軌跡球和光電鼠標(biāo)都是用鼠標(biāo)在桌面上移動(dòng)方向和軌跡來映射光標(biāo)移動(dòng)方向和軌跡。
所以，鼠標(biāo)運(yùn)動(dòng)一定要知道當(dāng)前鼠標(biāo)指針?biāo)谖恢?，才能操作鼠?biāo)向目標(biāo)位置移動(dòng)。這種運(yùn)動(dòng)并不是最自然的交互方式，甚至還因?yàn)檫@種操作不直觀發(fā)生過最早接觸鼠標(biāo)的一批人在遇到“請把光標(biāo)移動(dòng)到Windows窗口”這樣的操作指令時(shí)，直接把鼠標(biāo)貼到了屏幕上這樣的笑話。
僅從是否最符合用戶以物理世界移情于虛擬世界的心智模型的角度來看，鼠標(biāo)交互方式比起指哪打哪，無需考慮鼠標(biāo)指針前一個(gè)落點(diǎn)的觸控筆操作、手勢操作在直觀性上要欠缺很多。
而在PC端比較經(jīng)常發(fā)生的就是我們在想要找到鼠標(biāo)指針當(dāng)前位置時(shí)，結(jié)果卻因?yàn)橹羔樚』虮尘疤ㄉ诙閷げ灰?，OSX系統(tǒng)的快速晃動(dòng)鼠標(biāo)，鼠標(biāo)指針就會瞬間瞬間變大許多倍就是為了解決這種交互的一個(gè)缺點(diǎn)。
要把光標(biāo)移動(dòng)到某個(gè)點(diǎn)，需要知道當(dāng)前所在點(diǎn)
鼠標(biāo)指針的另一個(gè)特點(diǎn)是完全符合費(fèi)茲定律的限制，費(fèi)茲定律（Fitts’ Law）是心理學(xué)家 Paul Fitts 所提出的人機(jī)介面設(shè)計(jì)法則，是一種主要用于人機(jī)交互中的人類運(yùn)動(dòng)的預(yù)測模型。
它的公式是：
MT=a + b * log2(D/W + 1)
它主要定義了游標(biāo)移動(dòng)到目標(biāo)之間的距離、目標(biāo)物的大小和所花費(fèi)的時(shí)間之間的關(guān)系。目標(biāo)越大，完成點(diǎn)擊越快，時(shí)間越短。同樣地，目標(biāo)越近，指向越快，完成點(diǎn)擊時(shí)間越短。也就是說，定位點(diǎn)擊一個(gè)目標(biāo)的時(shí)間，取決于目標(biāo)與當(dāng)前位置的距離，以及目標(biāo)的大小。
我們不能說移動(dòng)端的手勢交互已經(jīng)擺脫了費(fèi)茲定律的束縛，但費(fèi)茲定律最早確實(shí)是針對PC端的交互而產(chǎn)生的，也最能反應(yīng)PC端鼠標(biāo)交互的特點(diǎn)。
鼠標(biāo)可以通過滾動(dòng)、滑動(dòng)等方式與指針?biāo)队拔恢玫腢I控件進(jìn)行交互，實(shí)現(xiàn)卷屏、平移、放大、縮小等操控效果，這一點(diǎn)是必須要通過接觸屏幕才能實(shí)現(xiàn)與控件進(jìn)行交互的移動(dòng)端設(shè)備有顯著不同的。
如果我們用移動(dòng)端的Touch來類比PC端的MouseDown的話，移動(dòng)端缺少了光標(biāo)懸浮情況下的各種交互可能，Surface的手勢懸浮觸控筆試圖在觸摸屏上復(fù)制PC端的鼠標(biāo)交互，但我對這一移植的前景并不看好。因?yàn)橐苿?dòng)端的設(shè)備交互方式自有其自身特點(diǎn)。
PC端設(shè)備的屏幕尺寸讓多項(xiàng)目、多應(yīng)用并行、分屏顯示成為常態(tài)，正常情況下，同一個(gè)屏幕上在同一時(shí)間只有一個(gè)窗口能夠成為激活狀態(tài)，未被激活的界面在鼠標(biāo)指針劃過界面元素時(shí)，一般不需要響應(yīng)指針的Hover動(dòng)作。
PC端設(shè)備有時(shí)候會在桌面上形成多個(gè)UI界面的堆疊，一般情況下，總是位于光標(biāo)投影點(diǎn)的最上層的界面和界面控件響應(yīng)鼠標(biāo)的點(diǎn)擊，并成為激活狀態(tài)（如果尚未激活的話）。
以上就是PC端鼠標(biāo)交互方式的一些特點(diǎn)，有些特點(diǎn)，在移動(dòng)設(shè)備上保留了下來。有些特點(diǎn)，則因?yàn)榧夹g(shù)或屏幕尺寸等原因被移動(dòng)設(shè)備交互完全放棄，熟悉了PC端交互方式和移動(dòng)端交互方式之間的區(qū)別，就能在設(shè)計(jì)應(yīng)用時(shí)，針對不同的設(shè)備特性做有針對性的優(yōu)化，以實(shí)現(xiàn)各個(gè)平臺的最大優(yōu)勢。
移動(dòng)端設(shè)備之所有又被稱為“移動(dòng)智能終端”，是因?yàn)橐苿?dòng)端設(shè)備由于嵌入了比PC設(shè)備多得多的各種傳感器，從而也就能實(shí)現(xiàn)比PC端多得多的交互效果。但因?yàn)楸疚闹饕且懻撌謩萁换ズ褪髽?biāo)交互的異同，所以對除了屏幕以外的其他傳感器交互方式不做進(jìn)一步的深入討論。
移動(dòng)端傳感器
PC上的鼠標(biāo)點(diǎn)擊會產(chǎn)生onmousedown、onmouseup、onmouseout、onmouseover、onmousemove的事件，但是在移動(dòng)終端頁面觸屏?xí)r會產(chǎn)生ontouchstart、ontouchmove、ontouchend、ontouchcancel 事件，分別對應(yīng)了觸屏開始、拖拽及完成觸屏事件和取消交互。
移動(dòng)端手勢交互和PC端最大的不同是：移動(dòng)端交互都是以Touch為基礎(chǔ)，只有手指接觸了屏幕，才能進(jìn)行后續(xù)的所有操作，任何交互都發(fā)生在手指Touch屏幕的那一瞬間之后。而PC端鼠標(biāo)要與界面UI控件之間發(fā)生交互，很多時(shí)候只需要光標(biāo)位置懸停在目標(biāo)控件之上即可完成。
移動(dòng)端Touch交互
這種根本性的交互差異深刻地影響了兩種設(shè)備的交互方式。
下面來看下移動(dòng)端可以實(shí)現(xiàn)的交互效果：
Tap，或稱為Click或Touch，是移動(dòng)設(shè)備上最常使用的一種手勢輸入方式，因手指已經(jīng)替代了智能筆，以犧牲點(diǎn)擊的精確度換取了便捷性。因此，要求確?？牲c(diǎn)擊的控件最小可點(diǎn)擊范圍(換算為物理尺寸大致在7mm－9mm之間)，可點(diǎn)擊范圍太小會影響用戶使用體驗(yàn)。
如果控件在點(diǎn)擊時(shí)和點(diǎn)擊后產(chǎn)生的操作之間間隔時(shí)間較久，建議控件在點(diǎn)擊時(shí)能夠在表現(xiàn)形式上做出即時(shí)反饋，這樣可以明確告知用戶點(diǎn)擊已生效而非系統(tǒng)卡死或沒點(diǎn)擊到。
Tap時(shí)的Active效果
滾動(dòng)是用戶在明確操作對象，與周圍環(huán)境阻尼系數(shù)較小時(shí)，通過快速移動(dòng)操作對象，并利用物體的慣性來達(dá)到移動(dòng)較長距離目的的操作方式。與拖拽相反，滾動(dòng)會盡量利用操作對象移動(dòng)的慣性，所以要求用戶在手指初次點(diǎn)擊屏幕到手指離開屏幕的持續(xù)時(shí)間短且點(diǎn)擊點(diǎn)和離開點(diǎn)的坐標(biāo)位置有較大差異。
雙擊是在手指界面上快速而連續(xù)的兩次輕敲，兩次輕敲之間間隔時(shí)間不能太長否則系統(tǒng)會作為兩次單獨(dú)的點(diǎn)擊處理。
雙擊
雙擊較多用于地圖、圖片瀏覽等場景中，一般會以點(diǎn)擊坐標(biāo)為中心點(diǎn)做一定程度的放大縮小操作。如果界面需要頻繁用到單次點(diǎn)擊，建議不要加入雙擊。如果使用了雙擊，就需要弱化或去除界面對單次點(diǎn)擊的反饋。由于雙擊的可發(fā)現(xiàn)性較弱，建議謹(jǐn)慎使用。
雙擊交互
長按是指手指在屏幕固定坐標(biāo)點(diǎn)按壓持續(xù)一定時(shí)長的手勢操作，如以PC端的左鍵點(diǎn)擊對應(yīng)移動(dòng)設(shè)備的點(diǎn)擊，則可以長按作為PC端右鍵點(diǎn)擊的對應(yīng)。一般多用于刪除列表項(xiàng)、啟動(dòng)編輯等應(yīng)用場景，但因?yàn)榭砂l(fā)現(xiàn)性弱，建議謹(jǐn)慎使用。
長按
在某些場景中，長按激活某控件的編輯狀態(tài)后，需要再配合點(diǎn)擊或拖拽手勢完成編輯任務(wù)，然后點(diǎn)擊“完成”、“結(jié)束”按鈕或界面上其它位置來恢復(fù)到默認(rèn)狀態(tài)。
長按激活拖拽
拖拽手勢是對現(xiàn)實(shí)世界中拖拽物體行為的一種簡單映射，用戶在拖拽物體時(shí)，期望控件落在一個(gè)較精確可控的坐標(biāo)點(diǎn)。
如果被拖拽物體所在環(huán)境，對被拖拽物體阻尼系數(shù)較大，用戶在物體到達(dá)目標(biāo)坐標(biāo)點(diǎn)后可以快速松開手；如果被拖拽物體所在環(huán)境對其阻尼系數(shù)較小，用戶在物體到達(dá)目標(biāo)坐標(biāo)點(diǎn)后會持續(xù)一小段時(shí)間以消除運(yùn)動(dòng)慣性，帶有限位刻度的，用戶會使用快速的拖拽，甚至是不精確的點(diǎn)擊來實(shí)現(xiàn)物體往目標(biāo)點(diǎn)的移動(dòng)。這些對用戶來說操作和反饋都是與現(xiàn)實(shí)世界一致的下意識行為，學(xué)習(xí)成本極低。
拖拽效果實(shí)現(xiàn)機(jī)制
輕掃手勢較多用于被操作對象有固定行程，且每段行程之間都需要單獨(dú)的輕掃手勢操作的情況，使用此手勢操作的用戶對于被操作對象的操作方式、操作結(jié)果有明確認(rèn)知。
輕掃交互
輕掃應(yīng)用場景
捏夾手勢是兩個(gè)手指在屏幕上做出捏夾動(dòng)作，系統(tǒng)根據(jù)手指落點(diǎn)坐標(biāo)和離開坐標(biāo)判斷兩指之間的距離是增大還是減小，并對界面進(jìn)行相應(yīng)的放大縮小操作。
Pinch交互
旋轉(zhuǎn)手勢是兩個(gè)手指對操作對象進(jìn)行旋轉(zhuǎn)操作，使操作對象也旋轉(zhuǎn)相應(yīng)角度的操作方式。
旋轉(zhuǎn)交互
其他手勢操作：
其他手勢交互
以上就是移動(dòng)端手勢操作的基本交互方式。下面，我們來一起分析移動(dòng)端手勢操作相較于PC端鼠標(biāo)操作的異同點(diǎn)。
在PC端用戶要判斷一個(gè)控件可以與之互動(dòng)的操作方式，可以用鼠標(biāo)在目標(biāo)控件上進(jìn)行“探測”，鼠標(biāo)指針和控件本身的形態(tài)變化都能夠明確指示用戶可以執(zhí)行的操作。
而在移動(dòng)端用戶要判斷一個(gè)控件的交互方式，除了控件本身的UI設(shè)計(jì)帶來的暗示以外，在真正點(diǎn)擊這個(gè)控件之前，都無法真正確定。這像極了量子物理理論里的“薛定諤的貓”，即你在真正點(diǎn)擊控件之前，你永遠(yuǎn)無法預(yù)知按鈕真正支持的操作方式。
此外由于移動(dòng)端所有交互都是基于Touch的，所以此交互行為和PC端有極大差異，PC端除了拖動(dòng)窗口滾動(dòng)條實(shí)現(xiàn)界面滾動(dòng)效果之外，基本都是用鼠標(biāo)指針懸停于目標(biāo)控件之上通過滾輪或輕劃實(shí)現(xiàn)滾動(dòng)效果。所以，PC端的滾動(dòng)交互，鼠標(biāo)指針和UI控件之間是沒有發(fā)生實(shí)質(zhì)意義的接觸的（如果我們把Hover視為無接觸的話）。
但移動(dòng)端由于屏幕物理尺寸限制，滾動(dòng)操作和點(diǎn)擊操作并列成為移動(dòng)端交互的兩大最重要交互方式。滾動(dòng)操作一定要手指先接觸屏幕表面，快速滑動(dòng)一段距離并抬起以實(shí)現(xiàn)滾動(dòng)效果。
所以，在手指按壓屏幕的瞬間，位于手指于屏幕接觸點(diǎn)的UI控件是有極大幾率被激活到“Active”狀態(tài)的，只是系統(tǒng)在判斷操作行為是“滾動(dòng)”而非“點(diǎn)擊”行為后，對Active目標(biāo)控件執(zhí)行了ontouchcancel——也就是目標(biāo)控件雖然被激活，但并沒有執(zhí)行后續(xù)運(yùn)行結(jié)果。
在移動(dòng)端，用戶在點(diǎn)擊控件后，如果新的內(nèi)容和反饋和點(diǎn)擊行為發(fā)生的時(shí)間中間有“Gap”，則用戶可能會對控件是否已被接收到交互產(chǎn)生迷惑。
如果這個(gè)Gap時(shí)間很長，則直接影響用戶體驗(yàn)，尼爾森法則里的狀態(tài)可見原則就是要預(yù)防這種情況：用戶在網(wǎng)頁上的任何操作，不論是單擊、滾動(dòng)還是按下鍵盤，頁面應(yīng)即時(shí)給出反饋。“即時(shí)”是指，頁面響應(yīng)時(shí)間小于用戶能忍受的等待時(shí)間。
移動(dòng)端對于控件在被點(diǎn)擊的瞬間能夠提供的效果反饋定義很不一致。
有的應(yīng)用，有的模塊提供了類似PC端的Active效果。
安卓的Material Design脫離了PC端UI控件交互方式的束縛，用Touch后的強(qiáng)反饋效果來指示用戶點(diǎn)擊產(chǎn)生的即時(shí)反饋，是一種很好的思路。
Material Design 的點(diǎn)擊動(dòng)效
以上的這些差異這也就對移動(dòng)端控件的設(shè)計(jì)帶來了新的要求：
a. 移動(dòng)端控件設(shè)計(jì)要嚴(yán)格按照設(shè)計(jì)規(guī)范
如支持移動(dòng)的控件，除了設(shè)計(jì)上增加控件“可移動(dòng)”的隱喻之外，還要標(biāo)配可移動(dòng)圖標(biāo)。
移動(dòng)端交互要配合明確的指示圖標(biāo)
如內(nèi)容不可點(diǎn)擊，就不要設(shè)計(jì)成列表項(xiàng)樣式。之前文章里曾經(jīng)舉過一個(gè)工作中遇到的例子，產(chǎn)品經(jīng)理想要把一組只讀性信息做成列表項(xiàng)樣式，這樣設(shè)計(jì)必然會讓用戶產(chǎn)生迷惑，從而帶來非常大的用戶體驗(yàn)問題。
只讀信息不能設(shè)計(jì)成列表項(xiàng)樣式
如樓層圖不可點(diǎn)擊，就不要設(shè)計(jì)成可點(diǎn)擊樣式。之前在實(shí)際項(xiàng)目中，遇到過一個(gè)聚合頁，樓層圖設(shè)計(jì)的樣式是明顯引導(dǎo)用戶點(diǎn)擊樓層頭圖進(jìn)入詳情頁的，雖然沒有加“更多”按鈕，這樣的設(shè)計(jì)就會引起很多體驗(yàn)問題。
樓層頭圖可否點(diǎn)擊 設(shè)計(jì)要符合自身特點(diǎn)
b. 移動(dòng)端控件設(shè)計(jì)要符合用戶心理預(yù)期和使用習(xí)慣
對于從來沒有接觸過移動(dòng)端設(shè)備和交互方式的用戶來說，如果要實(shí)現(xiàn)編輯一個(gè)控件，無論是左滑進(jìn)入編輯狀態(tài)還是長按進(jìn)入編輯狀態(tài)，都是需要一定的學(xué)習(xí)成本和學(xué)習(xí)過程的，但用戶一旦掌握了這種交互方式，就會在使用時(shí)形成關(guān)于如何操作此類控件的心理模型。
一般來說，用戶并不會太關(guān)注iOS平臺和安卓平臺的區(qū)別。所以，無論在什么類型的設(shè)備上，用戶都趨向于使用同一套思路去解決類似問題。如果條件允許，在可控范圍內(nèi)盡量實(shí)現(xiàn)控件交互方式和交互反饋的統(tǒng)一，是對用戶體驗(yàn)的最大支持。
如果不可控因素太多，那也要盡量按照下述優(yōu)先級去統(tǒng)一交互反饋：跨平臺交互反饋統(tǒng)一 > 系統(tǒng)內(nèi)交互反饋統(tǒng)一 > 應(yīng)用內(nèi)交互行為統(tǒng)一 > 板塊內(nèi)交互行為統(tǒng)一
c. 移動(dòng)端控件設(shè)計(jì)要符合用戶心智模型
移動(dòng)端的交互方式是觸摸手勢交互，所以相較于使用鼠標(biāo)來操作的PC端，移動(dòng)端與現(xiàn)實(shí)世界的交互方式對照也更緊密和一致。
早期的擬物化風(fēng)格UI界面上，相冊、日歷、筆記本、按鈕、開關(guān)、拖拽控件等，都是現(xiàn)實(shí)世界物品的完全照搬，都可以在現(xiàn)實(shí)中找到完全對應(yīng)的實(shí)物。正因?yàn)檫@樣，用戶的心智模型也更加穩(wěn)固，更加與現(xiàn)實(shí)一致。
擬物化圖標(biāo)
而一些比較抽象的如跳轉(zhuǎn)、彈框、返回等交互，用戶也已經(jīng)形成了固定的心智模型，甚至形成了穩(wěn)定的空間記憶。一旦遇到問題，用戶會在屏幕的二維空間固定位置去尋找對應(yīng)的控件。
d. 移動(dòng)端控件要盡量使用簡單，直接、可發(fā)現(xiàn)性高的交互方式
因?yàn)橐苿?dòng)端相比PC端缺少了鼠標(biāo)Hover來發(fā)現(xiàn)適合的交互方式的特點(diǎn)，移動(dòng)端用戶只有在手指實(shí)際接觸到屏幕的瞬間才能真正了解控件支持的交互方式。
所以，移動(dòng)端的交互方式要求盡量采用簡單、直接、可發(fā)現(xiàn)性強(qiáng)的交互方式，那些學(xué)習(xí)成本高的，不符合用戶心智模型和心理預(yù)期的交互方式注定會成為用戶體驗(yàn)的阻礙。
這也是為什么我們除了Demo演示App等少數(shù)特殊場景需求的應(yīng)用外很少看到多手指手勢大范圍應(yīng)用的原因，因?yàn)殡S著控制手勢的手指數(shù)量增加，操作復(fù)雜度的上升是指數(shù)級的。
如下圖這種多手指手勢操作，就極復(fù)雜且不符合用戶心智模型，用戶在使用過程中不但學(xué)習(xí)成本高，后期也難記起這些手勢：
復(fù)雜的手勢影響用戶體驗(yàn)
e. 如果控件交互后載入內(nèi)容有延遲，則建議在控件上增加“Active”效果以提示用戶控件已接收到交互請求并在處理。
移動(dòng)端不是強(qiáng)制要求添加控件的Touch時(shí)的Active效果，但如果某些控件如跳轉(zhuǎn)新頁面的列表項(xiàng)等，在用戶Touch了屏幕上的控件到新的頁面刷新加載之間可能會有一段延遲時(shí)間。如果這個(gè)延遲時(shí)間較長，則可以考慮增加“Active”效果以增加體驗(yàn)流暢度，減少誤操作。
Active效果
