費茲定律與使用者界面設計

　　之前在〔HCI〕談人機介面設計與Usability一文中提到了usability的概念，並用了Windows的開始鈕說明了在設計UI上容易忽略的陷阱。這篇文章我會繼續探討介面設計與usability，並以效率（Efficiency）與UI設計時最重要的定律之一費茲定律（Fitts’Law）為重點。
　　設計軟體的操作介面並不難，但很多時候直覺的設計並不一定能達成想像中的目的。這就是usability的研究想要了解的，到底什麼樣的設計才是更好的設計？什麼樣的設計其實只會讓usability變得更糟？
　　以menubar為例，menu是圖形介面（GUI）的最基本元素之一，現代軟體功能越來越強大，包山包海的結果就是menu變得越來越多、越來越深，每一個menu展開後幾乎都有submenu，甚至還有subsubmenu等等複雜的選單。我每次教我爸媽用電腦時，都覺得Windows的menu根本是設計來折磨使用者的，奇妙的是竟然很少聽人在抱怨這介面很難用，而是紛紛強迫自己學會這種操作模式。
　　我想會看到這篇文章的讀者，早就很習慣於操作GUI了，也沒想過選單能有什麼好用或難用之別。所以先讓我們來想想要開啟一個埋藏在submenu裡的功能是多困難的工作（就假設是檔案最近開啟某檔案。txt好了）。第一，把游標移到menubar的檔案上，並停住不動；第二，按下滑鼠左鍵打開檔案選單，把游標垂直往下移到最近開啟上停住；第三，等submenu打開，把游標水平往右移進submenu裡；第四，再度垂直往下找到某檔案。txt，在上面停住並按下左鍵。好，想像完畢後你可以試著用你的非慣用手操作滑鼠做一次看看。
　　如果是已經很熟悉GUI的使用者，想必都不覺得操作選單有什麼困難的，但當你被迫用非慣用手操作時，一定會感覺到操作速度大大的降低，甚至沒辦法精準控制游標進入submenu，這時我們才有機會體認到操作滑鼠其實並不容易。除此之外，如果仔細觀察，還可以發現進入submenu又比平常把游標移到任意地方還困難，因為必須把游標保持在一條狹長的隧道裡水平移動，如果在移動時不小心移出了這條隧道，submenu就會關閉。
　　有個有趣的案例發生在一個著名的opensource影像處理軟體GIMP上（可以說是免費版的photoshop）。當初開發GIMP的團隊曾做過一個有趣的決定，他們決定拿掉固定在視窗頂端的menubar，並用可以在任何地方按右鍵打開的contextmenu取代。因為contextmenu可以在任何地方打開，GIMP的開發團隊認為這樣可以加快存取menu的速度。這個想法很直覺，但真的對efficiency有幫助嗎？
　　既然我都說了這麼多，答案當然不會是yes。
　　contextmenu對efficiency並沒有幫助，反而使之變得更差。為什麼呢？
　　如上圖，從第一層的選單要進入第二層時，必須先經過第一層狹窄的隧道（紅色區域），才能進入第二層選單。如果直接走直線路徑到想要按的目標，就會先經過第一層的其他項目，導致不同的submenu被打開。傳統的menubar也是有submenu，所以直覺上可能不會覺得多一層的submenu會有多大影響，但事實上是這種把游標限制在一條隧道裡的設計大大的降低了操作游標的速度，和一般可以經由任意路徑指到目標的操作有指數級的速度差異。
　　Fitt在1954年提出了Fitt’sLaw，可以說是人機互動領域的第一條定律，對人類指向任一目標的動作建立了一個數學模型。基本的概念是，移到目標上的時間（T）可以表示為目標距離（D）與目標大小（W）的函數。具體來說，Tablog2（DW1），a和b都是一個常數。
　　Fitt’sLaw告訴我們，移到任意目標上的時間大約跟目標距離除以目標大小的對數成正比。也就是說，目標越遠移動時間就越長，目標越小時間也會越長；反之，目標越近或目標越大的話，所需時間就越短。有趣的是，距離和目標大小的影響並不算大，經過log讓這兩個變數的影響降低了一個指數等級。例如距離變長1000倍，並不會讓時間也變成1000倍，而是變成log2（1000），大約是10倍而已。
　　在軟體介面上，Fitt’sLaw有個特例值得討論一番。在電腦裡的滑鼠游標，有個基本特性是其活動範圍被限制在螢幕裡，只要游標到了螢幕邊緣，無論再怎麼繼續往同一個方向移動滑鼠，游標還是只能停留在邊緣上。這個特性讓UI設計有了戲劇性的變化，一個最有趣的例子是Windows和MacOSX的menubar設計。
　　Microsoft的Windows自古以來的UI設計都是把menubar放在視窗的titlebar下面，而MacOS採取完全不同的設計：把menubar固定在螢幕最頂端。一般人大多覺得這兩種設計只是習慣問題，沒有什麼客觀差別，但如果你已經學會了Fitt’sLaw，你覺得哪一種設計比較好呢？
　　如果直接套用Fitt’sLaw，第一個得到的答案很可能會是Windows的設計比較好，因為當滑鼠從視窗內移往menubar時，距離會比移到螢幕頂端還近。可是，別忘了考慮螢幕邊緣所造成的影響。Mac把menubar放在螢幕頂端，雖然距離變長了，但目標的大小也跟著變成了無限大。因為螢幕的邊緣會阻擋住游標的行動，於是使用者可以盡情的把用力滑鼠往上一甩，不用停下來對準目標，也就等同於目標的大小變成了無窮大。在Fitt’sLaw中，當W是無限大時，整個log函數得到的結果會變成0，也就是說T就會變成一個簡單的常數值a，跟距離或大小都沒有關係了。
　　如此比較之下，我們就可以發現Mac把menubar放到螢幕頂端是有其用意在的，因為它大大減少了把滑鼠放進menubar並對準目標的時間，使用者只要把滑鼠用力往前一移，自然就會進入menubar裡面了。我在〔HCI〕談人機介面設計與Usability一文中也提過Windows開始鈕的例子，跟menubar的例子也是相同的道理。
　　到目前為止，我們已經看過了三種形式的menu。對於efficiency而言，我們知道Mac的設計比Windows的設計還好，那如果和GIMP的contextmenu比起來呢？從Fitt’sLaw可以得知，Mac的設計已經達到極限了，無論如何也沒辦法捨去那個常數a，所以我們可以直接來比Windows的設計和GIMP的設計哪個比較差XD。
　　前面提過，submenu是一種很難的指向操作，除了要把游標移到目標上，還限制了中間經過的路徑在一個隧道裡。在Fitt’sLaw之後，AccotandZhai提出了Steeringlaw。其結論非常簡單，讓游標經過一個寬度W的隧道移動距離D的時間TabDW。換句話說，把移動路徑限制住的話，其移動到目標的時間和一般性移動（Fitt’sLaw）所需的時間是指數級的差距，這也就是為什麼電流急急棒可以變成一個有百萬獎金的挑戰，而隨意動動滑鼠則簡單的多。
　　了解了Steeringlaw之後，再回來看submenu的設計，你就會發現submenu是一個多不人道的設計。每一層的menu其實都是一個steering操作：垂直的menu移動比較簡單，因為menu寬度通常都蠻寬的；但每當要水平移動進入下一層submenu時，就是一個困難的挑戰，因為這時的寬度變成了menuitem的高度，通常也就是一個字母高而已。和Fitt’sLaw不同的是，寬度（W）變小n倍，對時間的影響不再是對數，而真的就是讓時間變長n倍。所以說呢，如果可以迅速又準確進入多層submenu的滑鼠高手，其實也有參加電流急急棒比賽的能力呢！
　　回過頭來看Windows和GIMP的menu設計，這時就可以明顯比較出來。GIMP把所有的選單操作全都變成了steering操作，Windows雖然也有submenu的問題，但至少第一層還是任意的指向操作，所以就efficiency來說，GIMP的設計其實是一大失策。。。
　　最後，再順便提兩個Windows和MacOSX對於submenu造成的問題所提供的解決方法。微軟和Apple都知道submenu很難操作，所以他們其實都有偷偷的在介面上做了一點貼心的設計。微軟的方法是，在游標要進入submenu時，如果不小心移出隧道外，只要在一定的時間內移回來，submenu就不會消失。這個方法其實有些風險，主要是因為這個時間很難掌控。如果這個設定的時間太短，那就沒多大效果；但如果設定太長，使用者如果是真的想要移到別的menuitem打開另一個submenu，就會覺得系統反應太慢（就是那種頓頓的感覺）。所以，微軟的這個方法其實並不是很有效的解決這問題。
　　而Apple雖然也是用同樣的方法來submenu不要馬上消失，但他們又加上了一個聰明的設計：submenu的延遲消失只有在游標到submenu的頂端和底端形成的三角形內有效。換句話說，如果使用者是想進入submenu中，他甚至可以直線移動滑鼠進入其中而不會意外打開另一個不同的submenu（只要在設定的延遲時間內移動完成）。而假如使用者是想打開另一個submenu，那直覺的把滑鼠往下移動就會自然的避開這個三角形區域而避免了頓頓的感覺。