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

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

2(西安工程大學(xué) 應(yīng)用技術(shù)學(xué)院,西安 710048)

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

1 概述

界面生成在軟件系統(tǒng)中占有重要地位.當前,由于計算設(shè)備的多樣性和運行平臺的差異性,使得幾乎每一款應(yīng)用都需要在不同的設(shè)備上開發(fā)相應(yīng)的客戶端界面.這導(dǎo)致了開發(fā)者會在不同平臺上使用底層控件和布局工具重復(fù)構(gòu)建同一應(yīng)用的界面,陷入到設(shè)計細節(jié)中.

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

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

2 相關(guān)工作

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

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

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

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

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

3 界面模式描述語言SPLML

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

3.1 SPLML 的結(jié)構(gòu)

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

圖1 SPLML 的結(jié)構(gòu)

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

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](下拉選擇框)模式的使用,這里只呈現(xiàn)＜implementation ＞部分.

＜splml＞

＜name＞Dropdown Chooser＜/name＞

＜implementation＞

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

＜/implementation＞

＜/splml＞

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

圖2 Web 環(huán)境下的Dropdown Chooser 模式

4 界面模式生成框架UIPF

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

4.1 UIPF 的整體結(jié)構(gòu)

UIPF 的整體架構(gòu)共分為3 層,如圖3 所示.

圖3 UIPF 的架構(gòu)

4.1.1 SPLML 解釋器

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

4.1.2 邏輯界面生成層

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

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

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

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

4.1.3 底層界面控件

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

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

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

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

4.3 UIPF 的事件模型

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

圖4 UIPF 的事件模型

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

5 應(yīng)用案例

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

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

圖5 Web 客戶端界面

圖6 Android 客戶端界面

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

6 結(jié)論與展望

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

下一步的工作包括:

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

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

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