昨天半夜，把第五到第八章的稿件也交給出版社了，本書目前為止已經完成超過一半，今天一邊休養（最近重感冒，嗓子完全說不出話來，而且喉嚨都是痰，快要沒辦法呼吸了），一邊把 PDF 整理起來寄給有參加「尤達大師」贊助預購的朋友們。
我稍微計算了一下，目前一到八章已交出的書稿中，總共大約有十一萬七千字，一百九十七張圖，十一份資料表格，四十五段範例原始碼；我的工作目錄中，包含所有用到的範例檔案與圖片等，加起來也有足足 1G 了。
以上是目前的進度說明，我將今晚睡醒之後就會開始撰寫第九章的內容。
2008/12/12
2008/11/03
第三章完成了
稍早已經寄出第三章的稿件了，這一章跟前兩章差不多，都是一萬五千字上下，不過本章介紹了 20 種硬體、7 種軟體、4 種作業系統，總共用了 32 張圖片跟 7 份表格，應該相當精采喔。
圖片的部分，跟第二章一樣，用了不少來自 Flickr、採創用 CC 授權釋出的圖片，交稿的時候也順便去 ImageStamper 把這些授權資訊存證了。
目前的寫稿進度大約比先前的預估進度慢了一天左右，不過我都有排緩衝期，所以後面十三章的進度並不會被拖到纔對。
2008/10/24
2008/10/16
慶祝簽約擴大贊助活動
目前《網頁親和力》第一冊已經和學貫行銷簽約完成，預計 2009 年春天就會出版囉！
為了慶祝簽約完成，助寫贊助暨初回限定版預購活動也將截止日期設到 2009/02/28，並將開放網頁瀏覽版本，開放規則如下：
在活動期間內，如果「尤達大師」贊助方案人次累積達 10 位（目前有 4 位），或者是總贊助人次累積達 50 位（目前有 14 位），則選擇「尤達大師」贊助方案的前 20 位朋友，將獲得網頁存取帳號密碼，並憑此帳號密碼可隨時線上瀏覽各章節之最新進度（我通常每天都會遞交進度好幾次）；此帳號密碼並將持續有效，不會受到書本出版之影響。
機會只有一次，請不要錯過了喔！
另，由於學貫主要是做教科書市場的，因此本書將會是彩色印刷，內容也將大為修改，修改後的全書大綱如下：
- 序論
- 這本書要教甚麼
- 甚麼是網頁親和力
- 親和力為什麼重要
- 認識你的使用者
- 以使用者為重
- 尋找使用者
- 設定角色人格行為面貌
- 角色範例
- 輔助科技
- 軟體
- 硬體
- 網頁多媒體
- 多媒體的世界
- 單獨的媒體
- 互相映襯的媒體
- 同步化的多媒體
- 多媒體背景與裝飾
- 圖片與動態圖片
- 照片
- 繪圖
- 複雜圖片
- 動態圖片
- 幻燈片
- 圖片閃爍
- ASCII Art、顏文字與表情符號
- 影片與動畫
- 字幕
- 使用者代理與媒體播放程式
- QuickTime
- RealMedia
- Windows Media
- DivX
- SMIL
- 語音與聲音
- 播放控制
- 音量
- 音調
- 速度
- 訊噪比
- 停頓與提示
- 配置
- 方位
- Flash
- Flash 的親和力
- 流程控制
- 文字內容
- 程式介面
- Plugin 與 Applet
- 外掛模組
- 小應用程式
- 其他嵌入物件
- PDF
- PDF 的親和力
- 保全選項
- 內嵌物件
- 表單
- Office 文件
- 文件的親和力
- Microsoft Office
- OpenOffice.org
- DRM 與創用 CC
- 使用的權利
- DRM 的潛在影響
- 創用 CC 與 DRE
- 檢驗與標章
- 檢核清單
- 相關規範
- 親和力標章
- 總結
- 綜合演練
- 自我評估
- 附錄
2008/09/14
aDesigner 和 aiBrowser
幾個月前，我在找據說已消失一陣子了的 IBM Home Page Reader，雖然後來千方百計地終於取得了，但是對於史上第一個螢幕朗讀軟體／語音瀏覽器就這樣消失，不免感到有些遺憾；後起之秀如 JAWS 或 Window-Eyes 雖然功能強大，但是售價也是 IBM Home Page Reader 的十倍以上（IBM Home Page Reader 當初售價大約一百美元出頭，JAWS 專業版要將近一千一百美元，Window-Eyes 要將近九百美元──就連 60 天評估版的 Window-Eyes 也要約四十美元纔能取得），不論是對於有需要的使用者，或者是對於想弄一套來測試的網頁設計師來說，都是相當大的負擔，讓人不由得心灰意冷。
我在 IBM 的網站東翻西翻，想要蒐集幾年間遺落的碎片，結果有了意外的發現，那就是 aDesigner、aiBrowser 以及他們背後的偉大推手──
到了 2004 年至 2005 年間，她發現 IBM Home Page Reader 已經無法應付多變的網頁媒體，以及接下來三年即將迎向她的各種 Web 2.0 網站和 RIA (Rich Internet Application)，這也是 IBM Home Page Reader 功成身退的時候。
但是她跟 IBM 東京研究室並沒有停下腳步。在 2004 年，她做出了 aDesigner，這是一套給設計師的工具，跟其他既有的分析工具最不同之處，在於它能夠用非常視覺化的方式分析網頁並產生報表──這麼直觀有效率的分析工具，竟然是出自盲人之手！
事實上 aDesigner 並不止於網頁，它還能拿來分析開放文件格式 (OpenDocument Format) 的檔案，包括 ODT (OpenDocument Text)、ODS (OpenDocument Spreadsheet) 和 ODP (OpenDocument Presentation) 等，也能夠拿來分析 Flash 檔案，還有一般的圖形化介面 (GUI) 應用程式。換句話說，除了網頁設計師外，互動式多媒體設計師、一般的文件撰寫者，還有應用程式的開發者，通通都可以用 aDesigner 來評估文件或程式的親和力，評估的基準除了全球資訊網協會 (W3C) WCAG (Web Content Accessibility Guideline)、美國 508 公法 (Section 508 of the U.S. Rehabilitation Act)、日本工業標準 (Japan Industrial Standard, JIS) 與 IBM 親和力檢核清單外，還包括了分析 IA2 (IAccessibility2) 與微軟 MSAA (Microsoft Active Accessibility) 資訊的功能。
在 aDesigner 之後，她又做了 aiBrowser──IBM Accessibility Internet Browser for Multimedia，這可以算是 IBM Home Page Reader 的加強版，加強的重點在於讓使用者可以控制隨著網頁載入的各種多媒體物件，而不會受到干擾而失去焦點。更棒的是，aDesigner 和 aiBrowser 都是使用者可以免費下載使用的。
2007 年 12 月 4 日，她代表 IBM 把 aDesigner、aiBrowser 等程式的源碼帶到開放源碼社群，ACTF (Accessibility Tools Framework) 計畫於是誕生了，不論是對親和力的領域，或對開放源碼社群來說，都具有相當重要的意義。
看一看
原本我祇是想搜刮一些工具而已，但是除了 aDesigner 和 aiBrowser 這兩大收穫外，又發現了這些工具背後居然是這麼了不起的一個人，不禁讓我內心也感到熱血沸騰、慷慨激昂。
最後僅以
We can make the impossible possible by never giving up.
2008/09/13
淺談 aDesigner
「親和力」的專題一連介紹了一整年，或許有些讀者會覺得，「這些跟自由軟體有甚麼關係啊？」這關係可大了。本期讓我們先撇開還沒講完的設計花樣，先來看看一個叫 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 的讀者有所幫助，並且讓讀者們看到，親和力與自由軟體／開放源碼軟體社群結合的趨勢所在，也希望這些議題在未來都能有更多人關注、發展出更多更好的解決方案，讓自由軟體／開放源碼軟體更具親和力、更多人樂於使用。
附錄──相關參考資源：
2008/09/12
親和力的設計花樣──打造有力的首頁
「設計花樣」是我們在做各種設計時所使用的術語，前一期我們介紹了「多重導覽途徑」這個設計花樣，本期則讓我們來看看跟「首頁」有關的設計花樣。
每個網站都會有首頁，首頁就像報紙的頭版、雜誌的封面、公司的門面，要說一個網站給人的第一印象如何，首頁絕對是佔了相當重要的地位。當我們考慮網站親和力──這個網站是否能帶給訪客親切和善的感受──的時候，首頁自然也會是重要的指標。
前一期所提到的多重導覽途徑，自然是首頁所能運用的設計花樣，但是這還不夠，因為首頁往往是網站的主要入口，不但要能吸引訪客（如果連這一點都辦不到，又怎麼能說有親和力呢？），同時還要能在許多其他因素間取得平衡，包括像是商標識別、內容的安置等等。
說到吸引訪客，有不少人相信首頁的第一個可見範圍又尤其重要；第一個可見範圍的意思是說，當訪客用瀏覽器來到首頁時，在不捲動瀏覽器視窗的前提下，所能看到的局部。想像一下，當你在便利商店看到一疊疊的報紙，通常你不會看到完整的頭版，因為報紙的折法，所以你祇能看到頭版的上半部，對折線以下的部分得要把報紙攤開來了纔能看到；既然網站的首頁猶如報紙頭版，因此首頁的第一個可見範圍也就有了個來自報紙的說法，叫「折線以上」。當然，網頁不是報紙，瀏覽器沒有固定的尺寸，「折線」更不是在正中間把整個網頁平分為二，甚至可能會有左右分的垂直折線；如果訪客用的是螢幕朗讀軟體，或者是其他的「線性」瀏覽器，那麼折線可能會以更為抽象的形式存在，例如「第三十秒」或「第 1024 位元」之類的。
確實折線以上是首頁的第一印象，但是並沒有必要把整個首頁的各個部分都塞進那個空間；一般說來，祇要折線以上／以前的內容，能誘使訪客將瀏覽器視窗捲動到其他部分，也就功德圓滿了。在這個區域中，唯一非要有不可的，大概要屬網站商標吧。你可能會問，為什麼這會跟親和力有關？
因為商標是網站識別的重要依據，而明確的網站識別對使用經驗來說，可以塑造一致的觀感與信任。當訪客感受到自己身處同一個網站，對該網站的使用經驗、情感、信任就會接續傳承而跟著累積。當他們感受到這一點時，就會預期網站的設計哲學、服務條款、隱私權政策等的一致性，也就更能掌握整個網站──網站也就更具親和力了。
雖然商標背負著這麼艱鉅的任務，但是可也別顧著把商標做得又大又明顯，反而佔掉了所有的空間。人們是來網站完成某些目的的，而不是單純來欣賞你的商標設計；如果首頁是個斗大的商標，那麼你的確能建立鮮明的網站識別──人們將會記得你的網站使用不便，如此就跟親和力背道而馳了。
運用前一期所介紹的設計花樣，讓你的首頁跟其他網頁具有一致且合乎邏輯的網頁架構，做出容易使用的導覽工具，這些都是增進親和力的要旨。接著，別忘了網頁的主角是「內容」，所以在規劃了網頁架構、導覽工具後，還得對首頁的內容下點功夫。
首頁是網站的入口，不但要能吸引訪客，還要把他們帶往正確的方向，因此有些增進親和力的手段可以派得上用場。首先，首頁的內容應該要鮮明活潑，讓訪客感受到網頁的更新與生氣，如果這些內容帶有強烈的線索與暗示，就能讓訪客祇消簡短的篇幅，猜到網站的目的與內容，並且能藉此迅速地導覽到想去的網頁；另外，如果還能根據使用者提供客製化的首頁內容，就再好不過了，因為這樣子可以幫助訪客精簡例行公事，而專注於他們覺得重要的任務。
既然說到首頁內容應該要鮮明活潑，還有一個要點一定要強調一下，就是首頁不宜使用過多的內容，或過於花俏華麗的效果；因為首頁是入口，所以必須要確保初次來訪的訪客就算在相當受侷限的條件下，也能順利取得首頁內容。這裡並不是要禁止你把首頁打扮得漂漂亮亮的，而是要各位確保首頁不應該要花上幾分鐘纔能載入完畢，或者得安裝特殊的外掛程式纔能順利一窺其廬山真面貌。華麗、新潮、豐富的媒體內容，得在訪客願意期待的前提下，纔有出場的機會。
像這樣的設計花樣，看起來主要是在增進網站的可用性，不過同時也會增進網站的親和力，讓訪客感到自在，並且祇需較少的資訊就能完成目標。
前述的「首頁入口」要讓訪客能立即明白網站目的，這還需要另一個設計花樣，那就是「預先提示價值所在」。這個設計花樣所要解決的問題很直接：有太多網站讓人們無法一目了然，看不出網站到底是為什麼而存在著的。網站的首頁必須要建構網站價值、營造第一印象並提出承諾，這正是親和力所在，因為這麼一來，訪客將能在最短的時間內，知道自己為什麼要來這裡、來這裡能完成甚麼、可以期待甚麼。
要滿足這個設計花樣，基本上會需要：
- 一個具說服力的承諾
- 一項獨特的提案
- 易於迅速理解的文案、圖樣或媒體
等等，這三件事還必須結合在一塊兒。網站的提案──用來說明網站的價值所在──必須要強而有力，並以此建構出網站的獨特性；然後這樣的提案還得用易於迅速理解的簡短文字或簡潔圖片等形式，加以表達在首頁上。
舉例來說，愛印網的首頁映入眼簾的九個大字：挑產品、改造型、送到家，就充分說明了整個網站的目的，並且以俐落的風格，加深了「明天立刻為您寄出」的迅速處理印象。更棒的是這九個字還擔任了訪客操作流程的指示器，讓人們知道自己已經做了甚麼、正在做甚麼、接下來還會需要做甚麼。再看看 blogger.com 首頁：尚未登入的訪客，馬上就會看到相當簡潔有力的四組圖說，解釋了部落格到底是怎麼一回事、可以怎麼玩，接著提示祇需要三個步驟即可建立部落格。
這些設計都讓訪客能一眼明白這裡是在做甚麼的，並且能預期接下來會發生甚麼事，而樂於參與及使用。用我們一貫的說法來講，這般首頁大大地增加了整個網站的親和力。
最後讓我們再回顧一下本期所介紹的兩個設計花樣：
1. 首頁入口
脈絡背景：
- 任何類型的網站
所要處理的問題：
網站的首頁乃是多數訪客來訪的入口，因此必須要能吸引訪客，同時還要能在商標、導覽、內容及載入速度等許多不同因素間取得平衡。
相關外力影響：
- 建立網站識別與商標。
- 以正確的觀感營造正面的第一印象。
- 用內容吸引人。
- 盡可能提供客製化的內容。
- 在商標與導覽區佔據的位置間取得平衡。
- 創造易用的導覽工具。
- 提供強而有力的資訊線索。
- 提供一致且具邏輯的網頁佈局。
- 讓首頁能迅速載入。
其他可能會有相關的設計花樣：
預先提示價值所在、網站商標與識別、隱私權政策、個人化的內容、多重導覽途徑、導覽列、動作按鈕、內嵌的鏈結、較長的描述性鏈結標題、明顯的鏈結、頁面模版、格線佈局、折線以上、釐清第一印象、減少檔案數量、能迅速載入的圖片……。
2. 預先提示價值所在
脈絡背景：
- 網站入口
所要處理的問題：
人們往往無法初到某個網站時便能迅速得知其目的。
相關外力影響：
- 需求。
- 整合。
解決方案：
用易於迅速理解的簡短文字或簡潔圖片等形式，在首頁上強而有力地表達網站的價值，並以此建構出網站的獨特性。
其他可能會有相關的設計花樣：
網站商標與識別、釐清第一印象……。
首頁祇是個開始，別忘了網站的內容纔是主角。下一期我們將開始說明，關於撰寫及維護網頁內容時，有哪些與親和力相關的設計花樣。
2008/09/11
親和力的設計花樣──建立導覽框架
從這一期開始，我們要從「設計花樣」的角度開始，來探討網頁親和力的種種實做。
「設計花樣」是我們在做各種設計時所使用的術語，不管是在電腦程式、人機介面、網頁等設計領域，設計師們在溝通要有哪些功能、設計、裝置時，都會用這些「設計花樣」的名詞用來表達那些概念。「花樣」可以是一種模式、一種功能、一項裝置等概念，可以是某種影響整個網站的定位或規範，例如「個人部落格」或「網站商標與識別」，也可以是小範圍的實做如「目前位置指示符」、「動態按鈕」或「網站地圖」等。
藉由設計花樣，設計師們可以便於釐清設計概念、情境，發掘設計障礙或困難，並找出合宜的設計方案。一般來說，當我們在描述一種設計花樣時，除了這個花樣本身的名字外，還會去描述其產生的脈絡背景、所要處理的問題、各種作用在該花樣上的外力影響、解決方案、以及其他可能會有相關的設計花樣。
運用設計花樣來溝通，可以讓設計師們不侷限於技術細節，同時又保有高度的靈活；當我們討論設計花樣時，並不是要給你甚麼成功網站非有不可的「甜蜜點」──真的做過設計的朋友就會知道沒有那種東西存在，隨著時間以及使用族群的演變，許多設計花樣也會跟著演變、消失或出現；經典的設計花樣會持續較久，但並非全然無可取代，另外某些設計花樣則可能僅適用於特定的情境或前提，或者與某些設計花樣一定要共存，但跟其他某些設計花樣互斥。不論是做程式設計或網站設計，見樹不見林或見林不見樹都是致命傷；如果用設計花樣來當作中介橋樑，就不會迷失在多變的設計之中，也將更能靈巧地面對未來的變化。
做為這個子系列的開頭，我們要先從跟「建立導覽框架」有關的親和力設計花樣開始。「導覽」是現代網站首要面對的挑戰之一，因為沒有人能夠預期讀者會從甚麼地方進入你的網站──有可能是從首頁，也有可能是部落格上的某一篇回應；如何建立一個導覽框架，讓讀者不管從哪邊開始，都能夠掌握整個網站的內容，這不但是個親和力議題，也關係著網站的可用性。
跟「建立導覽框架」有關的設計花樣並不少，囿於篇幅關係，在此我們祇先討論一個跟親和力尤其有關的，叫「多重導覽途徑」的設計花樣。基本上不論是哪一種網站，小自個人部落格，大至複雜的電子商務網站，都會需要這個花樣；因為不論是哪一種網站的訪客，都會用各自偏好的方式來瀏覽整個網站，如果有任何關鍵的導覽工具──例如導覽列或導覽側欄等──在某些頁面難以尋得甚至消失不見，那麼訪客們勢必會覺得網站本身難以使用。
更進一步來看，其實訪客們各自的「偏好」取決於他們的意圖跟衝動，也就是理智的目的以及感性的需求；如果網站缺少了意圖性的導覽工具，那麼訪客們會覺得網站的安排很詭異、很沒道理，反之若網站缺少了衝動性的導覽工具，則會變得枯燥乏味。不論是哪一種導覽工具，還要注意不同動機的訪客，也會有其所偏好的導覽風格──例如「搜尋」、「瀏覽」、「下一步」、「精靈」、「關聯」、「推薦」等，都是不同的導覽風格，也都有各自適用的導覽工具。
如果用來實現各種導覽風格的工具被任意安置，那麼訪客也許就無法從中獲得好處──他們根本不會去用！這些導覽工具需要被放在訪客們找得到而且也會去用的位置，這些也是「多重導覽途徑」這個設計花樣所要面對的問題。
解決的方法其實很明顯，也就是任何網站都應該要具備多種不同的導覽途徑，同時滿足意圖型的訪客與衝動型的訪客，而且這些導覽工具的安置應該要有其規律及一致性──運用「頁面模版」及「格線佈局」等設計花樣，將能讓多重導覽途徑兼具理性與感性。
為了讓各種訪客都能完成其來訪目的，通常我們會把搜尋工具及主要的瀏覽型導覽介面放在網頁的一開頭、最上面的位置；如果有需要用到「下一步」這類精靈風格的導覽工具，例如商務網站的結帳流程，則可以同時把他們放在頁面的上方及下方，最後別忘了盡可能加上關聯型的導覽工具，例如相關或推薦的產品／文章，滿足訪客的衝動需求；這些關聯型的導覽工具可以放在網頁文件較後端的位置，纔不會搶走主要內容的風采。
讓我們最後再來整理一下「多重導覽途徑」這個設計花樣：
脈絡背景：
- 任何類型的網站。
所要處理的問題：
- 訪客會用各種方式瀏覽整個網站，如果有任何關鍵的導覽工具難以尋得甚至消失不見，那麼訪客們勢必會覺得網站本身難以使用。
相關外力影響：
- 瀏覽網站的方式取決於訪客的意圖跟衝動。
- 不同動機的訪客，會需要不同的導覽風格。
解決方案：
- 導覽工具需被放置在訪客們找得到而且也會去用的位置。
其他可能會有相關的設計花樣：
頁面模版、具鑑別力的 HTML 標題、網站商標與識別、格線佈局、一致的相關資訊側邊欄、單一瀏覽繼承性、導覽列、頁籤列、目前位置指示符、有意義的錯誤訊息、找不到的網頁、靜態鏈結、跳過選單、網站地圖……。
上述的這個設計花樣，除了適用於任何網站外，同樣地也適用於各種圖形介面的應用程式設計。至於最後所提到的這一堆相關設計花樣，未來我們也會逐一加以說明。
2008/09/10
親和力部門的八項重要任務
在前一期當中，我們提到了親和力部門在執行長的授權下，有八項重要的任務要執行；在本期當中，就讓我們來一一細看，這些任務應該要怎麼進行。
在公司內部提高對親和力議題的體認，並提供員工們設計具親和力的產品或服務所需的相關訓練。
親和力部門的理想成員，是要由整個公司各個部門的人員所兼任的，這些兼任親和力部門成員的人，就是提高公司對親和力體認的重要種子，也因此他們在親和力部門的「兼職」，必須要有執行長的認可，而不會影響到他們原本工作崗位的考績，或者增加他們的業務負擔；這些成員平日的重要工作之一，就是與他們各自主要所屬的部門同仁，溝通與親和力有關的考量，並且在親和力部門定期（例如每週）舉行的會議上，互相交流各自部門的狀況、遭遇的問題、解決的方法等。
在例行會議中，除了促進各部門間對於親和力認知的互相熟悉外，還有一個重要的目的，是要弄清楚各部門對於親和力議題的體認程度為何。接著，再根據這些資料，規劃一系列的教育訓練。教育訓練應包含概念與實做細節，概念的課程可以同時針對所有的公司員工──包括各部門各級主管施行，因此宜短不宜長；實做細節的訓練則需要針對不同的部門予以客製化，以解決各部門實際會遭遇的問題為優先。在這個任務中，親和力部門主要扮演的身份是訓練課程的規劃者，而不需要是實際的授課者；儘管授課者可以外包，但是同仁對相關訓練的熱中程度、課後的反應及回饋、相關教材的統整與再利用、課程的安排與講者的溝通等，卻都是親和力部門得自己來的。
除了實體的課程外，在內部網路經營相關的知識庫，或者是舉辦定期的刊物等，其實也都是不錯的選擇。親和力是很活的東西，而且在日常使用中總是會不斷遇到相關的困難，所以親和力部門務必得鼓勵整間公司的同仁樂於分享、表達自己遭遇的情況，讓這個管道暢通了，纔有辦法落實親和力。
為公司所提供的產品或服務，發展親和力方針，並在技術上及經濟上可行的前提下，交由產品開發部門來負責實現這些方針。
第一個任務執行約三至六個月後，親和力部門就差不多能夠掌握公司整體對於親和力議題的敏感程度了。同時，此刻親和力部門也應該能掌握公司的目標、企圖、內部文化等屬性，所以應該要開始擬定公司內部的親和力方針。這個方針應該要以淺白、概括的方式撰寫，說明為什麼要這麼做、通用的程序、相關的其他規定或文件等，擬定完成後並由執行長頒佈施行；當第一份親和力方針訂定後，必然還會遭遇一些意料之外的狀況或反應，或者出現此方針無法處理的情境，因此接下來還應該要聽取同仁們的反應，將此方針予以修改、調整。
當親和力方針公布之後，包括教育訓練以及其他的相關任務，纔能夠有個依據；因此親和力方針應盡早制訂、發展。這個方針的制訂需慎重（所以我們會需要來自各個不同部門的同仁，一起來參與親和力部門），但是也不用吝於訂正──祇是每一次的訂正也都必須慎重，妥善製作相關文件，說明修改之處、前因後果等，務必顧及實際執行、使用這份方針的人（也就是所有的同仁）的感受，盡可能地協助大家度過這樣的過渡期。
在所有的部門當中，與此最為相關的部門，應該屬研發部門了。因為對於整個公司的親和力方針來說，最重要的就是讓製作產品的單位──研發部門──能夠把這些方針實現在產品上。這件事不能靠親和力部門來完成，因為掌握產品的並不是親和力部門，而是研發部門。也因此，在執行這項任務時，親和力部門與研發部門間的合作，就更為重要了。
在發展上述方針時，或者在產品或服務的設計及測試部門中，帶進實際有生理功能限制的人參與。
既然實際把親和力方針實現在產品上的是研發部門，那麼親和力部門究竟在這個階段能做些甚麼呢？
有一件值得做的事，就是在產品研發初期，就將有各種不同需求的使用者帶來實際參與──使用者經驗研究、焦點團體、深入訪談等都可以，這些資訊能夠協助研發部門預先避開一些錯誤。在選擇參與測試的人時，多找一些明顯有不同需求的人──像是有各種生理功能限制的人──尤其在初期更能獲得寶貴的資訊。
事實上，不僅是研發初期，稍後當產品處於推出前的測試階段時，也應該找類似的人再來做一次測試。這些互動的流程應該要根據前述的親和力方針加以標準化，而親和力部門應該謹記在心，要做這些事的目的是要協助公司、協助開發及測試團隊，而不是找麻煩或扯後腿；換句話說，溝通再溝通，以及提供真正有效的資源、解決方案，也是親和力部門必須要處理的。
在未來的產品開發及升級過程中，投注充分的產品開發及工程資源，以迅速地辨識並處理各種已知的親和力問題。
為了要協助開發及測試團隊，親和力部門也必須投注部分的資源在這個環節。確實，研發部門及測試部門纔是主角，但是這些部門也會有在親和力部門擔任職務的同仁，所以這就是個好的施力點。
這項任務的重點是藉由流程跟文件，來確保每一個遭遇到的問題都能清楚地留下痕跡──他們怎麼來、怎麼解決，都要有明確的描述與相關流程。而其他部門（例如客服部門）也能參與這個流程，將來自使用者回應的親和力議題，納入追蹤管理，將這些已知的議題加以處理。如果可以的話，不要把他們拖到下一個主要釋出版本，否則對使用者來說並不是個太親善的事。
藉由提供訓練、方針及技術解決方案等方法，讓開發社群能更輕易地建立具有親和力的產品或服務。
在上述的資源投入下，將能累積出豐富而有價值的親和力方針，以及與之相關聯的技術解決方案。在不透露公司機密的前提下，是可以試著把這些文件或細節予以公開的；尤其當公司產品或技術，有明確的相關開發者社群（例如開放源碼的軟體）時，這樣的公開將可以協助整個社群一起成長，最後公司仍然能從社群中受惠。
因為常見的問題也許人人都會遇到，但不見得人人都會去處理、或者能用最佳的方式來處理，但是一旦相關的議題被明確指出，並且提供可行的解法後，往往陸續就會有更多人提供更好的做法，或者整個社群有可能把某樣工具或組件予以改善，讓這些問題從一開始就能避免。這些對於公司日後要維護、更新產品時，都將能省下不少力氣。
針對產品及公開提供的服務，撰寫文件說明各項具親和力的設計。
不單是這些技術解決方案可以開放給社群，還有一種文件也相當重要，那就是針對各項產品及公開服務，說明各種親和力考量與設計。這樣的文件主要是給使用者看的，除了能夠協助使用者更融洽地使用各種產品外，也能夠幫助使用者更明確地看到他們自己的需求。日後如果需要改善產品或服務流程時，這樣的文件也能夠協助使用者把問題明確地指出。如果公司想要參與或經營使用者社群，這種文件也會是一個很好的開始點──還有甚麼會比明確表達「公司很重視使用者」還要更好的呢？
而且像這樣的文件，對於公司來說也是宣傳的材料。畢竟公司的確在親和力上投注了不少資源，要是沒有人注意到，就太可惜了。揭露這樣的文件，也能夠使相關同業、其他使用者感受到此一議題的重要性，而引起良性競爭，這對整個業界環境來說，將會是好事。
針對與產品或服務有關的親和力科技，支持贊助內部與外部（例如大學等學術單位）的研究發展，藉此提升最新的科技進展。
前面講了這麼多，包括參與開發者社群或使用者社群，好像都只有提到公司內部的事。但是親和力不可能祇靠公司內部就能做得很完善，因為還有太多未知的議題，以及尚無定論的爭議，而這些並不適合閉門造車地、一相情願地用試誤法來找出答案。以國內的情況來說，多數的公司養不起私有的、屬於自己的研究機構，來研究相關的理論及科技，但是我國的高等教育機構多如過江之鯽，其實也是個可行的合作方向。
親和力部門可以在學術界找到些固定合作的伙伴，支持贊助其研究計畫，讓親和力相關的研究進行下去。此舉不但可以協助公司獲知無法自行實施取得的研究資料，另外也能夠讓未來的員工──那些還沒出社會的在學學生──也能及早體認到親和力議題的重要性。這對於兩方來說都是互蒙其利的。
支持邁向親和力的標準實做，例如像全球資訊網協會針對瀏覽器、網頁內容和編輯撰寫工具，所發展的一系列指導原則。
最後一個重要的任務，在優先順序上並不亞於前七項任務。因為全球資訊網協會多年來已經努力地在發展一系列親和力指導原則，而面對這些指導原則最好的方式並不是去跟他打對台，而是與之順應。如果公司發展了一套親和力解決方案，但是實做細節上卻與全球資訊網協會制訂的標準實做相違背，那麼日後一定會自食惡果；因為現今的網頁編輯軟體、瀏覽器、使用者代理等，莫不以全球資訊網協會的推薦標準為努力方向，公司的產品及服務也應該要這樣。
另一方面，全球資訊網協會的推薦標準，可以說是在泛用性及細節上都有著最嚴格的要求，所以很適合作為公司制訂自己的親和力政策或者是發展技術實務細節時，相當好的參考依據。當然這些推薦標準的目的之一是要維持泛用性，所以有哪些應該要採納、哪些可以不處理，這也會是親和力部門的工作之一。
在做這件事時還有個風險，就是有一些細節可能在評估之時沒有需求，但是隨著公司產品、服務的演變，日後還是有可能會再度變得重要。另外即使是全球資訊網協會，也在不斷地改善其推薦標準；WCAG 1.0 到 2.0 版間，包括整個指導原則的哲學、架構、內容都變得很不一樣，這個時候公司應該要如何順應？這也是親和力部門需要處理的任務。
花了這麼多篇幅解釋親和力部門，但是要在這個專欄中提供一份像食譜一樣的步驟，讓各間公司成立這樣的部門，是不可能的。因為所有的親和力考量都是要因人制宜的──每間公司內部的文化、組織架構不同，面臨的使用者族群不同，就要採取不同的做法。「沒有一套至高無上、一定不會錯的辦法」正是親和力的重要精神之一，唯有實際地去為每個關係人設想，才能訂出好的、正確的辦法與方針。
由於這個主題將越來越抽象，所以在這個專欄中，接下來我們就要回歸到現實面，開始深入研究，每個不同的領域中，有哪些跟親和力有關的技術實做細節。
2008/09/02
進度說明
關心本書進度的朋友，一定注意到了，好像七月底跟八月底都要有新的章節進度的，怎麼沒有消息呢？
事情是這樣的。原來在撰寫的第一冊第五章，內容比較生硬，花了許多時間──而就在快要完成之際，有一間出版社前來洽談這本書的出版事宜。在與這間出版社討論過後，本書有了新的出版可能，不但在編排上可以有更多彈性，冊數上也可望增加，從兩冊變成三冊。
為了因應這樣的變動，本書的章節編排也將有大幅變動，有些內容會拆散到許多章節內，有些原本之後纔要寫的內容會提早寫，有些內容可能會變成附錄，有些內容則可能會刪除。
我這陣子在處理，就是這個內容的重新編排與調整，因此原訂的進度也將打散重來。不過別擔心，推動、贊助本書實現的朋友們，一旦有新的章節完成，那怕是重新編排過的，該交付到各位手上的仍然會交付。
就請各位朋友稍加等待一番，一旦有新的進度，或者在出版洽談上有確定的決定後，我也都會盡快公布於此部落格。
事情是這樣的。原來在撰寫的第一冊第五章，內容比較生硬，花了許多時間──而就在快要完成之際，有一間出版社前來洽談這本書的出版事宜。在與這間出版社討論過後，本書有了新的出版可能，不但在編排上可以有更多彈性，冊數上也可望增加，從兩冊變成三冊。
為了因應這樣的變動，本書的章節編排也將有大幅變動，有些內容會拆散到許多章節內，有些原本之後纔要寫的內容會提早寫，有些內容可能會變成附錄，有些內容則可能會刪除。
我這陣子在處理，就是這個內容的重新編排與調整，因此原訂的進度也將打散重來。不過別擔心，推動、贊助本書實現的朋友們，一旦有新的章節完成，那怕是重新編排過的，該交付到各位手上的仍然會交付。
就請各位朋友稍加等待一番，一旦有新的進度，或者在出版洽談上有確定的決定後，我也都會盡快公布於此部落格。
2008/06/24
色彩對比分析
配色是一門大學問，在網頁設計的世界中又比其他藝術創作更是如此；因為不當的對比，可能會讓妳的網頁一塌糊塗。
今年年初，我把新版的色彩對比分析程式帶進台灣（Windows 版跟 Mac 版都有），這可以稍微解決這個問題──妳可以用這個程式，挑選妳中意的配色，看看其對比是否理想。但是，萬一怎麼配都不理想，要怎麼辦？一個個慢慢試嗎？
Joe Dolson 用 PHP 做了一個線上服務，叫「色彩對比檢測程式」，能一口氣檢測上千種不同的色彩搭配，這樣就能更快找出恰當的色彩了吧。這個線上服務一樣由我中文化了，所以請盡情使用吧！
2008/06/06
第一冊第四章（提供 PDF 試讀）
第四章撰寫進度大幅超前，六月上旬都還沒過呢，就已經寫完，共約一萬四千七百字，PDF 也已經寄給參與贊助方案的朋友們囉。
由於受到請求，所以這一章也放出來給大家試讀：book01chap04-sample.pdf；如果你覺得這樣的內容還不錯、值得期待的話，別錯過現正熱烈舉辦中的贊助暨預購方案喔！這一章實際寫出來的內容目錄如下：
- 設計原理
- 檢測方式
- 檢測程序
- 優先等級
- 規範內容
- 原則一
- 規範一
- 規範二
- 規範四
- 規範七
- 規範十四
- 原則二
- 規範二
- 規範三
- 規範五
- 原則三
- 規範六
- 規範八
- 規範九
- 規範十
- 規範十一
- 原則四
- 規範十二
- 規範十三
- 原則一
- 瑕疵與建議
- 遭遇的問題
- 衝突
- 漏洞
- 翻譯謬誤
- 未妥善本地化
- 過於侷限在 HTML
- 前瞻性不足
- 應對之道
- 未來的改善建議
- 遭遇的問題
- 結語
2008/05/29
2008/05/01
第一冊第二章……
這星期在一邊辛苦地上下班中，很振作地把第一冊第二章完成了，不過因為一些技術上的問題，所以要等到週末纔有空做成 PDF 寄給參與贊助方案的朋友們，就請各位稍候啦！
這一章就跟第一冊第一章一樣，實際寫出來的東西比原本預期的還要更多更廣；實際寫出來的約有一萬五千五百字，內容目錄如下：
- 法律基礎
- 身心障礙者權益保障法
- 豐富身心障礙者文化及精神生活實施辦法
- 國際法規
- 全球資訊網協會
- 網頁內容親和力方針（WCAG）
- 編撰工具親和力方針（ATAG）
- 使用者代理親和力方針（UAAG）
- 具親和力的 RIA（WAI-ARIA）
- 評估及報告語言（EARL）
- 國際標準組織
- ISO 9241
- ISO 16071
- ISO 18019
- 全球資訊網協會
- 研考會規範
- 無障礙網頁開發規範
- 其他各國法規
- 比利時
- 巴西
- 葡萄牙
- 美國
- 歐盟
- 法國
- 芬蘭
- 德國
- 丹麥
- 泰國
- 紐西蘭
- 挪威
- 盧森堡
- 荷蘭
- 韓國
- 加拿大
- 西班牙
- 新加坡
- 香港
- 日本
- 瑞典
- 瑞士
- 以色列
- 義大利
- 印度
- 英國
- 愛爾蘭
- 奧地利
- 澳大利亞
- 結語
2008/04/16
網頁親和力工具列 2.0 繁體中文版文件
先前有提到網頁親和力工具列 2.0 繁體中文版，剛剛我把它的兩份文件都翻譯完了，請參考：
接下來有空的時候，還會再把 Opera 版的網頁親和力工具列也處理一下。
2008/04/02
助寫贊助暨初回限定版預購──現在接受 PayPal 了！
如果您因為任何原因，不便轉帳的話，也可以透過 PayPal 來贊助。請使用下列按鈕，將想選用的贊助方案放進 PayPal 購物車，再結帳付款：
四種贊助方案的說明，請見活動網頁。
請注意：使用 PayPal 贊助時會採歐元計價，並預先算入各種手續費成本等。如果您因故未完成結帳，亦可用下列的按鈕來檢視、更新您的 PayPal 購物車：
2008/04/01
《網頁親和力》助寫贊助暨初回限定版預購
《網頁親和力》一書已經撰寫幾個月了，但仍遲遲未能完成印行出版，因此在 hlb 的建議下，有了這麼一個活動，用實質的行動逼迫我盡早完成書籍。
這個活動背後的邏輯很簡單：因為我實在是個過於善良、誠懇、老實的傢伙，所以如果有人（那怕只有一個人）已經付錢預購／贊助了的話，說甚麼我也會拼死拼活地把書趕完。
當然，既然是叫「初回限定版」，我特別準備了一些「限定特典」給預購／贊助的朋友（也有人說這應該叫「完全預約生產」……），詳細的細節及辦法請見活動網頁：http://registrano.com/events/accessibility01
最後要補充說明一下：雖然今天是 4/1，但是我對這件事絕對是極為嚴肅認真以待的。（事實上這個活動的開始日期是 3/31，因為我花了些時間撰寫活動網頁的說明，才會拖到 4/1 凌晨……）
這個活動背後的邏輯很簡單：因為我實在是個過於善良、誠懇、老實的傢伙，所以如果有人（那怕只有一個人）已經付錢預購／贊助了的話，說甚麼我也會拼死拼活地把書趕完。
當然，既然是叫「初回限定版」，我特別準備了一些「限定特典」給預購／贊助的朋友（也有人說這應該叫「完全預約生產」……），詳細的細節及辦法請見活動網頁：http://registrano.com/events/accessibility01
最後要補充說明一下：雖然今天是 4/1，但是我對這件事絕對是極為嚴肅認真以待的。（事實上這個活動的開始日期是 3/31，因為我花了些時間撰寫活動網頁的說明，才會拖到 4/1 凌晨……）
2008/03/22
網頁親和力工具列 2.0 繁體中文版
網頁親和力工具列 2.0 版跟色彩對比分析程式 2.0 版都已經釋出好一段時間了，一直到最近終於抽出空來，做了繁體中文版。
有需要的朋友可以到（同樣是我翻譯的）中文網頁下載這兩個好用的小工具：網頁親和力工具列 2.0 繁體中文版（內含色彩對比分析程式 2.0 繁體中文版，但是這個也可以單獨下載免安裝的版本）。
這項資訊亦已刊登於 The Paciello Group Blog 以及 Web Accessibility Toolbar Blog 上。
色彩對比分析程式其實還有 Mac 版，我已經把相關的翻譯送回去了，但是開發者的 Mac 爛掉送修中，得要等一段時間纔會有辦法編譯含繁體中文的版本出來，屆時我也會放到中文網頁上。另外網頁親和力工具列也還有 Opera 版，這個我有空也會做中文化。
中文化的網頁中，除了上述工具的下載及說明頁面外，還有一些比較詳盡的文件，我也一樣會抽空來翻譯，敬請期待。
訂閱：
文章 (Atom)