拜讀 David Richards 在 Gnome Boston Summit 2008 的 User Experience Hackfest 所發表的簡報，這份簡報分享了在 Florida 的 Largo 市政府 佈署了五百多台 Debian, Gnome 為基礎的 Thin Clients, 作為政府員工的工作環境。這個系統大約有七百位使用者，平均上線約 300 人。
簡報中概要描述了一些架構與技術細節，像是 Thin Clients 的基礎建設是以 NoMachine 為基礎等，詳情請參考其簡報。論述中提到政府部門的需求，以及從數百名使用者中所習得的關於可用性的經驗。私認為相當值得參考，許多開發者認為簡易方便的功能，對於一般使用者 (average user) 而言可能毫無頭緒。
這裡僅節錄我認為特別有趣的事項，這些是對這群使用者而言可行的軟體設計。

設計一 MIME Helper Bars (Intermediate MIME bar)，因為使用者常不知該將檔案置於何處，或是該如何開啟、列印、儲存到桌面或文件夾或編輯。於是 Helper bar 的功能是幫使用者決定預設存在哪裡，或直接列印或寄出郵件，而不需要先開啟 OpenOffice, Evolution 再開啟檔案。
立方體多重視窗。使用者往往不知道該怎麼利用預設的 workspaces 設計，反而透過立體視覺作桌面切換，可以看到自己的軟體視窗浮在不同的桌面上，相較直覺。
單層軟體選單。樹狀選單基本上是行不通的，使用者找不到得點選超過兩次的項目。
透明視窗，讓使用者看到全部的視窗。
詢問對話框 (dialog)。許多軟體設計，會用對話框詢問使用者問題，像是「你是否要寄出此郵件？」等，但這種對話框是浮動的。也就是若你同時開了許多軟體，對話框很容易就被其他視窗蓋住，按掉對話框前原本郵件編輯器就無法使用，這點十分令人困惑。比較好的設計是點選編輯器時，應優先叫出蓋在上面的對話框，或改以其他對話框設計，如嵌入原編輯器中。
以電子郵件寄出功能。這是最常用得功能，可是卻藏在選單或只是一個小按鈕。
自動轉檔後用電子郵件寄出。雖用 OO.o 但是有時寄出文件仍需 PDF or Microsoft Office [...]

昨日晚去 Tossug 聽 Chrome OS 團隊的Google 工程師談偉航介紹 Chromium OS，ericsk 前輩對此聚會寫了演講摘要紀錄。演講的內容大約不外乎推廣 Chrome OS 設計理念，也就是「快速」、「簡單」、「安全」。
關於這個演講，我自己所見的疑問之一，是使用者資料安全的問題。雖說 Google 倡議其設計會將個人資料加密後存於本機，既使實體電腦遺失也不用擔心資料被竊走 (所謂豔照門 ?)，但其資料是會存至雲端系統，功能是讓你在不同的機器上同步個人資料與設定。不過目前網路上還沒有文件或技術規格說明其如何儲存個人資料，而個人資料的可儲存空間收費方式也是一個待議的問題。
作為一個使用者，我實在不希望任何的設定或文件以明碼的方式存於 Google，這家公司已經掌握太多個人資料了。一些使用者願意使用像是 Google Desktop 之類可以帶來一些便利的工具，但實質上是自願拿個人隱私與獨大公司交換便利性。這個代價實在太大了一點。
查了一下目前版本的 cryptohome 設計是預設以一動態金鑰對加目錄作 aes-cbc-essiv:sha256 加密。因整合一 pam_google 模組，各帳號登入時會自動掛載，並獨立加密。至於資料傳到雲端的部份，目前尚不知其如何作。
Native Client
另外一議題，似乎還沒有多少人重視，但我仍期待的是 Native Client。在當代的作業系統上，即便你有超過一半以上的時間可能都只是發發信件、瀏覽網站、上上社交網站，但是還是有許多使用者期待良好的影音效果或遊戲。雖說現在有各家利用 JIT 技術激烈激烈的 ECMA Script (Java Script) Engine，再配合 HTML5 已經可以作相當多應用。不過這種系統介面無法滿足想用盡每一個處理器指令集的多媒體解碼器或遊戲製造商，而且這些軟體開發者手上都已經有不少 code base，他們會希望可以移植，而不是從頭開發。
所以最好還是在系統上挖一個洞，讓開發者可以在瀏覽器上用盡所有硬體資源。業界的一個實做方式是 Microsoft 的 ActiveX，基本概念上就是讓你可以存取作業系統上的各種軟體元件。但是其安全機制一是透過數位簽章 (digital signing) 確保安裝檔未被竄改，一則是詢問使用者是否允許安裝。而這種模式輕易的讓許多麻瓜的電腦上種滿了木馬。
其中一個選擇是使用 NPAPI 的 Plugin. 雖說現在 Chrome Browser 已經開放了 NPAPI [...]

若想利用 HTML 5 開發一些多媒體程式的網站，你大概會需要一個本地檔案處理的 API 來儲存影片、圖檔等。同時你大概也會希望創作一種類似桌面系統的使用經驗，讓使用者可以直接從原生作業系統拖拉檔案到你的 Web Apps 中。而檔案塞進網頁程式後，又可以製作成縮圖，讓使用者透過網頁介面進行管理。
這些功能在 Google Gears 0.5.21.0 皆已經實做，包含了支援 Bolb, Blob Builder、Drag & Drop support 與 Image thumbnailing。
除了 Google Gears 的實做以外，其實從 Gecko 1.9.2 後在 Firefox 3.6 與 Fennec 1.0 也支援了這些直接利用 Java Script 進行檔案處理的功能。於是你可以利用 Java Script 刻一個的檔案瀏覽器工具，拿 FileList 來接受使用者拖拉進瀏覽器或自選的檔案列表，用 FileReader 作一些簡單的處理，像是把圖片丟進 Canvas 讓使用者改一改後，再傳到網路上伺服器存放等。依據安全性考量，你自然不能直接拿 File Reader 來讀系統檔案，File Reader 的參數都必須是使用者自行選擇帶入的 File 型別才可以。如此便可避免拿 Java [...]

關於 Web Typography。過去，你若想讓網頁上出現多樣性的字型與排版，往往得將文字作成圖片或 Flash 來顯示。如此一來常常使網頁失去文字複製、搜尋引擎最佳化 (SEO) 的功能，一個網頁製作再精美，但卻沒有人可找來閱讀的話，也是徒勞無用的。
於是你想使用瀏覽器預設的功能，但又不想屈就於有限的作業系統內建字型，這該怎麼辦？你或許會利用像是 sIFR, FLIR, Typeface.js 或 Cufón 等替代方案。
以 sIFR (Scalable Inman Flash Replacement) 來講，sIFR 是利用 Java Script 與 Flash 動態的替換瀏覽器上的文字，字型則來自網頁設計者預先從系統中設定欲使用的字型於 Flash 中。
而 Cufón 概念亦差不多，不過作法是先將字型外型轉成 Java Script/JSON 格式，實際使用時再利用 HTML5 Canvas 繪出字型。Cufón 的作法所生成的 Java Script 雖比所用的 Truetype 字型小，但其實檔案大小也頗大，BCSEEATI 試驗了一分割字型方式，可有效降低傳輸量，但需把字型計算工作轉移到伺服器端。
Cufón 的一項缺點是，用了 Canvas 來繪圖，結果造成使用者無法點選文字。關於這個問題，TypeSelect 與 Typeface.js 用 span tag 解決的選字的問題。這些作法都頗討厭，因為你要求瀏覽器為了美觀顯示，多做了圖形運算或重複塞了一圖一字就為了美觀跟可選字。
若是可以讓瀏覽器直接依字型繪字不是很好嗎？在 Firefox 3.5 (Gecko 1.9.1) [...]

最近已經不太貢獻時間到 Debian 計畫中，雖然日常工作、辦事還是全部使用 Debian GNU/Linux。做的比較多的大概是幫忙踩地雷，跟偶爾回報一些自己常用軟體的小問題。
相較於商業軟體軟體，在自由軟體或開放原碼社群，最棒的使用經驗就是如果你碰到了甚麼問題，而且你描述得當的話，通常有機會得到開發者的注意與修正。但是你得「描述正確」。作為一個嘴砲開發者，我不甚喜歡收到毫無意義的回饋，過度熱情的回報人往往造成小開發團隊的極大困擾，數量跟質量往往成反比，而低質量的大量回報只會降低團隊士氣跟產能。如果可以的話，我希望可以收到許多高質量的回饋，也期許自己盡力這麼作。
這裡不談基本的回報問題的方式，你若用 Debian 請參考 How to report a bug in Debian using reportbug 或 reportbug-ng，使用 Ubuntu 請參考 ReportingBugs。你若是新手，在你回報問題之前應該先讀 Simon Tatham 的如何有效地報告錯誤。這篇文章提供了一些基本的原則，你若碰到軟體使用的問題，應該試著按照文中的原則跟軟體開發者對話，可以避免殺死太多開發者的腦細胞，也可以幫你快點解決問題。
在先進的軟體中，不少已經內建 Crash reporter，像是 Gnome 的 Bug Buddy、Mozilla 的 Breakpad、Ubuntu 的 Apport 等等，這些工具會在你的軟體當掉時，自動收集一些系統資訊與程式狀態，並回報、收集到中央系統。這些資訊可以協助開發者收集一些技術性的資料，比「我的程式當掉了」這種回報更容易辨別錯誤所在。不過這些資訊只能提供一般性技術資料，並不方便作為直接除錯使用，大約可以利用於統計、分析軟體穩定性等加強軟體品質的用途。
若你恰巧不幸是軟體工程師，你可以試著利用 gdb 等試著收集更多資訊，甚至先進行初步的偵錯。但是我知道要求一般人重新編譯軟體加上除錯資訊等，再開啟暗黑 gdb 視窗下指令除錯，實在會嚇跑一些曾經習慣在其他平台只用 IDE 開發軟體的朋友。事實上，在 Debian 中還是有些工具可以讓你快速的進行軟體除錯，而且也有比較友善的工具可用。
你若要除錯，第一部大概是取得除錯資訊，預設的 Debian 套件是不含除錯資訊 (Debug symbols) 的，因為大部分的使用者不需要這些特別佔用空間的檔案。許多資深的 Debian Developer, 都會分別在包裝的套件時加上 Debug package，於是你可以在不重新編譯軟體的狀況下拿到同版的除錯訊息。 這些除錯套件的命名原則都是以 dbg [...]