Deﬁning Domain Speciﬁc Transformations in Human-Computer

Interfaces Development

Jean-S

ebastien Sottet and Alain Vagner

Public Research Center Henri Tudor, 29 Avenue John F. Kennedy, Luxembourg, Luxembourg

Keywords:

Human-Computer Interaction, Model-Driven Development, Model Transformation, Domain Speciﬁc Trans-

formation Languages.

Abstract:

Early model-based approaches for Human-Computer Interaction (HCI) clearly depicted models and frame-

works for generating User Interfaces (UI) but considered model transformations as black-boxes. In the 2000’s,

these approaches were criticized due to the poor quality of the produced UI. One of the main reasons of this

poor quality can be easily observed in state of the art UI transformations: they are the heart of designers’

know-how but are maintained by a minority of specialists. Meanwhile, mainstream UI design methods have

shown a growing number of heterogeneous stakeholders that collaborate to produce modern and qualitative

UI. We claim that these stakeholders must comprehend and interact with transformations and thus we need to

make the transformation language affordable to these stakeholders. Indeed, such a simpliﬁcation should hide

transformations complexity and burden for any stakeholder, ﬁnally focusing on a speciﬁc part of the design do-

main: a Domain Speciﬁc Language (DSL) for transformations or Domain Speciﬁc Transformation Language

(DSTL). We provide in this paper a method and a supporting tool for systematizing and ﬁnally executing

DSTL for model-driven UI development. We depict that framework on a proof of concept implementation for

an HCI-speciﬁc stakeholder: the usability expert.

1 INTRODUCTION

In the end of the 80’s, the development of Human-

Computer Interfaces (HCI) was not considered as a

particular task: it was done by any of the applica-

tion developers. The complexity and effort needed

for building User Interfaces (UI), like any other part

of information systems, were considerably growing

up during the last decades. In order to solve this com-

plexity issue and reduce the consequent cost, some

tried to generate the user interfaces. These approaches

considered that an important part of the UI has already

been made during the data and functional architec-

ture design. Thus, early academic work in this area

was focused on model-based approaches and frame-

works (Szekely et al., 1992; Vanderdonckt, 1995;

Puerta, 1997) for automatizing the creation of UI.

The focus of these ﬁrst model-based frameworks

was the establishment of (meta)models (e.g., expres-

sive power, deﬁning the concerns, etc.) whereas trans-

formations were seen as black boxes. More recently,

Model Driven Engineering (MDE) has inﬂuenced the

model-based HCI approaches. Transformations have

been more explicitly deﬁned and speciﬁcally instru-

mented by tools such as ATL (Botterweck, 2011; Sot-

tet et al., 2007), EMFText and Kermeta (Beaudoux

et al., 2010) or graph transformations (Stanciulescu

et al., 2005). They are thus an important artefact to be

considered in the automation of HCI development.

It is admitted that recent UI design projects (as

in any software part) involve collaboration between

various stakeholders, e.g., graphical designers, us-

ability specialists, analysts, etc. However several au-

thors claimed that using traditional MDE approaches

is a specialist work (e.g., transformation engineers)

that requires an important training. For instance

in (Coutaz, 2010; Panach et al., 2011), the authors

consider that traditional transformation languages re-

quire speciﬁc skills and could not be written by any

HCI stakeholder.

As a result, model transformations are very com-

plex to understand for many stakeholders. They could

not use or modify transformations in the same way

they impact models. For instance, a graphical de-

signer is traditionally using a mock-up tool, such as

balsamiq

which is a domain speciﬁc modelling en-

http://balsamiq.com/

246

Sottet J. and Vagner A..

Deﬁning Domain Speciﬁc Transformations in Human-Computer Interfaces Development.

DOI: 10.5220/0004699702460253

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 246-253

ISBN: 978-989-758-007-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

vironment. Thus, it seems important that designers

could also drive some of the transformation aspects

related to graphical design if we want to build quali-

tative HCI.

In this paper we strive for a better stakeholder in-

volvement (not only the developers) in Model-Driven

Development (MDD) transformation processes for

HCI. To reach this objective we must ﬁrst (section 2)

ﬁnd which stakeholders are concerned and understand

the need for building a Domain Speciﬁc Transforma-

tion Language (DSTL). We propose such a language

in section 3. Finally, in the section 4, we propose

a systematisation of DSTL construction, making it

more speciﬁc to the problem to be addressed. In this

section we also propose an approach to execute the

transformations expressed in our DSTL.

2 HCI DESIGN STAKEHOLDERS

AND THE TRANSFORMATION

PARADIGM

2.1 Model-Based Framework for User

Interfaces Design

HCI research in Model-based UI elicited a common

reference framework: CAMELEON (Calvary et al.,

2003). This framework is made of several metamod-

els (see Figure 1, the 4 core metamodels) in which

different aspects of HCI engineering are represented.

The CAMELEON models correspond to speciﬁc do-

mains such as graphical design (Concrete UI model,

CUI), functional analysis (Task Model), domain anal-

ysis (Domain Model), interaction design (Abstract UI

model, AUI), all of which lead to the production of the

UI code (Final UI, FUI).

Each stakeholder has his own background knowl-

edge and expertise domain: usability expert, system

analyst, graphical designer, developer, etc. All these

stakeholders may be disappointed by standard trans-

formation languages, like ATL. In practice they are

not directly involved in the deﬁnition of transforma-

tions but, at best, give advice on the transformation

result. For instance, the usability expert would rec-

ommend to use alphabetically ordered lists for the se-

lection of a contact in an address book.

In Figure 1, we show the envisioned distribution of

stakeholders on the design process and their potential

interactions on transformations and models. The main

stakeholders are the following:

Designers: have an interest on the concrete UI:

layout, graphical elements, mock-ups, etc. Thus, de-

signer could have an impact on the transformations

proposed between CUI and FUI.

Developers: classical development process could

start after CUI speciﬁcation. Developers have an im-

pact on the FUI (e.g., code). On the contrary, in a

transformation-based approach, developers will have

to dig CUI to FUI transformations and tune, if neces-

sary, both transformations and FUI.

Analysts: on the contrary to the developer role,

analysts have an early impact on forward engineering

based on task and domain models. In addition, they

can have an impact on transformations from domain

to AUI.

Usability Experts: have a potential impact on all

transformation steps since usability principles can be

diluted all along the forward engineering steps.

Task &

Domain

CUI

FUI

AUI

Analyst(s)

Ergonomists

Developer

Designer

Figure 1: HCI Stakeholders interest on transformation pro-

cesses in the CAMELEON Framework.

The CAMELEON framework depicts clearly

(meta)models to be used at each step of the process

(see Figure 1) and it is also quite straightforward to

ﬁnd which stakeholders will act on which speciﬁc as-

pects. We claim that every stakeholder could impact

positively the transformation processes.

2.2 Transformation complexity

As mentioned in (Sendall and Kozaczynski, 2003)

writing transformations requires a clear understand-

ing of input and output semantics. By the way, who

knows and understands the input and output domains?

A relevant answer is certainly: the people who also

participate in modelling activities.

The problem stands not only on (meta)model

understanding but also on transformation languages

complexity. Let’s take for instance the refImmediate-

Composite() symbol, which refers to the immediate

parent of an EMF composition in the ATL language

(Jouault and Kurtev, 2005). It does not directly de-

pend on the input or output models and metamodels

(but on the supporting metametamodel). In addition,

transformations embed some verbosity for technical

(e.g., give name or id to modelling elements) or struc-

tural (e.g., graph search) handling of metamodels. As

we can see on Listing 1, getting a simple label for

a Concrete UI calls for a lot of “structural coding”:

DefiningDomainSpecificTransformationsinHuman-ComputerInterfacesDevelopment

247

id, name and content of the label. Most of this code

is certainly a burden for a non-technical stakeholder,

who would rather simply say: “for this particular task

I would like to produce a label which takes the task

name”. Indeed most of the stakeholders are usually

reluctant to learn such “OCL-like” syntax.

Listing 1: Deﬁning a label for a Graphical User Interface.

t o ou t _ l abe l : CUI ! Label (

name <−in_tsk . name , -- copy the name of the t a s k

id <−in_tsk . g etID ( ) , -- get the id from task

value <− in_ t s k . a s s o c iations−>first ( ) .

,→m a ni p ula t edC o nce p ts . name , -- set the

,→c o n t ent of label

We claim that a collaborative building of transfor-

mations is the clue for more efﬁcient MDD of HCI.

Going in such direction could be an answer to the

bad conclusion of the ﬁrst generation of model-based

UI approaches (Myers et al., 2000). In order to sup-

port this claim we need to tackle several drawbacks of

classical transformation approaches:

• existing work rarely depicts what information is

added in the transformation processes (e.g., which

know-how to implement). Lot of heuristics are

provided but not necessary implemented, e.g., UI

adaptation (Florins and Vanderdonckt, 2004).

• transformations are either seen as black-box or ex-

pressed in a complex language for “transforma-

tion experts”. Thus, domain experts are unable to

express their “transformation heuristics”.

• in order to facilitate the adoption and commit-

ment/involvement of stakeholders, transforma-

tions have to be explained to each (collaborating)

stakeholders.

In this paper, we concentrate our effort on in-

volving usability experts in the design of transforma-

tions. Firstly because promising work tries to em-

bed usability criteria (Sottet et al., 2007; Garc

ıa Frey

et al., 2011) into transformations but without involv-

ing usability experts directly (e.g., deﬁning criteria of

transformations a priori). Secondly, because usability

experts are certainly the less technical stakeholders.

Their tasks are mainly dedicated to prototype (or end-

product) usability assessments. We are convinced that

they could have an interesting impact in early design

phases and avoid cycles of redesign by re-writing the

transformations.

It seems necessary, in order to involve domain spe-

cialists such as the usability expert to deﬁne a Domain

Speciﬁc Transformation Language (DSTL). It seems

to be a solution to cope with the complexity of stan-

dard transformation languages.

3 DOMAIN SPECIFIC

TRANSFORMATION

LANGUAGE

In the previous section, we have justiﬁed the need

for deﬁning a dedicated language, that should help

stakeholders to participate in the transformation de-

sign process. Notably we want them to understand the

transformation effects and involve them in the trans-

formation design. The idea is not to create a fully

functional language for deﬁning transformations but

to provide handlers (i.e., speciﬁc parts of the trans-

formation that drive the transformation heuristics) to

speciﬁc stakeholders in order to give them control

only on aspects, that would be of interest to them.

We previously established that the usability expert

is a key stakeholder of the AUI to CUI transformation

(see Figure 1). The transformation vocabulary must

be adapted to the usability expert and the structural

aspects of transformations (syntactic overload) must

be hidden. Most of the usability experts are more used

to unstructured languages. In order to design such a

language, we must address the following points:

• deﬁne the input vocabulary: usability experts un-

derstand the “interaction type” notion also called

canonical abstract types (Constantine, 2003) that

are used as a basis for model-based approaches.

For instance, all tasks with type “choice of an el-

ement amongst n” reﬂect an interaction pattern

known by usability experts.

• deﬁne the output vocabulary: an usability expert

understands what the elements of a ﬁnal user in-

terface are, for instance indexed lists, scroll lists,

etc.

• composing the transformation: the transforma-

tion must be easy to write (e.g., using auto-

completion) and have limited choices (e.g., list

of elements). This can considerably shorten the

learning and design time.

The process

depicted in ﬁgure 2 encompasses

the ﬁrst important step for transformation simpliﬁ-

cation by simplifying input and output vocabularies,

in other words getting a subset of these metamod-

els. Our input metamodel is named TDA (for Task

Domain Abstraction) and bring together the concepts

coming from CAMELEON task metamodel, domain

metamodel and interaction types (AUITypes). One

has to identify which portion of this input metamodel

is really impacting the transformation. In a previ-

ous project (Sottet and Vagner, 2013), we designed

This process could be generalized to other kinds of

metamodels and with multiple input/ouput metamodels.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

248

many TDA to CUI transformations with ATL. We

have identiﬁed that the “interaction type” is the most

used type in the transformation ﬁlter (e.g., the dis-

criminating factor). We have done the same for the

CUI, deﬁning which elements are of importance ac-

cording to the study of existing transformations (see

Reduced M2 TDA/CUI on Figure 2).

12-Jul-13 Presentation Tudor 47

Subset of

from M2’TDA element

To M2’CUI element

M2 TDA

M2 CUI

Reduced

M2 TDA

Reduced

M2 CUI

Figure 2: Process applied for speciﬁc transformation build-

ing for Task/Abstract UI model and CUI.

As an example, in natural language, usability ex-

perts usually provide some sentences (i.e., rules) like

“It would be nice if all interactive lists could be dis-

played as indexed lists”. Indeed, such form of sen-

tence requires some advanced techniques in natural

language processing in order to be able to interpret

and execute this sentence. Moreover, some provided

sentences can be contradictory, ambiguous, etc. In

this paper we do not provide such advanced natural

language processing tool but rather a controlled lan-

guage for transformation rules speciﬁcation by usabil-

ity experts.

Such an approach (grammar deﬁnition and text

editor) can be easily obtained by writing Xtext code

or using other DSL workbenches such as MetaEdit+

One can summarise the basic speciﬁc HCI transfor-

mation rules (for obtaining simple form-based UI)

as a set of 6 sentences/rules (see listing 2, one for

each interaction type, and APPENDIX 2 for an ex-

cerpt of the related Xtext grammar). In addition to this

syntactical simpliﬁcation and auto-completion, Xtext

comes with interactive lists (see Figure 3) for limited

choices which considerably reduces the error and time

to write such transformations.

Listing 2: Set of rules for building form-based interfaces

from TDA model to CUI model.

r u l e from C o ntai n e r int e r act i v e t o Windo w wi th

,→ A l l C once p t s ;

r u l e from C o ntai n e r no t i nte r act i v e t o Panel w it h

,→ No C o n c e p t s ;

r u l e from O u t p u t int e r act i v e t o Panel w it h A l l

,→ C o n c e p t s ;

r u l e from In p u t i n ter a c tiv e t o D ataF i e ld ;

r u l e from C h o i c e 1 / n in t e rac t i ve t o

,→L i st E lem e ntS e lec t or w i th A l l C once p t s ;

http://www.eclipse.org/Xtext/

http://www.metacase.com/mep/

r u l e from C h o i c e n / n inte r acti v e t o

,→L i st E lem e ntS e lec t or w i th A l l C once p t s ;

15-Jul-13 Presentation Tudor 48

Figure 3: List of possible widgets (output metamodel) to

bind with input Task elements.

We can extend this language to operators (more,

less, equal) that can complete the ﬁrst part (i.e., from)

like for example: “I want all interactive lists contain-

ing more than 6 elements...”. It makes the language

more complete because some rules have a speciﬁc

threshold which can be deﬁned the usability specialist

experience.

Obviously this solution considerably reduces the

expression power of these transformations, but this

helps the stakeholders to better grasp the effects/re-

sults of the transformation. In order to support the

execution of these transformations, we have to com-

plete them by generic code expressed in the underly-

ing transformation language (see section 4).

4 SYSTEMATISATION AND

EXECUTION

As mentioned in (Mernik et al., 2005) developing a

DSL is not for free. A lot of inherent costs have been

identiﬁed in the development of DSL like: (1) the

training of the community and (2) the implementa-

tion of an interpreter/compiler for execution purposes.

The cost of training the usability expert to our DSTL

would certainly not exceed the training to standard

transformation tools.

In order to simplify the development of such a

transformation DSL we provide a way to systema-

tise some of its construction aspects (See Section 4.1).

It encompasses the automatic extraction of input and

output patterns directly from metamodels. Finally we

provide an Higher Order Transformation (Tisi et al.,

2009) - HOT - (i.e., transformations which process

other transformations) to support the execution of

DSTL using existing transformation technologies (see

Section 4.2).

4.1 Systematisation

Our DSTL, see Listing 2, is obtained by analysing

both input and output metamodel elements (see Fig-

ure 2). This is a kind of HOT, which acts as

DefiningDomainSpecificTransformationsinHuman-ComputerInterfacesDevelopment

249

a parametrization of a transformation (Tisi et al.,

2009). As we already mentioned in the previous sec-

tion, for the input metamodel (e.g. Task-Domain-

Abstraction), we use the interaction type as the trans-

formation rules key input (e.g., it is the discriminat-

ing factor that drives the transformations). The output

metamodel contains a structured list of Concrete UI

elements (e.g., set of description of widgets to be dis-

played such as a button, a list, a menu, etc.). These

CUI elements are the choice that the usability expert

will have to do when generating user interfaces.

15-Jul-13 Presentation Tudor 48

M2 TDA

M2 CUI

M2 DSTL

DSTL

generated

DSTL

handwritten

EMF

Xtext Grammar

ATL

Acceleo

Figure 4: Automation of the creation of the DSTL grammar.

The idea is not write Xtext grammar code

but to

partially generate the grammar from the two meta-

models. The core idea (see ﬁgure 4) is to extract the

information from each metamodel in order to obtain

the input and output vocabularies for our DSTL (see

Section 3).

To perform this task we ﬁrstly transform (using

ATL transformations) the selected elements from two

metamodels into a DSTL speciﬁcation. This speciﬁ-

cation is an EMF model conform to our DSTL meta-

model. From the TDA metamodel (see Listing 3),

we select the “AUIType” (i.e., the canonical abstract

type) as the DSTL input pattern based on the enumer-

ation literals. From the CUI metamodel we extract

each element (i.e., graphical widgets such as button,

list, etc.). Once we got this DSTL (EMF) model built,

we extract from it a partial Xtext grammar thanks to

an Acceleo template. The two examples of generated

excerpts are available on Figure 5 in the lower left and

lower right boxes. These models are later combined

with a generic core transformation grammar (see 5

middle part) into the ﬁnal DSTL grammar.

Listing 3: Excerpt of ATL Code for exporting Task (TDA)

model enumeration (EEnumliteral from EMF) of types into

a DSTL input pattern.

r u l e T D AE n u me r at i onT a sk T oI n p ut E le m ent {

from

inE n u mLit : EMF ! EEn u m Lit e r al ( i nEnu m L it .

,→r e fI m med i at e C om p o si t e ( ) . name =’ A U I T ype ’ )

t o

This is trivial in this example. However it may be very

error-prone as one could forget to copy some elements.

inPat t : DSTL ! I n put E lem e n t (

name <− i nEn u m L it . name ,

el e m en t C on c e rn e d <− # ” T a s k ” )

}

15-Jul-13 Presentation Tudor 49

Type :

‘Container’ |

‘Output’ | ‘Input’ |

‘Choice 1/n’

‘Choice n/n’;

Elements :

‘Window’ |

‘Panel’ | ‘Sorted List’

| ‘IndexedList’ |

etc…;

Transformation

‘rule’ ‘from’ type=Type

‘to’ el=Elements;

M2 TDA

M2 CUI

DSTL

handwritten

DSTL

generated

DSTL

generated

Figure 5: Automation of process from Figure 2.

4.2 Executing the Domain Speciﬁc

Transformation Language

The DSTL speciﬁed in APPENDIX 2 is a simpliﬁca-

tion of the ATL transformation “from TDA to CUI”.

If the expressive power of such a language is inten-

tionally reduced, the technical and structural aspects

remain hidden behind the scenes in ATL generic code.

Indeed, we provide the stakeholders with a language

that intentionally does not cover all the aspects of a

transformation.

The execution semantics is provided by a general

purpose transformation language (GPTL). Here we

have chosen the ATL transformation language as tar-

get GPTL from our DSTL. In fact, the process that

derives GPTL rules from DSTL rules is also a HOT.

In practice, it consists in combining the DSTL model

(established using the Xtext textual editor from the

generated grammar) and existing core rules (i.e., writ-

ten by transformation specialists).

We have chosen Acceleo

, because (1) it is more

efﬁcient for writing code (i.e., Model to Text) than

ATL itself and (2) it is easier to integrate in the tem-

plate the existing technical ATL code

. We show

an excerpt of the main rule template in the AP-

PENDIX 1 section. It provides, for a DSTL model,

the ATL transformation input-pattern for the AUItype

plus some hand-written ﬁlters in order to avoid rules

overlapping (not accepted by the ATL compiler). For

the out-pattern (i.e, after the to) another rule is making

the link between DSTL and ATL-based CUI elements

(cOutPattern).

Finally an ATL transformation is produced: ready

to be compiled and executed. It integrates both previ-

ously implemented ATL transformations (made by a

transformation expert) and ATL code produced from

www.acceleo.org

Generic structural manipulations of metamodel in ATL

(e.g., helpers, call of libraries) are provided.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

250

the HCI DSTL transformation. You can ﬁnd an ex-

ample in the listings 4 and 5.

Listing 4: Example of rule expressed according to the

DSTL

r u l e from C h o i c e 1 / n in t e rac t i ve t o

,→L i st E lem e ntS e lec t or w i th A l l C once p t s ;

Listing 5: Generated ATL code corresponding to the rule

deﬁned in listing 4.

r u l e s e le c t io n _1 _ nT o L is t El e me n t Se l ec t or {

from

in_ts k : TDA ! Task (

in_ts k . au i T y pe =#” s e l ect i o n_1 _ n ”

and in_tsk . i s In t e ra c tiv e lyV a li d ( ) )

t o

out : CUI ! Lis t Ele m en t S el e c to r (

name <− i n _tsk . name ,

id <−in_tsk . g etID ( ) ,

co n tai n edE l eme n ts <− in_ t s k . a s s o c iations−>

,→c o l l ect ( e | this M o dule .

,→D oma i nA t tri b ut e ToI n te r act o r ( e .

,→m a ni p ula t edC o nce p ts ) ) )

}

5 RELATED WORK

Some related work in MDE and HCI engineering pro-

motes the adaptation of transformation languages for

speciﬁc purposes.

In (Agrawal et al., 2003), the authors propose a

UML visualisation of graph transformations, that ad-

dresses people who are accustomed to UML syntax.

In the same idea, UMLx (Willink, 2008), provides

a graphical representation of transformations. In-

deed, it is still not adapted to a wide variety of stake-

holders (speciﬁcally in UI design), but promotes syn-

tactical simpliﬁcations of transformations.

RubyTL (Cuadrado et al., 2006) is an implementa-

tion of a transformation language using a speciﬁc and

extensible language. Extensibility is another way to

provide more speciﬁc transformations (specialized re-

garding in/output metamodels). It provides the trans-

formation designers with more speciﬁc rules.

In order to make transformations easier to non-

transformation specialists, one can use natural lan-

guage, giving “more sense” such as in (St

orrle, 2013).

For instance, in Natural MDA (Leal et al., 2006), the

idea is to use a controlled natural language for ex-

pressing business rules. We can easily extend that to

transformation rules. Natural MDA approach is simi-

lar to our transformation writing principles. However,

here we propose mechanisms to semi-automatize the

building process of such a language.

In (Sottet et al., 2009), authors propose the notion

of trans-HCI: a speciﬁc UI on top of a transformation

language. We implement that idea here using a tex-

tual editor for transformations. (Aquino et al., 2010)

propose a framework for establishing transformation

templates, that are easier to understand and manip-

ulate than standard transformations. These transfor-

mations are edited thanks to the template and then

executed within a standard transformation engine:

proposing an upper-layer above transformations. If

similar to our approach, transformation templates, do

not hide some of technical aspects (e.g., necessity to

provide types for values: real, string, boolean) which

may confuse the stakeholders.

The paper of (Tisi et al., 2009) provides examples

and a classiﬁcation of Higher Order Transformation

(HOT). We have been inspired by several kinds of

HOT, notably the (Muliawan, 2008) approach. It is

used to simplify and to make existing transformations

more speciﬁc while keeping them executable. As in

this paper, we transform input and output metamodels

to pre-conﬁgure a transformation. Nevertheless, we

go a step further deﬁning a domain speciﬁc transfor-

mation language and thus we provide a speciﬁc syntax

dedicated to particular stakeholders concerns. We use

another kind of HOT in order to generate ATL code

from our DSTL.

As a summary, related work address technolo-

gies to make transformations clearer, notably through

adapted syntaxes (either textual or graphical) and by

proposing extension and specialization mechanisms.

We could indeed use these mechanisms to improve

some parts of our work: graphical syntax, exten-

sion mechanisms, enhancing our HOT approach, etc.

However, related approaches do not explicitly address

human-centric aspects e.g., the stakeholders skills.

For instance, the transformation template approach

embed too much concerns into the transformation that

could be a burden for stakeholders. On the con-

trary we deliberately give a simpliﬁed transformation

model to avoid technical burden.

6 CONCLUSIONS

The integration of MDE in the HCI community is not

uniform: although models found rapidly acceptance

it is not the same for transformations. The poor qual-

ity of some generated UI and the opaque deﬁnition of

transformations make them hardly accepted by some

HCI stakeholders and researchers. People would pre-

fer to use their standard design/implementation pro-

cesses instead of something they do not understand

clearly.

DefiningDomainSpecificTransformationsinHuman-ComputerInterfacesDevelopment

251

In this paper, we claim that stakeholders knowl-

edge and know-how are ﬁrst order citizen to build

more efﬁcient transformations for more qualitative

UI. We have to aim not only at people that are trained

to write transformations but to all kinds of HCI stake-

holders. As a result, we will naturally refer to the

deﬁnition of a stakeholder (i.e., domain) speciﬁc lan-

guage for designing transformations. Domain spe-

ciﬁc transformations tend to be closer to the stake-

holder vocabulary and to be enough focused on the

transformation rationale. They thus provide targeted

stakeholders with a support to express transformation

heuristics and participate to the transformation de-

sign.

Our DSTL implementation (and related gener-

ation/extraction transformations) targets a speciﬁc

stakeholder: the usability expert. To our experience,

this is certainly the most representative case for HCI

building: (1) the classic usability expert proﬁle is ori-

ented towards social science and (2) usability qual-

ity is crucial in HCI design. We provide the usability

expert with a very simple language (controlled natu-

ral language), that helps in the generation of adapted

(i.e., more usability regarding the situation) widgets.

We do not redesign a complete transformation lan-

guage but rather provide some handlers for speciﬁc

stakeholders. Such stakeholders act only on the spe-

ciﬁc transformation part while hiding the transforma-

tion inner mechanisms inside a traditional transforma-

tion in “back-end”. Thus, there is still room for code

transformation to be written by an expert (e.g., struc-

tural information).

On the HCI engineering side, our DSTL approach

provides a way to: (1) capture speciﬁc know-how

(this is usually done as assessment report after pro-

duction of prototype) and make it executable, (2) in-

volve more stakeholders in the MDE transformation

design (3) by this involvement, provide a better ac-

ceptance of MDE approaches for HCI.

Technically, on the MDE side, we propose a

generic approach for systematising the deﬁnition of

DSTL based on HOT principles that: (1) provides

a reduced set of input/output metamodels (that are

speciﬁc to the stakeholder job), (2) derives (semi-

automatically) a textual syntax to specify simpliﬁed

transformation rules and (3) allows the execution of

transformations.

This work is a ﬁrst proof of concept in the HCI

domain and more speciﬁcally addressing usability ex-

perts concerns. During this research process we did

ask some usability experts their feeling about the stan-

dard transformation tools and they helped us design-

ing the DSTL. However, we need more stakeholders

to validate our approach regarding the HCI commu-

nity. We try to present an initial instrumented method-

ology that can be generalised to other stakeholders

and domains. Future work will concentrate on pro-

viding other DSL for other types of stakeholders and

will try to address collaboration issues during trans-

formation design.

ACKNOWLEDGEMENTS

This work has been partially supported by the Lux-

emburgish FNR MoDEL project (C12/IS/3977071).

REFERENCES

Agrawal, A., Karsai, G., and Shi, F. (2003). A uml-

based graph transformation approach for implement-

ing domain-speciﬁc model transformations. Interna-

tional Journal on Software and Systems Modeling.

Aquino, N., Vanderdonckt, J., and Pastor, O. (2010). Trans-

formation templates: adding ﬂexibility to model-

driven engineering of user interfaces. In Proceedings

of the 2010 ACM Symposium on Applied Computing.

Beaudoux, O., Blouin, A., and J

equel, J.-M. (2010). Us-

ing model driven engineering technologies for build-

ing authoring applications. In DocEng ’10: Proc. of

the 2010 ACM symposium on Document engineering.

Botterweck, G. (2011). Multi front-end engineering. In

Model-Driven Development of Advanced User Inter-

faces, pages 27–42. Springer.

Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouil-

lon, L., and Vanderdonckt, J. (2003). A unifying ref-

erence framework for multi-target user interfaces. In-

teracting with Computers, 15(3):289–308.

Constantine, L. (2003). Canonical abstract prototypes for

abstract visual and interaction design. In Interactive

Systems. Design, Speciﬁcation, and Veriﬁcation.

Coutaz, J. (2010). User interface plasticity: Model driven

engineering to the limit! In Int. Conf. on Engineering

Interactive Computing Systems (EICS 2010). Keynote

paper.

Cuadrado, J. S., Molina, J. G., and Tortosa, M. M. (2006).

Rubytl: A practical, extensible transformation lan-

guage. In Rensink, A. and Warmer, J., editors, Model

Driven Architecture Foundations and Applications.

Florins, M. and Vanderdonckt, J. (2004). Graceful degra-

dation of user interfaces as a design method for multi-

platform systems. In IUI, volume 94, pages 13–16.

Garc

ıa Frey, A., C

eret, E., Dupuy-Chessa, S., and Calvary,

G. (2011). QUIMERA: a quality metamodel to im-

prove design rationale. In Proc. of the third ACM

SIGCHI Symp. on Engineering Interactive Computing

Systems (EICS).

Jouault, F. and Kurtev, I. (2005). Transforming mod-

els with atl. In Proceedings of the 2005 interna-

tional conference on Satellite Events at the MoD-

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

252

ELS, MoDELS’05, pages 128–138, Berlin, Heidel-

berg. Springer-Verlag.

Leal, L. N., Pires, P. F., Campos, M. L. M., and Delicato,

F. C. (2006). Natural mda: controlled natural lan-

guage for action speciﬁcations on model driven de-

velopment. In On the Move to Meaningful Internet

Systems 2006: CoopIS, DOA, GADA, and ODBASE.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

Comput. Surv., 37(4):316–344.

Muliawan, O. (2008). Extending a model transformation

language using higher order transformations. In Re-

verse Engineering, 2008. WCRE’08. 15th Working

Conference on, pages 315–318. IEEE.

Myers, B., Hudson, S. E., and Pausch, R. (2000). Past,

present, and future of user interface software tools.

ACM Transactions on Computer-Human Interaction

(TOCHI), 7(1):3–28.

Panach, I., Aquino, N., and Pastor, O. (2011). A model for

dealing with usability in a holistic mdd method. User

Interface Description Language (UIDL).

Puerta, A. R. (1997). A model-based interface development

environment. Software, IEEE, 14(4):40–47.

Sendall, S. and Kozaczynski, W. (2003). Model transfor-

mation: The heart and soul of model-driven software

development. Software, IEEE, 20(5):42–45.

Sottet, J.-S., Calvary, G., Coutaz, J., and Favre, J.-M.

(2007). A model-driven engineering approach for the

usability of plastic user interfaces. In Engineering In-

teractive Systems, pages 140–157. Springer.

Sottet, J.-S., Calvary, G., Favre, J.-M., and Coutaz, J.

(2009). Megamodeling and metamodel-driven en-

gineering for plastic user interfaces: mega-ui. In

Human-Centered Software Engineering, pages 173–

200. Springer London.

Sottet, J.-S. and Vagner, A. (2013). GENIUS: Automati-

cally generating usable user interfaces. Technical re-

port, PRC Henri Tudor, Luxembourg.

Stanciulescu, A., Limbourg, Q., Vanderdonckt, J., Mi-

chotte, B., and Montero, F. (2005). A transformational

approach for multimodal web user interfaces based on

usixml. In Proc. of the 7th inter. conference on Multi-

modal interfaces, ICMI ’05, pages 259–266.

orrle, H. (2013). Making sense to modelers: Presenting

uml class model differences in prose. In 1st Interna-

tional Conference on Model-Driven Engineering and

Software Development (MODELSWARD 2013).

Szekely, P., Luo, P., and Neches, R. (1992). Facilitating

the exploration of interface design alternatives: the

HUMANOID model of interface design. In Proc. of

the SIGCHI conf. on Human factors in computing sys-

tems.

Tisi, M., Jouault, F., Fraternali, P., Ceri, S., and B

ezivin, J.

(2009). On the use of higher-order model transforma-

tions. In Model Driven Architecture-Foundations and

Applications, pages 18–33. Springer.

Vanderdonckt, J. (1995). Knowledge-based systems for au-

tomated user interface generation: the trident experi-

ence. In Proceedings of the CHI, volume 95. Citeseer.

Willink, E. D. (2008). On challenges for a graphical trans-

formation notation and the umlx approach. Electronic

Notes in Theoretical Computer Science, 211:171–179.

APPENDIXES

1. Acceleo template for ATL code generation from a

DSTL model.

[ t e m p l a t e p r i v ate gRule ( rule : Rule ) ]

rule [ r u l e . a u i t y pe . c o n c at ( ’To ’ ) . con c a t ( nameS t r ing

,→ ( rule . uiel e m ent ) ) / ] {

from

in_ts k : TDA ! Task ( [ i f ( r u l e . aui t y p e .

,→e q ua l s Ig n o reC a se ( ’ Root ’ ) ) ]

( maintsk . s u per O per a t or . o c lIs U nde f i ned

,→ ( ) ) [ e l s e ]

in_ts k . au i T y pe = #”[ rule . auit y p e / ] ”

[ i f ( r u l e . i n te r a ct i v el y V al i d .

,→e q ua l s Ig n o reC a se ( ’ int e ract i v e ’ ) )

,→ ]

and i n_tsk . i s In t e ra c t iv e lyV a lid ( )

[ / i f ]

[ i f ( r u l e . i n te r a ct i v el y V al i d .

,→e q ua l s Ig n o reC a se ( ’ no t i nte r act i v e

,→’ ) ) ]

and i n_tsk . t y p e =#” a b strac t ” and i n_tsk .

,→i s No t L ea f N orR o ot ( )

[ / i f ]

[ / i f ] )

[ r u l e . u i e leme n t . c O utP a t ter n ( ) / ]

}

[ / t e m p l a t e ]

2. Excerpt of the DSTL Xtext grammar.

Rule :

’ r u l e

from ’ a u i t ype = Type ( ’ and ’

,→i n te r a ct i v el y Val i d =Valid ) ? ’ to ’

,→u i e leme n t =UIEl e m ent ’; ’ ;

Type :

’ C hoice n /n ’ | ’ Choic e 1/ n ’ | ’ Co n t a ine r ’ | ’

,→Inpu t ’ | ’ Output ’ | ’ C o m mand ’ | ’

,→N a viga t i on ’ | ’ R o o t ’ ;

UIE l e ment :

Windo w | L ist E lem e nt S e le c t or | Bu t t o n | P a n e l

,→ | Dat a F ield | I m ageF i e ld | Te x t Fiel d |

,→T e x tArea ;

Windo w :

’ W indow ’ l a b e l+=Label ? ’ with ’

,→c o nt a i ne d E le m e nt s += Co n c e pt ;

Panel :

’ P a nel ’ labe l += Label ? ’ with ’ c ont a ine d Ele m ent s

,→+=C o n c ept ;

Li s tEl e men t Se l e ct o r :

’ Li s t El e m en t S el e cto r ’ label = Label ? ( ’ with ’

,→c o nt a i ne d E le m e nt s += Co n c e pt ) ? ;

Conc e p t :

’ A ll Co n c e pts ’ | ’ No C oncep t s ’ | s elec t i on +=

,→S e lec t edC o nce p t ∗ ;

DefiningDomainSpecificTransformationsinHuman-ComputerInterfacesDevelopment

253