十二月 6, 2009
» [HCI] 淺談模式”mode”與文字編輯的技術與學習

很久以前就想過要寫一篇關於文字編輯(text editing)的文章,當然我要講的不是要怎麼寫文章,而是關於使用文字編輯器(text editor)的技術。

文字編輯可以說是電腦歷史上最古老也最被廣泛使用的功能之一,無論是古老的mainframe或是現代的PC、Mac,甚至是手機,上面一定都有文字編輯的功能。人們每天都在用文字編輯器,不管是寫blog、打報告、寫程式,即使只是用twitter或plurk寫一句話,也都是在做文字編輯。既然這件事每個人每天都在用,還有什麼好談的呢?有趣的地方就在於,雖然大家每天都在用文字編輯器,但很少人會仔細去想要如何才能把這件事做得更快更好。怎樣的編輯器才是一個好用的編輯器?怎樣的編輯器用起來才能讓人感到行雲流水、人機合一的美妙境界?

我們先從一般最常見的編輯器說起。一個常見的編輯器就像Windows的記事本一樣,或是瀏覽器內預設的文字輸入區(textarea),支援游標移動/選取、新增/刪除/修改文字、複製/剪下/貼上、搜尋/取代等基本功能。這種常見的編輯器用起來很簡單,只要在鍵盤上打字就能新增文字,按下backspace或delete鍵就能刪除文字;用滑鼠點擊任何文章內的地方游標就會移動過去;複製、搜尋等功能可以透過menu bar找到,或是利用一些約定俗成的快速鍵(Ctrl-C, Ctrl-V..)就可以在編輯文章中快速呼叫這些功能。這種編輯器的特色是學習門檻很低,要記憶的只有一些特殊的快速鍵,即使不記得也能透過menu bar或是context menu找到。

如果用之前說過的usability來分析這種編輯器,大概可以知道這樣子的UI具有容易學習(高learnability)、不容易忘記(高memorability)、不容易產生Errors、一般用起來也不會有太大不滿(satisfaction)。一切看起來都很美好,唯一的問題是,這種編輯器的efficiency到底是好還是不好?

回答這個問題前,先繼續看另一種編輯器的設計,我們才能比較不同設計的好壞。

在1976年UNIX剛誕生不久時,出現了一個特殊的編輯器叫做vi。vi引入了一個很特殊的概念:模式(mode)。

vi和一般常見編輯器最大的不同在於它有兩種模式,命令模式(command mode)和插入模式(insert mode)。在命令模式下任何鍵盤輸入都會被解讀成送給編輯器的特殊指令,例如移動游標、複製/貼上、搜尋..等等全都是送給編輯器的命令。而在插入模式下,鍵盤輸入的字會被送入編輯中的文件內,這模式也就是一般編輯器預設的模式。

在HCI的研究中,模式(mode) 是一個很常被探討的概念。在不同的模式下,使用者即使給了相同的輸入,但系統卻會產生不同結果。日常生活中最常見的例子就是汽車的排檔:在D檔時踩油門車子會前進,但在R檔時踩油門車子卻會後退。而有多種模式的UI會帶來最大的問題是mode error,也就是使用者分不清或是忘記現在系統所在的模式,而得到了非預期的結果。這種error問題可大可小,最嚴重可能就是開車時忘記在R檔而踩了油門想往前進卻撞上後面的車。也有些比較輕微的,像是在打字時忘記caps lock是開著的而不小心打出一連串的大寫文字就比較無所謂,因為看到後馬上就能回頭修正。

但如果是在看不到的時候意外開著caps lock打字呢?(像是打密碼的時候)還好最近幾年出現下面這種設計,在密碼輸入框上面顯示caps lock的狀態,用來避免打密碼時不小心開了caps lock造成的mode error。

mode-error

vi引入mode到編輯器中,最大的問題就是產生了mode error的可能。也就是說,使用者如果以為他在insert mode而快樂的開始打字,但結果卻是什麼事都沒發生(除非他剛好按到a或i進入了insert mode..)。這問題也是造成vi難以入門的原因:你可以想像有許多第一次進到vi的人,打半天字卻什麼都沒有跑出來會帶來多大的挫折感。而且mode error可怕的地方在於,不是只有新手會碰上這種error,即使是vi的專家也常常會在insert mode打指令或是在command mode中打文章。(如果你在文章中看到:wq這種怪東西,就知道那人是用vi的了)

說起來mode帶來不少壞處,但它也不是沒有好處。讓我們反觀一般編輯器的”mode”設計。常見編輯器其實不是沒有mode,而是他們的mode是「暫時」的(這叫spring-loaded mode),靠Ctrl、Shift、Alt、Cmd、Win這些功能鍵來「暫時」進入命令模式。例如說Ctrl-C可以複製文字,這其實就是靠Ctrl賦予”C”這個鍵暫時的特殊功能,而取消原本在文件裡插入”C”的預設功能。用spring-loaded mode的好處是不容易產生mode error,因為使用者平常就只處在一種mode中,只有當使用者想要用特殊功能時,才必須先刻意按住某些特殊功能鍵來啟動它。spring-loaded mode的壞處在於,Ctrl、Alt、Shift這些鍵的位置在鍵盤的邊緣,再加上還必須按住不放(有時候還要兩三個鍵一起按住),使用者常常就得用彆扭姿勢讓小指和無名指按住,造成精神與肉體上的折磨。在按住這些功能鍵的同時,快速鍵的位置還不能距離太遠才能用單手按到,所以我們才會看到最常用的快速鍵都集中鍵盤左下角(Z undo、A全選、X剪下、C複製、V貼上、F搜尋…)。

後來文字編輯器變得越來越複雜,快速鍵也大量增加,這時在有限的空間內分配快速鍵的位置並且讓使用者容易學習又不容易忘記就成了一件困難的事。現代的一般編輯器,包括很多寫程式用的IDE,大量使用各種混合Ctrl、Shift、Alt的快速鍵,這種快速鍵設計哲學是把每一個功能對應到一組複合鍵上。理所當然的,功能越多,快速鍵就越多越難記。

因為多了mode,vi和一般編輯器的命令設計哲學也非常不同。vi的哲學是把功能分解成最小單元,再把這些最小單元一一對應到不同按鍵上,最後再利用一連串的按鍵組合產生使用者想要的複雜功能。以移動游標來說,vi把這件事分得非常仔細,從字元(character)、單字(word)、行(line)、句子(sentence)、段落(paragraph)、螢幕(screen)、區塊(block)、到檔案(file)都有對應的鍵可以以不同的單位大小來移動游標,例如按w可以跳到下一個單字(word),}可以跳到下一個paragraph…等等。乍看之下似乎很複雜,連移動游標看起來都這麼麻煩,但這樣設計的好處在後面。文字編輯還有很多動作可以做,像是刪除、剪下、複製..等等。vi把動作和操作的單位分解開來,例如:刪除(delete)是d、複製(yank)是y,這樣我們就只需要分別記憶動作對應的鍵和單位對應的鍵,就可以交叉組合出多種一般編輯器做不到的複雜功能。例如說,dw就是刪除(delete)一個單字(word)的意思,y}可以複製(yank)一個段落(paragraph)。如果你想要的話,單位前面還可以加上量詞,例如說d2w是刪除2個單字。

vi的這種設計避免了快速鍵的組合爆炸(想想看如果把各種組合都對應到一個ctrl-alt快速鍵會有多少個..),並且讓使用者能完全使用鍵盤來精確、快速的編輯一個文件,一旦熟悉這種操作後,手都不用離開鍵盤,不管是寫程式或是寫文章都有了一種人機合一的流暢感,心中想到哪裡游標就能精確移動到哪裡,不管多複雜的文字操作都能快速解決,心中的爽快感其實是難以用筆墨形容的。一般編輯器依賴於滑鼠作為移動和選取的主要工具,其實不管在learnability、memorability、errors都優於vi的鍵盤設計,但最大缺點就是efficiency很低。原因之一是,要用滑鼠一隻手就得離開鍵盤,光是這個時間用鍵盤操作的人都已經做完了(用laptop的touch pad就是另一回事了);原因之二是,滑鼠移動是不精確的,要把游標對準某一點所花的時間遠比按下鍵盤上固定位置的按鍵來得長(請參閱之前關於Fitt’s Law的文章);原因之三是,即使是用鍵盤控制游標,也沒辦法針對不同單位大小做控制,所以常常會看到一般使用者按住方向鍵等游標慢慢移動到某個地方..。(註:一般文字編輯器有個小技巧,這裡順便告訴大家:Windows上按Ctrl+左/右可以以一個word為單位移動,Mac上是Alt+左/右。幾乎所有可以打字的地方都能用。)

身為一個靠打字(不管是寫程式或是寫論文)吃飯的人,文字編輯可以說是我在電腦上花最多時間的工作之一。我很幸運在國中就接觸到Linux,所以也就接觸到了vim(vi後來的延伸版,是目前最流行的vi版本),沒想到這一用就用了十年…。vim也是我從國中開始用的每一台電腦裡都必裝的軟體,即使學了數十種程式語言,從Windows、Linux換到Mac,我到現在都還是用vim寫程式、寫論文、寫報告..。甚至在command line (bash)下面,都可以設定成vi mode,接著就能用vi的快速鍵來編輯指令。寫程式如果沒有vim,我等於被打斷一條腿一樣(不誇張,每次被迫在IDE裡寫程式我都有種武功被廢了的感覺…)。雖然一開始學vi/vim的門檻較高,但我很高興一開始花了點時間去學它,後來就再也不用學新的editor或IDE,只靠這一招半式就能行遍天下,實在非常值得呀。


十月 2, 2009
» [HCI] 費茲定律Fitts’ Law與使用者介面設計

之前在[HCI] 談人機介面設計與Usability一文中提到了usability的概念,並用了Windows的開始鈕說明了在設計UI上容易忽略的陷阱。這篇文章我會繼續探討介面設計與usability,並以效率(Efficiency)與UI設計時最重要的定律之一費茲定律(Fitts’ Law)為重點。

設計軟體的操作介面並不難,但很多時候直覺的設計並不一定能達成想像中的目的。這就是usability的研究想要了解的,到底什麼樣的設計才是「更好」的設計?什麼樣的設計其實只會讓usability變得更糟?

以menu bar為例,menu是圖形介面(GUI)的最基本元素之一,現代軟體功能越來越強大,包山包海的結果就是menu變得越來越多、越來越深,每一個menu展開後幾乎都有sub-menu,甚至還有sub-sub-menu等等複雜的選單。我每次教我爸媽用電腦時,都覺得Windows的menu根本是設計來折磨使用者的,奇妙的是竟然很少聽人在抱怨這介面很難用,而是紛紛強迫自己「學會」這種操作模式。

我想會看到這篇文章的讀者,早就很習慣於操作GUI了,也沒想過選單能有什麼好用或難用之別。所以先讓我們來想想要開啟一個埋藏在sub-menu裡的功能是多困難的工作(就假設是檔案/最近開啟/某檔案.txt好了)。第一,把游標移到menu bar的「檔案」上,並停住不動;第二,按下滑鼠左鍵打開檔案選單,把游標「垂直往下」移到「最近開啟」上停住;第三,等sub-menu打開,把游標「水平往右」移進sub-menu裡;第四,再度「垂直往下」找到某檔案.txt,在上面停住並按下左鍵。好,想像完畢後你可以試著用你的非慣用手操作滑鼠做一次看看。

如果是已經很熟悉GUI的使用者,想必都不覺得操作選單有什麼困難的,但當你被迫用非慣用手操作時,一定會感覺到操作速度大大的降低,甚至沒辦法精準控制游標進入sub-menu,這時我們才有機會體認到操作滑鼠其實並不容易。除此之外,如果仔細觀察,還可以發現進入sub-menu又比平常把游標移到任意地方還困難,因為必須把游標保持在一條狹長的「隧道」裡水平移動,如果在移動時不小心移出了這條隧道,sub-menu就會關閉。

gimp

有個有趣的案例發生在一個著名的open source影像處理軟體GIMP上(可以說是免費版的photoshop)。當初開發GIMP的團隊曾做過一個有趣的決定,他們決定拿掉固定在視窗頂端的menu bar,並用可以在任何地方按右鍵打開的context menu取代。因為context menu可以在任何地方打開,GIMP的開發團隊認為這樣可以加快存取menu的速度。這個想法很直覺,但真的對efficiency有幫助嗎?

既然我都說了這麼多,答案當然不會是yes。

context menu對efficiency並沒有幫助,反而使之變得更差。為什麼呢?

gimp2

如上圖,從第一層的選單要進入第二層時,必須先經過第一層狹窄的隧道(紅色區域),才能進入第二層選單。如果直接走直線路徑到想要按的目標,就會先經過第一層的其他項目,導致不同的sub-menu被打開。傳統的menu bar也是有sub-menu,所以直覺上可能不會覺得多一層的sub-menu會有多大影響,但事實上是這種把游標限制在一條隧道裡的設計大大的降低了操作游標的速度,和一般可以經由任意路徑指到目標的操作有指數級的速度差異。

Fitt在1954年提出了Fitt’s Law,可以說是人機互動領域的第一條「定律」,對人類指向任一目標的動作建立了一個數學模型。基本的概念是,移到目標上的時間(T)可以表示為目標距離(D)與目標大小(W)的函數。具體來說,T = a +b log2(D/W+1),a和b都是一個常數。

Fitt’s Law告訴我們,移到任意目標上的時間大約跟目標距離除以目標大小的對數成正比。也就是說,目標越遠移動時間就越長,目標越小時間也會越長;反之,目標越近或目標越大的話,所需時間就越短。有趣的是,距離和目標大小的影響並不算大,經過log讓這兩個變數的影響降低了一個指數等級。例如距離變長1000倍,並不會讓時間也變成1000倍,而是變成log2(1000),大約是10倍而已。

在軟體介面上,Fitt’s Law有個特例值得討論一番。在電腦裡的滑鼠游標,有個基本特性是其活動範圍被限制在螢幕裡,只要游標到了螢幕邊緣,無論再怎麼繼續往同一個方向移動滑鼠,游標還是只能停留在邊緣上。這個特性讓UI設計有了戲劇性的變化,一個最有趣的例子是Windows和Mac OS X的menu bar設計。

Microsoft的Windows自古以來的UI設計都是把menu bar放在視窗的title bar下面,而Mac OS採取完全不同的設計:把menu bar固定在螢幕最頂端。一般人大多覺得這兩種設計只是習慣問題,沒有什麼客觀差別,但如果你已經學會了Fitt’s Law,你覺得哪一種設計比較好呢?

Mac OS X menu bar

Windows menu bar

如果直接套用Fitt’s Law,第一個得到的答案很可能會是Windows的設計比較好,因為當滑鼠從視窗內移往menu bar時,距離會比移到螢幕頂端還近。可是,別忘了考慮螢幕邊緣所造成的影響。Mac把menu bar放在螢幕頂端,雖然距離變長了,但目標的大小也跟著變成了「無限大」。因為螢幕的邊緣會阻擋住游標的行動,於是使用者可以盡情的把用力滑鼠往上一甩,不用停下來「對準」目標,也就等同於目標的大小變成了無窮大。在Fitt’s Law中,當W是無限大時,整個log函數得到的結果會變成0,也就是說T就會變成一個簡單的常數值a,跟距離或大小都沒有關係了。

如此比較之下,我們就可以發現Mac把menu bar放到螢幕頂端是有其用意在的,因為它大大減少了把滑鼠放進menu bar並對準目標的時間,使用者只要把滑鼠用力往前一移,自然就會進入menu bar裡面了。我在[HCI] 談人機介面設計與Usability一文中也提過Windows開始鈕的例子,跟menu bar的例子也是相同的道理。

到目前為止,我們已經看過了三種形式的menu。對於efficiency而言,我們知道Mac的設計比Windows的設計還好,那如果和GIMP的context menu比起來呢? 從Fitt’s Law可以得知,Mac的設計已經達到極限了,無論如何也沒辦法捨去那個常數a,所以我們可以直接來比Windows的設計和GIMP的設計哪個比較差XD。

前面提過,sub-menu是一種很難的指向操作,除了要把游標移到目標上,還限制了中間經過的路徑在一個隧道裡。在Fitt’s Law之後,Accot and Zhai提出了Steering law。其結論非常簡單,讓游標經過一個寬度W的隧道移動距離D的時間 T = a + b * D / W。換句話說,把移動路徑限制住的話,其移動到目標的時間和一般性移動(Fitt’s Law)所需的時間是指數級的差距,這也就是為什麼電流急急棒可以變成一個有百萬獎金的挑戰,而隨意動動滑鼠則簡單的多。

了解了Steering law之後,再回來看sub-menu的設計,你就會發現sub-menu是一個多不人道的設計。每一層的menu其實都是一個steering操作:垂直的menu移動比較簡單,因為menu寬度通常都蠻寬的;但每當要水平移動進入下一層sub-menu時,就是一個困難的挑戰,因為這時的寬度變成了menu item的高度,通常也就是一個字母高而已。和Fitt’s Law不同的是,寬度(W)變小n倍,對時間的影響不再是對數,而真的就是讓時間變長n倍。所以說呢,如果可以迅速又準確進入多層sub-menu的滑鼠高手,其實也有參加電流急急棒比賽的能力呢!

回過頭來看Windows和GIMP的menu設計,這時就可以明顯比較出來。GIMP把所有的選單操作全都變成了steering操作,Windows雖然也有sub-menu的問題,但至少第一層還是任意的指向操作,所以就efficiency來說,GIMP的設計其實是一大失策..。

最後,再順便提兩個Windows和Mac OS X對於sub-menu造成的問題所提供的解決方法。微軟和Apple都知道sub-menu很難操作,所以他們其實都有偷偷的在介面上做了一點貼心的設計。微軟的方法是,在游標要進入sub-menu時,如果不小心移出隧道外,只要在一定的時間內移回來,sub-menu就不會消失。這個方法其實有些風險,主要是因為這個「時間」很難掌控。如果這個設定的時間太短,那就沒多大效果;但如果設定太長,使用者如果是真的想要移到別的menu item打開另一個sub-menu,就會覺得系統反應太慢(就是那種頓頓的感覺)。所以,微軟的這個方法其實並不是很有效的解決這問題。

而Apple雖然也是用同樣的方法來sub-menu不要馬上消失,但他們又加上了一個聰明的設計:sub-menu的延遲消失只有在游標到sub-menu的頂端和底端形成的三角形內有效。換句話說,如果使用者是想進入sub-menu中,他甚至可以直線移動滑鼠進入其中而不會意外打開另一個不同的sub-menu(只要在設定的延遲時間內移動完成)。而假如使用者是想打開另一個sub menu,那直覺的把滑鼠往下移動就會自然的避開這個三角形區域而避免了「頓頓的」感覺。

Apple's solution for sub-menus

在UI設計上,Apple一向是比其他公司用心許多。這種聰明的設計雖然很小(甚至沒什麼人會注意到),但在每天反覆的使用中就能自然減少使用者的挫折感和提昇操作的流暢度,這也是為什麼我常說Mac有許多貼心的設計,用起來會自然讓人感覺很愉快,而其他系統在UI設計上所下的功夫就明顯不足了。

五月 21, 2009
» [HCI] 談人機介面設計與Usability

前言

在MIT不知不覺已經過完第一年了,雖說我的研究領域主要在人機互動(Human-Computer Interaction, HCI)上,但一直很少寫關於HCI的文章。說實在HCI的資訊和課程在台灣非常稀少,大多數人對於HCI的了解和想像也停留在電影裡才會看到的那種很fancy的操作介面,或是multi-touch之類的新興操作模式。但除了這些很炫的東西外,其實有更多會直接影響到我們目前正在使用的人機介面的基礎研究和理論存在。

以操作介面(user interface)的設計來說,這是在軟體開發流程中最容易被忽略的一環。一般公司和軟體工程師把寫UI視為一種苦工,於是常隨便抓個菜鳥去用VB之類的快速開發工具把元件拉一拉就結束了。但不幸的是使用者開始用軟體時,第一眼接觸到的就是UI,如果UI設計的不好,使用者容易感到挫折,甚至嘗試一兩次後就把軟體給丟了。於是,不管裡面有多巧妙多厲害的功能都沒用。因為使用者根本就沒辦法看到軟體裡面花了多少心血,使用者只能透過最外層的介面來感受到軟體的內涵。所以說,介面如果做爛了,底下的功夫不就只能包在裡面白白浪費了嗎?

最近幾年因為Apple的iPod、iPhone開始走紅,越來越多人注意到好的介面設計帶給使用者的影響是非常巨大的,甚至也對於產品的銷路有決定性的影響。很多人能感覺到Apple設計的介面比較好看而且也比較好用,但其實說不出來為什麼,所以工程師也很難複製Apple所創造出來的使用者體驗(user experience)。

圖形介面(Graphical User Interface, GUI)的快速開發工具將軟體介面設計的難度大大降低到像用小畫家畫畫一樣的程度,所有的標準GUI元件都是手到擒來,滑鼠一拉就能擺到任何想擺的位置。這項工作看似簡單,但要做得好其實並不容易。每個元件的長相、顏色、位置、大小、相對關係,甚至要選用什麼元件來呈現資訊,背後都有一套學問在。許多人誤解介面只要好看就好,但其實好看的介面不見得好用(常常還比較難用)。「好看」這件事目前還有很多藝術成份在裡面,但「好用」這件事其實已經有很多HCI研究發展出的理論能告訴我們怎樣設計會比較「好用」。

這個領域可以談的東西實在太多了,所以我打算慢慢把HCI中比較重要且有趣的概念分享出來,希望在台灣設計UI的公司和工程師們能做出更簡單易用的產品出來。(這不只是軟體而已,其實所有的人造產品都需要設計「介面」!不管是你家的冰箱還是門把都一樣有好不好用的問題。)

Usability – 易用性

這篇文章我打算從設計UI最核心的概念Usability開始,之後再慢慢另闢新文詳細介紹各個部份。
Usability的定義是人可以用某樣工具達到一個特定目標的容易程度。目前常用的中文翻譯有可用性和優使性兩種,前者給人的感覺像只有描述可用或不可用兩種狀態,後者則看不太出是什麼意思。我覺得比較好的翻譯是「易用性」,但我還是比較喜歡用原文稱呼就是。

Usability包含了下面五項要素:

  • Learnability: 使用者在第一次用就能學會的容易程度
  • Memorability: 經過一段時間之後再重新使用這UI還能熟練操作的容易程度
  • Efficiency: 使用者能用這個UI多快完成任務
  • Errors: 包括使用者有多容易出錯、錯誤有多嚴重、以及有多容易從錯誤中回復回來
  • Satisfaction: 使用者用這個UI時會覺得愉快的程度

Learnability指的是使用者在第一次用就能學會的容易程度。(沒通用的中文翻譯,或許可以叫「易學性」。)如果一個UI的learnability越好,使用者就越能輕鬆的學會如何使用它。相反地,如果learnability很差,使用者就容易搞不清楚到底要怎麼用。如果一個UI或產品的目標對象是一般大眾,包括幼稚園的小朋友到老阿媽,learnability通常是決定這個產品被接受程度的關鍵。至於要怎麼設計具有優良learnability的UI也不容易,目前大多是靠一些基本原則和低成本的測試方法來反覆設計,這部份以後再另闢專文介紹。

Memorability指的是經過一段時間之後再重新使用這UI還能熟練操作的容易程度。(中文姑且可以叫「藝妓易記性」吧。)memorability和learnability常有密切關聯,如果learnability夠好,其實就沒有memorability的問題了,因為每次都重頭學起也是很容易。但稍微複雜的介面都不是很好學,所以要怎麼在使用者第一次學會以後讓他們不容易忘記就是memorability關注的事了。

Efficiency指的則是使用者能用這個UI多快完成任務。(efficiency就是效率。終於不用想新翻譯了…(汗)) efficiency是五項usability要素中最容易定義和測量的,但這並不代表要設計有效率的UI就是很簡單的事。舉個簡單的例子,下面的圖分別是Windows XP和Windows 98的開始紐,雖然看起來只是一個按鈕,但這個紐在efficiency上有著極大的差異,有興趣的人不妨自己先想想看再往下看說明。

winxp-start

win95-start

好,這兩個開始紐的差別在哪呢?

說起來很好笑,其實關鍵的差異只有1個pixel的差別:Windows 98的開始紐最外圈的1個pixel是不能按的。也就是說,如果你把滑鼠移到最左下角想按開始,你會發現按下去什麼事都不會發生;你得把滑鼠往右上移回1 pixel以上(而且還不能超過按鈕的大小!),才能按到那個紐。(這問題在Windows 2000前都有,一直到XP才被解決。) 這個設計其實造成兩個問題,第一是使用者不能快速把滑鼠甩往左下角,而必須「瞄準」開始紐再移動,這兩種動作的時間差距大約是log(移動距離/按鈕大小)。(這是透過Fitt’s Law計算出來的。Fitt’s Law是HCI領域中很重要的一個定律,之後我會再另闢新文介紹。)第二,這1個pixel會讓直接移到最左下角的使用者得到一個沒有任何feedback的error(期望的事情沒有發生),使用者很容易會搞不清楚怎麼回事而產生挫折感。所以說,別小看設計中的小地方,即使是1個pixel,也可能造成很大的影響。

再來是usability的第四個要素,errors(錯誤)。errors的範圍比較廣,包含使用者有多容易出錯、這些錯有多嚴重、以及有多容易從錯誤中回復回來。usability的要素常常是緊密相連的,以上面那個Windows開始紐的例子來說,那1個pixel也會造成error,但其實並不算嚴重,而且也容易恢復。比較嚴重的error像是程式結束時沒問使用者要不要存檔就直接結束,可能會讓人損失重要的資料。

最後是第五個要素satisfaction(滿意度),它指的是使用者用這個UI時會覺得愉快的程度。一般的UI通常不會太注意satisfaction,只要讓使用者用起來不會想罵髒話就好。但以軟體來說,遊戲的UI設計是特別需要考量satisfaction的,因為玩遊戲重要的就是要開心,如果達不到這目的其他都是枉然。

Usability的五項要素是評估一個介面好不好用的基礎指標。下回設計介面時,不妨先逐一檢查每一項要素,看看其中是不是有些會影響到usability的問題存在。

二月 9, 2009
» Fingering of Keys

按鍵是很普遍的人機介面,也常用於內嵌系統(Embedded Systems)。既然大家那麼愛用按鍵,很自然地, Embedded Systems 軔體開發人員就常常得處理按鍵的偵測、編碼等議題。此外,為了按鍵操作流暢,我們還必須為按鍵設計適當的指法(fingering)及明確、統一的功能定義(function definition)。 不久前筆者設計了一款相框產品,它雖然只有三個按鍵,但除了要能執行基本操作,如上一張、下一張、設定自動換張的間隔時間等;也要能夠流暢地切換功能,如手動換張、自動換張、顯示日期時鐘、功能設定等;此外,最好還能透過這些操作,讓使用者充分感受到它優越的秀圖速度。 老實說,把這些操作通通塞進三個按鍵內並不是多困難的事,比較需要我們傷腦筋的是怎麼讓使用者覺得操作是簡單流暢、符合預期的。 這裡不是要跟你扯怎麼設計美美的畫面,雖然美美的畫面很重要,但畫面設計還是

biggo.com.tw

A Django site.