未來GUI及其應用的研究(1) — 基本的策略

GUI的開發，從來都不是一件簡單的事情。它涉及很多很複雜的關係，尤其是和使用者互動的時候，涉及很多狀態。

一個產品，往往花費大量的時間用在GUI的開發上。對於一些企業級的應用--如OA等--來說，有大量的GUI設計工具，這些工具提供了足夠多的

標準控制項、資料繫結、資料來源等等功能。在介面要求不必絢麗，使用者體驗要求不高的應用場合，GUI已經非常方便了。

而且，隨著硬體的加強和分布式開發的需求，這些應該都首選B/S架構，甚至，C/S架構已經寥寥無幾了。

但是，在嵌入式和其他應用場合，考慮到效能、速度等要求，仍然是以C/C++語言開發為主，雖然也有使用WebOS的裝置，但是大多屬於高端。

儘管在未來，WebOS及其變種，可能會大行其道。但是，畢竟WebOS不是為本地應用定製的，而且，js和本地介面的綁定，設計和開發起來，仍舊很困難。 

而且，WebOS不能解決所有GUI產品開發的整個流程。

從我做GUI的一些定製類項目的經驗看，開發一個完整的產品，不僅僅是GUI一方面的問題，而且還涉及到很多方面。

通常來講，開發一個GUI的產品，我們是這樣做的：

1. 進行需求分析，做產品設計
2. 架構師開始做整個產品的設計，同時，UI工程師，對介面進行設計
3. 開發人員根據UI工程師的設計，做介面的實現
4. 合并UI、資料管理等各個方面，成為一個統一的產品

這個過程，看起來很簡單，也很明確。但在現實中，是不可能實現的。

首先，使用者的需求往往是不明確的。尤其是在定製項目中，很多客戶可能在其他領域很在行，但是在UI和產品開發上，卻不行。一開始，他們自己可能都不知道應該作成什麼；

其次，及時客戶清楚做成什麼樣子，在開發過程中，根據開發的結果和進度，也會產生很多別的想法；

第三，很多時候，為了拿下單子，UI工程師常常會脫離實際，設計一些很難實現或者很不常見的介面，導致開發人員在實現時，費盡心力的去想方設法的實現

第四，由於設計和實現的脫節，當實現效果和設計效果有差距時，客戶往往會按照實際顯示效果重新做出調整

第五，UI工程師的設計，往往只針對一個頁面一種情境，沒有一定的經驗，往往不能預見到運行期間各種變化，常常設計出的效果，當運行狀態變化後，就需要做出調整；

第六， 好的UI，自然需要風格統一一致，而UI工程師在設計時，往往局限在局部的UI，整體的調整隻有在產品成型後，才開始涉及。

.....

還有很多。尤其是在一些行業領域，一些控制項不能滿足要求，還需現場開發。

這些都給GUI產品的開發帶來的很多的問題。使得開發週期長，項目成功率低。

對於一個產品來說，UI只是其中的一部分，不是全部，尤其一些外包和定製的項目，UI不是客戶的核心技術。而客戶的很多核心到技術，往往都是以SDK或者庫或者服務的方式存在，要形成一個產品，和UI結合起來，必須從 UI層次，定義好架構結構，然後把客戶的核心內容包裹起來。

而這種架構，如果不是對客戶產品很瞭解，而且對類似的應用很瞭解，而且經驗豐富，具有很強的架構能力，是很難做出好的產品的。

如果一個UI庫，僅僅提供一些繪製或者常用的控制項的話，開發這樣一個產品，其周期和風險可想而知。

從這幾年，IPhone和Android的流行，可以看到，大量平滑和豐富的特效，已經成為UI的必備功能。而且，時不時還要冒出一些很炫的效果來。

這對UI的要求就更高了。

縱觀目前的UI庫，在嵌入式領域，在PC領域，目前已經很少有能夠和IPhone和 android匹敵的庫了。

而市場的需求，已經被引發，在眾多的領域，大家都希望能夠有很好的介面。在消費類電子裝置中，這些幾乎是標準配置了。

如果分析Android和IPhone在介面上的成功，我們不難發現，

首先，Android和IPhone的介面庫，有很強的針對性，他們都提供了一組架構，就是針對智能手機的。這種架構非常重要，它解決了產品的可行性，解決了產品的基本外觀和使用者體驗，也解決了開發一個應用的基本範式。開發人員，只要比葫蘆花瓢，就可以實現；

其次，他們提供了很多基礎的功能，比如布局、特效等等，這使得開發變得很容易

第三，他們提供了很好的開發工具，使得開發變得容易。

要想在其他領域內，也實作類別似的成功，也提供易於開發、易於維護的產品，我想，需要考慮新的開發模式。

新的開發模式，應該遵循實際的開發規律。

通常，開發一個新產品，如果能夠首先見到一個原型，那麼，就可以明確很多內容。

1. 首先，快速開發一個原型，這些有：

   1） 搭建一個產品的基本架構，使用標準的UI元素和標準的主題

   2） 用原型和客戶探討，以明確介面的流程、產品的需求等更方面問題

這個原型，需要解決的問題是：

    1） 定調子，確定好產品的基本外觀和操作流程

    2） 解決產品的架構問題，確定它的基本骨架，以方便後期的添加

    3）作為UI、客戶、開發三者之間，交流的平台，以平衡需求、外觀、體驗和可行性及效能之間的關係，防止出現脫節的現象。

這些原型，是要求可以在開發板上運行，那麼，我們可以在開始的時候，就能夠大致估計出產品在實際使用中的效果。

能夠快速的在實際裝置上運行，無論對於客戶還是開發人員，都是很大的信心鼓勵。

2. 其次，在原型的基礎上，討論很確定外觀，這些有：

   1） 可以確立整體風格，保持風格的一致性

   2）發現可以改進的地方，如果有需要，可以定製新的控制項和介面元素

3. 第三，開發人員可以明確和產品其餘部分的結合，從而確定產品的總體架構

可以看的出，這裡面有幾個關鍵點：

1. 快速做出原型，最好的方法，就是從已經實現的產品中拿到一個，稍加修改，作為新的產品原型提供。

比如，很多產品都會類似的結構和頁面：如啟動畫面、主菜單、系統設定等。還會有一些很常用的應用，如日曆、記事本、計算機、相簿等。

這些結構和應用是如此的相似，以至於，主要是不同裝置的解析度、表徵圖等存在一些不一樣。

如果能夠把這些抽出來，作為已經實現的通用原型，無疑給後續的開發帶來很大的便利

2. 總有一些應用，是針對客戶自己特有的。

如果能夠在一個通用的原型基礎上，能夠快速的製作頁面、添加簡單的事件和類比資料，形成一個簡單應用，並能夠很方便的添加到通用原型中，

那麼，這樣的原型能夠很快的實現

3. 介面總是要修改的，如果能夠實現介面、資源和應用邏輯的分離，那麼，介面的修改不會對邏輯代碼產生太多的幹擾，就可以很快的實現外觀的修改。

這種事情可以和客戶一起做，即時修改，即時徵求客戶心聲，當客戶滿意時，UI部分就基本完成。

4. 在修改和定義介面的同時，架構師可以在原有基礎上，定義出產品的總體架構，然後就可以實現和介面邏輯關係不大的部分，當這兩部分都完成後，剩下的工作，主要就是系統整合了。

 如果我們有這樣一套東西，可以假設一下，做一個單子，會是什麼過程：

假設我們做一個MP4吧（雖然現在MP4前途很渺茫，不過，大家都比較熟悉，拿來舉例容易理解）。一個晶片廠商提供了MP4的晶片，希望做一個MP4，能夠播放音樂、視頻，可以看電子書、瀏覽圖片和一些其他的小功能。

當接到單子後，我們首先把通用原型拿出來，這些包括啟動畫面、主菜單頁面、一些小程式等。然後，我們把音頻和視頻播放器（假設也是做好的原型，但是沒有放到通用架構中），放到通用原型中。由於通用原型的介面是統一的，所以，這些程式，幾乎不需要什麼改動，就可以在運行。

然後，可以在客戶提供的裝置上，去運行和移植這樣的原型，把移植的結果，給客戶看，和客戶一起評估

第三，當大方向確定後，就可以和客戶評估每個應用的需求及細節，把他們依次記錄下拉，作為開發的需求

第四，同時，可以讓客戶提出自己對UI和操作的意見，從而確定好整體的風格，並及時安排開發人員和 UI工程師，實現這些風格（由於介面都是確定的，所以這些工作，主要是更換圖片和資源）

第五，與此同時，我們的工程師和客戶的工程師一起溝通，確定好音視頻播放及其他底層訪問的介面和方法，做一些和底層適配的工作

第六，整合工作在這兩方面的工作有進行到一定程度後，就可以進行了。以迭代的方式，不斷的整合，不斷的把產品呈現給客戶，每次迭代，都更進一步的接近客戶的需求。

這種方法，和敏捷開發是想一致的。

這種原型的方法，可以有效解決產品邊界的問題。在產品開發中，總是會出現一些過渡的設計，包括UI工程師和開發工程師，都一些這方面的傾向。或者是對自己過於自信；或者是對需求判斷不足；或者是為了拿到單子，迫於壓力，做一些不切實際的承諾；或者是內部缺乏有效溝通，大家都希望做出好產品，而忘記了現實的約束，只有在具體實現時，才發現，所有的一切都晚了。

=======================================================================

結合上面的分析，要想做好一個產品，要想在競爭中取勝，對我們的UI有這樣的要求：

1. 應該有靈活的可定製性。這些包括：

   1) 介面的外觀應該以資源的方式提供，更換資源，即可實現對介面的改變

   2) 應該有自動布局這樣的功能，以便適應不同的解析度和大小

   3) 應該能夠很方便的控制項定製功能，在用到沒有的控制項時，可以很方便的實現

   4) 友好的資料介面，有類似資料來源、資料繫結等的介面，這樣，開發起來會方便很多。

   5) 應該有統一的介面，這樣可以用xml等方法，作為資源把介面及其相關資料作成資源的方式

2.  架構非常重要，需要逐步提供架構：

   1) 應用管理的架構，可以方便的添加、移除應用

   2) 統一的資源管理架構，允許不同的應用共用資源，並保持一致的外觀

   3) 靈活的通訊機制，在不同模組直接進行通訊，並建立一些事件驅動的機制，也解決介面、應用和模組之間的耦合

3. 積累必要的應用還是非常重要的。應用的開發也是很不容易的，一個好的應用，堪比一個小型的系統。隨著開發的產品越來越多，應該把它們積累和統一起來，作為將來新產品的原型的來源。要做到這一點，很重要的是，保持架構和介面的穩定性。

後面的章節，我們將逐步的分階段的研究。