「親和力」的專題一連介紹了一整年，或許有些讀者會覺得，「這些跟自由軟體有甚麼關係啊？」這關係可大了。本期讓我們先撇開還沒講完的設計花樣，先來看看一個叫 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