八月 31, 2010
» 42年的鴻溝 – Dyna Book與iPad

昨天睡前心血來潮翻了一下《世紀末軟體革命復刻版》,這本我一直非常喜愛的經典書籍。(註)意外翻到書中提到Alan Kay在1970年代的Xerox PARC(Palo Alto Research Center)提出Dynabook概念的那段歷史: 曾經有好長一段時間,電腦給人的印象是處理複雜運算的龐然巨物,CPU龐大不說,磁帶機、終端機…硬體設備本身便以大著稱。這些「巨物」處理的事務也是龐大的:大量的數據、大量的資料…。電腦是不折不扣的資料處理機,和人們的生活其實是八竿子打不著邊的。 1969年,一位Ohio大學的研究生Alan Kay提出了一個構想:他希望創造一「本」可以帶著跑的電腦,並且利用電腦的資料儲存和運算能力,模擬甚至取代現有的紙跟筆。這台電腦的理想體積要和紙張的筆記本相近,能夠用它來從事寫作、繪畫、個人行程編排或是財務管理、通訊,或者是用它來取代傳統的教科書等「死板」的文字。 如果書本不再只是單向地灌輸知識,而是能對讀者的迴響做出反應(從最簡單的回答問題的正確到複雜的全文檢索等),甚至讓讀者也參與創作的過程(例如透過網路,作者可以和讀者交流,而在「筆記本」上的內容可以隨時更動),那麼我們所得到的,將是一個和當時截然不同的文化 – 對「電腦」的概念不同了,以往對「書本」、「資訊」的概念也將翻新。Kay把他理想電腦稱作Dyna Book,是「動態」的「書」,而不是xx computer,等於不再把電腦當做「電腦」了。 這段歷史我很久以前就知道了,但我一直以為Dyna Book的概念是更接近於筆記型電腦的東西。但昨天看到這段文字時,我卻有了完全不同的感覺,心裡異常的激動,因為這段文字描寫的Dyna Book,似乎更像另一個東西,一個直到今年才出現的東西。上網查了一下Alan Kay當初的論文,看到這圖我才明瞭,原來Dyna Book的設計根本就不是電腦!! 1968年Alan Kay的Dyna Book,其實就是2010年Apple iPad的原型啊。 看到這讓我不禁感嘆,1970年的Xerox PARC真是個傳奇性的研究單位,從以太網路(Ethernet)、最早的個人電腦Alto、圖型使用者介面(GUI)、物件導向程式設計(OOP)和第一個物件導向語言Smalltalk都是在這被發明出來的。(附帶一提,GUI、OOP、Smalltalk的發明人其實都是Alan Kay。)可是Xerox畢竟是個做影印機的公司,PARC做出了這麼多驚世發明,雖然跟影印機都沒關係,但不論哪一樣東西持續發展下去都大有可為,結果Xerox就這樣讓這些概念被Apple和Microsoft免費拿去創造了現今的電腦王國…。 但話說回來,即使在70年代Xerox就投下資源去做Dyna Book,結果也一定不會成功。對當時的環境來說,Dyna Book的概念實在太過先進,能實現這個產品的軟硬體技術都還不存在。除此之外,當時的電腦是只有大型企業或是尖端研究機構才會有的東西,大眾還沒辦法接受每個人都需要一台有「運算能力的機器」(computing device)這件事。即使到了1993年,那個個人電腦才剛開始普及的時代,Apple推出的Newton(最早被稱為PDA的機器,話說回來也還是想實現Dyna Book所描繪的遠景),最後也是慘淡收場。 商業界有本很有名的書叫「跨越鴻溝」(Crossing the Chasm)。這本書的核心概念是說一個新科技被接受的時間可以分為五個時期,過了最早的創新期後,要先讓一群對新科技比較敏感及狂熱的「早期接受者」(early adopters)接受後,再來才能大量擴張到「早期的主流大眾」(early majority)。但很要命的是在early adopters這個區域有一個巨大的鴻溝,如果一個創新的科技不能得到夠多early adopters的支持,就會直接跌落谷底而死亡。 Dyna Book在1968年前提出的概念,一直到2010年才真正實現並跨過鴻溝讓主流大眾接受。不知道該說是Alan Continue reading

十二月 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的問題存在。

三月 25, 2009
» 與大師的近距離接觸

Takeo Igarashi是東京大學的教授,兩年前MMDays曾經介紹過他在UI上的一些研究,還稱他為日本的UI之神。在當時我就非常佩服Takeo的發明,他讓使用者可以直覺地用滑鼠畫出3D模型或是自然地操作2D圖片。這些發明共通的特性是使用者不需要面對複雜的選單和按鈕,只要用直覺的滑鼠動作就能做到極為靈巧的操作;而表面上看起來雖然單純,但背後卻有著非常聰明的想法隱藏在裡面。

為什麼我會特別提到他呢?

因為再過兩個禮拜,HCI界中最大的conference CHI 2009即將要在Boston舉辦,會場就在離MIT不遠的地方。雖然少了一次機會可以順便去別的地方玩,但有個好處就是世界各地在這個領域的學生和教授都會自己跑來Boston。

Takeo當然也是CHI的其中一位與會人士,而我們老闆就趁這個機會邀請他來MIT給個演講,除了可以親眼看看他那些超酷的demo外,更棒的是他還會跟我們group的所有人一起吃飯!(當我聽到這消息真是超興奮的,這大概就是那種能跟偶像近距離接觸的感覺吧XD)

提到這件事,就讓我想順便比較一下MIT和台大在辦seminar的差異。MIT CSAIL的研究領域非常廣泛,基本上每個子領域的教授都會自己找該領域的研究人員來給演講,所以我們有AI seminar、HCI seminar、Theory seminar…。這些seminar不強制要求學生參加,每個人挑自己有興趣的去聽就行了。我的老闆負責主辦HCI seminar,大概每一兩個星期就會找個人來演講,這些人來自世界各地,很多都是這領域兩大conference (UIST和CHI)的熟面孔。他們除了來演講外,最有趣的是我們老闆總是會請演講者跟我們整個group的學生一起吃午飯。因此,我們很容易就能認識這領域中的頂尖人物,還可以有很多機會跟不同人討論自己的研究,交換不同的想法。

以前在台大時,資訊系每個星期也都會辦一兩場seminar,邀請國內各地的教授給個演講(很少有國外的講者)。大學生通常不會去聽,而研究生是被要求每個禮拜一定都要出席的(碩二要求少一點,但至少兩個禮拜也得去一次)。雖然台大也有這樣的制度,但其實碩士班過了兩年我也沒機會認識哪個講者,更別提能討論什麼研究了。seminar就只是單純的聽人演講,如果講者演說技巧不好或是對題目不感興趣,就會看到下面一堆人在睡覺或玩自己的電腦。

雖然說MIT不強制要求學生去聽seminar,但有興趣的人都還是自己會去聽。聽眾人數通常也不會很多,可是因為是自己想聽才去參加,所以演講中的互動和討論很頻繁,而且氣氛也很熱絡。有一次還出現很有趣的現象:台下的人問了一個問題把講者考倒了,但台下另一個人馬上就幫他回答了答案,就在講者恍然大悟後,台下兩個人就隔空討論起來了XD

我提到這件事也不是想說台大不好,只是MIT實在有太多台大很難有的優勢,像是MIT鄰近Boston這個被稱為「宇宙中心」(The hub of the Universe)的城市,世界各地的人很容易就會往這跑;再加上MIT的學術聲望和財力,要邀請各地的講者也不是什麼問題。台大雖然是台灣頂尖學府,但台灣距離西方國家太遙遠,很少人會專程想來台灣,再加上台大也沒辦法負擔這種國際旅行的費用(話說,五年五百億都用哪去了?),也難怪國際化只能停留在教授改用英文上課上面了。

十一月 15, 2008
» 千年傳統,全新感受的紙筆科技

無紙化的辦公室是電腦發明後人們一直懷抱著的夢想,但在電腦已經深入每間辦公室的今天,紙的用量不但沒有減少,反倒因為資訊爆炸以及列印技術的進步而讓紙張變得越來越多。雖然電腦對於編輯和修改文件非常方便,但液晶螢幕仍舊不是一個優良的閱讀介面,如果需要閱讀較長的文章,大多數人還是喜歡印一份出來慢慢看。

實體文件好處多多,只要一枝筆就可以在上面輕易塗改,不管是加上註解或替別人校對都是簡單方便。但這種「遠古」科技一直和現代的數位技術格格不入,雖然Bill Gates曾經預測Tablet PC會改變人們使用電腦的方式,但現在看來Tablet PC早已經是被遺忘的舊時代產物。人們依舊喜歡用紙筆來閱讀和紀錄,但數位文件又方便編輯和分享。這讓人不禁幻想,如果這兩樣科技能融合在一起該有多好?

University of Maryland的François Guimbretière教授做了很多研究企圖彌補電腦與紙筆之間的鴻溝。他的PADD(The Paper Augmented Digital Document infrastructure)
提出了一個有趣的解決方法:利用「數位筆」來連結實體的紙張與虛擬的數位文件。

這個數位筆特殊之處在於它裡面其實是一個附有攝影鏡頭的電腦,它可以知道你在哪一份文件上寫了什麼,並且直接把你在實體文件上的修改同步進電腦裡的數位檔案中。也就是說當你在紙張上修改完後,不用再回到電腦前看著印出來的紙張再重新修改一次該文件檔,這個筆會直接幫你做完。

有興趣的人可以看看PADD的demo影片(格式是MP4, 有些平台可能要自行修改副檔名為mp4才能觀看)

Guimbretière教授後來又提出新的構想PapierCraft:直接讓人用筆在實體文件上面做hyperlink和copy/paste。可以參考下面的影片:

Video: PapierCraft: A Command System for Interactive Paper

最近在美國也有一家公司LiveScribe推出了一種數位筆Pulse,可以在紙上書寫的同時紀錄下書寫的軌跡,並且還可以同步錄音,事後只要點一下筆記的地方,就能夠播出當時的錄音檔。這個筆對於需要上課抄筆記的學生非常實用,不僅可以輕易把筆記數位化(寫下來的字傳進電腦會自動經過OCR辨識成為可編輯的文字),並且把錄音和相對的筆記連結起來後,上課時就可以多放點心力在理解內容上,不用怕一時沒聽懂或是怕漏掉什麼而拼命抄下教授的每一句話,最後卻搞得沒辦法好好聽課。

LiveScribe Pulse成功的用合理的價格幫數位筆打開一條很實用的道路(我還真的在課堂上看過有人在用),這讓我非常期待Guimbretière的數位筆也能夠變成真實的產品,這樣未來說不定我們又能回到只有紙筆的生活。如果要用一句話來形容未來的紙筆科技,我想一定就是「千年傳統,全新感受」了吧 XD

biggo.com.tw

A Django site.