產品的易用性通常決定了他的成敗

一般來說，產品的易用性 (usability) 決定了他的成敗。排除特殊專門用途或是特殊冷門軟體不談，設計給一般廣大而普遍的使用者使用的軟體，如果在易用性上面表現不好，那麼這個軟體至少不會太成功。

程式設計師往往僅專注於達成軟體的功能設計需求，並確保該能運作正常，但多數的程式設計師往往不懂該產品。例如設計財會倉儲管理系統的程式設計師很少會懂財會或是倉儲，設計人事管理的設計師也不懂人事管理，因為這些領域往往過於專業，即使在團隊裡有系統設計師，有架構設計師，這兩個角色或多或少會在程式開發以及目標用戶之間扮演一些溝通的角色，但多半這兩個角色也不可能對軟體的目標領域有深入了解。

某一定程度的軟體的易用性，認真或是稍加投入的程式設計師還是可以達成一定程度的改善。舉例來說，當某個功能操作環節中有一個步驟要從清單中選取一個使用者自訂的項目類別，這個清單欄位被設計成10行高並且當選項超過10個時會出現垂直捲軸。稍加投入的設計師也許會發覺這個選項清單在多數的使用者一定時間的使用之後，選項多達百位數應該很常見，於是一定程度的增進快速選到想要的選項是必要的。例如在點選清單內任一選項後，快速輸入所想要選的選項值的前幾個字幕將會自動選取到符合的項目上，就類似檔案總管具備的特性那般。

然而，類似這種操作細節往往不會在功能設計需求上加以規範或多所著墨。系統設計師或是架構工程師往往也不管這些細節！如果不是開發團隊的主管乃至大老闆重視產品的易用性，有時即便某個程式設計師具有產品易用性的敏感度，大概也會因為專案時程的壓力而被迫妥協。

從另外的角度來看，程式開發團隊往往不容易發現產品的易用性相當糟糕。程式開發過程中，開發團隊確實會對程式進行單元測試與基本的功能整合測試，但多半是喂給程式很簡單的資料，或是經過特殊設計的資料，只為驗證經過程式運作後會得出預期的結果。例如錄製一個聲音檔，將這個聲音檔交給程式，程式自動將其轉檔成 MP3 格式，在轉檔前或是之後，為這 MP3 檔案加上標籤與自訂類別與評分，然後測試在播放界面打入類別字串，確認該檔案能被正確搜尋出來，然後結束。

很多時候產品易用性的意見反餽往往是品保測試部門提出較多，因為品保部門相較於開發部門而言較貼近使用者的角度，在產品測試時也較會由使用者的角度出發，來測試與驗證這個產品。如果測試時間充裕，品保部門多會建立較多且具有多元性的的資料，然後加以測試。其原意本非針對易用性進行測試，而是為了避免有任何疏漏未能測試到，但往往也同時發現易用性的問題。

嚴格來說，品保部門也不是合適的產品易用性檢驗單位。事實上易用性本身也是門學問，也有專家學者整理出來意用性的特質與特性。比方我們來想想，什麼叫做易用性？ Donald A. Norman 提出產品的易用應具備：Easy to discover, easy to learn, easy to use。

我們可以回想看看自己周遭的各種產品，它們的易用性如何，即便我們已經很熟悉的產品，例如自己的手機或是家裡的飲水機。想想看你天天搭乘的捷運，模擬你第一次搭乘，當你在捷運站附近時，捷運站入口是不是容易辨識？走進捷運站後，買票怎麼買，找售票口還是找售票機？在售票機前，如果你完全不看上面的文字，只看符號，是否容易懂得怎樣購票？買到票了，前往驗票閘門，你是否容易知道怎樣驗票？（特別是台北捷運單程票改為硬幣式，這在國外也很少見）通過驗票口後，月台方向指示是否清楚？到了月台後，欲搭乘的車輛在那個方向的月台，是否容易辨識？

當模擬自己是個對該產品極度不熟也不具備相關背景知識時，就越容易發現該產品的易用性做的好不好。這就好比請個鄉下人初次進都市搭乘捷運那般，或是找個外國人首次訪台。當然經過一定的訓練，或是對易用性具備足夠的敏感度，就越不需要刻意做情境模擬，就能發現易用性的問題。

最後，產品的易用性為什麼決定了它的成敗？試想，即使你的產品沒有功能瑕疵，而且你的產品也大賣，但是使用者緊接著發現產品不易使用，即使看了說明書依舊感到迷惑，那麼就會有越來越多的使用者撥電話到你的公司詢問產品問題，你的員工或是客服人員就會忙著解答這些使用上的問題，並且問題的數量會隨著你產品賣越多而跟著增長。我想沒有人會認為需要為了使用 PDA 手機而報名一堂需要繳費的課程來學習它，這並不是像學一套複雜的 PhotoShop 一樣。如果你的產品目標是廣泛且龐大的使用者，那麼它就是要具備足夠的易用性。此外，如果一個產品的易用性太低，好比說你有很多很強大的功能，但是藏的很深，很多人不知道怎麼用，那麼大概多數的人會因為根本沒發覺那些功能而覺得你的產品並沒想像中那麼好，價格功能比偏低，這些顧客會逐漸的流失。

iPhone 為什麼賣的那麼好，裡頭很大的因素之一在於它的易用。我相信有相當比例的人買了 iPhone 回來，說明書根本沒打開過，或是僅翻了幾頁，從此就沒再見過說明書了。 HTC 為什麼賣的比其他 PDA 手機來的好，因為 HTC 也客製操作界面，大大改善 PDA 手機的操作方式與習慣，大幅提升產品的易用性。其他未經客製的 Windows Mobile 手機就失敗在於這微軟原廠內建的界面並不符合手機群 "Smart" 的期望，因為它原先的設計是給 PDA 用的，拿著觸控筆想像你在操作一台微型電腦，設計的角度並非從 "Smart Phone" 出發，因此很輕易的就被後起的 iPhone 與 Android 打敗。

軟體平行/同步/協同開發下的軟體翻譯工程

6/19/2007

過往比較常見的軟體翻譯工程，普遍鑑於原始版本 (source version) 已經完成或是接近軟體開發的最後階段，才會開始進行軟體的翻譯工程。對於大型商業軟體而言，由於軟體開發週期常，加以引用不少先進軟體開發技術，當軟體開發已達80%左右的完成度時，多數的規格以逼近底定，此時不太會有新功能的引進，因此諸如操作流程、界面、功能呈現等皆不會有大的變化，在這個時期提前開始進行翻譯工程，即使在最終 RC (Release Candidate) 版本仍有外抽字串的變動，也僅是小幅度的變動。


在這種傳統的開發模式，亦即非平行開發 (parallel development) / 同步開發 (concurrent development) / 協同開發 (collaborative development) 的模式下，翻譯工程是基於來源語言 (source language) 是處於穩定狀態下來進行的。因此，即使在軟體完成度僅達 80% 便開始進行翻譯，直至最終軟體邁進 RC1 甚至 RTM 版本，之間的來源語言頂多只會有小幅度的變動，例如低於五次的小改版。

在此類來源語言處於一個穩定的狀態下，翻譯工程常見的是在第一次進行全面翻譯，當翻譯完成時，會建立翻譯記憶庫 (translation memory) ，則之後每次的小改版，依舊拿新的來源語言版本來進行翻譯。藉由翻譯記憶庫的對應 (mapping) ，未有變動的字串將可獲得 100% 的對應翻譯，則翻譯僅需針對變動字串以及新字串來進行即可，篇幅以及工作量將會很小。

試想，假設當翻譯工程開始進行，直至最終的 RC 或是 RTM 版本之間，來源語言有太多次的變動，例如多達十次以上的變動，或是週期性的，每週甚至每天皆有一個變動，並且希望翻譯可以盡量跟上來源語言版本，那麼既有的模式便會變得過於煩瑣、擾人、且不太實際。

另一種狀況，若是翻譯工程在軟體開發的很早期便開始進行，例如在軟體開發完成度達到 50% 便開始，加以期間的變動相當頻繁，且希望翻譯的目標語言可以盡量與來源語言版本同步，那麼翻譯工程勢必得思索一個更有效率的方式來進行。

舉一個例子，當第一次進行翻譯時，假定此時是基於 Rev.010 來進行，並且此時來源語言共有 1,000 行（假定每行對應一句來源語言），翻譯進行了一週完成，此時來源語言版本已更新至 Rev.011 ，並且新增/異動了 10 行。姑且以每週會產出一個新的版本 (Revision) 並且預期每週平均會有 10 行的來源語言字串的異動，那麼意味著每週進行一次的翻譯工程，其實只需確保這異動的 10 行能夠同步至翻譯的版本。若採用傳統的模式，則每次皆是進行約 1,000 行的自動翻譯（自翻譯記憶庫找尋已有的對應），然後再找出異動的字串來進行翻譯，以其達到與新的來源語言版本同步。

如果採用另一種方式來進行，即利用比對工具，將 Rev.010 與 Rev.011 之間的差異匯出，只針對差異進行翻譯，然後將翻譯完成的差異，匯入原已翻譯好的目標語言版本 Loc.Rev.010 ，則達到與 Rev.011 同步的結果，因此可稱為 Loc.Rev.011。這樣的模式，僅需要針對差異來進行翻譯，而不須頻繁的針對 990 句不會異動的字串一再的進行重新翻譯（自翻譯記憶庫自動比對）。

Applications that are easy to be used

3/23/2006

In the "Designing Interface" book which wrote by Jenifer Tidewell, one section is quite interested.

One could say, "The applicatuions that are easy to be used are designed to be intuitive."

The author think that's almost a tautology.

The author also wrote:

Except that the word "intuitive" is a little bit deceptive. Jef Raskin once pointed out that when we say "intuitive" in the context of software, we really mean "familar".

Upgrade path

9/14/2005

All softwares have their own upgrade path. A mature software will provide you very clear way that how you can do on your upgrading.

My previous colleague ask my opinion about the software developing project which I used to be part of the co-worker. Well, my opinion is I agree to provide a moe flexible way and more professional way that user can easier upgrade their software and configuration from old version to latest version. This is including upgrading to a newly-implemented localized version.

Imagine a German who can only live on the English software and try his best to read those unfriendly English strings. Now, there is a new German version. He will think about to upgrade to German version which is the most friendly stuff to him.

That's why I agree the way to upgrade to localized version should be provided. I wonder why some policymakers will make the decision that it's not provided!