You are on page 1of 8

TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

Linking GUI Elements to Tasks – Supporting an


Evolutionary Design Process
Andreas Wolff, Peter Forbrig Anke Dittmar, Daniel Reichart
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
[rusty|pforbrig]@informatik.uni-rostock.de [ad|dr007]@informatik.uni-rostock.de

ABSTRACT Author Keywords


In this paper we discuss an approach for linking GUI Model-Based Design, Task Models, Object Models,
specifications to more abstract dialogue models and Patterns, GUI, XUL, XIML.
supporting an evolutionary design process. These
ACM Classification Keywords
specifications are linked to task models describing
HCI
behavioural characteristics. First prototypes of interactive
systems are interactively generated. The automatically
INTRODUCTION
generated XUL specifications are refined using a GUI
With the increasing capabilities of mobile devices model-
editor, which allows replacing of user interface elements by
based development of software systems becomes more and
other elements or components. Components are pre-
more popular. It is necessary to design user interfaces in an
designed parts of user interfaces, and could optionally be
abstract way because there is a diversity of different mobile
parameterised. This enables us to support GUI design using
platforms with specific features. Most of these platforms
patterns.
have to be supported in an economic way by new
For illustration we are going to show a design cycle from interactive applications. Models help to derive specifi-
task model to abstract user interfaces and finally to a cations of interactive systems, and in particular, of user
concrete user interface. The design process is supported by interfaces.
patterns. Transformation by patterns
class class
Additionally, a proposal is presented of how to keep Transformation diagram diagram
connections between concrete user interface (CUI), abstract (analysis) (design)
(analysis) Implementation
user interface (AUI) and a task model. These connections task
can be used to propagate changes in a task model or an AUI model
application
only to affected parts of a CUI, instead of recreating the user
b.-object
model

model
whole CUI after a modification has been done. model
UI
In this paper we primarily focus on deletion, moving and device Transformation by patterns
model

adding tasks to an AUI and the implication of these model

procedures to a CUI. More complicated problems like Design


dialog abstract
splitting or merging of tasks are not addressed in this paper. Design graph user interface

The avoiding of unnecessary recreation processes for a CUI Design


can reduce the amount of time and work needed in model-
driven software development. Figure 1 - General view on a transformational model-based
development process.
Permission to make digital or hard copies of all or part of this work for We strongly believe that software engineers and user
personal or classroom use is granted without fee provided that copies are interface designers have to base their work on the same
not made or distributed for profit or commercial advantage and that models. Furthermore, we consider software development as
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists, a sequence of transformations of models that is not per-
requires prior specific permission and/or a fee. formed in a fully automated way but supported by humans
TAMODIA’05, September 26–27, 2005, Gdansk, Poland. using interactive tools. Our work is especially focused on
Copyright 2005 ACM 1-59593-220-8/00/0000…$5.00. methods and tools supporting transformations by patterns.

27
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

Initially starting with design patterns for class diagrams we The initiative for XIML started in 1999 and was focused on
more and more believe in patterns as appropriate idea for device-independence primarily of mobile devices. XIML is
reuse of knowledge. model-based but it needs a specific tool (converter) to
create a specific type of user interface. Our tool DiaTask [6]
In this paper we focus on the user interface development
was developed to make use of XIML. Task models, user
process. We present strategies and appropriate tool support
models, and object models with our metaphor of artefacts
(DiaTask) to derive and link user interface models (dialog
and tools are represented as XIML specifications. However,
graphs), corresponding abstract prototypes (XUL-
there seems to be no further support for XIML. Still there is
specifications) and task models (see the bottom part of
a lack of tool support. This is especially true for designing a
Figure 1).
concrete user interface. That was the reason for our group
The following paper is structured in such a way that after to look for user interface specifications, which are already
discussing some related work an example of a development supported by tools. We found XUL as a candidate for that.
process of a specific user interface is given. Afterwards
XUL [5,14] was presented in 1999 by the Mozilla project to
possible changes within the task model and their
specify Graphical User Interfaces of the Mozilla-browser in
consequences are discussed. At the end we give an outlook
platform-independent matter. XUL allows the specification
for further work to be done.
of interactive objects like buttons, labels, and text fields.
We can find these objects in tools for creating GUI’s like
RELATED WORK
Java.AWT and Java.Swing.
During the previous TAMODIA conference there were two
talks referring to the “mapping problem” in user interface Based on an existing project for eclipse a GUI editor for
design ([2] and [11]). This problem was first mentioned by XUL was developed [25]. It was built in such a way that
Puerta and Eisenstein [17]. They stated that the mapping co-operation wit task models and generated user interfaces
problem is the key problem to make model-based became possible. The following example will demonstrate
development acceptable for programmers. The mappings how this editor can be incorporated into the development
mentioned in [17] include only mappings from abstract to process of interactive software.
concrete models and between models of the same level. No
mappings from concrete to abstract models are mentioned EXAMPLE OF A DEVELOPMENT PROCESS OF A USER
in their paper. This was carefully analysed by Clerckx, INTERFACE
Luyten and Coninx [2]. They have classified five The software developer John has to develop a system to
mechanisms to solve the mapping problem. manage mails. One of the forthcoming users is Susan. She
works in a small company producing envelopes. John
1. Model derivation organizes an interview with Susan about the tasks she
2. Partial model derivation wanted to be supported by the mailing system.
3. Model linking The result of the interview is represented in the task model
of Figure 2.
4. Model modification
5. Model update. Initial Task Model

Limbourg and Vanderdonckt [11] address the problem by


supporting transformation of abstract models to more
concrete ones by graph grammars. The user interface
specification is based on UsiXML [23].
“UsiXML (which stands for USer Interface eXtensible
Markup Language) is a XML-compliant markup language
that describes the UI for multiple contexts of use such as
Character User Interfaces (CUIs), Graphical User Interfaces
(GUIs), Auditory User Interfaces, and Multi-Modal User
Interfaces. In other words, interactive applications with
different types of interaction techniques, modalities of use
and computing platforms can be described in a way that
preserves the design independently from peculiar
characteristics of physical computing platform”[23]. It Figure 2 – Initial Task Model
seems to be that UsiXML could be a living standard to According to the interview with Susan, a very simple mail
express models. It can play the role, which XIML [26] application is to be developed. It should be able to manage
originally wanted to gain. received mails, i.e. to store them and display at request, and
also to send new mail.

28
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

According to the task model of Figure 2 a user may either


read his mail, or write a new one. To read his mails, he has
to select a specific mail from a list that is generated and
presented to him by the application. Once he has selected a
mail he gets its content displayed. Select and display are
consecutive subtasks of an iterative tasks that can be
cancelled at any time.
Writing mails is modelled in a similar manner. After a user
decides to write a mail he has to enter the iterative task
produce mail, where he is requested to compose a new mail
and, after finishing this, the application will send it away.
This sub-task may also be cancelled at any time.

From Task Models to Dialog Graphs


John is an expert user of the system DiaTask (see Figure 3 –Dialog graph for sample application
e.g.[18],[4]), he decides to develop an abstract dialog
graph based on the task model (of Figure 2) that was From Dialogue Graphs to Abstract Prototypes of User
developed together with Susan. This task model is used as Interfaces
input for the dialog graph editor tool. Given a dialog graph DiaTask can generate an initial
While there is currently no satisfying way of an automatic abstract prototype in a WIMP style, which mainly reflects
generation of dialog graphs, the DiaTask editor can be used the navigation structure of the user interface. Windows
to create them manually. represent views and the elements of the views are mapped
to buttons as to be seen in Figure 4 for the example dialog
At first a designer has to decide, how many views are graph of Figure 3. Other task-element mappings can be
desired, and whether each of them is modal, single or realized by applying a different presentation model.
multiple. Next step is to assign relevant tasks to views. The
underlying task model determines the set of tasks, which The generated AUI is stored in XUL format. For testing
can be distributed on views. Thereafter the designer has to purposes it is possible to animate the designed dialog graph.
model transitions between tasks and views. DiaTask does DiaTask uses its generated XUL files to have a graphical
support necessary operations to do this. representation for each affected task.

John decided to use 4 different views. The first view is a Beside layout information, each XUL element contains
start screen, where a user decides whether he wants to read control attributes. Especially of relevance is identification
or write a mail. Beside this, a single view exists for reading attribute (id) of the associated task. This id is generated by
mails, a multi view for writing a mail and a modal dialog DiaTask while editing the dialog graph and is unique for
was designed to visualize progress during send operations. each task. It allows a trace back of interactions on the final
John decided that it makes sense to read only one mail at a graphical user interface to the corresponding task. The id of
time (single view) while writing different mails at the same a task is especially important if new UI-elements are
time should be possible (multiple view). John attaches tasks created.
to the views and combines them with the corresponding Other attributes are used to track changes in task-view
transitions. For details see Figure 3. assignments. More details on this matter are discussed in
The reader might recognize that no task is attached to the chapter “Moving tasks between views”.
fourth view (send progress). It was a technical design
decision of John to have this window describing the
progress of sending a mail. There was no task in the task
model forcing to have this view.

Figure 4 - Pre-Generated Views


An animation of the prototype reveals how transitions are
interpreted. Clicking on a button representing the start node
of a sequential transition let the active window disappear.
The window, which represents the destination view of the

29
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

transition, becomes visible and active. Concurrent related associations of an element and accordingly keep
transitions allow the corresponding window of the source connections to the task model.
view to stay visible. The user can activate it at any time. For
John starts the editor XUL-E and replaces buttons in the
the example, this means that first window (containing
abstract user interface specification by other more
“Read Mails”, “Write Mails”) stays open after pressing the
appropriate ui-elements. In view number 2 e.g. the button
"Write Mails" button. Multiple views go together with
“List Mails” is replaced by a tree structure and a list box,
concurrent transitions. A generated prototype allows the
whereas the button “Display selected Mail” is replaced by
creation of several instances of the corresponding window.
three labels and some text displayers. “Select Mail” is
John demonstrates Susan the animated abstract prototype. exchanged by a “OK_Help_Cancel”-component (see
Together they create some test scenarios and observe how Figure 5).
the abstract prototype behaves while executing the
scenarios. Susan agrees with the models specified up to
now but she expresses her wishes to have a look at the final
user interface. John promises that this will be possible
soon.
John was able to promise more specific user interfaces for
the prototype because he was aware of our GUI editor [25]
available for this purpose. The features of this editor will be
described in the next paragraph.

From Abstract Prototypes to Concrete GUIs


Following the generation of abstracts user interfaces (AUI)
testing the dialog structure; in a next step concrete user
interfaces (CUI) are to be designed.
This can be supported by a XUL editing tool (XUL-E) [25].
It was developed as a plug-in for the rich-client platform
“Eclipse” [8].
For information exchange between the tools XUL-E and
DiaTask, a slightly enhanced version of the XUL language
is used, which is called XULM. Enhancements include the
possibility to
Figure 5 - Designed GUI for Select & Read
• store multiple views/windows in one file,
Replacing a single element, like a button for example, by a
• define a repository for pre-designed components more complex component, raises the problem of where to
and attach task-related information to. While it would be
possible to actually apply these data to every element of a
• define placeholders that refer to these components
complex component, this is probably not the desired
The editor XUL-E itself is under continuing development, behaviour. Also it is imaginable that components contain
and is currently capable of editing most layout-affecting visualization stubs for referencing other than the current
XUL elements. task (See also section “adding a task” below).
XUL-E uses DiaTask’s generated AUI as starting point for Therefore XULM provides a facility of fine-grained control
layout refinements. It is possible to wrap every view of an on this matter. An element inside a pre-designed component
AUI into a single XULM-file. Alternatively single views may be marked whether it should have task-control-data
can be edited as separate XUL-files. applied or not. The default assumption is that they have not
to be applied (value = “none”). A second option is
The basic idea of an integrated editing process, as presented
“implicit”, meaning to apply task-control-data of the
here, is to edit by replacements. To design the user interface
replaced element. As a third option the value “explicit” can
of a task, another one can replace its current visualization.
be defined, meaning that this replacement requires user
A user interface designer has to proceed in the following
interaction. It has to be decided, whether to delete this
way. At first he has to select a visualization (graphical
element, as it is currently not necessary or to set manually,
element) of a task (e.g. a button), choose “replace”, and
which task this element belongs to. In the latter case, a
select via “drag & drop” a graphical element or a pre-
consequence might be to adapt the underlying dialog graph
designed component, which replaces the original one. To
and even the task model. In both cases consistency has to be
proceed in this way makes it possible to maintain task-
checked. The tool DiaTask is more appropriate for this
purpose than XUL-E.

30
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

For logical and organizational purposes XULM offers a some difference in the views appearances. That is not a real
feature to group components into packages. Those packages cutback, because if we would want to display all features
again can contain packages, creating a hierarchy in this we could use any gecko-based browser. The advantage of
way. Packages are stored in repositories – currently DiaTask’s simulation engine is that it is already integrated.
XULM-files – which can be referenced from any XULM
file and are dynamically loaded by XUL-E or any other tool
using XUL-E’s engine.
As each package can contain multiple components, it is
conceivable to group different visualizations for the same
task(s) into one (sub-) package. To support this approach,
one component of a package may be declared as default
component. By referencing a package, this default would be
used for visualization purposes. The editor is prepared to
easily replace components of the same package, but only of
the same level of hierarchy, by each other. Thus using a
different one than the default component of a package is not Figure 7 - A refined prototype of Fig. 4 in animation mode
a problem.
Susan is impressed by the prototype demonstrated by John.
Beside this, explicit referencing of a single component is Looking at the user interface in this concrete version she
supported too. Generally a reference is defined in terms of gets a better impression how the system will work in the
XULM placeholder-elements. future. However, the concrete user interface generates new
Thus XULM provides two ways to adapt a CUI to different ideas in her mind. At the moment there is no way to attach
contexts-of-use, either by using a different repository or by files to mails. She never mentioned this whish before.
overriding package defaults. Nevertheless, it is very important to have this feature. She
asks John to change the original task model.

EVOLUTION OF MODEL
Adding a task
Missing functionality has been identified by an animated
walk-through. To add this functionality it is required first to
change the task model. In a second step the new tasks have
to be interlaced into the dialog graph and finally the
concrete user interface has to be adapted.
John develops a new version of the task mode, by adding a
Figure 6 - Package structure of repository use for the example task “Show Attachments”. The result can be seen in Figure
For the example application, five components were created, 8.
which were grouped into two packages. Package tamodia
consists of three components, which all include the package
default of the tamodia.helper package (see Figure. 6).
The view “Select & Read” was designed using components
as replacements. A tree and a listbox replaced the button of
task „List Mails“. Button “Select Mail” was exchanged by a
“OK_Help_Cancel”-component and button “Display
Selection” consists now of three labels and some text
displayers. Note that sample texts have been integrated for
demonstration purposes only (see Figure 5).
However, after the redesign of all views, DiaTask can still
be used to animate the dialog graph. It is possible to discuss
the application based on a concrete design instead of rather
abstract – button-represented - tasks.
The animation of the dialog graph becomes "more
Figure 8 – Enhanced task model
readable" for users and is more appropriate for discussions.
In Figure 7 an animation state is shown, where a user writes Within the second step John integrates the new task into the
a mail. The simulation engine of DiaTask is currently dialog graph. He decides to put it into the “Select & Read”
restricted to a subset of XUL-E’s capabilities, so there is view. DiaTask notices the change of this view, and marks

31
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

the new task as “TaskAdded” within XULM. XUL-E is Moving Tasks between views
started to define a design for this task. To fulfil this requirement, no changes in task model are
needed. Therefore it remains untouched. It is only necessary
XUL-E interprets the above-mentioned “TaskAdded” to edit the dialog graph.
attribute and brings out the prototypical visualization of the
new task on a highlighted position above the affected view John edits the dialog graph. He splits the view “Select &
(See Figure 9). Read” into two separate views. The first view is “Select”
containing only selection-related tasks and the second vie
“Read Selected Mail”, a view that displays a mails text and
attachments. The result of his editing is presented by Figure
11.
A detection of those changes is only possible by DiaTask
itself, it has to mark any moved task with an attribute
“TaskDeprecated” in its old view and also as “TaskAdded”
in its new view. Handling of “TaskAdded” was outlined
Figure 9 - Editor's visualization of added tasks above; there is currently no difference between adding a
completely new task and moving a task from one view to
John is now requested to incorporate this task into current another one (see e.g. Figure 11).
“Select & Read” view. Using component
“tamodia.attachmentselector” and some resizing the view of
figure 10 is the result.
Note the button “Save” in the attachment display-part. It is
defined within component “attachmentselector”, attributed
with Task-Id=”explicit”. It is up to a designer to keep it,
and connect it to an appropriate task or remove it.
Here John decided to keep it for the moment, although he
will not create any connection to a specific task.

Figure 11 - Displaying a single mail has been moved into a


separate view
As support of “TaskDeprecated” XUL-E displays all
affected parts of a view surrounded with a thick red border
(see Figure 12). A designer has to remove these marked
parts from the view and if necessary to re-layout remaining
elements.

Figure 10 – Select & Read UI after integration of attachments


Together with Susan John has once again a look at the
animated prototype and the designed models. He recognizes
that there might be a better design of the system by moving
the task “Display Selection” into an own view, which will
be only for viewing a mail content.

Figure 12 – Tasks marked for deletion

32
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

CONCLUSION AND FURTHER WORK


Tools for model-based software development have
advanced to a development stage at which applying them to
real projects may add up to real benefits. We presented
strategies and tool support for designing interactive
systems, and in particular, user interfaces mainly on the
basis of task models.
One can consider our approach as complementary to
procedures as proposed by TERESA [21] and DynaMo-
AID [2]. While these references prefer an automatic
generation of user interface prototypes from task models,
we focus on a transformation-based development process
that is interactively controlled by designers. Therefore our
strategy is to leave explicit design decisions to interface
designers. In the future both approaches could be combined.
The tools we presented currently provide support for the
animation of abstract canonical prototypes and carefully
designed user interfaces. By starting from an abstract user
interface a prototype evolves to his final appearance by
designing step by step each view of the navigation dialog.
Our tools are also able to animate different navigation
graphs concurrently. Thus it is possible to look at different
design decisions and let users compare and discuss varying
Figure 13 – Newly designed views versions of the user interfaces.
Some shortcomings of the current tool set, DiaTask and
Deleting a Task XUL-E, have already been outlined in the preceding
Deletion of a task is essentially the same as the sections. As for example the fact that a UI design for tasks
“TaskDeprecated”-part from moving a task. This kind of is lost, when it is moved from one view to another one.
dialog graph modification can be detected by DiaTask only. Subject of discussion is also the way in which added and
Indeed, it is the only case where a change can be made at removed tasks are indicated. Furthermore, XUL-E should
first in XUL-E. DiaTask detects these forms of changes and be enhanced to restrict replacements on sensible elements
propagates them to the dialog graph. or components only.
USING COMPONENTS AND PLACEHOLDERS FOR It has been shown that, in the presented process, DiaTask
PATTERN and XUL-E are closely related to each other. While both are
The outlined approach also enables us to make use of ui- already developed as plug-ins for “Eclipse” there is still
patterns in interface design. Instances of patterns play the some work to do to improve the actual interaction between
role of components. both, in particular in the XUL-E to DiaTask direction.
To use patterns, one would have to design components that It might be worth to do some investigation on ways to
contain arranged pattern instances with layout information. associate sub-task models to pre-designed components. So
Elements within these components are to be marked as a component, or at a lower level of detail a package, could
Task-Id=”implicit”. bring along its own task-model, possibly including a dialog
graph, and if the component is applied to some view, task-
Replacing parts of these components with another task-
model and dialog graph of the application are enhanced by
annotated element results in a view, where on the one hand those of the component. This could have been used for the
each part of an instance of a pattern has its task assigned. save-Button (see Figure 8) of our sample application. In this
On the other hand a task is related to a pattern and case it would contain a small task model for saving
visualized by a pattern instance. attachments.
This problem of representing patterns by component is the Above all, there is a need to identify patterns that help to
object of undergoing research. Especially the application of
transform task models into dialog graphs. As a first step it
collections of patterns in real life projects has to prove the
might be of some help to automatically map specific
advantages of the outlined approach.
temporal relations to transitions.
For further integration of ui-patterns, it might be necessary
to enhance XUL-E with a transition mechanism between

33
TAMODIA 2005 | PAPERS 26-27 September | Gdansk, Poland

components that contain more than a single task. It might 13. Luyten, K., Clerckx, T., Coninx, K., Vanderdonckt, J.:
be located at package level and describe transitions between Derivation of a dialog model from a task model by
whose (sub-) components in XULM format. activity chain extraction. In Jorge, J., Nunes, N.J., e
Cunha, J.F. (ed.), Proc. of DSV-IS 2003, LNCS 2844,
REFERENCES Springer, 2003.
1. Cameleon: http://giove.cnuce.cnr.it/cameleon.html.
14. Mozilla.org: XUL Programmer’s Reference 2001.
2. Clerxkx, T.; Luyten K.; Conix, K.: The Mapping
15. Paterno, F.; Mancini, C.; Meniconi, S:
Problem Back and Forth: Customizing Dynamic Models
ConcurTaskTrees: A Diagrammatic Notatiob for
while preserving Consitency, Proc. TAMODIA 2004, P.
Specifying Task Models, Proc. Interact 97, Sydney,
33-42.
Chapman & Hall, p362-369, 1997.
3. Constantine L.L: Canonical Abstract Prototypes for
16. Paterno, F., Santoro, C.: One Model, Many Interfaces.
Abstract Visual and Interaction Design, in Jorge J. A. et.
In Proc. of the Fourth International Conference on
al (Eds): Proceedings DSV-IS 2003, LNCS 2844,
Computer-Aided Design of User Interfaces, p. 143-154.
Springer Verlag, Berlin, 2003, P. 1-15.
Kluwer Academics Publishers, 2002.
4. CTTE: The ConcurTaskTree Environment.
17. Puerta, A.R. and Eisenstein, J. Towards a General
http://giove.cnuce.cnr.it/ctte.html.
Computational Framework for Model-Based Interface
5. Deakin, N.: XUL Tutorial. XUL Planet. 2000. Development Systems. Proc. of the 4th ACM Conf. On
6. Dittmar, A., Forbrig, P.: The Influence of Improved Intelligent User Interfaces IUI’99 (Los Angeles, 5-8
Task Models on Dialogues. Proc. of CADUI 2004, January 1999). ACM Press, New York (1999), 171–178
Madeira, 2004. 18. Reichart, D.; Forbrig, P.; Dittmar, A.: Task Models as
7. Dittmar, A., Forbrig, P., Heftberger, S., Stary, C.: Tool Basis for Requirements Engineering and Software
Support for Task Modelling – A Constructive Execution, Proc. Of. Tamodia 2004, p. 51-58
Exploration. Proc. EHCI-DSVIS’04, 2004. 19. Sinnig, D., Gaffar, A., Reichart, D., Forbrig, P., Seffah,
8. Dittmar, A., Forbrig, P., Reichart, D.: Model-based A.: Patterns in Model-Based Engineering, Proc. of
Development of Nomadic Applications. In Proc. of 4th CADUI 2004, Madeira, 2004.
International Workshop on Mobile Computing, Rostock, 20. Teuber, C.; Forbrig, P.: Modeling Patterns for Task
Germany, 2003. Models, Proc. Of Tamodia 2004, p. 91-98.
9. Eclipse: http://www.eclipse.org. 21. TERESA: http://giove.cnuce.cnr.it/teresa.html
10. Elwert, T., Schlungbaum, E.: Dialogue Graphs – A 22. UIML Tutorial, http://www.harmonia.com
Formal and Visual Specification Technique for
23. UsiXML: http://www.usixml.org/
Dialogue Modelling. In Siddiqi, J.I., Roast, C.R. (ed.)
Formal Aspects of the Human Computer Interface, 24. Wilson, S.; Johnson, P.: Bridging the generation gap:
Springer Verlag, 1996. From work tasks to user interface design, In
Vanderdonckt, J. (Ed.), Proc. of CADUI 96, Presses
11. Limbourg, Q., Vanderdonckt, J.: Addressing the
Universitaires de Namur, 199, p. 77-94.
Mapping Problem in User Interface Design with
USIXML, Proc TAMODIA 2004, Prague, P. 155-164 25. Wolff, Andreas, Ein Konzept zur Integration von
Aufgabenmodellen in das GUI-Design , Master Thesis,
12. López-Jaquero, V.; Montero, F. ; Molina, J.,P.;
University of Rostock, 2004.
González, P.: A Seamless Development Process of
Adaptive User Interfaces Explicitly Based on Usability 26. XIML: http://www.ximl.org
Properties, Proc. EHCI-DSVIS’04, p. 372-389, 2004.

34