=Paper= {{Paper |id=Vol-214/paper-11 |storemode=property |title=Using HCI-Patterns with Model-based Generation of Advanced User-Interfaces |pdfUrl=https://ceur-ws.org/Vol-214/paper11.pdf |volume=Vol-214 |dblpUrl=https://dblp.org/rec/conf/models/RathsackWF06 }} ==Using HCI-Patterns with Model-based Generation of Advanced User-Interfaces== https://ceur-ws.org/Vol-214/paper11.pdf

Using HCI-Patterns with Model-based Generation of
Advanced User-Interfaces
Robert Rathsack, Andreas Wolff Peter Forbrig
University of Rostock University of Rostock
Institute of Computer Science Institute of Computer Science
Albert Einstein Str. 21, Albert Einstein Str. 21,
18059 Rostock, Germany 18059 Rostock, Germany
Andreas.Wolff@informatik.uni-rostock.de pforbrig@informatik.uni-rostock.de

necessity of separate mapping definitions for PICs. Details
ABSTRACT about this procedure can be found in [7].
In the HCI community a number of pattern catalogues were
created during the last years. Due to the nature of such Within the first part of this paper we present the extensions
patterns they are often described high-level and abstract. In to a pattern-language that we found necessary to define
this paper we present an approach to translate at least a PICs and explain how mapping files can be used to generate
certain kind of patterns into a machine readable form, while CUIs from abstract user interfaces that were furnished with
keeping them abstract in terms of problem independence. HCI-pattern information.

Those translated HCI patterns can be used for a semi- REALISATION OF PATTERN AS COMPONENTS
automated MDA-procedure using device- and mapping A pattern is an abstract description of a best-practice for a
definitions. Also an example for this development cycle, a certain problem. HCI patterns in catalogues are described in
sequence of pattern-based transformations, is presented. a textual manner, often with a graphical example and
sometimes sample source code or other implementation
INTRODUCTION hints. Such a description is insufficient for MDA purposes,
Object-oriented design patterns, as introduced by Gamma because it cannot be used for automated model
et. al., are considered as valuable aid in software transformations.
development. A comparable benefit is expected of HCI
patterns as well. Therefore a number of pattern-catalogues A pattern description usable for such transformations has to
were compiled by the HCI community. Well known be detailed down to the abstraction of a single user interface
examples are Tidwell [4] and Van Welie [5]. Along with object. Our approach is to construct PICs top-down by
these catalogues pattern-languages, as for example PLML segmenting a pattern into smaller PICs. The bottom-level is
[3], evolved to describe each pattern in a standardised constituted by PICs which can directly be mapped to
manner. abstract user interface objects. To refine a pattern and thus
define its PIC a basic set of operators and quantifiers was
In this paper we outline an approach of how to make use of identified.
this assembled knowledge within model-based generation
of user interfaces. We attempt to represent patterns in such XOR operator “!” is used to mark a choice between two
a way that they can be used within an (semi-)automatical components available as sub-PICs.
MDA process to generate a concrete user interface (CUI) of Display_Both operator “||” marks two sub-PICs as to be
an application. displayed simultaneously.
Similar work has been done for the original Gamma Display_Sequence operator “|-“ defines two sub-PICs as
patterns by Arnout [6], who investigated and, where to be displayed after each other. Evaluation is from left to
possible, created usable components of design patterns in right.
the Eiffel programming language.
Operator Name Priority
We currently investigate two separate methods of where to
specify the resulting “pattern instance components (PICs)”. ! XOR 1
The approach presented in this paper is to place a PIC ||, |- SIMUL, SEQU 2
within a catalogue itself. This is possible by enhancing the
underlying pattern-language and by making use of () GROUP 3
additional mapping files. The other approach is to include
some sort of programming logic within the pattern Table 1 – Operator precedence
catalogue itself which would reduce or even avoid the
Parenthesis may be used for grouping, squared brackets to Master_Detail’s PIC is defined in an XML dialect related to
parameterise a sub-component or to pass options for the PLML [3], added attributes are explained in table 3.
mapping stage. The operator precedence is shown in table Context, problem, solution and rational are omitted here to
1. save space, but actually do contain a textual description.
The defined component can be displayed using either PIC
Furthermore quantifiers were found useful to define a
“composite” or “lookup”, whereas “composite” is selected
repeated or optional sub-component. Table 2 depicts all
to be “Master_Detail’s” default representation. Related
available quantifiers.
patterns deal with comparable problems, in this case
Quantifier Meaning “print_object” and sub-component “browse” of pattern
“find” are declared to do so.
N/A 1

To illustrate the usage of sub-PICs, quantifiers and
Listing 2 – Master_Detail’s sub-components
operators in the following an exemplary component
definition is given. A pattern “Master_Detail” as Listing 2 shows the definition of Master_Detail’s possible
generalisation of “Two-Panel Selector” and “Cascading sub-components. The major difference between them is the
Lists” from Tidwell will be defined. Master_Detail is display sequence of alternatives. PIC “composite” shows
applicable (1) if a user has to navigate hierarchical data or navigation and details simultaneously on screen, while
(2) if displaying detail information of a set of objects in one “lookup” clears the screen after selecting the target object.
place is not desired or even possible, e.g. by display size Note that it is possible to declare any (sub-) component type
restrictions. The Master-Detail pattern specifies a solution as child; this includes parent types and the current
consisting of to steps: first select the object whose details component itself. Sections from the definition of PICs
are of interest and as second step display that information “print_object” and “find” are displayed in listing 3, they
separately. require another PIC “text” of which also only a small
fraction is shown.
Attribute Meaning

child_rule Available refinements and their relation
applicable Optional, restrict application of pattern or
follows the one proposed in [8] …
layout Defines arrangement of sub-components in

context="master_detail" context="text/multiline"
... applicable_on="input_string,output_string" />
...
...
Listing 3 – PIC definitions of “text”, “print_object” and “find”
... At this point “Master_Detail’s” decomposition is complete,

find/browse since all referenced components can be applied to abstract
print_object user interface elements.

USING PATTERN INSTANCE COMPONENTS FOR AUI
Listing 1 – Master_Detail as instance component
A brief description of how we integrate PICs in our model-
based interface development process follows. The idea is to
add component references by inserting them within a new GENERATING THE CUI
XML namespace into a XML based abstract user interface In order to make use of instance components and their
(AUI) description language. These references are used in refinements in an automated way and therefore supply
combination with device-dependent mappings while suitable tool support, the definition of mapping rules is
generating an application’s CUI (concrete user interface). necessary.
We consider model-based software development as a Mapping rules serve as and are based on device models and
sequence of transformations between models. Basis for any as such enable us to adapt a abstract user interface for
development is a task model. It results from requirements different devices and contexts-of-use.
engineering and is defined by means of CTTE [10]. To To map AUI elements to specific elements of a CUI
derive an AUI a dialogue model of an application is attributes pattern and layout, of table 4, are most relevant.
developed, whereto tasks are assigned to views and A mapping definition for a certain device is
transitions between such views and tasks are defined. straightforward. In a simple XML based UI language it
The combination of task and dialogue model forms an consists merely of value pairs (context, target). Context
initial AUI which we currently represent in XUL [9]. To denotes the (sub-)PIC and target is the destination element
retain task references during further transformations an in the CUI. To suit for more complex UI definitions
AUI’s XUL contains XML attributes for task control data. parameters can be defined and consequently passed to the
For details see e.g. [1] CUI generator as (name,value) pairs.
PIC references are added to the AUI definition in a similar Should a PIC definition contain choices (XOR operator) the
way. An own XML namespace was created for this mapping rules also include the decision which option is to
purpose, such it is easily possible to exchange XUL by be applied for the CUI.
XIML or another XML based interface language if desired If a destination language already supports a layout type by
in future times. Table 4 depicts a subset of content and itself layout-mappings should be defined. Abstract layout
meaning of PIC-namespaces elements. “vertical/grouped” in XUL as CUI for example can be
Attribute Meaning mapped to a specific element “groupbox”, parameterised
with orientation “vertical”. While an abstract layout
pattern PIC to use “horizontal/ungrouped” would be mapped to an XUL
display_sequences Interface elements which are opened “hbox” element.
after each other, referenced by an id; Listing 5 presents a section of mapping rules relevant for
correlates with “child_rule” of table 3 “master_detail”; result would be a XUL CUI suitable for a
display_order Defines sequence of child elements personal computer. A rule set for XUL on PDA is slightly
within a grouping container. Primarily different.
useful as hint to a CUI generator.
layout Layout hint for simultaneously
displayed elements; may be used to
override “layout” of a PIC definition
Table 4 – PIC reference attributes in an AUI

To demonstrate the application of a PIC to an AUI, listing 4

namespace is “hcipattern”.

hcipattern:layout="vertical/ungrouped">

name="Create new account"

target="hbox" />

"multivalue_input_form/input"

hcipattern:layout="table[numColumns:2]">

To actually generate an application’s user interface a
Listing 4 – PIC enhanced AUI definition
generator tool is needed. It combines a pattern enhanced
AUI description via above mentioned mapping rules to a
CUI for a specific device. Generators need to be written for
each destination language; currently we are able to generate CONCLUSION
XUL and partly Java UI’s. As an effort to make use of the knowledge in HCI pattern
catalogues in a model-based UI generation process, an
As an example and to demonstrate the results we get from approach was presented of how to integrate such patterns as
our tools a mail client was modelled and its user interfaces components into an existing MDA approach.
generated for a PC and a PDA. The master_detail pattern
was used twice here. Its first application is to select account We proposed to combine pattern catalogues and mapping
and folder. The second use is the decision which message rules to support varying devices and contexts-of-use, based
from within that folder shall be displayed. on the same AUI.
Mapping rules for XUL on PC state that all components can For these purposes enhancements to an existing pattern-
be displayed at once, figure 1 depicts the result: a typical language were proposed. An initial toolset supporting a
mail application view. developer in such a process was developed and used to
create an exemplary user interface for a mail client.
FUTURE WORK
Our toolset has to be enhanced to generate interfaces in
other languages. An advanced Java support seems to be a
minimum; it is required to have a better comparison of the
potential of our approach in real applications. Secondly, an
extensive comparison of our both approaches on pattern
instance components is required. Eventually a decision is to
be made whether to merge them or drop one. Most
important seems the extensions of our pattern catalogue.
Currently we only translated five, rather small, patterns. An
elaborated investigation similar to [6] should be done.
REFERENCES
Figure 1 – Mail client view PC 1. Wolff, A.; Forbrig, P.; Dittmar, A.; Reichart, D.:
Linking GUI Elements to Tasks – Supporting an
Evolutionary Design Process, Proc. of. Tamodia 2005,
Gdansk, Poland, p. 27-34.
2. Rathsack, R.: Generierung von Gerätespezifikationen
aus abstrakten Spezifikationen unter Beachtung von
HCI Pattern, Master Thesis, University of Rostock,
2006.
3. PLML: http://www.cs.kent.ac.uk/people/staff/saf
/patterns/plml.html
4. Tidwell, Jennifer: Pattern catalogue:
http://www.mit.edu/~jtidwell/ interaction_patterns.html
5. Van Welie pattern catalogue: http://www.welie.com/
patterns/index.html
6. Arnout, Karine: From Pattern to Components, PhD
dissertation, Swiss Institute of Technology, Zurich 2004
Figure 2 – Mail client view PDA 7. Wolff, A.; Forbrig, P.; Dittmar, A.; Reichart, D.: Tool
Support for an Evolutionary Design Process using
Mapping rules and sub-PIC choices for the same AUI on a Patterns, Proc. of Workshop on Multi-channel Adaptive
PDA are declared in a manner to reduce screen space. Each Context-sensitive Systems 2006, Glasgow, GB, p. 71-80
task has its own single view. A user would select folder and
8. Müller, Andreas: Spezifikation geräteunabhängiger
account on the first screen (top-left) select the message in
Benutzerschnittstellen durch Markup-Konzepte, PhD
screen #2 (top-right) and would get the message’s text on a
dissertation, University of Rostock, 2003
third screen (bottom). Note that the content of the tree,
messages selector and message text were added manually 9. XUL XML User Interface Language:
for demonstration purposes, as they would be normally http://www.mozilla.org/projects/xul
provided by an application at run-time. 10.CTTE: The ConcurTaskTrees Enviroment
http://giove.cnuce.cnr.it/ctte.html