難以說出口的原因是，這句話在很多時候會被解讀成帶有貶低別人的味道，所以……

大約一個月前，緊跟著 Opera 9.5、Firefox 3、IE 8 之後而來的 Google Chrome，似乎驗應了瀏覽器大戰又將火熱展開。Google Chrome 測試版推出的那一天，網路上大大小小的媒體無不爭相報導；本專欄從來不盲目追逐流行，所以讓我們在一個月之後的現在，再來冷靜地檢視這枚由穀歌拋出的震撼彈，看看在鮮明簡潔的表面之後，究竟有些甚麼。

Google Chrome 目前僅釋出一個測試版本，版次為 0.2.149.27 Beta，標榜的功能不外乎介面簡潔、反應敏捷等；許多相關報導都集中在多執行緒的記憶體用量，以及 V8 這個 JavaScript 引擎的執行效率上，認為這兩者搭配起來，讓 Google Chrome 更快、更穩健。實際使用了整整一個月之後，筆者發現這兩點似乎都不是那麼一回事。

首先要說明一下測試的環境。筆者使用的環境是四年多前購入的筆記型電腦，CPU 為 Intel Pentium M 1.1GHz，配有 768MB 的記憶體，採用 Toshiba 2.5 吋、轉速 5400rpm、容量 100G 的硬碟，作業系統則為繁體中文版的 WindowsXP Pro SP3。這樣的硬體配備以今天的標準來看，恐怕是寒酸得很，但是這麼多年來，這台筆記型電腦一直勤奮地工作著，沒有出過任何問題，而且筆者平日慣用的瀏覽器 Opera 也表現得相當敏捷，實在沒有不能拿來測試 Google Chrome 的道理。

Google Chrome 本身是多語介面的，意味著在中文版的 Windows 上安裝時，就會從一開始以中文介面呈現；但是穀歌向來祇注重全球市場，比較不花精力在各地區市場，於是在剛開始安裝的時候，就讓人皺起了眉頭──相信許多人都看到了，那個「歡迎使用 Google 瀏覽器」的安裝視窗標題，把「歡」誤植為「觀」了。但這不是 Google Chrome 當中唯一出現的中文錯字；在 Google Chrome 下載管理畫面的右鍵選單當中，也把「複製檔案」誤植為「複雜檔案」，真是讓人越看越複雜，對軟體使用比較沒經驗的使用者，恐怕是丈二金剛摸不著頭緒，弄不懂這個選項到底是做甚麼用的。

不祇是程式介面有這種本地化時的錯誤，就連相關的說明文件也不例外。在 http://www.google.com/chrome/intl/zh-TW/webmasters-faq.html#useragent 這一頁，指出 Google Chrome 的使用者代理程式字串為：

Mozilla/5.0 (Windows；U；Windows NT 5.1；en-US) AppleWebKit/525.13 (KHTML，如 Gecko) Chrome/0.X.Y.Z Safari/525.13。

如果真的有網頁管理者按照上述內容來判定 Google Chrome 的話，一定會音訊全無，因為目前為止，沒有任何程式送出來的使用者代理程式字串，會含有全型標點符號跟中文字；上述這段字串在英文版的文件當中其實是這樣的：

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13.

這段字串應該要保留隻字未動纔對，因為即便是中文介面的 Google Chrome，也會送出相同的使用者代理程式字串。這一點，負責製作中文版文件的人顯然疏忽了。一個錯字可以是意外，兩個錯字很難說是巧合；連文件都跟著有問題，則已經是商業軟體中相當嚴重的情況了。

接著再來看看 Google Chrome 的多緒分頁。按照穀歌的說法，Google Chrome 的每一個瀏覽器分頁，都會有一支獨立的執行緒，因此若有哪個分頁的記憶體洩漏了，哪麼祇需要把該分頁關閉即可，不會波及其他分頁；西元一九一二年，當時號稱全世界最大最安全的郵輪鐵達尼號，也用了相同的概念來設計水密艙，但是首航就發生的罹難事件，證實了當時被認為最安全的船也還是會沈沒。同樣地，許多瀏覽網頁時可能發生的意外，也會讓整個 Google Chrome 瞬間沈沒，而不是祇有一個分頁而已。例如 http://evilfingers.com/advisory/google_chrome_poc.php 指出，當 Google Chrome 遇到協定未註冊、內容含有特定字符的鏈結，像是「evil:%」時，就會馬上整個死掉，沒有任何分頁能存活下來。

Google Chrome 的多緒分頁設計還有一個附帶效應，就是會佔用更多的記憶體。儘管穀歌宣稱隨著分頁越開越多，最後佔用的總記憶體應該會比其他瀏覽器少，甚至在 Google Chrome 的 about:memory 頁面中，還會列入其他所有開著的瀏覽器的記憶體使用狀況統計，但實際上不管是開了五個分頁還是一百五十個分頁，Google Chrome 會佔用的記憶體還是最多的，比 Opera、IE、Firefox 都還要多。

如果你自己做了這樣的實驗，那麼應該還會發現，當 Google Chrome 開了一堆分頁、佔用一堆記憶體之後，他會漸漸地把記憶體擠回來。仔細觀察之後，會發現 Google Chrome 一有機會就會把記憶體內的東西置換到硬碟上（虛擬記憶體），等到要用的時候再讀回記憶體，藉此試圖降低記憶體用量。然而就算如此，Google 佔用的實體記憶體，還是比我的 Opera 還多。而且這種拼命置換的做法，結果就是會產生大量的硬碟讀寫動作；如果你跟我一樣，用的不是下個月纔要發表的全新電腦硬體，很容易就會被這種頻繁的硬碟讀寫給拖累，而讓整個作業系統動彈不得。

如果這時候你讓 Google Chrome 去處理複雜的網頁，情況就可能更糟糕。採用 V8 引擎的 Google Chrome 雖然執行 JavaScript 起來更快，但是也比其他瀏覽器耗用更多的 CPU 資源，而且支援程度並不理想，就連穀歌自己的網頁服務，遇到 Google Chrome 都有可能出錯。有人發現 Google Groups 裡面的「新增頁面」功能失常，筆者則是遇過 GMail 當中有一封信無論如何就是不會變成「已閱讀」的狀態。PicasaWeb 也同樣地不支援 Google Chrome（下載相簿的功能無法使用）。如果連穀歌自己的產品都支援不良了，第三方網站或程式又怎能期待有多好的支援呢？

目前為止，看來 Google Chrome 陷入了非常弔詭的局面：如果你的硬體配備夠快、夠好，那麼 Google Chrome 就能讓你體驗無比的速度；如果你的硬體配備比較慢、比較差，就會比別的瀏覽器更慢更遲滯，可以說是遇快則快、遇慢則慢。弔詭之處就在於，對於受瀏覽器緩慢所苦的使用者來說，Google Chrome 的「速度」祇會幫倒忙。

那麼，這個為明天（CPU 更快、記憶體更多、硬碟讀寫更有效率）的電腦所設計的瀏覽器，真的就能在明天派上用場嗎？

真的拿 Google Chrome 來用上一陣子，會發現在他簡潔的介面背後，用起來麻煩得很。首先 Google Chrome 並沒有任何「選單」，除了網址列跟幾個工具按鈕外，祇有「網頁功能」跟「工具」這兩個功能表，讓使用者藉此取用各項設定跟進階功能；然而這兩個功能表都沒有對應的按鍵，非得用滑鼠（或其他指標式輸入介面）操作不可。換句話說，你無法僅用鍵盤，開啟 Google Chrome 的「說明」或「選項」等。

瀏覽網頁內容時，一般的瀏覽器會在滑鼠點按任何網頁內容控制組件（例如按鈕、核選框、文字區域等）後，將該組件設為現用中的焦點組件，之後若使用者按下 Tab 鍵，則會根據文件流向，從現用中的組件繼續往後導覽；但是在 Google Chrome 中，按下 Tab 鍵卻會將焦點移回網頁文件開頭，重頭開始。我們常常在輸入完某些表單之後，直接按 Tab 鍵移往緊鄰的「送出」按鈕，但這種便利在 Google Chrome 當中則蕩然無存。

Google Chrome 這種逼你一定要用滑鼠的做法，違背了多項全球資訊網協會所訂定的「使用者代理親和力方針」。事實上，若我們進一步檢視，就會發現在 Google Chrome 使用介面中的各個控制元件，例如按鈕、輸入框等，以及網頁內容中的鏈結等，都缺乏正確的名稱、角色、狀態資訊，意味著各種輔助科技如螢幕朗讀軟體（像是 NVDA Screen reader、JAWS、Window-Eyes）等，都無法與 Google Chrome 搭配使用。

如果你試圖用 Windows 內建的親和力功能「協助工具選項」，把畫面顯示設定為「高對比」，會發現這個對比設定幾乎對 Google Chrome 無效──唯一看得出有大幅影響的地方是 Google Chrome 的「選項」畫面，而且是會讓此畫面的文字難以閱讀，而非協助使用者加以使用。

從網頁親和力的觀點來看，Google Chrome 簡直是一場災難。就算撇開親和力的眼光，從可用性的角度來分析 Google Chrome，也會發現些不對勁的地方，像是檔案下載的功能。

Google Chrome 的設計是，每個分頁在下載檔案時，就會在該分頁最底下出現一個「下載內容列」，列出下載有關的資訊。舉例來說，當我在下載一個 562 MB 大的 foo.avi 影片檔時，可能就會看到這些資訊：

foo.avi 3.8/562 MB，剩餘時間...

沒錯，我可能最關心的「還有多久可以抓完」的資訊，就這麼攔腰截斷；按照目前的 Google Chrome 來看，不論你下載多大的哪種檔案，在下載內容列都無法顯示出剩餘時間的資訊──既然如此，為什麼還要煞有其事地寫個「，剩餘時間...」呢？有個合理的猜測是這個資訊在英文版的 Google Chrome 當中是看得到的，中文版則是意外；若真如此，那麼 Google Chrome 可以說再度驗證了 Google 不重視非英文世界的一貫態度。

為了要知道到底檔案還要下載多久，我們得按下一旁的「顯示所有下載...」，開啟「下載」頁面。在這個頁面當中，終於我們可以看到更多資訊了；但是同樣讓人不解的是，不論你的螢幕有多寬、Google Chrome 瀏覽器檢視區域開了多大，檔案資訊硬是要擠在 500 像素不到的寬度內，而往往無法一口氣顯示出全部的內容，唯有將滑鼠游標移動到檔案資訊上，纔能由滑鼠提示畫面看到全部的內容。再一次地，Google Chrome 不讓我們輕易看到所有的資訊，順便歧視了不方便使用滑鼠（例如手上剛好拿著珍珠奶茶）的使用者。

筆者在下載檔案時，還發現了一件神秘的事：下載較大的檔案時，當剩餘下載時間低於一分鐘，檔案資訊中就會出現「正在安裝新版本...」的訊息。不論下載的是執行檔、壓縮檔、影片檔、聲音檔或任何檔案都一樣──到底 Google Chrome 是在安裝些甚麼呢？（當然我們也可以合理地猜測，又一次地，這是本地化時造成的中文版慘劇）尤其要知道，Google Chrome 的使用條款當中，有著這麼一條：

12.1 您使用的「軟體」將不時自動從 Google 下載並安裝更新。這些更新之設計旨在改善、強化和進一步發展「服務」，採取的形式則可能包括錯誤修正、增強功能、新軟體模組和全新版本。您同意接受此類更新 (並同意 Google 對您傳遞此類更新) 做為使用「服務」的一部分。

不論下載任何檔案是否會造成 Google Chrome 安裝我所不知道的更新，出現了這樣的訊息就足以讓人困惑；而按照使用條款，真的安裝起來我也無法拒絕，這更是讓人惶恐。

到底為什麼 Google Chrome 會變成這樣的瀏覽器呢？有人想到了，「Google Chrome 是開放源碼軟體嘛，我們可以來研究一下他的源碼」。

事實上這種說法不大精確，因為 Google Chrome 受到使用條款保護，並不符合自由軟體基金會對自由軟體的定義，也不符合開放源碼組織對開放源碼軟體的定義。穀歌祇是「將 Google Chrome 所用到的源碼整理後，採 BSD 授權釋出給公眾」而已，用那份源碼編譯出來的瀏覽器（他有個自己的名字，叫「Chromium」）是個開放源碼瀏覽器，但 Google Chrome 不是。沒有任何人能夠擔保 Chromium 的源碼真的跟 Google Chrome 用的一樣，任何對 Chromium 源碼的修改補綴貢獻，也不見得一定會回到 Chrome 的源碼中。在這個「開放源碼」的口號背後，仍然埋伏著這些不定。

整體來說，我們在 Google Chrome 上可以看到穀歌的行銷用心，包括採創用 CC 授權釋出的說明漫畫、提供（經整理過的）源碼等，但是 Google Chrome 本身的品質還很粗劣，談不上是β外部測試版了，祇能勉強算是α內部測試版的水準。

所幸有了 Chromium 這個開放源碼專案，無論 Google Chrome 未來變得多邪惡，我們都還能選擇 Chromium。不過，身為使用者，我們還是殷切地期盼穀歌如他們所說的，歹行莫做，早日弭平 Google Chrome 帶來的災難纔是王道啊。

出版是許多人無法抵抗的誘惑。再怎麼平凡的人，心中總有一股小小的憧憬，想著自己不再那麼平凡，盼著或多或少能夠影響這個世界，不然能影響部門同事、子女親人、豢養的寵物也好；因為這樣，所以人總有表現欲，或書寫、或繪畫、或歌唱、或舞蹈。我們要表達，要在名為歷史的巨著上留下足跡，哪怕祇有一句一字，都好過不帶走一片雲彩。

於是我們部落格。部落客先是一腳踏進雜誌與新聞的疆域，接著又用名為 Podcast 的利刃，突破電台跟電視台的界線；傳統媒體的巨人們或許受到了撼動，卻沒有因此倒下。儘管這個世界變得越來越抽象，虛擬與現實的交界越來越後現代，但是最後會留下來的東西卻很明白：那些有重量、佔據空間、能夠摸得到、可以親手把玩的，更重要的是，停電的時候仍然能取用的。

網路上那麼多印衣服、印馬克杯、做貼紙、做印章、做 DVD 的商家，那麼，何不把部落格印成書？白紙黑字、裝訂成冊的東西，拿起來、看起來都有份量，也跟從小烙印的權威印象一致：能夠加上書名號的，定有些過人之處。因應著這般需求，有些網站開始做起了隨選出版的服務，lulu.com 便是箇中翹楚，不過做的還是一般的隨選出版，而不是專做部落格的生意；後來有專門把部落格內容做成書的 BlogBinders，可惜當時的市場畢竟養不起這麼專一的生意，結果撐不了幾年。

有了 BlogBinders 的前車之鑑，後起之秀如 Blurb Blog Books 倒是學乖了，除了跟 lulu.com 一樣做的是各種各樣的隨選出版外，同時也讓你把部落格上發表過的內容，直接做成一本書，配上插圖、設計封面，甚至讓別人來選購；但是對於我們來說，印不出中文字實在是個不可承受的缺點。差不多也是 Blurb Blog Books 出現的那一年，國內的無名小站用外包的方式，也推出了出版網誌的功能。終於，雖然還是差強人意，我們至少有了一個選項。

用這種方法做出來的書──以及影音出版品，有個共通的缺憾：沒有編輯。雖然在作者跟讀者間，編輯應該要是不存在的；但若少了編輯，讀者將看不見作者，作者也聽不到讀者，喃喃囈語，不成對話。撰寫任何內容就像加法一樣，精心堆砌作者的精神，而編輯做的則是減法、乘法與除法，切割出鑽石的耀眼，琢磨出璞玉的光輝，讓作者在接觸到讀者前先瞭解讀者，讓讀者翻閱書本時更能瞭解作者，把持著取捨權重，堅持著成品美感。

當然徹底不成對話的部落格並不多，一來部落格多少向著某群人書寫，二來部落客也會做點編輯。但編輯這事真要這麼簡單，出版社也甭混了；加法不易，減法更難，遑論乘除。一篇文章之內，光要潤個字句就得耗上大半功夫，編排文章又是另個大學問──一本書，究竟要說些什麼？憑的是怎樣的邏輯？吐的是如何的口氣？有些內容不改寫不行，有些內容不合併不行，有些內容不割捨不行，這些對作者──部落客──自己來說，執行起來遠比想像中困難；除非一開始就打定主意要做日記體、新詩體，不然內文體例又是個麻煩。還有呢，字型、字體、行距、段落、左右天地、配色、用紙，真要計較起來，當真是沒完沒了。

剩下作者隻身的一本書，乍看之下是個悲劇，意外地盛行起來，因為這些編輯的瑣碎對於許多部落客來說，倒變得無所謂了。這麼說吧，人家祇是拍個大頭貼而已，本來就不是要畫出蒙娜麗莎的微笑。把數位的剎那化為紙本的永恆，這些大頭貼實在很稱職，刻意的做作再明顯、畫面解析度再差、內涵再膚淺，貼的人還是很自滿，看的人也還是很開心，彷彿分享了瞬間的感受，參與了生活中的片刻。部落格在這當中，說是如魚得水，一點兒也不過分。

微出版的產業是「高興就好」，能沈澱出什麼文化還說不準，但是增加小額、大量的金流卻是事實；大錢難賺，不管是出版商還是印刷業還是文化相關產業，紛紛想辦法來賺這些大量小錢，正是長尾效應的經典樣態，也難怪部落格會站到舞台中央。

微出版擴大了「出版」的可能，自身實證原來出版也可以為了這樣的目的、這樣子來做；傳統出版界莫害怕，兩者之間的市場區隔相當明顯，該視為整體市場擴出了新領域，而非瓜分既有領域。走上微出版路子的朋友也千萬不要妄自菲薄，真的要有什麼影響力，要能流傳久遠，傳統出版的作法還是有其道理的；偶爾有些部落客寫了書，走的是傳統的路子，部落格內容頂多當做素材，離最後的成品還很遙遠，該有的編輯功夫更是沒省，那是用上部落格流量的傳統出版，可不是微出版。

微出版可以向傳統出版學習紮實的功底，同時也得走出自己的路。「自己到底要如何實現自己」，不但是每個部落客所捫心自問的問題，也是微出版不變的真理。更靈活地匯集不同的資源，更有彈性地讓部落客從中發揮各自的美感與技巧，也正是微出版的迷人之處吧。

前一期我們針對冒險遊戲這種經典的類型，介紹了開放源碼界的一些故事，還有一些模擬器跟製作遊戲的套件；然而遊戲千百種，光是冒險遊戲是沒辦法滿足每一個玩家的胃口的。本期就讓我們來看看開放源碼界的其他遊戲類型，以及你可能錯過、卻不容錯過的精彩遊戲。

多年以來，遊戲一直是個重要的產業，因此許多跟開放源碼軟體有關的專案，也都會把遊戲納入其中。舉例來說，有個叫 OSSwin 的開放源碼軟體專案，目的是要整理各類能在 Windows 上面執行、使用的開放源碼軟體／自由軟體；這個專案在 2005 年起，也整理了一份遊戲清單，羅列了十九類、共計近 150 套開放源碼遊戲。

另外在維基百科上，也有一份開放源碼遊戲清單，按照字母順序，列出了近百套遊戲；還有一個叫 Free Gamer 的部落格，也洋洋灑灑地列出了超過 120 套開放源碼遊戲跟免費遊戲。

讓我們來端詳一下。在這些列出的遊戲當中，有一個大宗是來自 iD Software 當年釋出的毀滅戰士 DOOM（以及其後續／相關遊戲）原碼所做成的第一人稱射擊，後來如 Unreal 及 Quake 系列引擎也是這類開放源碼遊戲所常用的；另外還有一些知名遊戲的復刻板，例如 Freeciv 是文明帝國（Civilization）二代的開放源碼重製版，FreeCol 則是文明帝國四代──殖民霸業（Colonization）的開放源碼重製版，都是策略遊戲迷非完不可的經典之作。今年有個很紅的開放源碼橫向捲軸動作遊戲，叫 Secret Maryo Chronicles，許多關卡也可以看出是在跟超級馬力歐兄弟（Super Mario）致敬；UFO: Alien Invasion 則是根據著名的 X-COM 系列所做的開放源碼戰略遊戲。

有一個開放源碼的益智遊戲叫 Pathological，重製 1991 年的 Logical（由 Rainbow Arts 製作發行），但是內容大大加強，畫面乾淨、音樂精緻，看似簡單的規則（讓四個同顏色的球聚在一起，即可消除）卻能讓人繃緊神經；這個遊戲不知道為什麼，在前述的遊戲清單中全部缺席，但真正是個讓人想一玩再玩的好遊戲，請一定要拿來玩看看。

相信各位讀者已經發現了，這些當紅的遊戲，怎麼好像都是重製商業遊戲、或向商業遊戲「致敬」而來的？另一個開放源碼遊戲類型的大宗，是橋牌、博奕、棋類，加上剛剛說過的這些當紅遊戲，難怪有人會說，開放源碼界缺乏原創遊戲了。

不過事實上並非如此。這邊並不是要提出「商業遊戲也充斥著抄襲瞟竊」的論點，而是開放源碼遊戲確實有些令人激賞的作品。

最能體現開放源碼精神的經典遊戲，大概要屬 NetHack 莫屬了。

早在 3D 加速卡之前、早在彩色螢幕跟音效卡之前、早在 IBM PC 之前，有個叫 Rogue 的單機角色扮演遊戲，人們發現這個遊戲很好玩，又是開放源碼的遊戲，於是有了 Hack 。網路出現後，更多的人投注心力在這上面，一起貢獻與維護，因此而有了 NetHack 。所以這不但是歷史最悠久的遊戲，更是開發團隊（累加起來）最龐大的遊戲。

這套單機版的回合制角色扮演遊戲，內容收納了各種技客（Geek）界的流行文化──奇幻文學、科幻文學等，包括托爾金的《魔戒》、道格拉斯‧亞當的《銀河順風車指南》等；多達幾十萬字的訊息及對話，甚至鼓勵玩家偷看源碼來進行遊戲；於是遊戲源碼當中的註解，也成了遊戲內容的一部分！

如果你嫌 NetHack 內容來自其他作品拼貼而成，不夠具有原創性──那麼請接著看看 Liquid War。

Liquid War 不論是就遊戲內容或遊戲類型來說，都具有相當高的原創性；這個遊戲很像是即時戰略版的圍棋，每一方一種顏色，每個「點」都代表一名士兵，玩家控制游標移動，而每個「士兵」則會根據前往游標的最短路徑移動，當前方遭遇己方（相同）顏色的「士兵」時就會醫護（補血），遭遇敵對（其他）顏色的「士兵」時則會攻擊，當任何「士兵」的生命值歸零，就會被敵方俘虜，成為敵方的「士兵」；這遊戲最多支援到六人對戰（可以擠在一台電腦上，也可以透過網路連線對戰，也可以讓電腦操控某些「國」），存活到最後、兵力最強大的為贏家。

多樣的遊戲地圖，加上可以調整的遊戲參數（攻擊率、醫護率、防禦率等），讓 Liquid War 每一次玩起來都全然不同，需要用不同的策略來應對。根據設定的不同，每場遊戲短則 30 秒以內分出勝負，長則可以廝殺上一小時，不論是想要認真玩遊戲，或者祇是想打發空檔，都很適合。

Liquid War 因其獨創性，在 2002 年就獲得了 Linux Game Tome 的「最獨創的 Linux 遊戲」，至今就算是在商業遊戲當中，仍然沒有相近的類似競爭者出現。誰說開放源碼就沒有好的創新遊戲呢？

當然開放源碼遊戲還是有其發展限制──嶄新炫麗的影音特效、豐富長篇的故事劇情，都很難在開放源碼遊戲中出現。因為這些遊戲內涵通常對玩家來說並不會成為經年累月、每日服用的體驗，自然也就難以回饋到開放源碼社群；而且要開放源碼開發者像大公司那樣，投入幾年的精力全神在調整這些細節而不被打擾，也不是那麼容易。

因此，我們可以從本期所介紹的遊戲當中發現，這些優秀的開放源碼遊戲，都是那種人們會再三把玩、卻不大需要劇情的遊戲。即便是在創用 CC 授權已經流行起來的今天，各種媒體素材（物件模型、圖案、音樂、故事劇本等）畢竟還是沒辦法像拼積木般，輕易組成遊戲內容，使得這樣的現實並沒有甚麼改變。

不過反過來說，好的開放源碼遊戲，確實往往可以活得比商業遊戲還要長久，而且會被移植到多種不同平台，翻譯成許多不同語言，並且遊戲內容也有可能自由地衍生出更多創作（例如從 NetHack 發展而來的 Falcon's Eye），這些都是開放源碼的優勢所在。前一期所介紹的 ScummVM 恰好結合了商業遊戲的內容（當然你還是要先合法取得那些內容）與開放源碼的自由彈性，纔成就了這少見的特例（雖然嚴格來說，ScummVM 並不能算是「一個遊戲」）。

開放源碼遊戲與商業遊戲在許多方面都各有特色，無論哪一方都無法取代另一方，在可以預見的未來內也都不會消失，畢竟「玩」也是人類的天性之一。如果你喜愛玩遊戲，也熱愛開放源碼軟體，那麼不妨多多參與開放源碼遊戲的開發，看是要改善遊戲引擎，或者貢獻故事、劇本、圖片影音等，就算祇是多玩個幾遍並回饋意見、多介紹給其他玩家，都是在幫助這些專案繼續走下去；最重要的是，你也往往能從中找到更多樂趣。

那麼，就讓我們下一場遊戲見吧！

不管從軟體還是從硬體的角度來看，遊戲都無疑是促進資訊產業進步的最大助力之一。每年都有不計其數的使用者，為了要玩遊戲，購買更快的 CPU、更多的記憶體、更強悍的顯示卡、更大的網路頻寬；幾十年來，電腦的作業環境也不斷朝著更容易玩遊戲的方向發展，許多與多媒體相關的應用程式介面與函式，甚至可以說是為了遊戲而出現的。

讓我們把時光倒回二十年前，那是個還不很便利的年代，光是要把一套遊戲安裝進電腦執行，就有可能遇到非常多的阻撓──檔案管理、驅動程式（滑鼠、搖桿、音效卡、後來出現的光碟機）、記憶體空間與常駐程式（像是遊戲修改程式）、中斷呼叫等，每一樣都教人挫折到俯跪不起。

但正是在這樣的環境之中，造就了許多對資訊有興趣的人──大家其實不過是要玩個遊戲，卻因此開始摸索起批次檔、組合語言、反組譯……（也有很多人為了玩遊戲，而學了不少英文、日文，不過這並不是我們這次要討論的）。這些人長大之後，遇到了新的阻撓：小時候買不起玩遊戲所需的軟、硬體，長大之後使用的軟硬體遠遠超出這些遊戲的年代，太新太快，反而無法執行這些遊戲，這可怎麼辦呢？

開放源碼軟體／自由軟體社群的其中一項重要價值，在於重視少數人的需求；並且讓散居世界各個角落的「少數人」能更容易地團結在一起，照顧彼此的需求。筆者不是唯一遇到前述玩遊戲阻撓的人，有更多的人為了要玩遊戲，什麼事都做得出來──於是出現了一個叫 DOSBox 的開放源碼軟體專案，功能是讓你在各種不同的作業系統（例如 Windows、FreeBSD、Fedora、Gentoo、Mac OSX、OS/2、BeOS、Risc OS 等）上，模擬出一個純正的 DOS 作業環境，然後讓你能在裡面玩 DOS 時期的種種遊戲。

這個 DOS 模擬器一口氣把光碟機、音效卡、顯示卡、記憶體配置等麻煩事都解決掉了，只要改改參數或設定檔，就可以直接獲得你想要的主記憶體／XMS／EMS 數量──這簡直是當年的美夢！顯示卡跟音效卡可以直接模擬、對應到宿主系統上的，不再有支援不良或亂當機的苦惱；除了可以使用真正的光碟機外，也可以把光碟映像檔或某個硬碟上的目錄掛載成光碟機，這不但省掉了光碟驅動程式，而且當你在玩銀河飛將（Wing Commander）、殺人月（Under a Killing Moon）等以光碟片數量著稱的遊戲時，也就不用再拼命換片了。如果你玩網路遊戲的話，DOSBox 可以在 UDP 上模擬 IPX，在 TCP/IP 上模擬數據機通訊，意味著要跟別人連線對戰初代魔獸爭霸（Warcraft）或毀滅戰士（Doom）也沒問題。

如果你對於 DOSBox 組態檔不熟，或者祇想要更快地開始玩遊戲，那麼在各個平台上也有一堆專門寫給 DOSBox 的前端程式，協助管理遊戲與組態檔。有了這些前端程式，不但那些懷念純文字介面的人能重溫舊夢，想朝拜老遊戲的新朋友們也能更快入門。

DOSBox 有時候比真正的 DOS 機器還容易使用，甚至可以透過 DOSBox 來執行早期版本的 Windows；最近有個新聞，說有人在 Nokia N800/N810 上面執行 Windows 3.1 與 Windows95，這正是透過 DOSBox 辦到的。從 2002 年釋出的 0.5 版起，到最近的 0.72 版，DOSBox 六年來已經累積千萬次下載；這或許不是個大數目，但也不容小覷。

DOSBox 提供了一條出路。但開放源碼軟體／自由軟體的樂趣在於：辦法不祇一種。所以這個故事到這裡還沒說完。

在所有的遊戲類型當中，我最喜愛的還是冒險遊戲──這裡指的是那種以故事和劇情為主幹、幾乎不需要任何敏捷的手指技巧、到了二十一世紀已經所剩無幾的遊戲類型；也就是猴島小英雄（Monkey Island）系列、紗之器（Loom）、國王密使（King's Quest）系列、宇宙傳奇（Space Quest）系列、警察故事（Police Quest）系列、幻想空間（Leisure Suit Larry）系列、瘋狂大樓（Maniac Mansion）系列、印第安那瓊斯（Indiana Jones）系列、狩魔獵人（Gabriel Knight）系列、凱蘭迪亞傳奇（The Legend of Kyrandia）系列這類，至於鬼屋魔影（Alone in the Dark）系列、古墓奇兵（Tomb Raider）系列這種，則不算在內。

這些純冒險遊戲到了二十一世紀後，逐漸被新型態的互動故事（例如帶有解謎成分的動作遊戲、第一人稱射擊遊戲、角色扮演遊戲，這是 1999 年 Sierra 老闆娘 Jane Jensen 寫給 Sierra 的公開情書中的說法）取代，但就算以今日的眼光來看，這些遊戲仍舊充滿著豐富內涵，值得再三回味。

這些純冒險遊戲通常都會有個劇本系統，例如 LucasArts 的 SCUMM 引擎、Adventuresoft/Horrorsoft 的 AGOS 引擎、Coktel Vision 的 GOB 引擎、Sierra 的 AGI 引擎與 SCI 引擎、Humongous Entertainment 的 SPUTM 引擎等等，所以除了用 DOSBox 來執行這些遊戲外，另外也可以剖析他們的「劇本」，從資料檔取出各種媒體材料（圖片、動畫、音效、音樂等），重新拼湊出完整的遊戲。首先我們要介紹其中最有名的開放源碼軟體專案──ScummVM。

SCUMM 是 1987 年 Aric Wilmunder 和 Ron Gilbert 為了 LucasArts（當時是 Lucasfilm 的遊戲部門）的冒險遊戲瘋狂大樓（Maniac Mansion）所製作的，全名叫「Script Creation Utility for Maniac Mansion」，亦即「為了瘋狂大樓而做的劇本創造工具」；後來 LucasArts 以此引擎為基礎，陸續推出了多款冒險遊戲，包括異形大進擊（Zak McKracken and the Alien Mindbenders）、瘋狂大樓２：瘋狂時代（Day of the Tentacle）、紗之器（Loom）、印第安那瓊斯：聖戰奇兵（Indiana Jones and the Last Crusade）、印第安那瓊斯：亞特蘭提斯之謎（Indiana Jones and the Fate of Atlantis）、猴島小英雄：猴島的祕密（The Secret of Monkey Island）、猴島小英雄２：理察克的復仇（Monkey Island 2：LeChuck's Revenge）、猴島小英雄３：猴島的詛咒（The Curse of Monkey Island）、妙探闖通關──大腳之謎（Sam & Max Hit the Road）、異星搜奇（The Dig）、極速天龍（Full Throttle）。

ScummVM 在 2001 年發起之初，就是以 SCUMM 引擎為目標，要在各種不同的平台上，重溫 LucasArts 的經典冒險遊戲。這個專案相當地活躍，現在已經有超過 60 位開發者參與，SVN 檔案庫裡的修訂版次超過三萬，支援的作業環境包括 Windows、Fedora、Debian、SlackWare、Mac OSX、PlayStation2、PSP、Nintendo DS、Symbian S60、Symbian UIQ、PalmOS、Windows CE、Opie、Maemo、Dreamcast、GP2X、Solaris、BeOS、AmigaOS、Atari、OS/2、MorphOS、Mandriva、PocketPC、HanheldPC 等，甚至支援最新的 Wii（非官方移植）與 iPhone；各種 SCUMM 引擎的遊戲都有 90% 以上的支援度，另外也支援許多其他非 SCUMM 引擎的遊戲，包括前述 Adventuresoft/Horrorsoft 的 AGOS 引擎、Coktel Vision 的 GOB 引擎、Sierra 的 AGI 引擎、Humongous Entertainment 的 SPUTM 引擎等，共計 100 個遊戲，其中有 88 個遊戲的支援度在 80% 以上。

SourceForge 自從 2006 年起舉辦社群票選獎以來，ScummVM 年年入圍最佳遊戲玩家專案，並獲選為 2007 年年度最佳遊戲玩家專案（同年亦入選年度最佳專案）──然而你所不知道的是，ScummVM 有不少部分是靠著苦命的逆向工程實現，以及各種針對特定遊戲、特定平台而做的補綴。目前 ScummVM 除了主計畫外，還分支出兩個子計畫：ScummEx 與 Residual。

ScummEx 是 SCUMM 的資源檔瀏覽器、檢視器與擷取器；Residual 則是 GrimE 引擎的模擬器──LucasArts 最後一個用 SCUMM 引擎製作的冒險遊戲是猴島小英雄３：猴島的詛咒（The Curse of Monkey Island），下一個冒險遊戲神通鬼大（Grim Fandango）換了用 Lua 全新撰寫的 GrimE 引擎，這個引擎後來也拿來製作 LucasArts 最後一個冒險遊戲，猴島小英雄４：逃出猴島（Escape from Monkey Island）；與 SCUMM 引擎最大的不同之處，在於 GrimE 引擎採用的是 3D 繪圖，這讓 ScummVM 難以處理，所以纔有了這麼一個子計畫。（有的讀者看到 Residual 這個名字，異想天開地問道：它未來會支援惡靈古堡 Resident Evil 嗎？不，它不會，永遠也不會。）

ScummEx 大約在 2006 年的時候進入停頓期，而 Residual 則還有在緩慢地發展──玩遊戲纔是真正的動力來源嘛。

ScummVM 並不是開放源碼界唯一一個這麼做的專案。有個叫 FreeSCI 的專案也是針對特定的冒險遊戲引擎（Sierra 的 SCI，這個引擎並不在 ScummVM 的模擬之列）而發起的。SCI 全名是 SCript Interpreter 或 Sierra Creative Interpreter，用這套引擎製作的遊戲包括幻想空間（Leisure Suit Larry）二代到七代、宇宙傳奇（Space Quest）三代到六代、國王密使（King's Quest）四代到六代、英雄傳奇（Quest for Glory）一代到四代等。

FreeSCI 的成熟度與開發速度都比 ScummVM 還要低很多，目前穩定支援的平台也較少，但也是一條路，而且也很歡迎任何有能力、有興趣的人參與。就算是少數中的少數，開放源碼也帶來了一線希望。

由於 ScummVM 已經支援 Sierra 的 AGI 引擎，而成熟度及開發活躍度又比 FreeSCI 領先不少，也有不少人建議將這兩個專案合併，藉此提昇 SCI 引擎的支援。然而，任何真正接觸過開放源碼軟體專案的人都知道，合併專案──尤其是合併原本就小眾的專案──並不容易，最壞的情況下就是要把其中一邊的程式碼重新清理乾淨，移植到另一邊，而且會需要對兩邊程式碼都熟悉的人來做這件事。如果有熟悉 SCI 引擎的人能夠把 FreeSCI 的程式碼移植進 ScummVM，為什麼不讓他先專心補綴／改善 FreeSCI 呢？

另一方面，前面也有提過，ScummVM 針對不同遊戲、不同作業平台，做了很多特定的補綴，而不是真的一套辦法從頭適用到尾，因此把 FreeSCI 合併到 ScummVM 的話，這些苦工並不會瞬間生效，處理 SCI 引擎的人還是得再面對相容性等議題。這兩個專案不大可能會合併，但是若有任何一方有哪段程式碼值得學習（例如模擬器本身的介面等），另一方總是能自由地學習、採用──因為已經是開放源碼了呀。

隨著 ScummVM 闖出知名度，也有不少人打起了 SCUMM 的主意：既然所有用 SCUMM 引擎製作的遊戲，都幾乎能完美地用 ScummVM 來執行，那麼我們是否可以拿 SCUMM 來寫自己的遊戲，搭配 ScummVM 來玩呢？

理論上這是可行的，但是 ScummVM 為了支援舊遊戲所做的補綴，可能會讓自製的 SCUMM 遊戲發生問題；再說，目前根本沒有任何工具或套件，能夠拿來製作 SCUMM 所需的各種資源檔。換句話說，ScummVM 是為了玩遊戲而發起的專案，並不建議拿來「製作」遊戲。

如果你就是想要自己做一套遊戲呢？同樣地，開放源碼軟體／自由軟體是你的好朋友──有許多跟遊戲製作有關的開放源碼軟體／自由軟體專案，像是 SDL 跟 Lua，都很適合拿來製作跨平台的遊戲。稍早我們提到 LucasArts 最後的冒險遊戲引擎 GrimE，就用了 Lua，因此用 Lua 來製作冒險遊戲絕對是可行且恰當的。

事實上，有個叫 MAD 的開放源碼軟體專案，就是運用 Lua 所做的跨平台開放源碼遊戲引擎（這個引擎就叫「MAD」）。如果你想要製作自己的冒險遊戲，但是又不想重頭刻起，那麼 mad 或許是個不錯的開始。

為日常繁忙的工作感到疲憊嗎？對時下動輒打殺的遊戲感到空虛嗎？不妨泡杯咖啡，翻出經典的冒險遊戲，重溫多年前的精采故事吧！

補充說明：MAD 最後一次更新已經是多年之前；除了 MAD 外，還有一些「免費」（但是並不自由）的冒險遊戲開發套件，像是 Adventure Game Studio、Visionaire Studio、SLUDGE 等。有個叫 Maniac Mansion Deluxe 的遊戲，就是狂熱的玩家用 Adventure Game Studio 復刻的瘋狂大樓（Maniac Mansion），還獲得了 2004 年的 Adventure Game Studio 年度最佳程式腳本獎。

認識我的人都知道，如果問到自己架設部落格，我大概會選擇 MovableType；如果問到免費的部落格服務，我通常則會推薦榖歌的 Blogger。

MovableType 從很久以前，就在官方文件當中說明，要如何從 Blogger 把部落格內容搬移到 MovableType，並且詳細說明了 MovableType 的匯入匯出格式，因此對於原本是 Blogger 的使用者來說，不管是要「跳船」到 MovableType，或者是要把位於 Blogger 的部落格備份到 MovableType 上，都相當方便。

反之，如果是想要把 MovableType 的部落格內容弄到 Blogger 上，卻非常地辛苦；在過去幾年間，xdite 和 VicJuan 先後以 PHP 撰寫了腳本，幫助人們把 MovableType 的內容，塞進 Blogger 當中──這些作法相當地克難，並且有諸多限制，例如每天祇能匯入 50 篇文章、無法匯入留言迴響、必須手動更正文章發表時間、冒著帳號密碼外流的風險等。這些困難讓反方向的操作（從 MovableType「跳船」到 Blogger，或用 Blogger 來備份 MovableType）難以接受，尤其是對一個已經寫了不知道幾百篇文章的部落客來說更是如此。

上個月，Blogger 測試區推出了部落格的匯入匯出功能，並且採用開放的 Atom 格式，霎時間生機湧現！

當我們在討論開放源碼軟體時，經常會提到「開放檔案格式」；事實上，許多開放源碼軟體也很堅持要採用開放檔案格式，因為這麼一來，這些檔案將能更容易地被其他程式所處理，而不會讓使用者被任何一套程式所箝制。這種「能夠隨時跳槽」的自由，向來是自由軟體／開放源碼軟體所尊崇的。在上個月的專欄當中，我們知道，這也是 Web 2.0 世代所期盼的。

以 Blogger 這個（讓人們期待了好多年的）新功能來說，我們可以輕易地弄懂它的匯出檔案格式，自然也就有辦法把其他部落格系統或平台的內容，包裝成相同的格式，匯入 Blogger。

實際上要怎麼做呢？前面提過，這個新功能目前祇有在 Blogger 測試區提供，所以你得從 http://draft.blogger.com/ 登入 Blogger，接著在「設定 > 基本 > 網誌工具」當中，就可以看到匯入、匯出等選項了。

首先讓我們試著匯出原有的部落格內容，你會得到一個檔名為 blog-MM-DD-YYYY.xml 的檔案，其中 MM-DD-YYYY 是以數字表示的匯出日期；這個檔案會是以 UTF-8 編碼的純文字檔，不含任何換列，所以可能不大容易閱讀。不過因為檔案內容其實是 Atom 格式，所以就算有換列也不影響其效用；稍加整理一下，你會發現這個檔案的內容大致上長這樣：

讓我們說明一下其中各個標籤內容：

部落格ID

在 Blogger 當中，每一個部落格都會有一個十九位數字的編號，請觀察一下 Blogger 控制主頁當中，那些超連結就會透露出這組編號。這個標籤內容的格式是：

tag:blogger.com,1999:blog-十九位數字的部落格編號.archive

例如：

tag:blogger.com,1999:blog-1234567890123456789.archive

部落格最後更新時間

部落格最後的更新時間，也就是部落格上最後一篇文章的最後更新時間。這個標籤內容的格式是：

YYYY-MM-DDThh:mm:ss.sss+ZZ:ZZ

其中 YYYY 是四位數的年份，MM 是兩位數的月份，DD 是兩位數的日期，hh 是兩位數的二十四時制時刻，mm 是兩位數的分鐘，ss.sss 是兩位數並且到小數點以下第三位的秒數，+ZZ:ZZ 則是表達時區。例如：

2008-06-30T23:51:06.135+08:00

部落格標題

部落格的名稱。這個標籤內容應該要是純文字，如果你偷用了任何 (X)HTML 碼，則會直接濾掉不見。

部落格Atom網址

部落格的 Atom 源料網址。這個屬性值的格式是：

http://www.blogger.com/feeds/十九位數字的部落格編號/archive

例如：

http://www.blogger.com/feeds/1234567890123456789/archive

部落格網址

部落格的網址。例如：

http://foo.blogspot.com/

部落格管理者顯示名稱

部落格管理者的顯示名稱。例如：

FooBar

部落格管理者資料網頁網址

部落格管理者的簡介網頁網址。在 Blogger 上，每一個使用者帳號都會有個二十位數字的編號，因此這個標籤內容的格式就會是：

http://www.blogger.com/profile/二十位數字的帳號編號

例如：

http://www.blogger.com/profile/00000000000000000020

管理者電子郵件地址

這個標籤內容是固定的：

noreply@blogger.com

在 <entry> 與 </entry> 之間的，則是文章或迴響；每一篇文章、每一則迴響，都會單獨放在一組 <entry>……</entry> 內。如果是一篇文章的話，則這段內容看起來會像這樣：

要判斷某一段 <entry>……</entry> 是否代表一篇文章，可以根據是否有這個標籤：

<category scheme='http://schemas.google.com/g/2005#kind' term='http://schemas.google.com/blogger/2008/kind#post'/>

注意一下 term 這個屬性的值要是：

http://schemas.google.com/blogger/2008/kind#post

這樣纔是文章。接下來讓我們看看每一個標籤或屬性內容：

文章ID

在 Blogger 當中，每一篇文章也都會有個十九位數字的編號；要表達文章 ID 時，這組編號還要跟部落格編號一起使用。這個標籤內容的格式是：

tag:blogger.com,1999:blog-十九位數字的部落格編號.post-十九位數字的文章編號

例如：

tag:blogger.com,1999:blog-1234567890123456789.post-0987654321098765432

文章張貼時間

這篇文章的最初張貼時間。這個標籤內容的格式是：

YYYY-MM-DDThh:mm:ss.sss+ZZ:ZZ

其中 YYYY 是四位數的年份，MM 是兩位數的月份，DD 是兩位數的日期，hh 是兩位數的二十四時制時刻，mm 是兩位數的分鐘，ss.sss 是兩位數並且到小數點以下第三位的秒數，+ZZ:ZZ 則是表達時區。例如：

2008-06-30T23:51:06.135+08:00

文章更新時間

這篇文章的最後更新時間；如果文章張貼之後就沒有更新過的話，自然就會與文章張貼時間一模一樣。這個標籤內容的格式是：

YYYY-MM-DDThh:mm:ss.sss+ZZ:ZZ

其中 YYYY 是四位數的年份，MM 是兩位數的月份，DD 是兩位數的日期，hh 是兩位數的二十四時制時刻，mm 是兩位數的分鐘，ss.sss 是兩位數並且到小數點以下第三位的秒數，+ZZ:ZZ 則是表達時區。例如：

2008-06-30T23:51:06.135+08:00

文章標籤

如果這篇文章被貼上標籤了，就會出現 scheme 屬性的值為：

http://www.blogger.com/atom/ns#

的 <category /> 標籤，其 term 屬性的值就是標籤名稱。如果貼了好幾個標籤，這樣的 <category /> 標籤也就會出現好幾個。例如：

<category scheme='http://www.blogger.com/atom/ns#' term='Tag01'/>
<category scheme='http://www.blogger.com/atom/ns#' term='Tag02'/>

在上述的例子當中，表示這篇文章同時貼著 Tag01 與 Tag02 這兩個標籤。

文章標題

這篇文章的標題。這應該要是純文字，如果你偷用了任何 (X)HTML 碼，則會直接濾掉不見。

文章內容

這篇文章的內容。這個標籤內容允許出現 (X)HTML，但是必須要逸出──意思就是說，所有的 < 都要變成 &lt;，所有的 > 都要變成 &gt;，所有的 & 都要變成 &amp;，所有的 " 都要變成 &quot; 纔行。

文章網址

這篇文章的網址。例如：

http://foo.blogspot.com/2008/06/blog-post.html

文章Atom網址

這篇文章的 Atom 源料網址。這個屬性值的格式是：

http://www.blogger.com/feeds/十九位數字的部落格編號/posts/default/十九位數字的文章編號

例如：

http://www.blogger.com/feeds/1234567890123456789/posts/default/0987654321098765432

文章作者顯示名稱

這篇文章的作者的顯示名稱。例如：

FooBar

文章作者資料網頁網址

這篇文章作者的簡介網頁網址。在 Blogger 上，每一個使用者帳號都會有個二十位數字的編號，因此這個標籤內容的格式就會是：

http://www.blogger.com/profile/二十位數字的帳號編號

例如：

http://www.blogger.com/profile/00000000000000000020

文章作者電子郵件

這篇文章作者的電子郵件地址。例如：

foobar@gmail.com

如果是一則迴響的話，<entry>……</entry> 的內容看起來則會像這樣：

請注意，如果某一段 <entry>……</entry> 內容是一則迴響的話，就會出現一個 scheme 屬性值為：

http://schemas.google.com/g/2005#kind

的 <category /> 標籤，其 term 屬性值是：

http://schemas.google.com/blogger/2008/kind#comment

接下來也讓我們看看每一個標籤或屬性內容：

迴響ID

在 Blogger 當中，每一則迴響也都會有個十九位數字的編號；要表達文章 ID 時，這組編號還要跟部落格編號、文章編號一起使用。這個標籤內容的格式是：

tag:blogger.com,1999:blog-十九位數字的部落格編號.post-十九位數字的文章編號.comment-十九位數字的迴響編號

例如：

tag:blogger.com,1999:blog-1234567890123456789.post-0987654321098765432.comment-0123456789012345678

迴響張貼時間

這則迴響的張貼時間。這個標籤內容的格式是：

YYYY-MM-DDThh:mm:ss.sss+ZZ:ZZ

其中 YYYY 是四位數的年份，MM 是兩位數的月份，DD 是兩位數的日期，hh 是兩位數的二十四時制時刻，mm 是兩位數的分鐘，ss.sss 是兩位數並且到小數點以下第三位的秒數，+ZZ:ZZ 則是表達時區。例如：

2008-07-01T23:51:06.135+08:00

迴響更新時間

Blogger 中的迴響無法修改、更新，所以這個標籤內容一定會與迴響張貼時間一模一樣。

迴響標題

這個標籤內容會是純文字，所以實際上會是將迴響內容的 (X)HTML 全部去除後，取前五十個中文字，再接上三個 . 號。如果迴響內容少於五十個中文字，則全取而且不加 . 號。

迴響內容

這則迴響的實際內容。這個標籤內容允許出現 (X)HTML，但是必須要逸出──意思就是說，所有的 < 都要變成 &lt;，所有的 > 都要變成 &gt;，所有的 & 都要變成 &amp;，所有的 " 都要變成 &quot; 纔行。

迴響網址

這則迴響的網址。例如：

http://foo.blogspot.com/2008/06/blog-post.html?showComment=1212721680000#c0123456789012345678

迴響Atom網址

這則迴響的 Atom 源料網址。這個屬性值的格式是：

http://www.blogger.com/feeds/十九位數字的部落格編號/comments/default/十九位數字的迴響編號

例如：

http://www.blogger.com/feeds/1234567890123456789/comments/default/0123456789012345678

留言者顯示名稱

這則迴響作者的顯示名稱。例如：

BarPaz

留言者資料網頁網址

這則迴響作者的簡介網頁網址。在 Blogger 上，每一個使用者帳號都會有個二十位數字的編號，因此這個標籤內容的格式就會是：

http://www.blogger.com/profile/二十位數字的帳號編號

例如：

http://www.blogger.com/profile/00000000000000000020

如果迴響作者並不是登入 Blogger 纔留言的話，則這個標籤內容也有可能是任何網站網址，端看留言者填寫了什麼而定。

留言者電子郵件

這則迴響作者的電子郵件地址。例如：

barpaz@gmail.com

文章Atom網址

這則迴響所屬的文章的 Atom 源料網址。這個屬性值的格式是：

http://www.blogger.com/feeds/十九位數字的部落格編號/posts/default/十九位數字的文章編號

例如：

http://www.blogger.com/feeds/1234567890123456789/posts/default/0987654321098765432

文章ID

這則迴響所屬的文章的文章 ID。這個屬性值的格式是：

tag:blogger.com,1999:blog-十九位數字的部落格編號.post-十九位數字的文章編號

例如：

tag:blogger.com,1999:blog-1234567890123456789.post-0987654321098765432

請注意，Blogger 是靠著這個屬性值纔有辦法把迴響跟文章連在一起。

在這個匯出檔案當中，會先一口氣把所有的文章列完，再開始列出所有的迴響。另外，在匯入的時候，我們會發現幾件事：

1. 有些標籤內容一定要符合上述格式，否則匯入時會發生錯誤；但是有些則不用符合特定格式，像是：
   • 部落格Atom網址
   • 部落格網址
   • 部落格管理者資料網頁網址
   • 文章網址
   • 文章Atom網址
   • 文章作者資料網頁網址
   • 迴響網址
   • 迴響Atom網址
   • 留言者資料網頁網址
2. 有些內容在匯入之後，會取得新的值；意思是說，原來是什麼其實不重要。像是：
   • 部落格Atom網址
   • 部落格網址
   • 部落格管理者資料網頁網址
   • 文章網址
   • 文章Atom網址
   • 文章作者資料網頁網址
   • 迴響網址
   • 迴響Atom網址
3. 不管匯入檔案裡面的部落格管理者資訊是誰，你匯入的就會變成你；不存在於你部落格的那些作者，他們的文章匯入後也會變成你的文章。

掌握這些要點之後，要讓 MovableType 生出符合這樣規格的檔案，就很容易了。以 MovableType 2.661 版為例，我們只要建立一個新的索引模版，名稱就叫做「Blogger.com 匯入檔」好了，輸出檔名可以用「blogger.xml」，然後模版內容如下：

接著重建索引檔案，你就會取得 blogger.xml──這個檔案可以直接丟給 Blogger 匯入，包括迴響、文章與迴響的時間資訊都能匯入，原有的文章分類也會做成標籤，而且你完全不用透露密碼等敏感資訊給第三方。（如果你想要的話，還可以把引用通告也做成迴響。）

這聽起來好多了，然而這個服務還在測試中，有些不足之處，像是目前它無法接受超過 1MB 的 xml 檔（這對於榖歌來說實在很諷刺呀），有時候匯入還會出問題，無法完整匯入所有的內容……這些小症頭，榖歌說未來將會改善，所以縱使這個功能還不夠當做正式上線，卻已經值得好好測試一番了。

有的讀者還會有進一步的疑惑：既然說是使用開放格式的 Atom 來匯出、匯入，為什麼祇能按照本文所描述的語法呢？事實上榖歌也正在努力，讓 Blogger 可以直接服用 WordPress 或其他部落格平台直接生出來的、符合標準的 Atom，祇不過透過本文的努力，我們就可以提早享受到開放格式的好處，而不用等到原生支援出現了。

「Freedom..0」要念成「Freedom 二點零」，是 Web 2.0 時代的關鍵自由。

自由軟體基金會為自由軟體訂定了四種屬於軟體使用者的自由：

• 第零自由（Freedom 0）：為任何目的執行軟體的自由。
• 第一自由（Freedom 1）：學習程式如何運作，並將其原理納入自己作品的自由。此自由建立在能取用源碼的前提上。
• 第二自由（Freedom 2）：重新散布副本的自由。
• 第三自由（Freedom 3）：改善程式、並將此改進釋出予公眾，使社群獲益的自由。此自由建立在能取用源碼的前提上。

在這四種自由當中，第零自由是最根本的自由，保障人們使用軟體就跟使用其他東西一樣地自由──你可以拿一本書來當枕頭、蓋泡麵、打蟑螂、燒來取暖、撕書頁來摺紙飛機、挖空來藏東西，賣書給你的書店、出版書的出版社、寫書的作者都沒有權力剝奪你把書本拿去做各種奇怪的使用；同樣地，自由軟體的使用者在第零自由下，也能夠任意地把程式挪做他用，例如拿處理 DNA 序列的程式來處理文字語料等。

筆者多年前曾指出，Web 2.0 的本質乃是くそ（Kuso）：在技術上、社交層次上或法律上，能讓使用者惡搞、以原創者及經營者所設想不到的方式，來使用或混搭各種網頁服務。這種自由，恰好與自由軟體的第零自由相呼應，筆者稱之為「Freedom..0」。

「Freedom..0」要念成「Freedom 二點零」，是 Web 2.0 時代的關鍵自由：為任何目的（或信念），使用（或不使用）網頁的自由。

有了這種自由，Wikipedia 纔能越來越不 Wiki、越來越（Encyclo）pedia；Twitter 也在這種自由中，偏離了原本「我在做什麼」的喃喃自語，成為許多人愛用的微部落格。

然而，此刻的 Web 2.0 時代，卻比以前更需要強調這種自由。

Web 2.0 的本意是回歸到以人為本的網頁世界，重視每一個人的個體性及完整性，強調任何網頁服務都應該要圍繞著使用者，而不是去限制使用者；網頁服務應該要表達每一個人的多元及多變，投影出人際關係與鮮明個性、成長蛻變和情緒起伏，而不是把使用者當成匿名的消費者路人甲看待。

然而 Web 2.0 卻比任何先前的網路技術，造就了更廣大的「鄉民結社」；許許多多的網頁服務，促成了使用者社群，也把人們綁死在那些小圈圈內。就好像很多人開始用 MSN Messenger 的原因是「因為朋友／客戶在用」，許多網頁服務也是受到這種同儕壓力，而不得不用：到 gravatar 上傳圖片、用 Twitter／Jaiku（順帶一提，這是芬蘭文，音近「易牙骨」）碎碎唸、拿 SlideShare 放投影片、註冊 Plaxo／Facebook／LinkedIn／orkut／Flickr 帳號並加入聯絡人／自己人……這一切都是因為誰誰誰有在用，所以自己不得不跟進；人與人見面就是在問對方的 Twitter／Jaiku／Plaxo／Facebook／LinkedIn／orkut／Flickr 帳號，彷彿咄咄逼人般地要對方也跟著用。

在 Web 2.0 時代，我們到每一個熱門的新網站上註冊帳號，把同樣的一群人加入為好友。什麼個別差異、自由意志的，都被這種病毒般的幫派結構扯下了；你跟他都用了同樣的一堆網站，做類似的一些事。曾幾何時，人們幾乎要忘了自己還有選擇的權力、選擇的自由。

Freedom..0 讓你能夠隨心所欲地使用各個網站或網頁服務，同時也讓你能夠做出選擇，選擇要用那些、不用那些，讓你做選擇的時候免於受到任何型態的脅迫，讓你從「做選擇」開始做自己，而不是別人的應聲蟲、不是無頭暴民的零件而已。

曾經有個人，因為無法說服筆者去用 Twitter 而反目，這事著實荒謬地令人費解。Twitter 很好，其他成千上萬的網頁服務也很好，各有其擅長之處、適合使用的時機，但是每個人都有不同的想法、習慣、偏好、環境、需求，強迫人人都用同一套解決方案來做所有的事，不但是一種退步，而且還很無趣。

在理想的 Web 2.0 國度當中，各種服務、各項著作內容，彼此間都有著可互通性；就算選用了不同的網站服務，彼此之間仍然能夠聯繫、傳遞，所有的付出都不會白費、所有的貢獻都會留下足跡，既有的人際關係不用反覆設定，網站服務同中求異、異中求同，讓使用者更能掌握自己到底要什麼。

此刻的 Web 2.0 離這個理想還很遙遠，可以說祇是 Web 2.0 Beta 而已；然而我們必須把這件事牢記在心，纔有機會讓這個理想實現。正因為我們經歷了 Web 2.0，所以更要能與眾不同地挑選網站服務。這不僅對使用者來說很重要，也是讓各種網站服務持續邁向真正 Web 2.0 所不可或缺的、根本的自由。

不久之前我在某個電子媒體的專欄上，寫了一篇叫「心智圖線上」的文章；有讀者讀了這篇文章後，跑來問我，有甚麼心智圖法的自由軟體／開放源碼軟體值得推薦？

很不幸地，以心智圖法來說，在自由軟體／開放源碼軟體的世界中，還沒有哪一套真的值得推薦。別誤會，像是 FreeMind 與 Cayra 都是不錯的軟體，祇是真的不適合用於心智圖法。

好的心智圖法軟體有甚麼必備的條件呢？首先，看起來要好看，要夠活潑（有機）、要能繽紛多樣。這種被許多沈迷於寫程式的人所不齒的細節，對心智圖法來說卻是關鍵，因為在心智圖法的理論背景中，相當強調各種不同的視覺刺激，包括色彩、線條、圖片、形狀、間隔、佈局等，並且必須仰賴這些視覺刺激，讓右腦的整體性思考與左腦的邏輯性思考一起發揮力量。

倘若軟體無法在視覺處理上提供充分的變化與自由，那麼反而會妨礙到心智圖法的發揮。光是這一點，大概就是目前各種自由／開放源碼心智圖軟體的罩門了。這一點並不是靠著「圖庫」就能夠改善的；即使對市面上多數的商業心智圖法軟體來說，能否畫出「有機」──隨意蜿蜒伸展的枝幹──的心智圖，都是個難以克服的課題，經歷了多年的改版，支援仍然相當有限。這對於檔案格式、程式效率以及介面設計來說，都是個考驗，也是自由／開放源碼心智圖法軟體所應該要認真以對的。對這部分有興趣的讀者，不妨去試用看看 iMindMap 這套軟體，就比較能有所體會。

這裡所提到的操作介面設計，是心智圖法軟體的另一個必備條件。心智圖法軟體在操作上一定要相當有效率，因為人的念頭往往稍縱即逝，唯有能及時捕捉這些思緒的軟體，纔能夠幫助人們腦力激盪。多數的心智圖法軟體都能同時使用鍵盤及滑鼠來操作，有的心智圖法軟體還會特別提供「腦力激盪模式」，都是為了要讓人們能夠在第一時間，捕捉自己的心思。這一方面倒是許多自由／開放源碼心智圖法軟體都有起碼的水準，不過卻總是還有能改進的空間。

舉例來說，在商業心智圖法軟體中，可以在使用任何其他應用程式的時候，隨時把想到的事扔進某個暫存區，然後再一口氣倒進心智圖中，繼續處理；或者是提供了自訂「腦力激盪精靈」的功能，來強化特定的思維模式；也有的能夠用鍵盤做完幾乎所有的事，包括加上圖示、變更字體或顏色等。

這些操作介面設計，其實又回歸到視覺表現上，著重的是對各種操作的即時視覺回饋；除了要能把某個枝幹折疊、展開，或者是一口氣將特定深度的分支折疊起來外，其實心智圖法還有更多的需求，包括重新把焦點放在特定的枝幹上（然後完全隱藏其他的枝幹），或者是將局部的心智圖轉換成多種不同的表現形式，以利探索念頭間的新可能等。這些在 XMIND 等商業心智圖法軟體中的功能，也很值得自由／開放源碼心智圖軟體來學習。

免費（但不自由的）心智圖法軟體 Cayra 做了些不錯的嘗試，把圖上的每個「念頭」變成一個個的節點，瀏覽到任何節點時再帶出與之關聯的其他節點。然而這樣的做法雖具創意，實際用起來卻又不是那麼一回事──因為心智圖的「整體」被打散了，使用者雖然能在複雜的關聯架構中清楚地看到每個局部，卻難以做概括性的思考。Cayra 團隊也明白這件事，並且也將此列入主要的待辦改進事項。

那麼 FreeMind 的表現又如何呢？正如本文一開始所說的，視覺表現上的不足，是 FreeMind 最大的難題，但是 FreeMind 確實在心智圖法軟體領域中，扮演著相當重要的指標。現今各種心智圖法軟體或線上服務，幾乎都支援著匯入或匯出 FreeMind 格式的檔案，而且 FreeMind 與圍紀結合、線上瀏覽等功能的開發，也是走在各家心智圖法軟體廠商前頭的。

這些卓越之處，嚴格說起來並不是 FreeMind 程式本身的功勞，而是其存檔格式的優勢；使用格式開放、內容簡單的檔案格式，讓 FreeMind 文件能被更自由地操弄。繼續保持開放的檔案格式，對 FreeMind 來說是理所當然也是極為重要的，不過若此格式繼續保持簡單而沒有進一步擴展，恐怕就會成為妨礙 FreeMind 程式功能的絆腳石了。

FreeMind 本身相當自由，但是用它來繪製心智圖卻不是那麼地自由；有太多人拿 FreeMind 來用，只是為了要用樹狀結構來記筆記而已，而無法以心智圖法的技術，對事物進行全腦思考，實在是相當可惜。

如果你是 FreeMind 的使用者，那麼除了去想想這樣的軟體能夠怎麼幫助你之外，我也要鼓勵你花些時間瞭解一下心智圖法背後的理論基礎於實務，並且一起來想想，如何能讓 FreeMind 更自由地使用心智圖法。

熟悉心智圖法 (Mind Mapping) 的讀者，就會知道心智圖 (MindMap) 用來整理資訊、協助思考，是個相當強力的工具。然而設計來繪製心智圖的工具雖多，軟體的進步卻十分緩慢，而且售價並不便宜，幾個領導品牌的第一線產品如 Mindjet MindManager、NovaMind 等，甚至要價 250 美元至 350 美元（折合台幣大約是七千五百元至一萬一千元），對許多人來說又增添了一份阻力。

當然也有一些免費的解決方案，例如相當知名的開放源碼軟體 FreeMind 就是一例；然而真正善用心智圖的讀者，一定也跟筆者一樣，瞭解「畫面」對於心智圖來說是非常重要的一環──因為心智圖法仰賴各種豐富的視覺提示，同時刺激理智的左半腦跟情感的右半腦，在這種顧慮之下，FreeMind 祇及格了一半，缺乏彈性、樣式呆板的視覺呈現，成為它的致命傷。

步入 2008 年後，心智圖工具的發展更顯牛步，因為使用者發現這些心智圖難以交流共用──使用的人往往需要有特定的軟體，而這些軟體又不便宜；網頁當道的這個年頭，「思考」如此仰賴桌面軟體，恐怕也是新一代網路使用者所難以置信的。

事實上心智圖「每張圖祇有一個中心思想」的邏輯，以及「自由蔓生的連結」，都與圍紀相呼應，於是有了 Wikka Wiki 這套圍紀系統，把心智圖帶進圍紀的世界。Wikka Wiki 用的是 FreeMind 的 Java Applet 程式碼，因此支援的格式也就以 FreeMind 為主，並且可以把 RSS 源料內容也轉換成心智圖顯示；很不幸地，稍早我們題過的 FreeMind 諸多限制，也發生在 Wikka Wiki 上，導致這樣的做法除了「看起來像個心智圖」外，許多心智圖法的重要精神通通無法發揮。

即使如此，支援 FreeMind 心智圖的功能，仍然成為 Wikka Wiki 在圍紀世界中的成名特色，那些程式碼稍後也被移植到其他的圍紀系統如 XWiki 上。來自 FreeMind 的這段程式碼，不但能用於圍紀上，也可以單獨取得 FreeMind-Browser 套件來使用，因此任何人都可以把自己的 FreeMind 格式心智圖發表到網頁上，讓其他人線上瀏覽；除了 FreeMind-Browser 之外，另外也有 Flash 的版本，叫 FreeMindFlashBrowser，也是一個選擇。

這些「在網頁上瀏覽心智圖」的技術似乎祇限於 FreeMind，實則不然。心智圖軟體的龍頭老大 Mindjet 做了一個 ActiveX 版的 MindManager Viewer，因此 MindManager 格式的心智圖也可以線上瀏覽──可是 ActiveX 祇能用於 Windows 版的 IE，其他瀏覽器或其他作業系統則無法使用；所幸 MindManager 跟 FreeMind 都用了 XML 來儲存檔案，所以可以用 XSLT 來轉換檔案格式，於是 Eric Blue 就把上述這些套件拼湊起來，做了一個叫 MindMap Viewer 的網站，提供以 Java Applet 或 Flash（因此是跨平台的）線上瀏覽 MindManager 格式心智圖的服務。聽起來很美好，但是因為其實是把檔案先轉換成 FreeMind 格式再線上瀏覽的，所以再一次地，前面所提到的問題仍然存在。

隨著技術進步，我們可以預期這些困境遲早也會有所突破。舉例來說，Cayra（這是個用 .NET 3.0 框架製作的免費心智圖軟體）加入了認知圖的做法，所以在使用彈性上又比單純的心智圖軟體更為豐富靈活。

另外，也有許多網頁服務如 MindMeister、Mindomo、bubbl.us、WiseMapping、Mind42.com 等，除了 Java 跟 Flash 外，也用上了 AJAX 技術，不但讓使用者可以在線上瀏覽、編輯心智圖、把心智圖發佈在其他網頁上，甚至還能夠像使用圍紀一樣，一群人同時編修同一張心智圖，檢視版本差異等。

這些網頁服務當中，目前評價最高的又屬 MindMeister；在付費使用的版本中，它可以匯入、匯出 MindManager 及 FreeMind 格式，而且還用了 Google Gears，讓使用者可以在離線的時候使用大多數的功能，等回到線上的時候再同步化回去，儼然想跟 MindManager 搶生意；MindMeister 每個月收費低於 5 美元，買一套 MindManager 的錢足足可以用上十年的 MindMeister……不過 MindManager 的功能還是多很多的。

除了 MindMeister 之外，目前正在「封測」中的 Spinscape 也值得留意。這個線上服務除了像 Cayra 一樣，用「節點」的概念加強心智圖的彈性外，更把「外掛模組」的做法帶進了這個市場，讓新增功能變得更容易、更靈活。在 Spinscape 中，可以隨時改變心智圖的中心思想，可以在兩層節點之間插入一層，外掛模組的支援已涵蓋了 del.icio.us、Google 搜尋、Google 文件、線上檔案存放服務等，甚至是很多主流桌面心智圖軟體所辦不到的。

在 Web 2.0 的浪花中，心智圖法愛用者們也在期待著心智圖法 2.0，追求線上、合作、分享、開放、3D 的心智圖；或許哪一天，心智圖法也將改變網頁的面貌呢。

「親和力」的專題一連介紹了一整年，或許有些讀者會覺得，「這些跟自由軟體有甚麼關係啊？」這關係可大了。本期讓我們先撇開還沒講完的設計花樣，先來看看一個叫 aDesigner 的軟體，回答上述的疑惑，並做為「親和力」專題第一階段的結尾。

在自由軟體及開放源碼軟體發展的歷史上，向來最為人詬病的就是軟體的介面設計。如果單以技術面來審視自由軟體，確實有許多非常傑出的作品──程式碼漂亮、功能強大的軟體，但是這些軟體卻往往不是一般人在挑選軟體時的首選；它們固然穩健敏捷，效能卓越，並且便於延伸擴充，但是介面設計卻不討喜，使得軟體人們不具親和力，甚至有的完全缺乏設計。

讓我們直視問題的癥結，介面設計在軟體開發流程當中，原本就是相當奢侈的一環，有言「好設計是不折不扣的」，因為要做出好的介面設計，不但要仰賴藝術天分，而且一定會需要許多的測試者參與協助，並且花費昂貴的代價來建置測試用的空間與設備，這些都不是靠著年輕熱血，窩在鍵盤前就有辦法完成的。

君不見今日的圖形設計師仍一面倒地使用 Adobe Photoshop，少有依賴 GIMP 為生的？當然還是有一些較成功的專案，以 Firefox 為例，其實很大部分是靠著 Mozilla Foundation 把資金投入行銷、使用者經驗研究這些光靠技客們無法處理的領域，纔有今日的成就。

就算撇開主流市場不談，有些悲天憫人的軟體開發者，認為自由軟體或開放源碼軟體存在的必要，在於提供社會上的弱勢族群，也能享受到資訊技術的進步。套用古老笑話中的說法，「這群人在路邊幫人們拼裝了時速可達兩百公里的超級坦克車，而且還免費贈送。」但是這樣的善意並不見得有辦法傳遞到弱勢族群手中──因為弱勢族群不見得有手、有眼睛、有耳朵，能夠用來操控這樣的軟體。

雖然在筆者過去一年來談論親和力的時候，總是強調讀者們不應把「親和力」跟「殘障人士」劃上等號，但是此刻讓我們先以殘障人士的角度來審視這樣的議題，畢竟這群人對親和力不佳的設計，會感受到最大的不便。

對於肢體動作、視力、聽力等能力有所不便的使用者來說，有一些輔助科技可以協助操作電腦軟硬體；這些輔助科技包括了硬體與軟體的組合，像是把螢幕畫面轉為語音甚至點字輸出的設備、利用語音做為標準輸入輸出的設備，或者是即時以視覺方式來呈現聲音線索、即時將多媒體內容的語音上字幕的軟體等。

問題來了，這些輔助科技如何能夠得知，作業系統或其他應用程式到底繪製了甚麼畫面、發出了甚麼聲音、輸出了甚麼內容呢？

以這些輔助科技支援最廣的作業系統──微軟 Windows 為例，從 Windows98 以及 Windows 2000 開始，包括這兩個版本，所有後續的 Windows 作業系統都支援了微軟在 1995 年起制訂的 Microsoft Active Accessibility (MSAA) API，至於更早一點的 Windows95 則可以安裝一個 RDK（Re-Distributable Kit，可再散佈的套件）來支援 MSAA，而 WindowsNT 4.0 則是從 SP4（Service Pack 4）也支援 MSAA；MSAA 的核心是一個叫 IAccessible 介面的東西，因此當軟體元件支援 IAccessible 介面時，就能夠享受到由 MSAA 所提供的環境，與其他支援 MSAA 的輔助科技互通。舉例來說：各種應用程式能使用便捷鍵（跟組合快速鍵不一樣，不過這個說來話長，日後有機會再詳述），螢幕朗讀軟體可以唸出選單、對話窗、按鈕上的文字，字幕程式可以替程式輸出的語音顯示字幕，或者使用替代滑鼠的其他指標裝置等。

到了 1998 年，原有的 MSAA API 已不敷使用，IBM 與 Sun Microsystems 於是合作提出了新一代的介面，叫 IAccessible2，並以此實做出 Java Accessibility API；這個 API 稍後又繼續發展成許多不同的 API，包括 OpenOffice.org 做的 UNO Accessibility API，GNOME 社群所做的 UNIX Accessibility Toolkit（ATK）及其伙伴 Assistive Technology Service Provider Interface（AT-SPI）等。

這些新一代的 API 都是奠基於 IAccessible2 介面而來的，而 IAccessible2 則是個免費的開放標準，IBM 已將其規格捐給自由標準組織（Free Standards Group，FSG，現在是 Linux Foundation 的一部分），並逐步將相關的程式碼捐贈給自由軟體／開放源碼軟體組織；藉由投入自由軟體／開放源碼軟體界，讓社群能夠享受到親和力科技的努力成果，讓社群也樂於採用這樣的 API，打造更具親和力的軟體，並且能進一步地回饋，持續改良 API。包括像是 IBM Workplace Productivity Editors、Firefox、Eclipse 等軟體，都是採用 IAccessible2 介面的實例；現今所流行的 Web 2.0 網頁應用程式（AJAX、DHTML 等）也受到 IAccessible2 的支援。因此可以說，IAccessible2 介面乃是目前為止實做資訊系統親和力功能時，最重要的核心之一。

瞭解了這些背景後，讓我們回過頭來看軟體介面設計。

雖然已經有許多不同的 API 支援 IAccessible2，能讓程式設計師以較低的成本在多種平台上實做具親和力的應用軟體，但是我們都知道，有 API 不代表就能做出好東西，有沒有甚麼工具或辦法，能夠協助自由軟體／開放源碼軟體社群，來評估軟體的親和力呢？

在 MSAA 時代，有一些工具例如 Inspect32 及 AccEvent 等，可以用來測試軟體的介面親和力，但是他們都祇能支援 IAccessible 而已，沒辦法用於 IAccessible2 的測試。一直到了 2004 年，IBM 東京實驗室推出了一個叫 aDesigner 的工具，解除了這樣的困境。2007 年年底，IBM 傑出工程師淺川智惠子（Chieko Asakawa）代表 IBM，將包含 aDesigner 在內的許多程式碼，捐給了 Eclipse Foundation，展開了一個叫 ACTF（Accessibility Tools Framework）的開放源碼計畫，期待對自由軟體／開放源碼軟體社群有所幫助的同時，也能讓自由軟體／開放源碼軟體的介面設計更具親和力。

ACTF 還是個很新的計畫，國內更是沒多少人知道 aDesigner 這套工具。aDesigner 其實不是一套專為軟體開發人員所設計的工具，而是適用於各種設計人員──除了軟體設計師外，網頁設計師、Flash 多媒體設計師也同樣是這套工具的對象，甚至連拿著投影片要去做簡報的人，也可以使用 aDesigner。

aDesigner 的使用上，大致可以分成四個不同的模式：網頁（HTML）、文件（OpenDocument）、Flash，以及應用程式圖形介面（GUI）的親和力分析模式。既然我們這次主要要介紹設計軟體介面時的親和力檢查，就讓我們從圖形介面的親和力分析模式介紹回來吧。

在 GUI Accessibility 檢視的模式下，設計師可以針對任何執行中的應用程式予以分析；這個檢視模式會有五個子視窗，分別是 GUI Summary、GUI Outline、GUI Properties、GUI Event 以及 GUI List（包括 GUI Report 與 GUI Siblings）。在 GUI Summary 子視窗中，會將選定的應用程式「線性化」，把各個物件以純文字的方式依序顯示出來；如果使用者透過螢幕朗讀軟體來操作應用程式的話，螢幕朗讀軟體唸出來的內容，就會跟 GUI Summary 的輸出結果差不多，因此若介面元件安置的順序不良，在此就能夠看出結果。

GUI Outline 子視窗會把選定應用程式的 MSAA 物件結構以樹狀方式顯示出來，如果在這個樹狀結構中加以點選，除了會以閃爍的黃色外框實際在應用程式周圍標示該物件外，GUI Summary 子視窗中相對應的部分也會反白標出，GUI Properties 子視窗的內容亦會隨之更新；至於 GUI Properties 除了會顯示出 GUI Outline 子視窗中所選物件的 IAccessible 介面資訊，還會顯示出 IAccessible2 介面資訊的細節，可供軟體開發者進一步分析親和力問題。

當然，aDesigner 也有自動分析的能力，因此在 GUI List 子視窗的 GUI Report 分頁中，將會自動地尋找所選程式中，各個 MSAA 物件是否提供了替代文字，並將有問題的部分列出；GUI Siblings 分頁則是會根據 GUI Outline 子視窗中所選的物件，列出其毗鄰物件，讓軟體設計師不會迷失在物件樹之中。

除了靜態的分析之外，aDesigner 的 GUI Event 子視窗也會動態地顯示出各個應用程式所觸發的 MSAA/IAccessible2 事件，並且會記錄大於一秒鐘的時間間隔，當要分析應用程式的操作效率時，這項資訊就會非常有用。

除了一般的應用程式會用到 MSAA/IAccessile2 之外，現在也流行運用 Flash 或 AJAX 技術來開發網頁應用程式，這些網頁應用程式其實也會透過 MSAA 介面輸出，所以 aDesigner 能夠與 Internet Explorer 或 Firefox 搭配使用，讓開發者分析瀏覽器中的網頁應用程式 GUI 親和力。

除了以 GUI 為導向的分析方式外，aDesigner 也可以用 Flash 模式來分析 Flash 媒體的親和力，這時候 aDesigner 將同時擔任代理伺服器的任務，除了 GUI Summary、GUI Outline、GUI Properties、GUI Report、GUI Siblings、GUI Event 之外，還會多出 Flash Outline 以及 Flash Proxy Log，前者會直接剖析 Flash 媒體內容的執行期結構，後者則會紀錄存取 Flash 內容的 HTTP 歷程，對於以 Flash 為主的開發者來說，會是很好的除錯工具。

aDesigner 的網頁（HTML）分析模式也跟歷來的各種網頁親和力分析工具有所不同。最大的差別在於 aDesigner 會將盲人使用者所感受到的瀏覽經驗，以視覺化的方式呈現給設計者：網頁的不同部分，會用深淺不同的底色，來表示使用者瀏覽至該位置所耗費的時間，並且會提供此估算的秒數，讓網頁設計師能夠「看」到有沒有哪些內容，對使用者來說將難以取得；另外也會用雷達圖的方式，綜合評論網站是否（在技術上）符合相關規範、是否易讀、是否便於導覽，雖然這離真正完整的親和力評估仍有距離，但是卻比之前任何檢測工具要來得全面性了。

網頁分析模式除了盲人模式外，還有一個弱視模式，不但會同步模擬網站在弱視使用者眼中的樣子，並且會有一個「Problem Map」來標示出哪些部分的對比可能不足。這些用視覺化的方式，來分析並呈現網頁整體的親和力概況的做法，實在可以說是一項創舉，也是 IBM 東京實驗室的驕傲。值得注意的是，促成 aDesigner 誕生、推動 ACTF 計畫最用力的 IBM 傑出工程師淺川智惠子（Chieko Asakawa）本身是一位盲人，卻能夠帶領這項計畫走向視覺化，也明白親和力跟自由軟體／開放原始碼軟體的結合，將能促成雙贏局面，這樣的用心實在是值得我們效法。

最後，aDesigner 還有個文件分析模式，除了能以 XML 技術分析 ODT（OpenDocument Text）、ODS（OpenDocument Spreadsheet）和 ODP（OpenDocument Presentation）等開放文件格式檔案的親和力，並以盲人模式跟弱視模式模擬外，還特別做了一個「簡報模式」，讓使用者可以模擬在不同的簡報環境（小型會議室、大型會議室、大禮堂）中，自己的文件或簡報投影在螢幕上時，台下的觀眾看到的樣子究竟如何。這項功能也是個創舉，任何要上台做簡報的讀者都應該要試著用用看，畢竟場地的干擾將可能讓任何耳聰目明的聽眾變得視茫茫，而沒有任何簡報軟體能提醒你這一點。

上述這些祇是 aDesigner 的簡短介紹，每一種模式又都可以再深入探討。之所以應用程式的 GUI、網頁、文件的親和力檢查可以放進同一個工具程式之中，其實是因為親和力的本質是相同的，當今資訊技術所建構出來的解決方案也是相似的。同樣地，筆者在這個專題一年來所說明的，也適用於應用程式的 GUI、網頁、文件等不同設計領域。

從親和力的概念、釋疑，到最近所介紹的設計花樣，除了用於網頁外，亦可用於文件或應用程式 GUI 設計。希望藉由介紹 aDesigner 的背景及功用，能對於設計軟體 GUI 的讀者有所幫助，並且讓讀者們看到，親和力與自由軟體／開放源碼軟體社群結合的趨勢所在，也希望這些議題在未來都能有更多人關注、發展出更多更好的解決方案，讓自由軟體／開放源碼軟體更具親和力、更多人樂於使用。

附錄──相關參考資源：

• alphaWorks : aDesigner : Overview
• IBM Women in WITI Hall of Fame - profile for Chieko Asakawa
• Accessibility designer
• IBM developerWorks : Blogs : Accessibility Strategy and Architecture

「設計花樣」是我們在做各種設計時所使用的術語，前一期我們介紹了「多重導覽途徑」這個設計花樣，本期則讓我們來看看跟「首頁」有關的設計花樣。

每個網站都會有首頁，首頁就像報紙的頭版、雜誌的封面、公司的門面，要說一個網站給人的第一印象如何，首頁絕對是佔了相當重要的地位。當我們考慮網站親和力──這個網站是否能帶給訪客親切和善的感受──的時候，首頁自然也會是重要的指標。

前一期所提到的多重導覽途徑，自然是首頁所能運用的設計花樣，但是這還不夠，因為首頁往往是網站的主要入口，不但要能吸引訪客（如果連這一點都辦不到，又怎麼能說有親和力呢？），同時還要能在許多其他因素間取得平衡，包括像是商標識別、內容的安置等等。

說到吸引訪客，有不少人相信首頁的第一個可見範圍又尤其重要；第一個可見範圍的意思是說，當訪客用瀏覽器來到首頁時，在不捲動瀏覽器視窗的前提下，所能看到的局部。想像一下，當你在便利商店看到一疊疊的報紙，通常你不會看到完整的頭版，因為報紙的折法，所以你祇能看到頭版的上半部，對折線以下的部分得要把報紙攤開來了纔能看到；既然網站的首頁猶如報紙頭版，因此首頁的第一個可見範圍也就有了個來自報紙的說法，叫「折線以上」。當然，網頁不是報紙，瀏覽器沒有固定的尺寸，「折線」更不是在正中間把整個網頁平分為二，甚至可能會有左右分的垂直折線；如果訪客用的是螢幕朗讀軟體，或者是其他的「線性」瀏覽器，那麼折線可能會以更為抽象的形式存在，例如「第三十秒」或「第 1024 位元」之類的。

確實折線以上是首頁的第一印象，但是並沒有必要把整個首頁的各個部分都塞進那個空間；一般說來，祇要折線以上／以前的內容，能誘使訪客將瀏覽器視窗捲動到其他部分，也就功德圓滿了。在這個區域中，唯一非要有不可的，大概要屬網站商標吧。你可能會問，為什麼這會跟親和力有關？

因為商標是網站識別的重要依據，而明確的網站識別對使用經驗來說，可以塑造一致的觀感與信任。當訪客感受到自己身處同一個網站，對該網站的使用經驗、情感、信任就會接續傳承而跟著累積。當他們感受到這一點時，就會預期網站的設計哲學、服務條款、隱私權政策等的一致性，也就更能掌握整個網站──網站也就更具親和力了。

雖然商標背負著這麼艱鉅的任務，但是可也別顧著把商標做得又大又明顯，反而佔掉了所有的空間。人們是來網站完成某些目的的，而不是單純來欣賞你的商標設計；如果首頁是個斗大的商標，那麼你的確能建立鮮明的網站識別──人們將會記得你的網站使用不便，如此就跟親和力背道而馳了。

運用前一期所介紹的設計花樣，讓你的首頁跟其他網頁具有一致且合乎邏輯的網頁架構，做出容易使用的導覽工具，這些都是增進親和力的要旨。接著，別忘了網頁的主角是「內容」，所以在規劃了網頁架構、導覽工具後，還得對首頁的內容下點功夫。

首頁是網站的入口，不但要能吸引訪客，還要把他們帶往正確的方向，因此有些增進親和力的手段可以派得上用場。首先，首頁的內容應該要鮮明活潑，讓訪客感受到網頁的更新與生氣，如果這些內容帶有強烈的線索與暗示，就能讓訪客祇消簡短的篇幅，猜到網站的目的與內容，並且能藉此迅速地導覽到想去的網頁；另外，如果還能根據使用者提供客製化的首頁內容，就再好不過了，因為這樣子可以幫助訪客精簡例行公事，而專注於他們覺得重要的任務。

既然說到首頁內容應該要鮮明活潑，還有一個要點一定要強調一下，就是首頁不宜使用過多的內容，或過於花俏華麗的效果；因為首頁是入口，所以必須要確保初次來訪的訪客就算在相當受侷限的條件下，也能順利取得首頁內容。這裡並不是要禁止你把首頁打扮得漂漂亮亮的，而是要各位確保首頁不應該要花上幾分鐘纔能載入完畢，或者得安裝特殊的外掛程式纔能順利一窺其廬山真面貌。華麗、新潮、豐富的媒體內容，得在訪客願意期待的前提下，纔有出場的機會。

像這樣的設計花樣，看起來主要是在增進網站的可用性，不過同時也會增進網站的親和力，讓訪客感到自在，並且祇需較少的資訊就能完成目標。

前述的「首頁入口」要讓訪客能立即明白網站目的，這還需要另一個設計花樣，那就是「預先提示價值所在」。這個設計花樣所要解決的問題很直接：有太多網站讓人們無法一目了然，看不出網站到底是為什麼而存在著的。網站的首頁必須要建構網站價值、營造第一印象並提出承諾，這正是親和力所在，因為這麼一來，訪客將能在最短的時間內，知道自己為什麼要來這裡、來這裡能完成甚麼、可以期待甚麼。

要滿足這個設計花樣，基本上會需要：

• 一個具說服力的承諾
• 一項獨特的提案
• 易於迅速理解的文案、圖樣或媒體

等等，這三件事還必須結合在一塊兒。網站的提案──用來說明網站的價值所在──必須要強而有力，並以此建構出網站的獨特性；然後這樣的提案還得用易於迅速理解的簡短文字或簡潔圖片等形式，加以表達在首頁上。

舉例來說，愛印網的首頁映入眼簾的九個大字：挑產品、改造型、送到家，就充分說明了整個網站的目的，並且以俐落的風格，加深了「明天立刻為您寄出」的迅速處理印象。更棒的是這九個字還擔任了訪客操作流程的指示器，讓人們知道自己已經做了甚麼、正在做甚麼、接下來還會需要做甚麼。再看看 blogger.com 首頁：尚未登入的訪客，馬上就會看到相當簡潔有力的四組圖說，解釋了部落格到底是怎麼一回事、可以怎麼玩，接著提示祇需要三個步驟即可建立部落格。

這些設計都讓訪客能一眼明白這裡是在做甚麼的，並且能預期接下來會發生甚麼事，而樂於參與及使用。用我們一貫的說法來講，這般首頁大大地增加了整個網站的親和力。

最後讓我們再回顧一下本期所介紹的兩個設計花樣：

1. 首頁入口

脈絡背景：

• 任何類型的網站

所要處理的問題：

網站的首頁乃是多數訪客來訪的入口，因此必須要能吸引訪客，同時還要能在商標、導覽、內容及載入速度等許多不同因素間取得平衡。

相關外力影響：

• 建立網站識別與商標。
• 以正確的觀感營造正面的第一印象。
• 用內容吸引人。
• 盡可能提供客製化的內容。
• 在商標與導覽區佔據的位置間取得平衡。
• 創造易用的導覽工具。
• 提供強而有力的資訊線索。
• 提供一致且具邏輯的網頁佈局。
• 讓首頁能迅速載入。

其他可能會有相關的設計花樣：

預先提示價值所在、網站商標與識別、隱私權政策、個人化的內容、多重導覽途徑、導覽列、動作按鈕、內嵌的鏈結、較長的描述性鏈結標題、明顯的鏈結、頁面模版、格線佈局、折線以上、釐清第一印象、減少檔案數量、能迅速載入的圖片……。

2. 預先提示價值所在

脈絡背景：

• 網站入口

所要處理的問題：

人們往往無法初到某個網站時便能迅速得知其目的。

相關外力影響：

• 需求。
• 整合。

解決方案：

用易於迅速理解的簡短文字或簡潔圖片等形式，在首頁上強而有力地表達網站的價值，並以此建構出網站的獨特性。

其他可能會有相關的設計花樣：

網站商標與識別、釐清第一印象……。

首頁祇是個開始，別忘了網站的內容纔是主角。下一期我們將開始說明，關於撰寫及維護網頁內容時，有哪些與親和力相關的設計花樣。

從這一期開始，我們要從「設計花樣」的角度開始，來探討網頁親和力的種種實做。

「設計花樣」是我們在做各種設計時所使用的術語，不管是在電腦程式、人機介面、網頁等設計領域，設計師們在溝通要有哪些功能、設計、裝置時，都會用這些「設計花樣」的名詞用來表達那些概念。「花樣」可以是一種模式、一種功能、一項裝置等概念，可以是某種影響整個網站的定位或規範，例如「個人部落格」或「網站商標與識別」，也可以是小範圍的實做如「目前位置指示符」、「動態按鈕」或「網站地圖」等。

藉由設計花樣，設計師們可以便於釐清設計概念、情境，發掘設計障礙或困難，並找出合宜的設計方案。一般來說，當我們在描述一種設計花樣時，除了這個花樣本身的名字外，還會去描述其產生的脈絡背景、所要處理的問題、各種作用在該花樣上的外力影響、解決方案、以及其他可能會有相關的設計花樣。

運用設計花樣來溝通，可以讓設計師們不侷限於技術細節，同時又保有高度的靈活；當我們討論設計花樣時，並不是要給你甚麼成功網站非有不可的「甜蜜點」──真的做過設計的朋友就會知道沒有那種東西存在，隨著時間以及使用族群的演變，許多設計花樣也會跟著演變、消失或出現；經典的設計花樣會持續較久，但並非全然無可取代，另外某些設計花樣則可能僅適用於特定的情境或前提，或者與某些設計花樣一定要共存，但跟其他某些設計花樣互斥。不論是做程式設計或網站設計，見樹不見林或見林不見樹都是致命傷；如果用設計花樣來當作中介橋樑，就不會迷失在多變的設計之中，也將更能靈巧地面對未來的變化。

做為這個子系列的開頭，我們要先從跟「建立導覽框架」有關的親和力設計花樣開始。「導覽」是現代網站首要面對的挑戰之一，因為沒有人能夠預期讀者會從甚麼地方進入你的網站──有可能是從首頁，也有可能是部落格上的某一篇回應；如何建立一個導覽框架，讓讀者不管從哪邊開始，都能夠掌握整個網站的內容，這不但是個親和力議題，也關係著網站的可用性。

跟「建立導覽框架」有關的設計花樣並不少，囿於篇幅關係，在此我們祇先討論一個跟親和力尤其有關的，叫「多重導覽途徑」的設計花樣。基本上不論是哪一種網站，小自個人部落格，大至複雜的電子商務網站，都會需要這個花樣；因為不論是哪一種網站的訪客，都會用各自偏好的方式來瀏覽整個網站，如果有任何關鍵的導覽工具──例如導覽列或導覽側欄等──在某些頁面難以尋得甚至消失不見，那麼訪客們勢必會覺得網站本身難以使用。

更進一步來看，其實訪客們各自的「偏好」取決於他們的意圖跟衝動，也就是理智的目的以及感性的需求；如果網站缺少了意圖性的導覽工具，那麼訪客們會覺得網站的安排很詭異、很沒道理，反之若網站缺少了衝動性的導覽工具，則會變得枯燥乏味。不論是哪一種導覽工具，還要注意不同動機的訪客，也會有其所偏好的導覽風格──例如「搜尋」、「瀏覽」、「下一步」、「精靈」、「關聯」、「推薦」等，都是不同的導覽風格，也都有各自適用的導覽工具。

如果用來實現各種導覽風格的工具被任意安置，那麼訪客也許就無法從中獲得好處──他們根本不會去用！這些導覽工具需要被放在訪客們找得到而且也會去用的位置，這些也是「多重導覽途徑」這個設計花樣所要面對的問題。

解決的方法其實很明顯，也就是任何網站都應該要具備多種不同的導覽途徑，同時滿足意圖型的訪客與衝動型的訪客，而且這些導覽工具的安置應該要有其規律及一致性──運用「頁面模版」及「格線佈局」等設計花樣，將能讓多重導覽途徑兼具理性與感性。

為了讓各種訪客都能完成其來訪目的，通常我們會把搜尋工具及主要的瀏覽型導覽介面放在網頁的一開頭、最上面的位置；如果有需要用到「下一步」這類精靈風格的導覽工具，例如商務網站的結帳流程，則可以同時把他們放在頁面的上方及下方，最後別忘了盡可能加上關聯型的導覽工具，例如相關或推薦的產品／文章，滿足訪客的衝動需求；這些關聯型的導覽工具可以放在網頁文件較後端的位置，纔不會搶走主要內容的風采。

讓我們最後再來整理一下「多重導覽途徑」這個設計花樣：

脈絡背景：

• 任何類型的網站。

所要處理的問題：

• 訪客會用各種方式瀏覽整個網站，如果有任何關鍵的導覽工具難以尋得甚至消失不見，那麼訪客們勢必會覺得網站本身難以使用。

相關外力影響：

• 瀏覽網站的方式取決於訪客的意圖跟衝動。
• 不同動機的訪客，會需要不同的導覽風格。

解決方案：

• 導覽工具需被放置在訪客們找得到而且也會去用的位置。

其他可能會有相關的設計花樣：

頁面模版、具鑑別力的 HTML 標題、網站商標與識別、格線佈局、一致的相關資訊側邊欄、單一瀏覽繼承性、導覽列、頁籤列、目前位置指示符、有意義的錯誤訊息、找不到的網頁、靜態鏈結、跳過選單、網站地圖……。

上述的這個設計花樣，除了適用於任何網站外，同樣地也適用於各種圖形介面的應用程式設計。至於最後所提到的這一堆相關設計花樣，未來我們也會逐一加以說明。

在前一期當中，我們提到了親和力部門在執行長的授權下，有八項重要的任務要執行；在本期當中，就讓我們來一一細看，這些任務應該要怎麼進行。

在公司內部提高對親和力議題的體認，並提供員工們設計具親和力的產品或服務所需的相關訓練。

親和力部門的理想成員，是要由整個公司各個部門的人員所兼任的，這些兼任親和力部門成員的人，就是提高公司對親和力體認的重要種子，也因此他們在親和力部門的「兼職」，必須要有執行長的認可，而不會影響到他們原本工作崗位的考績，或者增加他們的業務負擔；這些成員平日的重要工作之一，就是與他們各自主要所屬的部門同仁，溝通與親和力有關的考量，並且在親和力部門定期（例如每週）舉行的會議上，互相交流各自部門的狀況、遭遇的問題、解決的方法等。

在例行會議中，除了促進各部門間對於親和力認知的互相熟悉外，還有一個重要的目的，是要弄清楚各部門對於親和力議題的體認程度為何。接著，再根據這些資料，規劃一系列的教育訓練。教育訓練應包含概念與實做細節，概念的課程可以同時針對所有的公司員工──包括各部門各級主管施行，因此宜短不宜長；實做細節的訓練則需要針對不同的部門予以客製化，以解決各部門實際會遭遇的問題為優先。在這個任務中，親和力部門主要扮演的身份是訓練課程的規劃者，而不需要是實際的授課者；儘管授課者可以外包，但是同仁對相關訓練的熱中程度、課後的反應及回饋、相關教材的統整與再利用、課程的安排與講者的溝通等，卻都是親和力部門得自己來的。

除了實體的課程外，在內部網路經營相關的知識庫，或者是舉辦定期的刊物等，其實也都是不錯的選擇。親和力是很活的東西，而且在日常使用中總是會不斷遇到相關的困難，所以親和力部門務必得鼓勵整間公司的同仁樂於分享、表達自己遭遇的情況，讓這個管道暢通了，纔有辦法落實親和力。

為公司所提供的產品或服務，發展親和力方針，並在技術上及經濟上可行的前提下，交由產品開發部門來負責實現這些方針。

第一個任務執行約三至六個月後，親和力部門就差不多能夠掌握公司整體對於親和力議題的敏感程度了。同時，此刻親和力部門也應該能掌握公司的目標、企圖、內部文化等屬性，所以應該要開始擬定公司內部的親和力方針。這個方針應該要以淺白、概括的方式撰寫，說明為什麼要這麼做、通用的程序、相關的其他規定或文件等，擬定完成後並由執行長頒佈施行；當第一份親和力方針訂定後，必然還會遭遇一些意料之外的狀況或反應，或者出現此方針無法處理的情境，因此接下來還應該要聽取同仁們的反應，將此方針予以修改、調整。

當親和力方針公布之後，包括教育訓練以及其他的相關任務，纔能夠有個依據；因此親和力方針應盡早制訂、發展。這個方針的制訂需慎重（所以我們會需要來自各個不同部門的同仁，一起來參與親和力部門），但是也不用吝於訂正──祇是每一次的訂正也都必須慎重，妥善製作相關文件，說明修改之處、前因後果等，務必顧及實際執行、使用這份方針的人（也就是所有的同仁）的感受，盡可能地協助大家度過這樣的過渡期。

在所有的部門當中，與此最為相關的部門，應該屬研發部門了。因為對於整個公司的親和力方針來說，最重要的就是讓製作產品的單位──研發部門──能夠把這些方針實現在產品上。這件事不能靠親和力部門來完成，因為掌握產品的並不是親和力部門，而是研發部門。也因此，在執行這項任務時，親和力部門與研發部門間的合作，就更為重要了。

在發展上述方針時，或者在產品或服務的設計及測試部門中，帶進實際有生理功能限制的人參與。

既然實際把親和力方針實現在產品上的是研發部門，那麼親和力部門究竟在這個階段能做些甚麼呢？

有一件值得做的事，就是在產品研發初期，就將有各種不同需求的使用者帶來實際參與──使用者經驗研究、焦點團體、深入訪談等都可以，這些資訊能夠協助研發部門預先避開一些錯誤。在選擇參與測試的人時，多找一些明顯有不同需求的人──像是有各種生理功能限制的人──尤其在初期更能獲得寶貴的資訊。

事實上，不僅是研發初期，稍後當產品處於推出前的測試階段時，也應該找類似的人再來做一次測試。這些互動的流程應該要根據前述的親和力方針加以標準化，而親和力部門應該謹記在心，要做這些事的目的是要協助公司、協助開發及測試團隊，而不是找麻煩或扯後腿；換句話說，溝通再溝通，以及提供真正有效的資源、解決方案，也是親和力部門必須要處理的。

在未來的產品開發及升級過程中，投注充分的產品開發及工程資源，以迅速地辨識並處理各種已知的親和力問題。

為了要協助開發及測試團隊，親和力部門也必須投注部分的資源在這個環節。確實，研發部門及測試部門纔是主角，但是這些部門也會有在親和力部門擔任職務的同仁，所以這就是個好的施力點。

這項任務的重點是藉由流程跟文件，來確保每一個遭遇到的問題都能清楚地留下痕跡──他們怎麼來、怎麼解決，都要有明確的描述與相關流程。而其他部門（例如客服部門）也能參與這個流程，將來自使用者回應的親和力議題，納入追蹤管理，將這些已知的議題加以處理。如果可以的話，不要把他們拖到下一個主要釋出版本，否則對使用者來說並不是個太親善的事。

藉由提供訓練、方針及技術解決方案等方法，讓開發社群能更輕易地建立具有親和力的產品或服務。

在上述的資源投入下，將能累積出豐富而有價值的親和力方針，以及與之相關聯的技術解決方案。在不透露公司機密的前提下，是可以試著把這些文件或細節予以公開的；尤其當公司產品或技術，有明確的相關開發者社群（例如開放源碼的軟體）時，這樣的公開將可以協助整個社群一起成長，最後公司仍然能從社群中受惠。

因為常見的問題也許人人都會遇到，但不見得人人都會去處理、或者能用最佳的方式來處理，但是一旦相關的議題被明確指出，並且提供可行的解法後，往往陸續就會有更多人提供更好的做法，或者整個社群有可能把某樣工具或組件予以改善，讓這些問題從一開始就能避免。這些對於公司日後要維護、更新產品時，都將能省下不少力氣。

針對產品及公開提供的服務，撰寫文件說明各項具親和力的設計。

不單是這些技術解決方案可以開放給社群，還有一種文件也相當重要，那就是針對各項產品及公開服務，說明各種親和力考量與設計。這樣的文件主要是給使用者看的，除了能夠協助使用者更融洽地使用各種產品外，也能夠幫助使用者更明確地看到他們自己的需求。日後如果需要改善產品或服務流程時，這樣的文件也能夠協助使用者把問題明確地指出。如果公司想要參與或經營使用者社群，這種文件也會是一個很好的開始點──還有甚麼會比明確表達「公司很重視使用者」還要更好的呢？

而且像這樣的文件，對於公司來說也是宣傳的材料。畢竟公司的確在親和力上投注了不少資源，要是沒有人注意到，就太可惜了。揭露這樣的文件，也能夠使相關同業、其他使用者感受到此一議題的重要性，而引起良性競爭，這對整個業界環境來說，將會是好事。

針對與產品或服務有關的親和力科技，支持贊助內部與外部（例如大學等學術單位）的研究發展，藉此提升最新的科技進展。

前面講了這麼多，包括參與開發者社群或使用者社群，好像都只有提到公司內部的事。但是親和力不可能祇靠公司內部就能做得很完善，因為還有太多未知的議題，以及尚無定論的爭議，而這些並不適合閉門造車地、一相情願地用試誤法來找出答案。以國內的情況來說，多數的公司養不起私有的、屬於自己的研究機構，來研究相關的理論及科技，但是我國的高等教育機構多如過江之鯽，其實也是個可行的合作方向。

親和力部門可以在學術界找到些固定合作的伙伴，支持贊助其研究計畫，讓親和力相關的研究進行下去。此舉不但可以協助公司獲知無法自行實施取得的研究資料，另外也能夠讓未來的員工──那些還沒出社會的在學學生──也能及早體認到親和力議題的重要性。這對於兩方來說都是互蒙其利的。

支持邁向親和力的標準實做，例如像全球資訊網協會針對瀏覽器、網頁內容和編輯撰寫工具，所發展的一系列指導原則。

最後一個重要的任務，在優先順序上並不亞於前七項任務。因為全球資訊網協會多年來已經努力地在發展一系列親和力指導原則，而面對這些指導原則最好的方式並不是去跟他打對台，而是與之順應。如果公司發展了一套親和力解決方案，但是實做細節上卻與全球資訊網協會制訂的標準實做相違背，那麼日後一定會自食惡果；因為現今的網頁編輯軟體、瀏覽器、使用者代理等，莫不以全球資訊網協會的推薦標準為努力方向，公司的產品及服務也應該�