五月 31, 2011
» 駭客們,起來創業吧

三月 19, 2011
» 分享我的vim設定檔

八月 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

五月 25, 2010
» 為什麼我用Mac

這篇文章其實已經醞釀很久了。起因是前幾個月看了tinyfool的为什么我认为每个程序员都应该用Mac OS X?youxu的开发人员为何应该使用 Mac OS X 兼 OS X 小史,我當時就很想順便分享一下我的經驗,但那時忙著Sikuli實在沒法靜下心來寫文章,直到最近稍微閒下來了才又想起這件事。

我從2005升上研究所前買了第一台Mac mini到現在已經五年了,說起來其實沒有很長,但自從2005年起,我就成了非Mac不用一族。但用Mac是一回事,我要先澄清我不算是狂熱的Apple粉絲,我除了Apple的電腦外,只有跟朋友以超低友情價買過一台開學優惠送的ipod touch來玩,除此之外,我沒有iphone、沒有ipad、也沒有Apple鍵盤滑鼠以外的周邊產品。在2005年以前,我高中和大學約6年都是用Linux作為主要工作環境。我一路從Slackware、RedHat、Mandrake(後來改名Mandriva)、玩到Debian、Ubuntu,那段時期我有數台24hr online的Linux server,還換過3台laptop,但都是裝Linux。在更之前呢,從國小的386 PC算到高一將近10年就是用DOS和Windows了。

這篇文章主要想分享的是作為一個programmer使用各種作業系統開發的經驗,不是想要說服大家全改用Mac。雖然從時間上看起來我用DOS和Windows最久,但我真正開始大量寫程式是國中開始用Visual Basic的事,所以我在DOS和Windows平台的開發經驗其實算是最少的。而大學階段是我最密集寫程式的時候,所以我的經驗和使用的工具也都是以UNIX派的為主,不見得適用所有人。

我在DOS+Windows、Linux、Mac這三大主流平台上都混過一段時間,這個遷徙的歷史其實也代表了我個人心態上的轉換。

在剛開始學電腦的時候,我是純粹的使用者。我用電腦玩遊戲,國中幫老師用excel做全班的成績單,閒來無事就隨手玩玩photoshop、3D studio等軟體自娛娛人。我記得在386的DOS時代要玩個遊戲還挺不簡單,雖然很多遊戲都說只要打play.bat就可以玩了,但事實上總要修改config.sys和autoexec.bat裡的一些記憶體或音效卡的設定才能玩。所以那個時代的使用者其實大都是玩家級的人物,多少都對Adlib、EMS、XMS、可恨的640K限制有些了解才有辦法「玩」電腦。

國中開始寫程式之後,我的心態就不太一樣了。像一般玩家般玩電腦已經不能滿足我,我開始熱切的想了解電腦內部運作的一切原理,想了解每個程式是怎麼寫出來的,每個零件是怎麼運作的,每一個細節我都想知道。而我剛好就在這段時間接觸到Slackware Linux。

Slackware Linux其實是一個不太好用的Linux distribution,可能很多人也沒聽過它。現在的Ubuntu和Windows沒兩樣,一直按「next」就能裝完整個系統並開始使用。但那時的Linux裝完後可是「什 麼 都 沒 有」。沒有X11,更別提其上的GNOME或KDE;文字編輯器只有vi(不是vim)和joe;沒有make、沒有gcc、…,總之,真的什麼都沒有。那個時候裝Linux其實是為了自己架MUD server,但當時Linux的安裝教學都說裝完的一件事就是自己重新compile kernel。(因為預設的kernel很陽春,幾乎什麼driver都沒有,不自己compile的話很多硬體都動不了。)其實當時我覺得這還蠻酷的,make config打完出現數百個選項可以慢慢勾選,讓我這種想要一窺作業系統裡面在搞什麼鬼的人非常過癮。(一開始我還不知道有make menuconfig可以用,所以其中一個選項不小心選錯就會非常痛苦要整個重來……)但過了一段時間我就發現,MUD server沒架起來,但倒是很會重編Linux kernel和設定xf86config。

國中我還在用Visual Basic寫程式時,其實沒有注意到「平台」不同的影響,因為當時我只用Windows和VB寫程式,也不會其他語言,更不用提在不同平台寫程式。一直到上高中學了C,開始寫比賽的程式時,才讓我注意到Turbo C和gcc雖然都可以compile C的程式,但有某些header檔(像是conio.h)是只有Turbo C中才能用的。發現這件事後,我才突然搞懂library是什麼,還有Linux下有一堆libxxxx及libxxxx-dev的套件是在做什麼的。

Windows和Linux的關鍵差異 – 資訊透明度 – 也就在這裡顯現出來。在我學VB的時候,我把當時一本VB5的經典書籍從頭到尾全讀過了,但我竟然對library一點概念都沒有。我以為我能用的東西就是VB提供的那些元件,後來我多學了一點後發現我還能呼叫Windows API做一些VB辦不到的低階功能,我從來沒想過要去利用別人已經寫好的程式和函式來節省自己的開發時間。簡單說,我以為要造一輛車子,就是要從輪子甚至是螺絲釘自己做起。

某方面來說這是個好事,因為我的第一個VB遊戲「黑白棋」,就是這樣一個個pixel從無到有自己畫出的。但如果要寫更大的程式,每次都從輪子做起就不是個好主意了。接觸到Linux後,我也學了很多open source界的「哲學」,其中最重要的就是重用別人的輪子。

記得很久以前在Redhat和Mandrake上裝軟體非常痛苦,雖然每個程式都被包裝成一個RPM檔,但RPM之間的相依性常會讓人發瘋。每裝一個軟體都有可能會跳出數個相依的library或套件需要安裝,然後使用者必須自己去找這些相依的RPM,更糟的是這些相依套件可能會沒完沒了的依賴更多其他的套件…。(還好後來改用Debian就不用再被這個RPM地獄折磨了。)

這個過程讓我深刻的體會到,軟體應該是像金字塔一樣一層疊著一層往上蓋的,Linux套件的包裝方式清楚的讓使用者能夠看出來一個軟體是利用了哪些library建構起來的,如果自己想寫有類似功能的程式,很容易就可以找到相關的library來用。但在Windows下就不是這麼一回事了。Windows的軟體是為end-user設計的,目標使用者很可能什麼都不懂,所以發佈軟體時應該要把所需要的library或套件全部包進去變成一個龐大的自動安裝程式,使用者只要一直按下一步就可以裝完了。這讓使用者變得比較輕鬆,但同時也一些對開發者有益的細節也隱藏起來了。

Windows的軟體大多是完全不透明的,安裝時你不知道它裝了什麼,也不知道它寫了什麼到registry,更別提要知道他的某某功能是怎麼做的。但Linux是在另一個極端,每個程式的一切都是透明易懂的,RPM或DEB套件裡有什麼東西一個指令就一清二處,每個套件需要用到哪些相依套件也是明明白白。此外,Linux下的設定檔都是純文字,只要文字編輯器就可以修改,不但方便編輯,也方便寫自動化的script或是備份系統。當然,更不用提Linux下幾乎所有程式都是open source的,只要有興趣,隨時可以打開每天在用的軟體的source研究它是怎麼做的。這些事情在Windows底下則是天方夜譚,所有的細節都被自然的包裝和隱藏起來了。這種透明度的差異對於充滿好奇心的程式設計師會產生南轅北轍的影響,當你接觸的東西越開放,就能自然而然接觸和學習電腦從裡而外的各種知識;但當你接觸的東西越封閉,就只能受限於黑盒子的限制而當個單純無知的使用者。

高中時轉到Linux作為工作環境還有另一個很大的原因:「效率」。Linux的世界是架構在文字設定檔和command line工具上的,整個OS的操作都可以用command line解決。更方便的是搭配shell script或是Perl、Python這種script language,可以輕易把系統裡各種小工具結合起來完成複雜的工作。command line有個很大的好處,你每天用的操作介面,和寫自動化script的介面是完全一樣的。也就是說,你只要把每天打的指令串起來放進一個檔案,就自然變成了shell script,而日後只要執行這個script就能自動完成需要一連串指令的工作。這種工作方式滿足了我身為一個「懶人」的慾望,因為我懶得每天用手親自重複做同樣的事情,所以我寫script將這些事自動化。當script寫的越多,就會面臨越複雜的工作,這時就會想要學更多”UNIX power tools”的用法(這是O’REILLY的一本好書)或是更強大的「黏合」語言(像是Perl)來組合不同工具。透過這種正向循環,可以不斷刺激自己提昇工作效率:事情做得越快,就可以想得更多,解決更複雜的問題,進而就能學得更多,做得更快。

大學那幾年我成了虔誠的Linux command line信徒,不管是什麼樣的事情我都可以用各種小工具加上Perl或shell script來解決,而Windows在這方面就完全比不上Linux。Windows的哲學是一套軟體可以做N種事情,但如果你想做的事情不在它原本設計的功能裡,只能兩手一攤什麼事也做不了。

資訊的透明度和command line帶來的高效率讓我非常享受在Linux上工作的樂趣,然而Linux也不是沒有缺點。當我學得越多,對系統底層的好奇心漸漸被滿足後,Linux的缺點就漸漸暴露出來,其中最讓我受不了的是殘破不全的driver支援。讓我印象最深刻的是在802.11b無線網路剛開始流行時,我花了很多時間在找driver和當白老鼠compile最新的driver,重編kernel幾乎是每日例行公事。除了無線網卡外,就算是有線網卡Linux都不見得支援,最惡名昭彰的莫過於Dlink系列的卡,他們的530TX甚至還被暱稱為惡魔卡。(這張便宜的卡在當時非常流行,但偏偏在Linux上就是不能用…)

雖然我是個programmer,但我同時也是一般user。在我想要快樂用電腦看電影或上網時,還要不時的處理系統內部的問題其實有點惱人,更別提當我只想寫一般的桌面程式或是Web app時,為什麼我還得跟Linux kernel奮戰呢?

除了硬體相容性外,Linux這種過於開放的平台還有個大問題是缺乏統一且一致的user experience design,導致usability常常奇差無比,而這也是很多open source軟體普遍共有的問題。程式設計師在乎的是功能面的設計,每個人做自己想要或喜歡的功能,雖然看起來和樂融融,但很少project有專門的團隊負責思考user是誰,他們想要什麼,以及他們會怎麼用這個軟體。同樣的功能但由不同的介面呈現,帶給使用者的感覺也會有天南地北的差異,而由千百個open source軟體拼湊起來的Linux系統帶給使用者的就是千百種不同的設計和使用方式。(後來Ubuntu的出現大大的改善了這個問題,但那時我早已跳到Mac上了…。)

就在Linux的缺點慢慢浮現後,我同時也注意到身邊很多FreeBSD/Linux hacker們開始改用Mac OS X。深入了解後,我很快發現Mac是一個完美解合Linux的效率和開放,同時又兼顧了精心設計過的user experience design的平台。Mac作業系統核心是BSD的近親Darwin,上層有跟Linux相同的command line shell,所以我以往在Linux慣用的設定檔和程式(bash、screen、vim…)全都可以直接帶到Mac上使用。(更棒的是還能像在Debian下一樣用apt-get install或是port install一個指令就自動裝完所有相依套件)

而在command line的上面則是Apple設計的GUI系統,美觀、一致、充分為使用者「設計」過的介面,輕易的就打敗我在Linux上較調半天的FVWM設定。(我換過和較調過無數的window manager,從enlightenment、GNOME、KDE、Window Maker、FVWM…)除此之外,我也不用再自己重編kernel和找driver,每一台Mac都是買來後一打開就能用了。

後來Mac用久了,漸漸發現更多Mac的好處,尤其是對於programmer而言。

每一台Mac都有附Mac OS X的安裝光碟,裡面同時附帶Xcode。而只要把Xcode裝上去後,我整台Mac就已經準備好可以讓我工作了。Xcode是Apple開發的IDE,可以開發各種常見的程式語言,但其實我不用這個。我都用Xcode底層的command line工具,像是gcc、make、svn,加上OS X內建的screen、vim、perl、python、apache(只用這些的話其實連Xcode都不用裝,每一個OS X都內建),我就有了完整的程式開發環境,而且我甚至還不需要連上網路就可以有這些。除此之外,Xcode裡還附帶很多好用的開發、除錯工具,像是我最愛的Shark(非常好用的profiling和memory debug工具)、或是Malloc Debug(找memory leak的好東西)、BigTop(監看每一個process耗用的資源記錄)。

自從我轉到Mac後,後來因為需要寫跨平台程式而切到Windows時,都覺得極端痛苦。因為Windows是給一般使用者的系統,而且所有程式都是獨立分開的,每次光要把開發環境準備好就要先耗上一整天在下載和安裝。後來我學乖了直接裝cygwin弄一個假的UNIX環境出來,但cygwin畢竟還是跑在Windows上,系統設計的哲學不同讓cygwin還是格格不入。(像是Windows就是沒有用文字檔存放系統設定,所以也沒辦法用一般的文字工具自動操作;Windows也沒有提供夠多的command line工具可以控制系統;Windows也沒有符號連結(symbolic link),我之前想用Bazaar check out一個有符號連結的repository就爆炸了…)

從Linux轉到Mac,讓我可以花更多時間專注在我想寫的程式上,而不是拿去研究driver的相容問題,或是Linux kernel新增的設定選項。對於一個應用程式或網頁程式的開發人員來說,這些底層的細節都是不重要的。雖然說Windows也把系統底層的細節藏起來了,但它實在藏的太徹底了。萬一偶爾需要看系統底層的訊息來debug,在Mac上還是跟Linux一樣直接到/var/log下grep一下就有了,但在Windows上除了「回報給微軟」外,也沒太多辦法可以自力救濟。

Mac上很多設計也改變了我使用電腦的方式。例如說QuickSilver讓我可以用鍵盤快速啟動任何程式,甚至是做更複雜的操作。Spotlight讓我不再需要思考怎麼把檔案文件分類整理到不同folder裡,需要什麼就像用google一樣只要直接用spotlight找就好了。Mac上的繪圖、設計軟體都有很貼心的設計,例如OmniGraffle的自動對齊線,可以幫忙使用者輕易設計出平衡、一致、美觀的圖像、網頁、或是圖形介面。Mac上幾乎什麼都可以自然地用drag and drop操作(例如Safari很早以前就可以把檔案拖到網頁裡上傳),但很奇怪Windows上就是有些地方可以有些不行。

整體來說,Mac是一個融合Windows和Linux雙方優點的平衡點,我可以像一般使用者一樣不費心力的操作電腦,也可以用高效率的command line處理複雜的任務,甚至是在需要的時候扮演hacker挖掘底層的錯誤訊息,或是利用Darwin Ports安裝和修改我需要的open source軟體。但除了Mac外,其實我還是有在用Linux,只是都跑在遠端的server上而已。主要原因是在沒有圖形介面時,Mac就沒有什麼優勢了。所以到現在即使我的laptop都改用Mac,我也還是會有一個terminal連到我的Linux server上。(雖然說主要是拿來掛IRC和BBS的…)


五月 7, 2010
» Do the right thing and do the thing right

這學期糊里糊塗的就忙過去了,回頭看看blog,學期中竟然連po篇文章的時間都沒有。(順便跟有留言的讀者道歉,之前太忙也沒時間回,留言似乎就這樣積到喜瑪拉雅山上了….)

因為畢業前一定要做一次助教,剛好老闆這學期開課人少不夠,就被拉去做助教了。在MIT做助教還真不是普通花時間,難怪拿的薪水比之前做RA還多。在這當助教一學期後,有個簡單的心得:全天下的學生其實都沒兩樣,MIT的學生也沒有比台大的學生厲害。以前在台灣當鄉民,聽過很多外國月亮比較圓的謠言,最經典的像是「美國大學生都不蹺課,因為學費很貴」(才怪XD MIT學費一年三萬多美金,蹺課的也多的是),「美國名校學生都強如鬼神,人人考試都100」(才怪XD 考試出來成績也還是常態分佈;期末project也一堆做得亂七八糟,能讓人眼睛一亮的一隻手都數不滿。)

以前我也在台大當過助教,相較之下,兩個地方能讓人眼睛一亮的學生比例其實差不多。這實在蠻令人納悶的,這兩個學校的學生原本也都是各地頂尖的「強者」,但被聚集在一起後,整體程度也還是回歸到常態分佈。(這就是所謂的人外有人,天外有天,一山還有一山高?)

觀察這些強者中的強者其實是蠻有趣的事,到頭來我覺得這些人其實也是普通人,一樣要吃飯睡覺,一樣有男/女朋友,一樣有各種千奇百怪的興趣。但唯一不同的是,這些強者似乎比較知道怎麼做「對的事」。

昨天我跟其他兩個助教加教授四個人馬拉松5個小時看了四十幾組的project demo,因為題目是各組自訂的,大家應該都是選了自己最有把握最有興趣的東西做。每一組都或多或少有做出點東西,有的組雖然做的功能很單純,但他們把這些簡單的事做得非常好;有的組雖然做了很多東西,但其實大多跟我們在意的重點沒什麼關係。

馬拉松一天後,晚上有個助教就收到其中一組的抱怨信。他們說10分鐘的demo時間根本不夠,他們花了很多心思把程式修到沒有bug,還花了很多時間做了功能A、B、C、D、E,但成績竟然不到全班平均。

收到這樣的信其實還蠻囧的。他們其實不是做得不好,只是根本沒搞清楚重要的事是什麼,所以雖然花了很多力氣,但方向完全就搞錯了,不重要的事做到200%也不會變重要。此外,更糟的是他們一直都沒有意識到哪裡不對了,所以才理直氣壯的來討分數。反觀能讓人眼睛一亮的組,他們一開始就花了比較多力氣確定要做什麼才是對的,一旦確定後,雖然做的事情可能比較小,但因為做了「對的事」並且也把事情「做對了」(do the right thing and do the thing right),成果就能讓非常人印象深刻。

一個最好的現代例子莫過於twitter。twitter的功能實在簡單到不行,在web 1.0甚至bbs時代就有一大票功能遠強過twitter的留言板或論壇網站,但twitter卻異軍突起了。原因很單純,twitter選擇了幾個對的事(WEB+限制長度的短訊+公開API),然後把他們做到最好。

Do the right thing and do the thing right雖然是很簡單的概念,但令人意外的,即使在世界上可能是天才密度最高的地方,卻還是只有非常、非常少人能同時做到。


一月 30, 2010
» Sikuli帶來的意義與無限的潛力

這禮拜真是我人生中最瘋狂的一天了..。

自從Sikuli發表後,我本來還打算一封封回覆所有的問題,後來發現排山倒海而來的郵件和留言速度遠大過我能閱讀和回覆的量。前幾天我優先把Sikuli比較大的bug和一些平台問題修掉,昨天釋出了0.9.7讓各平台都提升到同樣的版本(只剩Linux還是沒有抓圖的快捷鍵了),整體運行的速度也提昇了不少,並且新增了一個.skl格式讓人能透過command line或double-click直接執行script。如果之前下載過舊版的朋友強烈建議升級到0.9.7。

修完緊急的bug後,我們會再陸續補上一些文件和教學,說明一些常見的問題要怎麼解決。例如說,畫面上有多個一樣的元件(像check box, radio button)要怎麼處理如果按特殊鍵或是在不同的鍵盤排列上使用(用dvorak的人還真不少,一堆人跟我說type()在dvorak上會有問題)..。

但這篇文章中我想談的不是被上萬人盯著的壓力,而是關於Sikuli能帶來的改變,以及未來的潛力。

有些人說Sikuli看起來只是另一個按鍵精靈或是AutoHotkey,但其實Sikuli還有許多在這個直觀意義之上的潛力我們沒直接說出來。

第一,Sikuli最重要的革命是程式碼的可讀性(readability)和易用性(usability)。把螢幕截圖直接放在程式碼裡面,讓人能直接「看到」他想控制的東西,這是從來沒人想過的事情。以往的方法,不管是透過應用程式自己的程式介面(API)或是透過XPath拿到網頁裡的某個元件,都是只有程式設計師才能寫、才能讀懂的神秘外星語言。機器喜歡精確的語言,人類花越多力氣把事情描述的越清楚,機器就越容易讀懂。

可是,有沒有人想過,人類發明這麼多程式語言來操控電腦,究竟是便利了人類還是便利了電腦?現在我們每天用的程式語言,不管是C++、Java、C#、Python、Javascript..都是只有程式設計師才能寫才能讀的語言。更諷刺的是,這些「現代」語言跟五十年前就有的LISP、Fortran本質上並沒有什麼不同,一樣都是純文字,一樣要求精確嚴謹的語法,一樣是架在百層高塔的系統架構上。即使是訓練有素的程式設計師,要寫程式做些有用的事情也都得先翻翻充滿黑話的說明文件,看看需要的功能對應到什麼函式,運氣不好可能還得學個COM+之類的鬼東西才能使用。

如同我在追求神乎其技的程式設計之道(十):程式設計師的生產力之謎中提過的一樣,即使同為程式設計師,運用電腦的效率依然會有數十倍甚至百倍的差距。如果每天都要按一百個按鈕,程式設計師可以找到適合的命令列工具使用,或是自己寫程式呼叫應用程式提供的函式,就可以用一個按鍵取代這一百個按鈕。那完全不懂程式的一般使用者呢?恐怕只能兩手一攤任由別人寫好的軟體擺佈。也就是說,即使一個人掌控了鍵盤和滑鼠,但實際上卻是被別人的軟體限制住,如此使用電腦其實完全沒有自由可言。

Sikuli的革命把寫程式的門檻降低了,人們和系統或應用程式溝通不再需要讀用黑話寫的文件,也不用搞懂底層的架構是怎麼做的,只要把平常使用鍵盤滑鼠的方式,再加上想控制目標的螢幕截圖,就可以輕易寫成能自動執行的程式。

Sikuli Script範例

除了好寫外,任何人看程式和圖都能很容易讀懂程式到底做了什麼事,於是Sikuli很自然就能成為一種寫教學文件的最佳媒介。以往的教學文件常常step by step列出使用者要做的事,加上使用者應該要看到的畫面,很巧的是這兩者Sikuli script都有。但比傳統的文字描述更好的是,只要把Sikuli的指令混用在文件中,或是透過簡單的對應把文字描述轉成script,這樣一份文件不只人能看懂,連電腦都能執行這些步驟並且一步步告訴你要按的按鈕在哪裡。

第二,除了直觀上的GUI自動化外,其實Sikuli更重要的意義是提供了一種把使用者操作UI的互動過程記錄下來的新方法。以程式設計師的黑話來說,這可以說是GUI操作過程的serialization,如果用一般人的方法說,這就是把人機互動過程「數位化」的一種方法。

電腦發展的過程中,一條必經之路就是把人類周遭的一切資訊全部數位化。一旦資訊被數位化,就可以輕易儲存在電腦裡,或是透過網路分享給別人,電腦科學家也才能發展更多方法來處理、分析、運用這些資料。在21世紀的今天,人們把聲音、影像、文字全都數位化了,所以我們可以輕易的複製、傳播、使用這些資訊。但在人們如此依賴電腦的今天,人和電腦的互動過程其實一直沒有一個好方法可以記錄,所以更別提要複製或是分享這種互動過程。

而Sikuli在這個人機互動領域開了一條全新的道路,這也是為什麼Sikuli的論文是出現在「User Interface Software and Technology」的會議上,而不是在討論程式語言的會議上。

人機互動的過程一旦能被一個標準的方法記錄下來,接著就能複製,就能分享,就能讓電腦自動執行或是演算這些過程。未來的應用方式有千百種,唯一的限制只是看我們的想像力而已。

第三,Sikuli把電腦視覺的研究領域,從真實世界延伸到電腦的桌面上。這點說起來真是很有趣,電腦視覺的研究人員數十年來嘗試想讓電腦能像人一樣「看」這個「真實世界」,可以像人一樣認得別人的臉,或是認得馬路長什麼樣才能讓電腦自動開車,但卻沒什麼人想到讓電腦「看」電腦自己輸出的畫面。在技術上來說,電腦螢幕上的資訊全都是電腦自己產生出來的,沒有光影問題,沒有角度問題,辨識上的難度遠低於真實世界所需的難度。以現在的電腦視覺技術來說,辨識螢幕上的東西簡直可以說是殺雞用牛刀。

Sikuli把電腦視覺和人機介面兩個研究領域打通了,有很多古老的問題(例如OCR,文字辨識)在真實世界很難解決,但在電腦桌面上卻可能可以發展出又快又準確的方法。Sikuli也可能激發更多人把電腦視覺應用到軟體介面上的創意,讓使用者介面不只是簡單使用,也能讓每個人能真正隨心所欲的操控電腦。

第四,建立在Java平台上並且open source的Sikuli,很有潛力能讓每個人都能打造給自己的專屬程式。

Sikuli不只是提供了一堆自動按滑鼠和按鍵的指令集而已,每一個Sikuli script都是一個和Python語法相容的程式。這意味著你可以使用任何的Python語法,不管是迴圈、if、定義function、或是定義class,每一個Sikuli script都是一個真正的Python程式(嚴格來說,應該是Jython,但這中間的差別並不太重要)。除此之外,Sikuli核心是跑在Java平台上,所以可以輕易的使用任何Java的函式庫。例如說,你可以用swing建立一個新的視窗包含了兩個按鈕,按下第一個就用Sikuli執行每天上班前的例行工作,而按下第二個紐則執行下班前的例行工作。會寫程式的人可以輕易混用Sikuli和現有的函式庫,把Sikuli當成和系統或其他應用程式溝通的媒介,並在上層建立自己的新介面。也就是說,這就是桌面環境的mashup,可能的應用是無限大。

雖然不懂程式設計的人,難以撰寫複雜的GUI程式或是資料處理。但Sikuli結合了現有的平台並且open source,這樣的好處是會有來自世界各地有閒有能力的人幫忙讓Sikuli變得更簡單更好用,並結合其他的程式語言或是函式庫讓寫程式的整體門檻大大降低。

雖說Sikuli現在還不是那麼完美,但我相信open source會加快Sikuli的發展,讓更多有興趣的人進來幫忙。很多技術上的問題其實都好解決,例如有人問到是不是桌面換個skin後script就廢了,或是能不能在背景執行script。這些問題其實都有好幾種可能的答案可以解決,只是有沒有必要現在就做而已。技術問題向來都不是能阻擋我的絆腳石,真正困難的只有突破自身創意和想像力的界線而已。

每個人使用電腦的方法都不同,軟體公司設計的軟體也只能按照大部分使用者的需求和習慣所設計。但不論有多少功能,總是不可能涵蓋到每個人的大大小小需求。讓每個人都能寫程式(不論他們是不是知道他們正在寫程式)是我一心嚮往的目標之一,或者說是我希望每個人都能100%按照自己的意願花最少力氣完成最多工作。但在今天的電腦環境上,不會寫程式就有太多事都無法做到,即使會寫程式的人,也不見得願意花那麼多力氣去研究讓自己未來更省力的方法。

這個問題的癥結不在於使用的人太懶惰或是不夠聰明,而是電腦太難用。一個人得經歷幾年的訓練才能熟悉這種用程式「掌控」電腦的感覺,實在太不合理。或許沒有人想研究讓寫程式變得更簡單是因為怕丟了自己的飯碗,但我偏偏就覺得每個人應該要有聰明使用自己工具的自由,而不是反過來被工具限制了自己。所以,我希望Sikuli能讓更多人把使用電腦的自由搶回自己手中,而不是被軟體工程師們掐住脖子動彈不得。

寫到最後,能參與Sikuli這個project其實最需要感謝的人是和我合作的Tom Yeh,在我進MIT前他就在跟我老闆Rob Miller討論用螢幕截圖來搜尋文件的可能性,所以其實在我還在當兵時我們就已經搭上線開始合作了。後來我到了MIT後,一連串的討論就激發出許許多多混合螢幕截圖和電腦視覺所產生的點子,其中第一個成果就是現在的Sikuli。

Sikuli Script只是這一串研究的開端和基石,在這之上其實我們還做了很多東西。例如說我們已經有一個能錄製螢幕和使用者動作的程式,可以把使用者的動作自動轉換成Sikuli Script,也就是說使用者一行程式都不用寫,只要把想做的步驟做一次,程式碼和螢幕截圖就會自動產生出來讓你修改或直接使用。用這個錄製程式,我們可以輕易的在現有的GUI系統上觀看全系統的操作歷史,甚至是自動redo某一部分操作。有這些系統做基礎,我們能做的事情實在太多了,我只怕自己時間和能力有限,沒辦法把所有的點子都做出來。所以,這也是我們把Sikuli公開的目的,希望開放這塊寶石後,能有更多人發揮想像力發明出更有趣更有用的東西來,並徹底打破現今使用電腦的方法,一起來改變世界吧!


一月 25, 2010
» Change The World!

之前一直沒機會跟大家分享我在MIT到底在做什麼研究,但拜登上MIT首頁的一篇報導「Picture-driven computing」所賜,我這兩年的project Sikuli像原子彈爆炸一般透過slashdot和twitter以不可思議的速度擴散開來。而這幾天,剛好碰上學校每年都會舉辦的滑雪三天三夜旅行,我照著計劃坐上遊覽車到四小時車程外的緬因州滑雪。第一天晚上到旅館發現沒網路可用,只好早早上床睡覺養足隔天的精神。到了隔天中午,在雪場的餐廳吃午飯時,我想說該來試試有沒有網路用,於是拿出ipod touch連上網後,沒想到迎面而來的是近百封關心sikuli的郵件。在震驚之餘,我還沒意會過來到底發生什麼事了,直到我看到一封來自跟我同實驗室的學長Michael發給實驗室所有人的信,標題寫著:「Sikuli on Slashdot!」,接著我才意識到:啊!原來是遭到slashdot effect攻擊了!(slashdot是全世界關心科技、網路、電腦技術的人幾乎必看的網站,只要某個網站一被登上slashdot,馬上就會遭到來自世界各地數以千計的閱覽攻擊,其效果等同於分散式阻斷服務(DDoS)攻擊,而這現象就被稱為slashdot effect。我以前都以為只有網站會有突然出現的巨大流量,沒想到連我的信箱也會…)

在這件事情之前,我從沒體驗過媒體和網路的力量可以有多麼驚人。從MIT News發出的一篇報導,隔天被轉載到一小部分科技、技術網站,並且在twitter上開始有人開始口耳相傳這個新玩意。再過一天,有人把這消息推上了Slashdot: MIT Offers Picture-Centric Programming To the Masses With Sikuli,很快的sikuli這名字開始傳遍世界。我在twitter上搜尋了sikuli,想看看人們都說些什麼,結果看到由各種不同語言寫的tweet不斷湧出,就在我還沒看完一頁時又冒出 「xx more tweets since you started searching」 的訊息。搜尋出來的tweets除了絕對多數的英文外,也看到很多俄文、法文、日文,反倒是中文的消息最少,實在讓我有點哭笑不得。(關於訊息的傳播,我也透過這次的事件觀察到不同國家對同一事件反應的一些有趣現象,以後再另寫新文跟大家分享。)

人在偏僻的山中滑雪,突然看到這麼多人們在討論著我的project,還有信箱裡塞滿各種關於sikuli的問題,讓我興奮得不得了。當時我的心情其實完全顧不得滑雪了,但難得的旅行還抱著電腦一直坐在餐廳裡實在也有點可惜,只好趁著有網路時把每封信大略瀏覽一下,下午就趁著坐纜車上山的空檔想想怎麼回覆這些郵件。

太陽下山後,我終於按奈不住卸下裝備就拿著電腦回到餐廳裡繼續連上網,結果又是更多的郵件湧入、更多的tweets、更多的衝擊。而當初把sikuli open source的決定,也讓我接到來自世界各地開發人員的意見和回饋,有人在一天內幫我把Linux上還沒實作的幾個功能寫完並送了patch給我,也有人為了在它的64-bit Windows上執行而直接hack了沒有原始碼的二進位EXE wrapper。除了寫程式的人外,有專業的user experience designer願意加入,也有人志願幫忙移植到Linux的工作。看著這些不知道什麼時候才能回完的信,我突然發現,我似乎真的做了一件不得了的事….。

在MIT裡其實常常能看到許多很驚人的點子,但可惜的是即使在MIT,大部分的東西也都停留在為研究而做的雛形階段,研究人員雖然產出了論文,但如果沒有對的人讀到那些文章,很多好點子也不過是停留在紙上變成可回收的資源而已。

Sikuli的論文其實在去年九月就在ACM關於user interface中最頂尖的會議UIST上發表了,在當時還拿了Best Student Paper Award,但為什麼一直到今天才突然爆發開來變成人們口中「革命性的新發明」呢?

說起來這還是得感謝MIT有自己的News office,一個記者剛好問了我老闆最近有沒有什麼有趣的研究,於是sikuli這個字就從這篇報導散播開來。但除此之外,我也蠻慶幸之前自己決定要把sikuli release出去,而且老闆也很支持我這麼做,整學期都沒問我「研究」上的進度。(把程式release跟研究本身沒什麼關係,有些教授對這些研究結果的實作是否能實用也不太關心,甚至覺得做這些事是浪費時間。)

其實一般人可能很難想像,要把一個研究用的雛型打磨到能夠公開讓任何人用的程度,所花費的力氣可是遠超過寫出最重要的核心功能。我花了幾個星期研究怎麼把Java程式包成Mac上的.app,研究怎麼把.sikuli變成能夠點兩下就打開的document package,怎麼把sikuli會用到的一大包dynamic libs包進.app中讓使用者不用安裝其他的相依函式庫…。搞定Mac後,我又花了一陣子把Sikuli移植到Windows上,雖然上層是Java寫的很好解決,但有部分程式碼是透過JNI連結到C++呼叫OS提供的API才能完成的。因為我一直都用Mac開發,所以這些東西本來都只有寫Mac版的,但為了要真正讓多數人能用這個軟體,只好跟老闆要了一台PC裝上Windows來完成這些相依平台的程式碼。Windows並不是我熟悉的平台,除了國中時玩過VB外,之後就幾乎沒在Windows上寫過什麼程式了。所以為了搞定Windows的移植,除了得速成學會一些Windows API外,還得搞定DLL+EXE的包裝,最後再包成installer讓人能一路按Next就裝完整個軟體。雖然這些事情我都是第一次做,但還好沒遇到太多困難,即使每個禮拜都要花兩三天寫Distributed Algorithms的作業,剩下的時間也剛好夠我處理完這些瑣碎的工作。

完成Mac和Windows初步的包裝後,我也一邊開始做網站、API文件,也請跟我合作的Tom一起寫了一些教學文章,順便讓實驗室的同學們當一下測試的白老鼠。因為周圍沒什麼人用Linux desktop(真是有點出乎意料?),所以Linux版就暫時被我擱著沒動。
後來大家都去放聖誕假期時,我趁著空閒做了一個demo的影片放到youtube上,但因為我也還不急著釋出public beta,所以也沒跟其他人說我做了這個影片。

就在MIT News來採訪的前幾天,0xlab剛好有幾個人突然寫信問我有沒有Linux版的sikuli。雖然不知道他們怎麼發現的,但看到有人想用我也就有了勁想把Linux版趕快完成。花了一天在我新要來的PC上裝好ubuntu後(還包含一個小時在搞定這台電腦的無線網卡driver…。沒想到到了2010年我竟然還在做這種事情…),再修一修Makefile後就包了一個功能不全的Linux版放到網站上。

有句話說「機會是留給準備好的人」。當sikuli被公諸於世的時候,之前做好的事情就突然就派上了用場。MIT News促成了這個好機會讓sikuli這個很酷的想法脫離UI研究會議的小圈圈,進入世界上有網路的每個角落,這時我之前憑著一股熱血就自顧自的作了這麼多的雜事,突然都有了它的意義。於是,在機會到來時,demo的影片加上能下載試用的軟體讓人們親眼看到並且能把玩這個革命性的點子,結果就讓twitter上充滿了一大片的「holy crap this is awesome! http://sikuli.csail.mit.edu」。

我一直夢想著要做些不一樣的事情來改變世界,徹底發揮我的長處做出能夠對世界產生巨大影響力的東西。還記得三年前我在申請MIT時,在SOP上大膽的寫了我的目標「I believe that programming environments should be smarter and more intuitive, and it is my goal to reinvent one that allows beginners to learn easily and adepts to be more productive.」,而三年後的今天,我非常興奮我踏出了改變世界的第一步。


十二月 16, 2009
» 給程式設計師的Vim入門圖解說明

12-09 Update: The English version of Vim Visual Cheat Sheet is also available. PNG, PDF)

(更新: 在圖內加入基本指令表和說明以及PDF版,方便大家列印出來貼在牆上隨時查看。)

剛在寫那篇關於vi和文字編輯器的文章時,本來想附上一個vim的超簡單入門連結,但找了一下都沒有很滿意的,所以決定自己動手先來畫個入門用的說明圖。

vim-cheat-sheet-full
PDF版下載

vim-cheat-sheet-diagram

這個圖把vim中基本的移動方法都畫上去了,為了方便programmer,特別列出了很多只有寫程式才會用的按鍵。除了這些以外,其實還有一些好用的東西我還沒想到怎麼畫上去比較好(像是tags、沒有標準快速鍵的tab、man..),如果大家有idea歡迎提供。

這些圖示依照移動的單位大小分為以下幾個種類,分別用不同顏色標示:
(注意,這不是完整的vim快速鍵列表,只是我覺得比較常用的鍵而已。)

字元(character)
h
j
k
l
單字(word)
w
下一個word
W
下一個word(跳過標點符號)
b
前一個word
e
跳到目前word的尾端
行(line)
0
跳到目前行的開頭
^
跳到目前行第一個非空白字元
$
跳到行尾
段落(paragraph)、區塊(block)
{
上一段(以空白行分隔)

">
">}
下一段(以空白行分隔)

">
">[{
跳到目前區塊開頭

">
">]}
跳到目前區塊結尾

">
">%
跳到目前對應的括號上(適用各種括號,有設定好的話連HTML tag都能跳)
螢幕(screen)、絕對位置
H
螢幕頂端
M
螢幕中間
L
螢幕底部
:x
xG
跳到第x行(x是行號)
搜尋(search)
/xxxx
搜尋xxxx
#
往前搜尋目前游標所在的字(word)
*
往後搜尋目前游標所在的字(word)
fx
在目前行往後搜尋字元x
gd
跳到目前游標所在的字(word)的定義位置(寫程式用, 跳到定義變數/函式的地方)
分割視窗
:split
分割視窗(可加檔名順便開啟另一檔案)
:diffsplit xxx
以分割視窗和檔案xxx做比較(diff)
Ctrl-W p
跳到前一個分割視窗(在兩個分割窗來回切換)
Ctrl-W j
跳到下面的分割窗
Ctrl-W h
跳到左邊的分割窗
Ctrl-W k
跳到上面的分割窗
Ctrl-W l
跳到右邊的分割窗
自動補齊(Auto-completion) (在Insert Mode中使用)
Ctrl-N
自動補齊檔案內的下一個可能字(word)
Ctrl-P
自動補齊檔案內的上一個可能字(word)
Ctrl-X Ctrl-F
自動補齊檔名


十二月 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設計上所下的功夫就明顯不足了。

七月 19, 2009
» Google Wave Devloper Preview

昨天透過神秘管道拿到了Google Wave的developer sandbox的邀請。這看起來是對之前有參加Google I/O的人發送的開發用測試帳號,裡面處處可以看到Google I/O的影子。 第一次登入Google Wave後,乍看之下真是個讓人摸不著頭緒的東西。左邊的Navigation和Contacts看起來很像傳統gmail的介面,但神奇的是inbox裡會一直冒出來新的”wave”,但這些wave卻不是特別寄給我,而是公開給所有人的。看起來Google Wave像個大型論壇(後來發現更像聊天室,因為你可以看到討論串中每個人正在打的每一個字元慢慢出現!),裡面已經可以看到英文、日文、中文的wave,大多是正在嘗鮮的開發者們的測試文章。 wave到底是什麼呢? Google Wave目前給我的印象像是超大型的協同工作+溝通合作平台, Google似乎想把wave變成一種新型態的溝通媒介,可以取代傳統的email或是可多人共享的google docs。一個wave融合了許多概念,除了文字、圖片外還可以包含一種特殊的小程式wave gadget。wave gadget是開放給所有人可以自行開發的,就像igoogle gadget一樣。wave的特色是它可以讓許多人同時編輯、回應,除了可以即時看到每個人的修改外,還有一個時間軸可以回溯整個wave的編輯和討論過程。時間軸可以讓人從最初的樣子開始播放,看每個時間點有誰進來改了什麼,或是做了什麼回應,就像錄放影機一樣。 感覺的出來當wave正式推出時又會是一場新的革命,目前先一步進去的developers就像是幫Google探路的先鋒部隊一樣,除了探索可能的殺手級應用外,也幫Google開發盡可能多的wave gadget。 目前的sandbox雖然看起來已經有基本的樣子了,但速度還蠻慢的。我想這是因為這還沒有廣泛的deploy到production機器上的關係,希望正式版時就不會有這問題。 目前我可以登入的這個developer sandbox裡已經有不少開發者在裡面亂玩,有興趣想先睹為快的人,可以試試看填這個Developer Sandbox Account Request。這是我在sandbox裡面的其中一個wave找到的連結,我不保證一定可以申請到,也不知道要多久,有興趣的人就自己試試看吧。(如果成功申請到也請順便跟我說一下,這樣我才知道這個表有沒有用。)

七月 12, 2009
» Android G1初體驗

android-art_537x496

自從昨天拿到一隻免費的android手機(G1)後,這兩天全泡在android裡。昨天花了一晚研究怎麼不插sim card啟用這隻手機(我寫了簡單的筆記,但是是用英文寫的,我懶得再用中文寫一次了,有需要的就將就著看吧),花了幾個小時降級、取得root、升級後,就不知不覺掉入可怕的android世界裡,這也第一次讓我親身體驗到開放平台造成的震撼。

因為android手機上的軟體完全是開放的,從boot loader、firmware、OS、系統程式、應用軟體、使用介面,無一不能自行修改。雖然我很早就知道android是開放平台,但我之前並沒辦法 想像會真的自己去玩這些hack的人有多少,可是親身體驗過後就發現這世界上有能力且願意投入的強者還真不少。網路上輕易就能找到無數版本的自製系統,經過眾多高手較調和最佳化後,不管是效能或系統功能的豐富程度都遠勝手機內預設的官方版本(像是G1硬體其實有支援multi-touch,但因為Apple把持著專利,所以android官方就不能直接支援。可是這種好康終究是藏不住的,於是有不少自製系統都包進了支援multi-touch的browser…)。更奇妙的是,還有很多HTC內流出來的系統,像是還未上市的Hero,都已經有ROM流出來,甚至還有針對G1最佳化過後的版本。

相較之下,iPhone採取的封閉策略的確讓發展可能性大大受限,開發人員只能在最上層的應用程式區打轉,難以改變系統底層的程式碼。話雖如此,世界上大部分的人買手機只是為了要用它,會像我閒閒沒事一直冒著讓機器 變成磚頭的風險不斷重裝系統的人永遠是少數。android的社群力量雖然強大,但如果社群的產出和商業利益相衝突時,製造商也不會輕易採納,於是最大眾的end user就很難享用到最完美的系統了。

 

我大概在一年前買了Nokia N82,衝著S60、500萬畫素的相機,加上Nokia的品牌才選了它,但實際用起來其實讓我頗為失望。最大的要害是S60實在太慢,讓操作變得很不流暢,每按個鍵都要等上好幾秒才會有反應。雖然相機解析度高,但操作相機的介面卻很糟,按下快門等他對焦並照完也是要好幾秒。S60上的軟體也不容易取得, 雖然我常用的服務(像是Google系列軟體)都有S60版本,但軟體跑得慢就讓人用起來覺得很難過,所以到最後也很少使用。說了一堆缺點後,還是要提一下N82還是有不錯的地方,繼承了Nokia手機一貫的優點:很耐摔XD (手機這種東西要不摔真的很難…)

反觀G1,我原本並不預期G1會有什麼特殊的表現,看過很多demo也沒有特別深刻的印象。但實際用過後,G1超出我預期最多的地方就是它的操作順暢度,不管是web browsing、gmail、或是許多非官方應用程式在操作介面設計上都有一定水準。雖然iphone有multi-touch,但其實並不是有那麼多場合都需要用multi-touch,再加上G1可以透過自製版的軟體用到部份multi-touch的功能,所以iphone和android在我心中的地位差距已經不那麼大了。

七月 6, 2009
» Web上的萬能瑞士刀: Chickenfoot

喜歡用UNIX的人大都知道UNIX會是一個天然且高效率的工作平台不是沒有原因的,純文字的程式輸出入、輕巧又強大的shell、還有適合各種場合的script語言(像是Perl、Python等等)可以把許多小程式非常快速的結合起來完成許多複雜的工作。

但自從web開始蓬勃發展後,越來越多程式和系統開始移到web上。在剛開始的web 1.0時代,大部分網頁都是提供資料的靜態網頁,當時web app也都是用簡單的GET、POST參數接收資料後再到server side做處理。因為網頁是純文字的HTML寫的,所以在這個時代還有一些人會用scripting語言(像是Perl + WWW::Mechanize)來做網頁的自動化處理。但寫過這種程式的人都知道,要parse HTML並不是很容易的事,因為大部分HTML都沒照標準寫,於是只能用regular expression硬來,但無論如何都沒辦法應付一個最大的問題:只要人家的網頁一更新,script當場就變殘廢…。

到了web 2.0時代,問題變得更嚴重,因為web app不再是單純的server side程式;許多網站大量依賴在browser裡面執行的javascript,只是抓網頁回來而不執行javascript往往無法得到browser裡看到的網頁內容。

所幸我來MIT後發現我們group開發的一個超棒工具Chickenfoot,不但讓使用者能用很簡單的指令做到網頁自動化,它甚至還像是一個架在browser上的萬能shell scripting平台,可以輕易把不同網站的內容和功能連結在一起(就像UNIX shell的pipe一樣!)。

Chickenfoot是一個Firefox的extension,可以讓人在Firefox上寫script全自動操作網頁或是修改網頁的內容。Chickenfoot乍看之下很像另一個能讓人在client端另外插入javascript的Greasemonkey,但實際上Chickenfoot更像一個外掛在browser上的快速scripting平台。

Greasemonkey的目標使用者是會寫Javascript程式的網頁開發者,也因此它的進入門檻很高,如果是不會看HTML原始碼、不了解DOM或XPATH、不會寫Javascript的一般人是沒辦法用的。另外, Greasemonkey主要的功能偏重在單一網頁的客制化上,沒有針對網頁自動化做的設計,也很難做跨網頁的自動化操作。

相反地,Chickenfoot的設計是截然不同的方向:1. 使用者不需要看HTML原始碼,只要看網頁的畫面就能用關鍵字來鎖定畫面上的元件,並用簡單的指令(例如自動按按鈕的click、自動輸入文字的enter、自動選擇checkbox的check..等等)自動操作網頁;2. Chickenfoot是獨立於任何網頁之外的平台,可以輕易做到跨網頁的自動化操作,甚至可以從網頁中提取想要的資料,並帶到其他網頁中使用。3. Chickenfoot是browser的一部分,所以只要在browser中能看到的頁面就能自動操作,不用處理認證或cookie問題。

除了網頁的自動化和客製化外,Chickenfoot還有個很有趣的功能:可以把任何Chickenfoot script包裝成獨立的Firefox extension。也就是說,如果要把script分享給他人不需要請其他人事先安裝Chickenfoot,而是直接把「你的」extension給別人安裝就可以了。

我不打算寫詳細的tutorial,我建議可以從實例來學習,例如Google Icon Search就是一個很好的例子,包含了網頁內容的修改、跨網頁的自動化、還有基本命令的使用。最近釋出的Chickenfoot 1.0.5已經支援Firefox 3.5,並且也修正了中文網頁的支援問題,在中文網頁上也能正確執行。

另外附帶一提,我覺得Chickenfoot中有個很好用的小技巧,但在文件上其實不太容易找到XD 在Chickenfoot的script editor中寫script時,每寫一行就可以按ctrl-enter來執行「一行」指令。用這種方式就可以很容易一邊寫script,一邊測試並觀看每一行指令的結果,而不用一次寫一大堆後再一起測試。

有興趣更深入了解Chickenfoot的人可以參考官方網站上的Quick Start GuideExamples,或是直接看看paper: Michael Bolin, Matthew Webber, Philip Rha, Tom Wilson, and Robert C. Miller. “Automation and Customization of Rendered Web Pages”

六月 26, 2009
» 傳奇人物就在我身邊

今天老闆突然寄來一個youtube video給大家,影片內容是1988年世界上第一隻Internet worm: Morris worm出現時造成的話題新聞。

Morris worm是網路上出現的第一隻worm,它會利用系統的bug (sendmail、fingerd、rsh)複製自己並散播到其他UNIX主機上。當時這隻worm還被稱為virus,但它的威力比起一般virus又強大許多,因為一般的virus只能在同一台電腦中複製自己感染不同檔案,所以擁有向外擴散能力的Morris worm在當時引起了很大的風暴。

這隻worm當時是從MIT開始擴散的,所以讓很多人認為作者是MIT的學生。但後來發現,作者其實是Cornell的研究生,會選擇從MIT開始散播就是要混淆視聽。據說這隻worm當初被開發出來的目的並不是要造成什麼破壞,而是為了測量Internet的大小,只是程式有點bug,沒想到…就造成了全世界的電腦大癱瘓。因為這隻worm實際上造成了非常大的損失,所以作者也成了美國第一個被以電腦詐欺及濫用法定罪的人。雖然作者遭到定罪,但他仍被視為某種傳奇的英雄人物,因為這隻worm暴露出網路系統的bug可以造成多大的危害,也迫使所有人開始重視網路系統的安全問題。

很有趣的是,這個當初在Cornell企圖利用MIT來混淆視聽的學生,現在竟然是…MIT的教授Robert Morris。從他在MIT的網頁完全看不到這段過去的「傳奇事蹟」,但如果去看他的wikipedia頁面,就會發現整頁幾乎都是在講Morris worm而已XD

我在知道這件事後實在非常驚訝,因為我上個禮拜才因緣際會跟他一起吃了許多頓飯。雖然坐在一起吃了很多次飯,也都沒聽人說起這件事,直到今天迂迴的發現原來他就是Morris worm的作者,才讓我大大吃了一驚。

另外,藉由他的wikipedia page,我還發現他跟Paul Graham是超級好朋友,曾一起開過一家公司Viaweb (後來賣給Yahoo!,成為Yahoo! Store的前身) ,後來還一起發明一個程式語言Arc。(Paul Graham是著名的LISP Hacker,寫過很多LISP的書,還有一本我很喜歡的「駭客與畫家」。)

正覺得世界很小的時候,我又發現更驚人的事情。原來Robert Morris的老爸竟然是美國國家安全局底下的電腦安全中心首席科學家,專長是密碼學,每個UNIX都會有的/etc/passwd裡的加密密碼就是用他寫的crypt library產生的。

把全世界搞得雞飛狗跳的hacker,老爸竟然是國安局的密碼學家,這可以說是….虎父無犬子嗎XD

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

五月 13, 2009
» 從快打旋風談格鬥遊戲

Street Fighter 4

已經想寫一篇文章討論「遊戲」很久了,遊戲對我影響很深,但玩遊戲在社會上一直是個不入流的娛樂,在爸媽眼裡是個會讓小孩墮落的萬惡淵藪。就像如果有人問平常的休閒娛樂是什麼,回答打高爾夫球人家就會覺得你是上流社會的公子,但回答打電動就會被貼上宅男的標籤。小時候如果愛打電動(尤其去外面的電玩店),還會被當成開始變壞的前兆,彷彿玩快打旋風就會真的去跟人家打架一樣。

根據我爸的說法,我打電動的歷史可能比我的年紀還長。因為我媽在懷我的時候,我爸買了一台Apple II給我媽玩遊戲,所以.. 我應該是在我媽肚子裡就開始學著打電動了吧XD

玩遊戲這件事被污名化很久,好像玩遊戲都是百害而無一利,好像每個遊戲都是打發時間的娛樂而已。所以我決定還是要寫點東西,說說玩遊戲的深度和價值在哪,幫廣大遊戲玩家吶喊一下,也希望能讓沒接觸過的人少點刻板印象甚至產生興趣。

我最早接觸且著迷的遊戲是格鬥遊戲,從快打旋風1代 (Street Fighter, 1987)我就玩過了,但那時還不太會玩,而且格鬥遊戲的基本系統也還未發展成熟,所以快打旋風1代比較像是純粹的拳打腳踢遊戲。接下來就是引起全世界格鬥旋風的經典之作:快打旋風2系列 (Street Fighter 2, 1991-1994)。之所以稱快打旋風2為經典,是因為它訂定了現代格鬥遊戲的基礎系統,這個我稍後再詳細說明。除了CAPCOM的SF2外,當時我比較愛的其實是SNK的餓狼傳說(Fatal Fury, 1991)、龍虎拳(Art of Fighting, 1992)、侍魂(Samurai Spirits, 1993)這三個作品,這三個作品其實各有特色,但大體上已經脫離不了SF2訂下的基礎,只是加上了一些延伸變化(例如超必殺技或是加上武器)。

當時2D格鬥遊戲的世界說起來只有兩大陣營,一是製作快打旋風系列的CAPCOM,另一個就是SNK。CAPCOM在SF2時期非常風光,但很可惜過了幾年,就被SNK的另一經典: 格鬥天王 (The King of Fighters, 1994) 打得慘兮兮。KOF的特色在3人一組取代1對1的格鬥,還有華麗的招式及連續技。只可惜SNK太注重於華麗連續技的技巧,導致格鬥被扭曲為能輸入強力的連續技的人即佔有極大優勢,而喪失了原始對戰的精隨。

那格鬥遊戲的精隨到底是什麼?

簡單來說,就是即時互動的心理戰:根據對手的行動即時應對,需要敏銳的觀察力看破對手的行動、瞬間的反應力以見招拆招、準確和穩定的執行力趁對手露出破綻給予強力打擊。

這也是人類競爭的精隨與本質,只要能早一步洞悉對手的行動,就能克敵制勝。無論在球場上,商場上,或是戰場上都是一樣。格鬥遊戲只是把這個兩人賽局的過程濃縮到一個三戰兩勝的60秒戰鬥裡。所以說,格鬥並不是比誰的力氣大或招式比較華麗,而是一場即時鬥智加上鬥技的競賽。

先前提到過快打旋風2建立起了格鬥的基礎系統,這系統包括了幾個最重要的基本元素:輕、重攻擊,上、中、下段的拳腳攻擊與防禦,以及無法防禦的摔技。所有的格鬥遊戲都脫不出這些基本要素,除了這些基本元素外,剩下的連續技或是超必殺技都只是看起來很華麗的包裝而已。

這些格鬥的基本元素就像剪刀石頭布一樣,兩兩相剋,沒有一個無敵的妙招。上段攻擊可以站著防禦,蹲下則可以閃開;中段攻擊可以站著防禦,蹲下卻擋不住;下段攻擊不能站著防禦,只能蹲著防。也就是說,站著防可以防上中段攻擊,卻防不了下段攻擊;而蹲著防可以防上下段攻擊,卻防不了中段攻擊。所以當你想採取防禦姿態時,就要猜測對手的可能攻擊,是中段?還是下段?

一般來說,中段的攻擊招式或拳腳比較少,所以初學者大多會一直蹲防。如果我是攻擊的人,就會試探對手是不是偏好蹲防,或是故意一直用下段攻擊讓他以為我偏好打他的下盤,等到關鍵時刻,就可以用中段攻擊起頭再接上連續技打得他措手不及。

格鬥遊戲至少會有3戰2勝,也就是說第一場的輸家只要有學乖,還是有機會反敗為勝。但正如我所說的,格鬥其實是心戰,一切的關鍵就在能不能看透對手的想法和策略。聰明的對手如果在第一場學到不能一直蹲防時,突然的中段攻擊可能就不是那麼有用,這時我就會找其他的弱點來突破他。前面有提到,除了上中下段的攻擊與防禦外,還有一個重要元素是摔技。摔技是近身時才能使用的招式,摔技的特點是無法防禦,所以很適合拿來對付很愛防禦的人。以上一場學乖的那個對手來說,他如果反應力很好能看穿我要打中段還是下段,他就會很專心看我的動作,這樣我可能絕大多數的攻擊都會被擋下來。這時,要突破他最好的方法就是接近他,用輕拳攻擊誘使他專心防守,再突然用摔技來突破他的防禦。

這麼說來,摔技就是無敵的囉?當然不是,最簡單的反擊方法就是跳開,然後對手就會因為摔技失敗而露出大破綻,接下來就可以趁隙反擊。

選擇攻擊的輕重也是另一種tradeoff。輕攻擊威力較小,但即使揮空後的硬直時間(任何攻擊和招式使出後都會有一小段無法行動的時間,即稱為硬直時間)也很短;相反地,重攻擊威力大,但是萬一揮空的破綻也大。所以在攻擊時,不該以破綻大的攻擊起頭,而應該盡量以破綻較小的攻擊開始,如果命中再接著輸入連續技給予大打擊。

快打旋風除了建立起這些基本攻擊系統外,還引入兩個每個2D格鬥都看得到的標準招式:波動拳和昇龍拳。波動拳是遠距離的牽制武器,即使不在對手身邊也能照樣攻擊他。昇龍拳是對空武器,只要對手傻傻的跳過來,就可以用昇龍拳把他打下來。這兩種招式帶給格鬥遊戲更多變化,也把戰鬥從近距離的拳腳纏鬥提升到更寬廣的層次。

和2D格鬥比起來,3D格鬥遊戲就少著墨於飛行武器和跳躍攻擊,例如VR快打系列(Virtua Fighter, 1993)講求的是真實的格鬥技,沒有誇張的氣功和必殺技,所有招式都只是拳腳攻擊的組合和變化。相較之下我一直都比較愛VR快打系列,勝於其他所有的2D格鬥,因為VR快打裡沒有華麗的包裝(呃,畫面很真實其實是它的賣點之一啦),只有純粹的格鬥。

最近為了快打旋風4買了Xbox 360,能在網路上和無數高手對戰真是喚醒我體內格鬥的熱血。面對真人和電腦是完全不同的感受,像是上面所說的引誘對手只防守下盤基本上只對人有用,對電腦來說是沒什麼意義的。人容易被騙,但人也學得很快。我在網路上常遇到各種不同打法的人,有的善於不斷混用摔技和打擊技(這叫投打二擇。投擲和打擊二選一的意思)讓你不知道該防還是該躲,有的不斷利用近身跳躍到你背後踢背(直接跳過你踢你的背,所以要反過來往另一邊防禦才行),有的一直龜在地上不動等你跳過來就昇龍拳…。

世界上玩家眾多,可以說有多少人就有多少種打法。我最喜歡在第一局觀察對手的攻擊模式,並加以試探他可能的弱點。即使第一局輸了,也要在二三局利用他的弱點和模式反將他一軍。有時對手比我還高干,就可以明顯感受到兩個人透過畫面上的角色互動揣摩對方的戰略和弱點,一來一往之間都會不斷迸出激戰的火花,實在非常過癮。

其實格鬥遊戲就像許多雙人對打的運動一樣(例如桌球、網球),除了講求準確的肌肉控制技巧外,也需要即時的觀察與反應力,更重要的藉由對手的動作和反應看穿對手的內心,並從這種互動過程中學習和成長。

四月 14, 2009
» [DIY] Dominion Travel Box

最近閒來無事就會找朋友玩board game,而Dominion目前是在我的收藏中最好玩也最耐玩的一套(強力推薦!)。dominion最大的特色是有500張卡片,每次遊戲是從25種行動卡中挑10種出來玩,而每次看到不同的行動卡都得擬定不同的策略和牌組來取勝。不同的行動卡有不同功能,遊戲中購買卡片時要仔細思考並互相搭配行動卡組成連續技才能發揮最大效用。除此之外,遊戲的勝利條件是要購買勝利點數,在適當的時機開始買點數並保持自己牌組的平衡也是遊戲的一大挑戰。Dominion的規則超簡單,但卻很耐玩;它耐玩的地方在於每次都只挑其中10種行動卡,所以變化非常多,每次用亂數決定也很難玩到重複的組合。而且隨著玩家經驗的累積,常常會發展出不同的策略和打法,即使是同樣的牌組多玩幾次也有不同樂趣。但有點可惜的是Dominion只能最多4個人玩,人太多就沒辦法玩了。(其實我們有試過5個人玩過,同時修改一下遊戲結束條件也還是很好玩。另外,其實5月Dominion就要推出擴充版了,最多可以同時6個人玩一桌,或是8個人玩兩桌XD)

雖然dominion是純卡片遊戲,但因為它的卡片種類實在太多,每一種卡都要分開來放,所以導致它的盒子非常的大,每次如果要帶出去,就很難再帶其他的board game了..。為了解決這個困擾,我的DIY魂又燃燒了起來,於是最近在玩時都一直碎碎念:「既然買不到小盒子乾脆就自己做吧!」。

我的目標是設計一個可以剛好放進500張卡片的盒子,大小要便於攜帶,而且也要容易把想要的卡片拿出來。google一下後發現也有人做了同樣的事。但我照他的設計圖做了一個prototype後發現他的盒子有點太大了,而且他的圖上沒有畫黏接面,剪好後沒辦法黏起來XD 所以我就依他的設計修改了一下,讓盒子的尺寸能剛好塞進沒上過牌套的500張卡片加上33張分隔卡。以下是我的設計圖:

dominion travel box design

dominion travel box design

盒子主體和蓋子我是拿有點硬度的壁報紙做,但我後來覺得應該要拿更厚更硬的紙板才會夠堅固。盒子的角落會有4個70×70的正方形,我把其中兩個對半剪開加上雙面膠拿來固定四個角落。盒子完成後,蓋子也是如法炮製,只是尺寸稍大一點而已。我做完後發現上蓋的長寬可以再小一點,其實應該比主體各多2mm就足夠了。但我已經懶得再做第三次,就留給有心人去試吧。

分隔卡總共要33張,包括25張行動卡、3張錢幣卡、3張勝利點數、1張詛咒卡、1張place holder。我用上面那個連結裡的設計圖,把他的每張分隔卡上半部剪下來,自己貼在70×90的紙板上,重複33次就完成了..。(手工藝真是很累orz)

成品與原盒的比較。 From [DIY] Dominion Travel Box
33張分隔卡。 From [DIY] Dominion Travel Box
把卡片全部放進去的完成品。 From [DIY] Dominion Travel Box

三月 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的學術聲望和財力,要邀請各地的講者也不是什麼問題。台大雖然是台灣頂尖學府,但台灣距離西方國家太遙遠,很少人會專程想來台灣,再加上台大也沒辦法負擔這種國際旅行的費用(話說,五年五百億都用哪去了?),也難怪國際化只能停留在教授改用英文上課上面了。

二月 22, 2009
» 又開學了

上學期結束後,我有種浴火重生的感覺,讓我在放寒假時完全的放空,好好做一些學期中沒辦法做的事。

於是在這個寒假中,我開始學滑雪和鋼琴。(呃 我知道這兩件事完全扯不上邊…)

身在波士頓這個有將近半年時間被雪掩蓋的城市,滑雪幾乎是每個當地人從小就會玩的休閒運動。台灣天氣雖然四季都很溫暖,但相對的也有著終年都不會降雪的缺點(?),以致於只要寒流來襲讓合歡山下了點小雪,通往山上的道路就會在一夜之間爆滿。


Snow in MIT

Snow in MIT

先來點題外話。在台灣會覺得下雪好像很浪漫,實際上如果生活在雪國裡可完全不是這麼一回事。下雪的第一天很漂亮,整個城市會鋪滿白雪。但到了第二天後,行人道和路面的雪都會被剷除,然後堆在路邊變成一座一座小山。如果在下學期間幸運沒什麼人車經過,這些小山會是白色的;但其實通常不是這樣,只要有一些人車經過,地上的雪就會變成像泥巴一樣的深褐色,於是小山也會變成泥雪山。如果地面上的雪有些許融化,地上就會充滿深褐色的雪水,踩起來感覺就像走在一個泥巴池塘上一樣。我只能說很噁心,噁心到你不會想穿任何會濕掉的鞋走在路上….。(波士頓其實算是乾淨的,如果你去過下雪後的紐約,就能體會到更奇妙的雪冰水加上垃圾水四態共存的噁爛世界。)

回到正題。自從第一次在紐約跟朋友一起去滑雪後,就愛上了滑雪。我前兩次都是玩ski,就是一般台灣人認知中的滑雪,兩隻腳分別裝上一塊長長的板子,手上還要拿兩根桿子。

ski

ski

Ski還蠻容易上手的,我早上上了一個半小時的課以後,下午要離開前就已經能開心的在初級坡道上滑來滑去享受乘風的感覺了。後來再玩了一次後,就想試試看另外一種滑雪的方法:snowboard。

snowboarding

snowboarding

Snowboard有點像衝浪一樣,只用一塊板子在雪上滑,但差別在雙腳是固定在板子上動不了的。snowboard比ski難上手許多,因為穿著ski其實是不太容易跌倒的,但snowboard需要一直在板子上保持平衡,有點像騎腳踏車一樣。一開始時有點速度後,很容易就會慌張然後一直往前仆倒或往後摔到屁股。除了要站著不倒外,snowboard還要靠著改變重心加上用力踩腳跟或腳尖來減速和改變方向。至於要踩哪一邊則是要看板子的方向和地形的起伏,如果不小心踩錯邊,馬上就是跌個狗吃屎…。整體說來,雖然snowboard難學得多,但一旦學起來後可是非常有成就感,而且snowboard的滑法可是千變萬化,不管什麼方向都能自由來去,玩起來也是帥氣許多XD

連續幾個週末都跑去玩snowboard後,現在終於比較能隨心所欲控制了,希望今年雪季結束前能征服各大滑雪場的藍線和黑線。(滑雪路線的難度是用顏色區分的,最簡單且平緩的是綠線,再來是中階的藍線,最後是超級陡峭的黑線;此外,某些滑雪場還有比黑線更可怕的雙黑線….。)

除了滑雪外,這個寒假也開始學鋼琴。其實已經想學琴很久了,只是小時候沒這機會。現在宿舍有兩座價值上百萬的鋼琴可以隨時去彈,而且身邊又有人可以教,實在是個難得的機會。雖然很少人這麼老才開始學的,但我整天打電腦手指應該也是很靈活的吧(?)(後來才發現這真是想太多XD ),所以此時不學更待何時呢?

開始固定練習後,就發現學琴還真是比想像中難很多,兩隻手的十隻手指要能分開控制但又要協調在同樣節奏上,難怪學習過程都是以年來計算的。而且雖然我很會打電腦鍵盤,但鋼琴鍵盤沈重許多,每隻手指都要有足夠且平均的力氣去按,不先把每根手指的肌肉都鍛鍊好是很難彈好的。

開學後能練習的時間就會比較少了,而且用宿舍的琴練還得跟別人搶,所以就狠下心買了電鋼琴放在房間不管半夜幾點都能練。希望PhD畢業時也能順便練得一手好琴藝 :P

Yamaha P-85S 電鋼琴

Yamaha P-85S 電鋼琴

這寒假過得實在挺愉快且充實的,真是不想開學啊啊啊~~~~

十二月 14, 2008
» 我活下來了

book pile

第一學期的「收穫」

在MIT的第一學期終於結束了!!從9月3號開學到這星期期末考和project都結束,也不過是三個月又一星期,中間還放了兩次長假加上兩次莫名其妙的星期一假期(據說是防止學生壓力過大自殺的假日,幾乎每個月都會有一天),但我有種已經過了一整年的感覺。學期結束後,我終於能從地獄爬出來了,說實在的,我現在只想對著天空大叫一整天!

很多人都說MIT是個會徹底毀滅一個人的地方,毀滅你的生活,毀滅你的自信,毀滅你的愛情。經過一學期的摧殘,我很高興我終於撐過去了。而且事後想想其實我也沒有過得多糟,至少我每天都還能睡滿七、八個小時,即使在期末週被兩科考試加project交叉攻擊下,我還是奇蹟般的把他們都一一擊破了。這真是讓我親身體驗到人類在危急時總是會爆發出無限潛能是怎麼回事XD 雖然學期順利結束,但也不知道能不能順利都拿到A。我們的資格考之一是要在指定的四門課都拿到A才行,所以要是沒拿到A我等於是白修了這門課,之後又得再痛苦一次(真是讓人想到就胃痛orz)。

其實來MIT後我才開始學著當個認真上課的好學生。以前台大的課我幾乎都不會想去,仔細想想我六年下來有全勤的課其實…只有兩門課吧。或許會這樣的原因其實是台大的教授教材都做得很好,所以只要寫作業或考試前把投影片看一看,再和同學討論一下,幾乎沒什麼難到自己看會看不懂的東西。但是,在這裡卻完全不是這麼一回事。我這學期修了兩門課,除了中間一個禮拜去加州參加conference外,每堂課都乖乖去上課還乖乖抄筆記(教授們都不太愛用投影片…||),但每次作業出來時看到題目都覺得沒有一題會寫的,搞得我們雖然每天都在寫作業,卻還是要連續寫上一個禮拜才寫得完。

除了修課之外,我們group每天都有個「下午茶時間」,其實也就是研究生都知道的meeting時間。只是我們的下午茶時間比較非正式一點,除了跟研究直接相關的進度報告外,其他就都是在閒聊,整個氣氛都很歡樂,跟傳統式輪流報告paper的meeting完全是兩種極端。我們會聊什麼呢,我們有個大家都可以編輯的google docs,上面寫了每天預計要討論的事項,還列了一大串有趣的話題,只要當天預計的事項都討論完就會拿出來聊。這些有趣的話題包羅萬象,但主要圍繞在人機介面、軟體工程、程式語言、WEB技術上,像是最近從網路上看到的新奇資訊或影片,或是剛發表的Python 3.0多了什麼新鮮的功能,我們也討論設計user interface的心理學,或是人與人之間互動的社交心理學;我們會一起做brainstorming討論各種可能的新點子,也會很nerdy的花半小時研究VGA接頭上的第9支針腳到底有什麼功能(呃,因為當天投影機怪怪的,於是我們就開始研究起它的VGA接頭規格,看能不能把它修好…..)。我們最近甚至還設立了一個blog,會把部份討論的主題分享出來,有興趣的人可以過去看看。

我的老闆也是一個很神奇的人,他是個會在meeting中討論討論就馬上開始coding來驗證的教授。他不但是我第一個看過還會自己寫程式的教授(後來我才知道其實很多MIT的教授都會自己動手,而台灣大部分的教授都進化(?)到只出一張嘴的等級了XD),而且他還是個會堅持漂亮的coding style的人。再加上他研究的興趣和我幾乎是100%相同,讓我不禁覺得能在這裡碰到這麼契合的老闆,應該是我到目前最幸運的一件事了吧 :D

biggo.com.tw

A Django site.