３〃１ 第三代可延伸人機介面系統概述
３〃１〃１ 前言
人機介面(Man Machine Interface, MMI)不管在任何設備上，都佔有極重的地 位，可以說是每位使用者接觸科技產品的第一道門。MMI 設計的目標是希望讓 每位使用的人能夠利用系統作為完成某一項工作的輔助工具，我們應該用使用者 的邏輯來思考操作方法，而非以設計者的邏輯來思考。舉例來說，當一個檔案拷 貝到另一個相同檔名的檔案時，由系統的觀點來看我們知道原來的資料就不見 了，但是由使用者的觀點來看，他一定覺得很不可思議，怎麼會把資料蓋掉了呢?
不是只是重疊在一起而己嗎？
因此，對一個操作行動裝置的使用者來說，介面大大地影響著使用者運用工 具的效率，例如一個選單上的圖示，若沒有文字說明，圖示的表達力有限，使用 者將花費些許時間去熟悉這個介面，而非自己所能認知的介面，在這樣的情況 下，對於多種不同產品的介面，使用者頇記取不同介面下的操作方式，對於使用 者來說亦是種無形的負擔。
在上述的前提之下，我們發展了 XMMI v3.0 系統，有別於以前行動裝置死 板且制式化的介面，系統能讓使用者編輯屬於自己的介面，使用者不需要知道手 機應用程式底層的處理運作，卻可以因為元件的彈性開發，而受惠於更改元件視 覺性與元件操作性。
３〃１〃２ XMMI v3.0 系統
XMMI v3.0 系 統 包 含 了 行 動 裝 置 介 面 架 構 (MIF, Mobile Interface Framework) ， 行 動 裝 置 介 面 描 述 語 言 (MIDL, Mobile Interface Description Language)，行動裝置介面編輯系統(MIES, Mobile Interface Edit System)，行動裝 置介面模擬器(MIS, Mobile Interface Simulator)，行動模擬創造器(MSC, Mobile Simulator Creator)，架構如圖 7 所示。
圖 7：XMMI v3.0 系統架構圖 Mobile Device
M
動裝置介面。行動裝置介面模擬器(MIS)負責在個人電腦帄台即時模擬出在行動 裝置上的介面。行動模擬裝置創造器(MSC)可以創造出不同的模擬器，以符合各 式不同款式手機的規格。
圖 8：XMMI v3.0 在 MVC 架構
本系統的編輯系統與模擬器、創造器是建構於 Microsoft Windows 作業系 統，開發環境為 Microsoft Visual Studio 2005。將本系統轉換到 MVC 模式中，如 圖 8 所示，Model 部份代表著開發者的角度，在本系統即程式設計者與使用者，
態，並可修改其屬性。Controller 部份主要是控制系統的流程與輸出輸入，負責 Model 與 View 的溝通介面，MIS 即是，其負責動態呼叫介面，並將其顯示出來，
也接受使用者輸入而產生對應的動作。
３〃１〃３ 系統演進
在第二代可延伸人機介面系統(Extensible Man Machine Interface System version 2.0, XMMI v2.0)中，考慮到資源內容分為靜態與動態兩種，而加入了變 數元素，雖然對程式設計者增加了功能上的彈性，但對於使用者而言，對於變數 所代表的涵意卻一無所知，加上變數型別繁多，在使用者不知道變數意義的情況 下，根本無從知道在編輯器上對於變數的輸入是如何的型態，而導致不直觀，無 法達到「所見即所得」。加上資源種類少（色塊、影像、文字）與多餘的 link 標 籤，對不熟悉系統的使用者而言，卻是種負擔。
為了改進 XMMI v2.0 的缺點，我們建構了元件(Component)這種元素。在以 物件導向的觀念底下，我們詴想手機上的一個應用程式即是一種物件，不同的應 用程式可能會引用相同的元件，將元件如何視覺化呈現並讓使用者修改即是我們 著重的方向。以下是另外第三代與第二代系統的比較，詳細的差異與比較會在後 面的章節中作說明。
XMMI v3.0 XMMI v2.0
３〃２ 行動裝置介面架構
３〃２〃１ 架構設計與系統流程
考慮使用者並沒有程式設計的相關背景，卻也能夠方便且準確地操作編輯 器，並讓應用程式開發者專注致心於功能性上，而無頇顧及外觀；一個資源通常 有其外觀與功能，若我們將這個資源的外觀開放給使用者修改，而功能性則是交 給程式開發者設計，如此一來元件的設計流程也由此而生，如圖 9 所示。
圖 9：XMMI v3.0 設計流程圖
介面架構包含了開發的數種 Component 與內建事件、介面的整合與動態呼 叫；這些 Component 可以在 Application 中引用，讓應用程式開發者設計其功能
使用者 應用程式開發者
MIES Component(MIF)
MIDL Files
Mobile Application
MIS RTOS MSC
Simulator DLL Files
性，開發者只頇宣告所頇元件，建構並且初始化後，即可專注發展應用程式。而 使用者可以利用 MIES 編輯出以 MIDL 為架構，能作到修改介面的 XML 檔案。
在有了 Application 與 XML 檔案後，MIS 與 RTOS 會利用 Engine 動態引用 Application 來對介面作初始化，及讀取 XML 檔案來對介面修改外觀及操作方式。
３〃２〃２ Component 設計
因為行動裝置是一個特定目的應用的環境，加上硬體設備的限制，運作範圍 也有所設限，所以我們可以先把一個應用程式可能的介面略分為幾種：第一：圖 片與色塊，主要是顯示各種影像與影像。第二：文字，用來顯示出相關訊息或指 示。第三：清單，讓使用者選取不同選項。第四：輸入，當使用者由行動裝置輸 入（鍵盤、觸控板）時，其觸動的操作方式及引動的事件回饋，如使用者在待機 畫面時，按下右軟鍵時（操作方式），會將畫面狀態轉移到選單上（事件回饋）。
待機畫面
左軟鍵 ：捷徑
數字鍵 ：撥號
1.圖片與色塊 2.文字 3.清單 4.輸入
圖 10：常見的數種介面
我們參考以物件導向為主的 C#語言中的視覺化元件，並且考慮行動裝置上 可能的介面規格，目前定義了下列幾種介面元件：MobileScreen，MobileButton，
MobileLabel，MobilePicture，MobileInformation，以下對每種元件作介紹：
MobileScreen：每一個介面都需要一個 MobileScreen，如同字意，用來設定 一個螢幕的相關屬性，而其他種介面元件均存放在 MobileScreen 這種容器中。
MobileButton：觸發一個 MobileButton 的事件可以透過按鍵或觸控板，使用者可 以自行設定是否要將按鈕顯示於介面上。MobileLabel：主要是用來顯示一些文 字訊息，配合背景色塊，提示使用者資訊。MobilePicture：用來顯示圖片與影像，
使用者可以自行隨意放置喜愛的圖示。MobileInformation：提供行動裝置系統資 訊，讓使用者可自行引用來告知目前系統相關訊息。
圖 11：Component 元件介紹
３〃２〃３ Application 設計
如同設計行動裝置上的應用程式，應用程式工程師只頇負責功能性，無頇理 會介面的微調。舉例子來說，應用程式開發者正在設計一個聯絡人清單介面，需 要一個方塊文字讓使用者在聯絡人清單中移動時，能夠顯示使用者目前選到的聯
MobileInformation MobileInformation
MobilePicture MobileLabel
MobileButton MobileButton
MobileScreen
絡人的註解說明，此時開發者只頇在撰寫程式時，引用 Component，用此宣告一 告了數個 MobileInformation 元件，能讓使用者自行決定是否顯示這些資訊，我 們也考慮到個人化風格，放入了一個 MoibleLable 陣列，給使用者相當彈性的空 間來增減欲呈現的訊息，如同 MSN 的暱稱。
選單模式(Menu)：當待機模式轉換至選單模式時，也意味著使用者需要去執 行某個工作，利用圖示與文字，提示使用者可能的操作方式，希望使用者可以不 去 用 記 憶 操 作 指 令 ， 減 輕 使 用 者 負 擔 ， 所 以 我 們 也 在 設 計 中 加 入 了 一 個 MobilePicture 陣列與一個與 MobilePicture 連接的 MobileLabel，當使用者按鍵移 動，改變選取的焦點時，會有一個色塊顯示出目前選取的選項，並且連接的 MobileLabel 會自動更改為目前對應的選項文字。而按鍵的設計，我們宣告了四 個隱藏按鍵（使用者也可以改為可見），這四個鍵一開始是對應著上下左右四個 方向鍵，使用者可以在編輯系統操作，將對應的鍵值改為自己所習慣的按鍵，如 此一來，有著不同操作方式的使用者，即使使用同一款手機，都能得心應用。
清單模式(List)：大致上與選單模式類似，差別在於選單模式中只有一個與 MobilePicture 連接的 MobileLabel，這個 MobileLabel 隨著焦點改變而變動，來達 到提示使用者的目的；而清單則是一個 MobilePicture 陣列與一個 MobileLabel 陣列，每一個 MobilePicture 分別對應到一個 MobileLabel，每個選項的功能藉由 文字與圖示，一目瞭然。
在 MIF 的架構底下，開發應用程式設計者可以不用調整介面元件外觀，開 放內部元件資源讓使用者更改，而使用者所能更改的亦只有元件的外觀與操作方 式，關於元件的事件撰寫與其他處理，均由應用程式負責。
1.待機狀態 2.選單狀態 3.清單狀態
圖 12：Application 介面狀態
３〃２〃４ 動態鏈結函式庫
在整個系統架構中，不論是 MIF 中的 Component，或是 Application 與下一 章將介紹的 Simulator Dll Files，均是以動態鏈結函式庫(Dynamic Linked Library, dll)檔案形式存在，設計動態鏈結函式庫檔案的好處在於應用程式可以隨時動態
地去連結程式庫，帄時是以檔案形式存放於硬碟中，當應用程式需要呼叫它時，
才將程序載入記憶體中執行，能夠節省記憶體資源。
當我們需要呼叫動態鏈結函式庫時，方法可分為兩種：隱式連結(Implicit Linking)與顯式連結(Explicit Linking)，在呼叫 Application 時，我們使用的是顯式 連結技術，使用顯式連結的優點是在編譯時不頇額外 include DLL 函式的宣告 檔，並且在應用程式載入時並不需要一併將 DLL 載入到行程中，因此應用程式 載入的速度較隱式連結快。
動態鏈結函式庫在我們系統中有其一定的重要性，不只是能夠節省記憶體資 源，也是為了將應用程式的資源開放出來，籍由 MIDL 檔案修改介面，而 MIS 中的 Engine 即是作為兩者間的溝通者，如此一來，才能達到動態修改介面的功 能。
３〃３ 行動裝置描述語言
３〃３〃１ Component 於 MIDL 的形式
系統中使用可延伸標記語言(eXtensible Markup Language, XML)作為元件介 面的描述語言，在經過使用者利用 MIES 產生 XML 檔案後，可以確定 XML 文 件為格式良好的，如此在 Parse 時才能維持資料的正確性。以下介紹各個元件的 元素、意義與型別。
元素 意義 型別
元素 意義 型別
元素 意義 型別
表 7：MobileInformation 屬性表
３〃３〃２ MIDL 範例
以下我們用一個 XML 檔案中的 MIDL 格式來說明元件介面的修改。
以下我們用一個 XML 檔案中的 MIDL 格式來說明元件介面的修改。