一種基于模式的界面生成方法①

崔 洛,周千明,魏 煒,賀興時

1(西安工程大學 計算機科學學院,西安 710048)

2(西安工程大學 應用技術學院,西安 710048)

3(西安工程大學 理學院,西安 710048)

1 概述

界面生成在軟件系統中占有重要地位.當前,由于計算設備的多樣性和運行平臺的差異性,使得幾乎每一款應用都需要在不同的設備上開發相應的客戶端界面.這導致了開發者會在不同平臺上使用底層控件和布局工具重復構建同一應用的界面,陷入到設計細節中.

為了解決跨設備、跨平臺的界面可復用性問題,一種基于模式的用戶界面描述方案被廣泛應用.界面設計模式是針對特定界面設計問題,通過總結前人設計經驗,抽象出的界面模型.同時提供相關的自動化工具解析其界面模式,從而生成符合各平臺使用風格的具體用戶界面[1].這樣,開發者可以從更宏觀的角度把握整個用戶界面的設計,而不是拘泥在具體的控件選擇和設計等細節中,能夠提高界面開發效率.

基于上述方案,本文設計了一種界面模式描述語言SPLML,實現了一個基于模式的界面生成框架UIPF,可以運行在多設備上,解析成符合各平臺使用風格的用戶界面,從而提高界面設計和開發的效率.

2 相關工作

界面設計模式[2]是前人針對特定設計問題的經驗的總結,它隱含了界面的可用性設計,可以對界面開發提供指導,提高設計效率[3].當前的界面模式庫仍然大多采用文本、草圖、模板等非形式化方式而忽略界面模式的自動化應用.這類研究包括《Designing interfaces》[4]、《The design of sites》[5]等書籍,它們可以輔助設計者完成界面設計工作,但應用中仍需要手工編寫代碼實現具體界面,限制了應用的便利性.

另一類研究,如GUIDE[6]、Damask[7]等,試圖將模式和界面自動化設計工具結合起來,除了研究模式集本身外,還能夠根據用戶指定的設計需求自動選擇界面模式.有一些工具除了支持界面設計之外,也能支持原型設計,例如MyUI[8]和 OlivaNova[9]等.但這些工具都僅能支持某一個特定平臺下的界面原型設計,不能和具體開發過程很好的結合起來.

綜上,為了能在實際產品開發中高效的使用界面模式,需要對其進行形式化的描述.在當前的研究中,主要使用PLML[10]等基于XML 的語言來進行形式化描述,這是自動或半自動處理界面模式的基礎.PLML定義了一系列標簽用于從不同的角度描述一個界面模式,但其對支持自動化工具最重要的＜implementation＞標簽并沒有嚴格的形式化定義,從而無法真正的支持使界面的自動生成.

針對此問題,西北大學的華慶一、吳昊等做了有意義的探索[11],對PLML 的＜implementation＞標簽重新做了設計,并在此基礎上設計了一個新的界面模式描述語言GUIDPLM 用于支持將界面模式自動化.但這些研究最終是通過在模式描述語言中嵌入具體的程序設計語言代碼(例如Java),以完成界面生成自動化.這并不能減少界面重復設計開發的問題.

基于以上研究,本文提出了一種基于PLML 的模式描述語言SPLML 描述界面模式,并設計了一個界面模式生成框架UIPF 支持不同平臺上的實際界面設計與開發,使得界面設計者不需要關注底層平臺的界面控件,從而形成一個較為完整的解決方案.

3 界面模式描述語言SPLML

SPLML 借鑒了GUIDPLM[11]的部分設計思想,基于PLML,其改進點在于簡化了PLML 中部分與結構化描述無關的界面模式說明及描述性標簽.SPLML 對＜implementation＞標簽進行重新設計,擴充了能夠表示基礎控件的新標簽,使其可以抽象的表示底層界面控件而又與平臺無關.最終由這些平臺無關的抽象控件構成界面模式.

3.1 SPLML 的結構

SPLML 文檔以XML 為描述語言,其根標簽為＜splml＞,內部可分為兩部分,首先是描述性部分,包括四個標簽＜name ＞、＜problem ＞、＜context ＞、＜solution＞,這部分采用半結構化描述,其主要功能是讓界面設計人員理解該模式要解決的問題和解決方案.除了＜name＞標簽外,其他幾個標簽并不會影響到后續對SPLML 文檔做自動化解析.第二部分是SPLML 的核心,即具體實現部分,主要是標簽＜implementation＞以及內部包含的各標簽及屬性.＜implementation＞標簽中可以包含一些SPLML 特有的抽象控件標簽,例如＜menu＞、＜button＞等,分別表示菜單、按鈕等控件,這些控件又可以包含位置、顏色、甚至回調句柄等屬性.SPLML 的結構如圖1 所示.

圖1 SPLML 的結構

這些可以添加到＜implementation＞內部的控件標簽,是我們對現有的界面設計模式及各平臺常用的界面基礎控件進行總結的基礎上定義的抽象控件標簽,在不同的平臺上可以被解析成具體控件,最終形成符合該平臺風格的用戶界面.這些控件包含了菜單、按鈕、卷滾條、文本框等常用控件,可以滿足絕大部分應用需求.同時,為了支持組合模式,即在一個界面模式中直接使用其他模式,SPLML 支持＜composite＞標簽,此標簽包含一個name 屬性,其值必須為模式庫中已有模式的名稱,否則該＜composite＞在界面自動生成時會被忽略.普通控件和＜composite＞標簽中表示的界面模式可以同時出現,并按既定規則渲染到界面上.

SPLML 的部分Schema 描述如下:

＜xs:element name="splml"＞

＜xs:element name="name" type="xs:string"＞

＜xs:element name="implementation"＞

＜xs:complexType＞

＜xs:sequence＞

＜xs:element name="textbox" type="xs:string"minOccurs="0"/＞

＜xs:attribute name="type" type="xs:string"use="required"/＞

＜xs:attribute name="chooser" type="xs:string"/＞

＜/xs:sequence＞

＜/xs:complexType＞

＜/xs:element＞

＜/xs:element＞

3.2 SPLML 舉例

下面使用一個SPLML 文檔(片段)的實例闡述其使用方法.本例中使用SPLML 描述了Dropdown Chooser[4](下拉選擇框)模式的使用,這里只呈現＜implementation ＞部分.

＜splml＞

＜name＞Dropdown Chooser＜/name＞

＜implementation＞

＜textbox type="input" chooser="calendar" action=”action"/＞

＜/implementation＞

＜/splml＞

在＜implementation＞標簽中,只描述了Dropdown Chooser 模式的核心組成部分,即一個輸入功能的文本框.同時chooser 屬性值為calendar,表示點擊文本框后出現的下拉選擇框是一個日歷,根據需求,這里還可以是時鐘、表格等控件.action 表示待響應事件的處理方法,本例中即選擇了下拉框中具體日期后系統做出的處理,可以由UIPF 框架(詳見第4 節)解析并回調.該模式的最終界面在不同的平臺上有不同的顯示風格,但其基本功能是一致的,體現了SPLML 的跨平臺性.例如,在Web 環境下,一個可能的展示如圖2 所示.

圖2 Web 環境下的Dropdown Chooser 模式

4 界面模式生成框架UIPF

為了能在實際開發中使用SPLML,我們設計了一個界面模式生成框架解析SPLML,并調用具體平臺圖形庫底層控件最終自動生成用戶界面.由于SPLML 的平臺無關性,我們在不同的平臺上構建了相應的UIPF,設計人員將界面描述成SPLML 后,可以在不同的平臺上被解析和使用,進而生成符合各自平臺風格的用戶界面.

4.1 UIPF 的整體結構

UIPF 的整體架構共分為3 層,如圖3 所示.

圖3 UIPF 的架構

4.1.1 SPLML 解釋器

頂層為SPLML 解釋器,負責解析SPLML 文檔.SPLML 解釋器本質上是一個XML 解釋器的擴展,最終將SPLML 文檔中的界面內容表述成一個由SPLML各抽象控件所組成的有向無圈圖,稱為PG.SPLML 中描述的各界面模式(或控件)在PG 中以葉子節點形式存在.后續UIPF 框架最終將PG 渲染到界面上,得到具體的用戶界面,也可以根據用戶行為刷新PG,完成和用戶的交互.這些工作由4.1.2 節中的邏輯界面生成層完成.

4.1.2 邏輯界面生成層

中間層是邏輯界面生成部分,為UIPF 的控制核心,分為3 個子模塊.

(1)渲染控制器負責將SPLM 解釋器生成的有向無圈圖表示成抽象控件的組合,這些控件是UIPF 定義的邏輯控件,并不與任何具體平臺相關.同時它還負責在運行時維護界面模型與視圖的一致性(詳見4.2 節).

(2)布局控制器的功能是控制整個界面的布局,包括界面邏輯控件的大小、位置、外觀等,在UIPF 中使用相對值表示(具體實現中使用配置文件或樣式文件管理).這部分的功能是根據SPLML 文檔生成了不依賴于特定平臺的邏輯界面.在具體實現上,布局控制器將整個應用的布局區分為整體布局和局部布局兩部分,且局部布局的優先級高于整體布局.

(3)事件轉換器的功能是將具體平臺界面控件的底層事件轉換成UIPF 框架的內部事件,使得系統中底層界面控件可以和上層UIPF 框架建立統一的運行機制,共同完成具體界面的渲染和構建.詳見4.3 節.

4.1.3 底層界面控件

底層為具體的平臺控件,是各具體平臺提供的基礎控件.在這一層中提供了對上層統一的接口,可以很好的屏蔽UIPF 框架對具體平臺控件的依賴.例如,我們在Web 環境下實現的WUIPF 框架,底層界面控件使用了Vue.js[12]提供的功能.在WUIPF 中,框架的上兩層與底層交互時,通過事件轉換器將UIPF 事件轉換成Vue.js 事件,并使用了Vue.js 的界面渲染機制構建出Web 界面框架.在其他平臺(如Android)上,也可以方便的使用類似的方式構建UIPF 框架.

4.2 UIPF 上模型與視圖的一致性

UIPF 上使用被稱為“動作”(action)的一組實體保持模型PG 和它的視圖之間的動態一致性.即用戶操作應用的界面元素時,會涉及界面呈現方式的實時變化,而這種變化通過底層控件庫的相應事件傳導到UIPF,并被轉換為UIPF 的抽象事件(詳見4.3 節),同時促使PG 做出符合用戶期望的更新,并及時刷新界面.從用戶觀點看,就是應用界面根據用戶期望的方式實時更新.

UIPF 定義了一組動作用來維護視圖與模型的一致性,例如RenderAction 表示重畫PG 上的節點,進而刷新界面;CallbackAction 表示執行應用設立的回調函數等.PG 中葉子節點既可以表示UIPF 定義的一個抽象控件,也可以表示一個特定的界面模式.而在UIPF 中,特定的模式是使用抽象控件組合而成,對模式使用者而言,其與原子的抽象控件并沒有區別,從而簡化了框架的實現過程.

4.3 UIPF 的事件模型

UIPF 事件模型的設計獨立于具體的應用平臺.UIPF 定義了一組抽象事件及一個事件轉換器,用來與具體平臺控件通信,從而能夠捕獲并理解底層控件的各種事件,并轉換為UIPF 能夠理解的抽象事件.這一機制可以驅動SPLM 解釋器生成的有向無圈圖PG 做出各種動作,滿足用戶的交互需求,并將結果反饋給事件轉換器,從而能夠再次和底層控件通信,最終完成用戶界面的改變,達到交互目的.UIPF 的事件模型如圖4 所示.

圖4 UIPF 的事件模型

例如,我們針對Web 平臺開發的WUIPF 框架原型中,當用戶做出交互行為時(例如點擊界面按鈕),用戶的行為被瀏覽器捕捉,轉換為Vue.js 事件,經由UIPF 事件轉換器,將其轉換為UIPF 能夠理解的抽象事件,而后驅動PG 做出刷新,后再將改動重新渲染到瀏覽器上,從而完成這次交互.

5 應用案例

我們使用SPLML 和UIPF 實現了一個在線個人事務助理系統ASSISTANT,該系統基于Web 和Android 平臺各自實現了客戶端.二者都使用了同樣的SPLML 文檔描述界面元素,并由基于不同平臺的UIPF 框架予以解析,最終形成符合各自平臺風格的用戶界面.

如圖5 和圖6 所示,WEB 客戶端由于屏幕尺寸大,我們將各類任務列表盡量放在同一個頁面上呈現,減少用戶切換頁面的頻率,增強用戶體驗.而在Android客戶端中,由于屏幕尺寸小,我們將任務分屏顯示,滑動屏幕即可自由切換,充分利用了移動客戶端中的交互手勢.實驗表明,這組界面具有較高的擴展性和可維護性,并能夠方便的為用戶使用.

圖5 Web 客戶端界面

圖6 Android 客戶端界面

在這個例子中,我們使用了Dashboard,Many Workspaces,Titled Sections,Liquid Layout,List Inlay,Button Groups[4]等大量界面模式,它們在不同平臺的UIPF 解析和渲染下,能夠呈現出不同的,但符合本平臺交互風格的用戶界面,而這一過程中,描述界面模式的SPLML 是一致的.這樣就達成了只描述一次界面模式,就可以到處運行的目的.

6 結論與展望

本文設計了一種設備無關的界面模式描述語言SPLML,并在不同平臺上實現了UIPF 框架用于支持各設備上基于模式的用戶界面自動生成,為減少建立多設備應用程序用戶界面的設計工作提供了一種途徑.實驗表明,該方案是可行和有效的.

下一步的工作包括:

(1)進一步擴充SPLML 能夠描述的模式庫和虛擬控件,使其能夠處理更多的用戶界面自動化場景.

(2)支持SPLML 中用戶自定義標簽的功能,使得整套方案更具有擴展性和靈活性.

(3)擴充UIPF 框架,使之能夠支持主流的服務器端接口,從而和SPLML 相結合,最終形成一個前后端統一的全棧解決方案.