2016-11-10 ui設(shè)計(jì)分享達(dá)人
如果您想訂閱本博客內(nèi)容，每天自動(dòng)發(fā)到您的郵箱中，?請點(diǎn)這里
要探索費(fèi)茲定律的運(yùn)用方式，我們首先需要了解這條定律是什么，它是怎樣誕生的。
費(fèi)茲定律由俄亥俄州立大學(xué)的心理學(xué)家Paul Fitts于1954年提出，旨在為人類在電腦屏幕上點(diǎn)擊目標(biāo)對(duì)象的行為建立模型，同時(shí)涉及到了肢體移動(dòng)及鼠標(biāo)行為方面的問題。
舉個(gè)栗子，設(shè)想你的注意力和鼠標(biāo)指針正停留在某個(gè)網(wǎng)站的logo上，而你被告知要去點(diǎn)擊頁面中的某個(gè)按鈕，于是你需要將注意力焦點(diǎn)及鼠標(biāo)指針都移動(dòng)到那個(gè)按鈕上。這個(gè)移動(dòng)過程當(dāng)中的效率問題就是費(fèi)茲定律所關(guān)注的。
費(fèi)茲定律的原始公式是這樣的：
MT=a + b * log2(D/W + 1)
其中MT代表位移所需花費(fèi)的時(shí)間，這是我們最需關(guān)注和解決的問題。a與b兩個(gè)變量代表系統(tǒng)方面的耗時(shí)及效率，屬于經(jīng)驗(yàn)參數(shù)。D代表初始位置與目標(biāo)位置之間的距離，W代表目標(biāo)對(duì)象的尺寸。
這套公式所表達(dá)的基本概念是：目標(biāo)對(duì)象距離越遠(yuǎn)或尺寸越小，用戶點(diǎn)擊的困難就越大，耗時(shí)越長；反之，距離越近、尺寸越大，就越容易準(zhǔn)確點(diǎn)擊，耗時(shí)越少。
拿實(shí)例說事兒，來對(duì)比一下Windows與Mac(OS X Lion之前的版本)中的滾動(dòng)條。在Windows中，縱向滾動(dòng)條上下兩端各有一個(gè)按鈕，里面的圖標(biāo)分別是向上和向下的箭頭；橫向滾動(dòng)條也是類似。這種模式確實(shí)更符合用戶的心智模型，因?yàn)橛|發(fā)左右移動(dòng)的交互對(duì)象分別處于左右兩端，你到左邊尋找向左移動(dòng)的方法時(shí)會(huì)看到左箭頭按鈕，向右側(cè)也是一樣；而Mac系統(tǒng)則將左右按鈕并列在同一側(cè)，使左右導(dǎo)航的點(diǎn)擊操作所需跨越的距離大大的縮短，提高了操作效率。
在UX的世界中，目標(biāo)用戶群的特征是我們需要時(shí)刻牢記在心的，對(duì)于費(fèi)茲定律的運(yùn)用也是同樣的道理。對(duì)于目標(biāo)用戶中包含了兒童、老人甚至是殘障人士的產(chǎn)品來說，界面交互元素的尺寸需要更大，以便這類相對(duì)特殊的用戶可以很容易的點(diǎn)擊操作。
在設(shè)計(jì)任何一個(gè)可交互的UI元素時(shí)，我們都需要考慮它的尺寸以及與其他元素之間的相對(duì)距離關(guān)系。市面上有各種各樣的設(shè)計(jì)規(guī)范，其中多數(shù)都會(huì)提到按鈕最小尺寸以及與其他交互元素之間排布距離方面的問題。盡量將多個(gè)常用的功能元素放置在距離較近的位置；另外需要考慮的是，對(duì)于那些會(huì)產(chǎn)生高風(fēng)險(xiǎn)的交互元素，在很多時(shí)候你不希望用戶能夠很輕松的點(diǎn)擊到它們，這種情況下要盡量將這些元素與那些較為常用的界面元素放置在相對(duì)距離較遠(yuǎn)的位置上。如下圖所示，這里的危險(xiǎn)操作(刪除按鈕)與常用的下載按鈕之間的距離就過近了。
角落 - 對(duì)應(yīng)著費(fèi)茲公式中的“W”，處于界面角落上的元素可以被看做是具有無限大尺寸的，因?yàn)楫?dāng)鼠標(biāo)指針處于屏幕邊緣時(shí)，它就會(huì)停下移動(dòng)，無論怎樣繼續(xù)向“外”挪動(dòng)鼠標(biāo)，指針的位置都不會(huì)改變。用戶可以很輕松的點(diǎn)擊到處于角落的交互元素，只要將鼠標(biāo)向角落的方向猛的劃過去就OK，屏幕邊緣會(huì)自動(dòng)將指針限定在角落的位置上。這也正是Windows的開始按鈕以及Mac的系統(tǒng)菜單被放置在左下角或左上角的原因之一。
頂部和底部 - 與“角落”類似，由于屏幕邊緣的限制，界面頂部和底部也是容易容易定位和點(diǎn)擊的位置，不過確實(shí)沒有角落更容易，因?yàn)檫@兩個(gè)位置只在縱向上受到了約束，在橫向上依然需要用戶手動(dòng)定位；但怎樣都比邊緣以內(nèi)的元素更容易點(diǎn)擊。出于這個(gè)原因，蘋果將菜單放置在了整個(gè)屏幕的頂部，也就是最頂端的位置，而不是像Windows那樣只將菜單放在了當(dāng)前活躍窗口自身的頂部。
彈出菜單 - 讓彈出菜單呈現(xiàn)在鼠標(biāo)指針旁邊，可以減少下一步操作所需要的移動(dòng)距離，進(jìn)而降低操作時(shí)間的消耗。
輪盤彈出菜單 - 從費(fèi)茲定律的角度來看，輪盤彈出菜單是一種很棒的模式，因?yàn)檎麄€(gè)菜單是以鼠標(biāo)指針?biāo)诘奈恢脼閳A心來呈現(xiàn)的，每個(gè)菜單項(xiàng)距離鼠標(biāo)指針都很近，而且等距。那么為什么這種形式并不是非常普及呢？坦誠的說，最主要的原因還是設(shè)計(jì)方面的難度較大，而且通常不會(huì)被包含進(jìn)各種標(biāo)準(zhǔn)的UI控件庫。
我們接下來要分別了解兩種主要類型的移動(dòng)設(shè)備。之所以要分開講，是因?yàn)樗鼈兏髯缘某叽缣匦源_實(shí)導(dǎo)致了一些交互上的區(qū)別。我們將用手機(jī)指代3.5寸屏幕的設(shè)備，用平板電腦指代7寸屏設(shè)備。當(dāng)然，這樣按照尺寸進(jìn)行的分類并不很，我們只是通過這種方式在本文中說事兒。
即使是同一款移動(dòng)設(shè)備，交互方式也會(huì)隨著屏幕定向方式的變化而有所區(qū)別。這一點(diǎn)有別于傳統(tǒng)桌面設(shè)備，因?yàn)闊o論在怎樣的情況下，我們使用鼠標(biāo)的方式都是一致的。你可能會(huì)想到筆記本上的觸控板，但這類設(shè)備并不會(huì)改變費(fèi)茲定律在桌面設(shè)備中的運(yùn)用特性。
角落和邊緣效應(yīng)同樣會(huì)作用于觸屏移動(dòng)設(shè)備當(dāng)中，但方式有所不同。與桌面設(shè)備不同，你的手指并不會(huì)像鼠標(biāo)指針那樣真正受到屏幕邊框的限制，處于這些位置的元素不再有所謂的無限尺寸。那么為什么說這類效應(yīng)同樣可以體現(xiàn)在移動(dòng)設(shè)備中呢？
多數(shù)情況下，人們都是通過拇指在觸屏移動(dòng)設(shè)備上進(jìn)行操作的，所以我們需要在拇指的移動(dòng)范圍考慮費(fèi)茲定律的作用。不過，一旦界面元素的定位超出了拇指熱區(qū)的范圍，那么針對(duì)該元素的操作就需要付出更多的努力，相應(yīng)的，費(fèi)茲定律的公式中也需要增加額外的變量來應(yīng)對(duì)移動(dòng)時(shí)間的增長。在接下來的討論中，我們需要始終記住這一點(diǎn)。
我們首先來看豎屏的情況，因?yàn)檫@是3.5寸設(shè)備最常見的使用方式。我并不想總是拿蘋果當(dāng)做例子，但他們確實(shí)在幕后做了很多聰明的好事，其中有些在體驗(yàn)提升方面的努力和堅(jiān)持是不為普通用戶所知的。(4S以及之前的)iPhone的尺寸是恰到好處的，因?yàn)樗梢员ＷC人類平均的拇指長度能夠觸及到屏幕上的任何一個(gè)位置。而回頭看看臺(tái)式設(shè)備，通常，要使指針跨越全屏，我們一次只能移動(dòng)約四分之三的距離，然后就需要抬起鼠標(biāo)再移動(dòng)一次，完成剩下的路程。
正如Josh Clark所說，在移動(dòng)設(shè)備中對(duì)特定的UI元素所進(jìn)行的布局都是有講究。iPhone中的原生工具欄與Tab欄都是定位在屏幕底部的，因?yàn)樵谡ＸQ屏持機(jī)的情況下，這個(gè)區(qū)域正是拇指伸直或彎曲所能覆蓋到的范圍。而要觸及到頂部標(biāo)題欄中的元素，需要的成本則略高，因?yàn)檫@個(gè)位置已經(jīng)超出了拇指熱區(qū)的范圍，有些用戶需要改變手掌的姿勢才能夠到左上角的按鈕；將拇指移動(dòng)到這里的行為已經(jīng)不是簡單的無障礙的過程了。
而Andorid的模式則有所不同，他們將相關(guān)工具及菜單放在了界面頂部。這不是沒原因的，因?yàn)锳ndorid設(shè)備的一些硬件控制是位于屏幕底部的，所以他們將界面中的菜單放置在頂部，以避免兩組交互元素由于位置過近而導(dǎo)致用戶產(chǎn)生誤操作；這是費(fèi)茲定律的一個(gè)很直接的體現(xiàn)(雖然是相反的)。
此外，我們還可以在一些可能帶來風(fēng)險(xiǎn)的交互環(huán)節(jié)(“關(guān)閉”、“刪除”、“取消”等等)當(dāng)中看到費(fèi)茲定律的某種衍生，例如在iPhone中的列表單元里向左滑動(dòng)展開“刪除”按鈕，或是點(diǎn)擊左側(cè)的刪除圖標(biāo)而激活右側(cè)“刪除”按鈕的雙重確認(rèn)方式，都是通過在交互過程中人為的制造距離和障礙來增大操作困難度，以達(dá)到防錯(cuò)的目的。
在橫屏狀態(tài)下，如果你想盡量降低用戶手指操作的移動(dòng)成本，那么屏幕左右邊緣的位置則是你必須考慮的重要區(qū)域。橫屏的時(shí)候，用戶通常是雙手操作的，拇指熱區(qū)變成了兩個(gè)，費(fèi)茲定律適用的范圍擴(kuò)大了很多。
不過相應(yīng)的，屏幕正中的上下兩側(cè)就變成了最難觸及到的地方，所以一些常用的或重要的操作要盡量避免被布局在這些位置，而對(duì)于一些刻意要增加難度的操作，則可以考慮這些位置。
另外一種情況就是用戶會(huì)一手拿著手機(jī)，另外一只手進(jìn)行操作。這種情況下拇指作用范圍的問題就不存在了。不過很多用戶在這種時(shí)候只會(huì)固定的使用一只手指進(jìn)行操作，這其實(shí)不大理想，特別是在打字或游戲等情境中。
Josh Clark曾經(jīng)強(qiáng)調(diào)過，很多人在使用平板的時(shí)候會(huì)拿著機(jī)身的上半部分，特別是在半臥或仰臥的狀態(tài)下。這時(shí)，屏幕左上角或右上角就是最重要的熱區(qū)，你需要考慮將一些常用的或是需要吸引注意力的元素放置在這些位置。
不過從我的個(gè)人經(jīng)驗(yàn)來說，我也確實(shí)見過很多人拿著平板的機(jī)身底部進(jìn)行使用，特別是在打字的時(shí)候。這種情況下，拇指熱區(qū)又轉(zhuǎn)移到了屏幕的左下角或右下角。所以能否針對(duì)自己產(chǎn)品的特性來規(guī)劃出一個(gè)最得當(dāng)?shù)牟季衷瓌t，這也是作為設(shè)計(jì)師需要面對(duì)的挑戰(zhàn)。
對(duì)于平板來說，在豎屏狀態(tài)下單手持機(jī)還算相對(duì)輕松，但要橫過來就有些挑戰(zhàn)了，由于設(shè)備本身相對(duì)較重，所以會(huì)有掉落的危險(xiǎn)。在橫屏的時(shí)候，用戶通常都是雙手同時(shí)持機(jī)的。另外需要記得的一點(diǎn)是，橫屏?xí)r，home鍵(或安卓的菜單按鍵)總會(huì)出現(xiàn)在一側(cè)的，這時(shí)如果界面?zhèn)冗呏虚g位置出現(xiàn)大量常用交互對(duì)象的話，有可能會(huì)因?yàn)榕c硬件按鈕距離過近而產(chǎn)生誤操作。
前面提到的這些都屬于用戶自己持機(jī)的情況，但很多時(shí)候你也可以看到人們是在“?？磕Ｊ健毕率褂闷桨宓?，例如放在膝上、桌上或是支架上。這時(shí)，拇指熱區(qū)就不再是問題了，費(fèi)茲定律的作用范圍可以延展到全屏。
要記住，切換持機(jī)方式和屏幕定向是用戶經(jīng)常會(huì)做的事情，他們在切換的時(shí)候甚至不會(huì)多做考慮，只是想得到一個(gè)當(dāng)下最方便最舒服的狀態(tài)。對(duì)于設(shè)計(jì)師來說，除非確定在開發(fā)過程中固化了定向規(guī)則，否則不能假設(shè)用戶一定會(huì)保持在某種定向模式下持續(xù)的使用。我們要對(duì)每種定向模式所對(duì)應(yīng)的交互特征心知肚明，在每種模式中都考慮費(fèi)茲定律的作用范圍，在設(shè)計(jì)中進(jìn)行相應(yīng)的體現(xiàn)。
費(fèi)茲定律可以在不同的平臺(tái)中以不同的形式發(fā)生作用，要打造上乘的產(chǎn)品體驗(yàn)，我們就需要了解這些作用形式。特別是在移動(dòng)設(shè)備上，我們會(huì)面臨很多在傳統(tǒng)桌面設(shè)備中不曾遇到的挑戰(zhàn)與變數(shù)。當(dāng)然，費(fèi)茲定律絕不是唯一需要考慮的設(shè)計(jì)原理，但絕對(duì)是非常常用的、幾乎會(huì)在界面設(shè)計(jì)過程中時(shí)時(shí)處處體現(xiàn)出來的一個(gè)。
藍(lán)藍(lán)設(shè)計(jì)( bouu.cn?)是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì)?、 cs界面設(shè)計(jì)?、 ipad界面設(shè)計(jì)?、 包裝設(shè)計(jì)?、 圖標(biāo)定制?、 用戶體驗(yàn) 、交互設(shè)計(jì)、?網(wǎng)站建設(shè)?、平面設(shè)計(jì)服務(wù)
藍(lán)藍(lán)設(shè)計(jì)的小編 http://bouu.cn
