移動應用自產生之時開始，便存在跨平台的需求,目前ios/android/wm平台為手機的主流平台, 在我們產品做設計之前, 走了足夠多的彎路:
1. 規劃的時候，首先從android入手，android開發完畢後，再開發windowsmobile,隨後是ios平台, 帶來的問題是:關注某個平台而忽略其他平台, 導致設計上，缺乏系統考慮和整體考慮。
2. 各種平台的操作方式都不同，android使用者如果轉到android應用，由於操作不同而需要新學習成本或者代價。
3. 技術支援的成本: 需要更具不同的使用者發放使用者手冊。需要不同的說明，一致性比較差，維護成本高。
l 總結ui設計的乙個通用模式, 作為後續積累的乙個方向
l 設計一套可以公用的ui層次結構, 方便重用(至少:低成本移植)
l 探索ui的邏輯美學
ui設計應該遵循什麼樣的準則, 才是最有效的。 甚至是否需要存在準則，都是乙個問題。我們目前ui面臨諸多問題。下面以現象的方式列出。
ui經過大的調整2次， 各種版本的調整不下百次, 調整的理由各異, 有的調整，最後又回到了最初，沒有既定的規範，帶來ui設計資源的嚴重浪費。
縱觀當前的ui設計過程，ui設計的可重用性很難做到，產品的共用性沒有提出來，重複設計過多，尤其在android情況下，很多不同解析度的裝置，甚至都採用了不同的，這樣對資源及其浪費。更不用說跨作業系統平台的環境下的ui設計了。
1. 遵循可見度最大原則, 減少切換代價。 ios的硬鍵盤個數小於android和windows moble, 因此需要採用所見即所得的原則, 避免各種應用的風格不一致.
2. 頁面之間儘量減少重複資訊,第一頁涵蓋了某個資訊，第二頁必然不涵蓋該資訊。不要做重複設計
3. layer層次不宜過多, 盡量控制在兩層, 如果是三層以上, 必然是乙個複雜系統，必然不可取。截止第三層。
第三點特別注意，我們要求的是縮短層次深度，附帶的問題是廣度提公升。個人建議廣度上不超過維度7, 因為這是人的記憶能力的極限。另外ui的layer為2層，實際上資料或者邏輯可以達到6層(按照下圖情形一計算得來: 每頁可以顯示三個深度)。剛好小於人的極限記憶能力7。（關於人的極限記憶能力，可以參考《金字塔原理》一書）
示意圖: ui設計的第一層
為了避免空談主義, 現在實現這樣乙個主框架, 截圖如下:
已實現的主框架截圖示例
說明:1. 主框架**, 即上中下的整體結構, 封裝在: ostrichmyself_sdk_ui 這樣乙個library工程中.
3. 該布局非常有利於phonegap等html5技術的融合, 比如網易曾經就是native code + html5的方式, 所以這個框架非常合適做這樣的轉型
未完待續
Validation客戶端驗證框架
二 使用步驟 匯入js庫 example4 js validation framework.js script validation config.xml 驗證規則的配置，專案中驗證模組的工作主要就是在此檔案中配置規則。validation framework.js 對validation conf...
瘦客戶端 胖客戶端 智慧型客戶端
胖客戶端模式將應用程式處理分成了兩部分 由使用者的桌面計算機執行的處理和最適合乙個集中的伺服器執行的處理。乙個典型的胖客戶端包含乙個或多個在使用者的pc上執行的應用程式，使用者可以檢視並運算元據 處理一些或所有的業務規則 同時提供乙個豐富的使用者介面做出響應。伺服器負責管理對資料的訪問並負責執行一些...
客戶端UI技術一點總結 PCMOM
具體說說duilib的優點 中立不吹牛，非廣告貼，且真實測過 基於win32封裝，效率很好。控制項很多，常用的都有，提供的ccontrolui介面擴充套件很方便。xml控制布局，介面設計很靈活，如果有志者，加乙個中間層進去，業務和介面解耦將不是問題。原生態的支援換膚。非常的方便。提供了介面設計器，很...