Specifying computer-based counseling systems in health care: A

new approach to user-interface and interaction design.

Abstract
Computer-based counseling systems in health care play an important role in the toolset
available for medical doctors to inform, motivate and challenge their patients according to a
well-defined therapeutic goal. The design, development and implementation of such systems
require close collaboration between users, i.e. patients, and developers. While this is true of
any software development process, it can be particularly challenging in the health counseling
field, where there are multiple specialties and extremely heterogeneous user groups. In order
to facilitate a structured design approach for counseling systems in health care, we developed
(a) an iterative three-staged specification process, which enables early involvement of
potential users in the development process, and (b) a specification language, which enables
an author to consistently describe and define user interfaces and interaction designs in a
stepwise manner. Due to the formal nature of our specifications, our implementation has
some unique features, like early execution of prototypes, automated system generation and
verification capabilities.
Keywords: Computer-assisted therapy, Health promotion, Primary health care, User
computer interface, Humancomputer interaction, Public health informatics

1. Introduction
In an interdisciplinary team of general practitioners, psychologists and software engineers,
we developed a Computer-Based Counseling System (CBCS) and along with it an iterative
three-staged specification process for such systems in health care. Regarding the specification
process we focussed on consistency, ease of use, refinement capabilities and an underlying
formal basis. Our project is based on the fact that physical activity is a recognized therapeutic
principle for most patients who suffer from chronic diseases in our case diabetes mellitus
and/or coronary heart disease. A lot of research has been done on the question how to
encourage these patients to start and to maintain physical activity. There is a growing
evidence on the effectiveness of CBCS for health behavior promotion. In particular, those
systems seem promising, which are tailored to patients needs.
We designed a CBCS for patients with chronic diseases in general practice. Our system is
tailored to the patients stage of change according to the transtheoretical model of behavior
change. In a dialog with the patient, the counseling system concludes the motivational level
of behavior change and moves over into an adapted, well-fitted consultation. With respect to
the patients motivational level the system interactively explains the effect of physical activity
on health. The patients pros and cons to maintain a sedentary lifestyle are discussed and
strategies to encourage self efficacy, commitment and how to integrate physical activities in
everyday life are proposed. We are currently conducting a pilot study on the acceptance and
on the efficacy of our CBCS with respect to patient outcomes.

The design and development of a computer-based counseling system in health care has some
unique characteristics. The most striking one is the heterogeneity of the addressed target
group. Being a patient is a weak common denominator. Chronic diseases like diabetes
mellitus and coronary heart diseases are most prevalent in the elderly. Other than that we
have to assume a broad spectrum of capabilities and experiences among patients operating
with a computer-based system. Obviously, the user interface must be as simple as possible,
intuitive and consistent to use. Despite its simplicity in use, the service a counseling system
provides should not be trivial. Why should a patient spend his or her time with a computer?
Why should a patient not abort a counseling session? If the system adds some value to the
patients perception, then we are likely to succeed in keeping the counseling dialog running
and achieving something. The system might provoke a stimulus for behavioral change; it
might change the patients attitudes etc.
From research in usability engineering we know that there are five essential usability
characteristics that are vital for any HumanComputer Interaction (HCI): learnability (the
user can rapidly begin to work with the system), efficiency (the user attains a high-level of
productivity), memorability (it is easy to return to the system after some time of non-use),
low error rate (users are prevented from making errors and errors do not have devastating
consequences) and satisfaction (the system is pleasant to use). These characteristics are not
easy to achieve, especially when one has to deal with as heterogeneous a user group as in
health care.
All in all, there are many reasons calling for a methodical and structured design approach and
involvement of potential users in the development process of a counseling system.
Yet to this point there seems to be no structured approach guiding one through the
development process of a counseling system in a systematic wayprocess-wise and
specification-wise. In this paper, we are not concerned with a manual, tips, rules of thumb,
heuristics etc. on how to better design counseling systems for patients. What we are after is a
process including a specification language. We developed an iterative three-staged
specification process for counseling systems in health care, which enables early involvement
of potential users in the development process. Our process is substantiated by a set of
accompanying XML-based (eXtended Markup Language) specification schemata, a storage
pool for media resources and a tool. The set of specifications consists of two platform
independent specifications and one or more platform dependent specifications. The tool
automatically generates a functioning counseling system for use on a TabletPC out of the
specifications. Due to the formal nature of our specifications, we support the process with
some unique features, like early execution of prototypes, automated system generation and
verification capabilities.
In the following Section 2, we discuss related work. In Section 3, we first present a general
conceptual framework for a structured approach to user-interface and interaction design taken
from the literature. We then present our development metaphor and our realization of the
conceptual framework, an iterative three-staged specification process, which is adapted to the
specifics of building interactive, computer-based counseling systems. A detailed explanation
of the accompanying specification language is given in Section 4. Here, we discuss the
different specification schemata manifesting a new approach to user-interface and interaction
design. Finally, Section 5 closes with some conclusions.

2. Related work
As outlined by evidence-based guidelines, patient empowerment is an essential goal in caring
for patients with diabetes mellitus and coronary heart diseases. Healthcare professionals have
recognized the multifold options which computer-based systems offer to enhance patient
competence and awareness, but up to now, computer-based counseling systems have mostly
focused on software which offers individualized feedback regarding a certain topicwith
little or no flexibility regarding change or adaption of the system or even transforming it for
another device. Systems to persuade people to change their behaviors have been
implementing using mobile phones or PDAs. Computer-based systems on a desktop or
touchscreen kiosk have typically been web-based, implemented in Flash Action script and
HTML: for example there are counseling systems based on the transtheoretical model dealing
with physical activity, obesity or contraceptive use. In addition to the features of the systems
described in these studies, our system will not only allow for individualized feedback and
navigation based on the transtheoretical model, but will also log all interactions in real-time,
allowing e.g. for usability analysis.
The role of evaluation in iterative user-centered design and testing has been highlighted in the
context of health care systems, which are confronted with a level of uncertainty not found in
traditional business environments. Yet based on our research, formal specifications, which
can be used to facilitate the development of information systems, have not been used to
generate computer-based counseling systems. Creating the counseling system directly out of
the specification could help to solve a bundle of problems for which solutions had to be handtailored in the past: generate output for different media, e.g. instant messaging or for a
specific target group, e.g. elderly people remaining at home.
Unlike systems which are employed in order to reach a certain objective, i.e. have a clear
utility, the use of computer-based counseling systems depends largely on their affordance and
user-friendliness. Thus usability issues have been crucial to health systems from the very
beginning and a variety of methods from usability engineering have been adapted to
healthcare systems. Benson has proposed the Unified Modeling Language as stringent
description language in order to not alienate users and being able to communicate within the
multidisciplinary development team. We are taking this one step further by formally
specifying the humanmachine interaction and having the whole system generated on the
basis of this formal reasoning.

3. A structured approach to user interface and interaction

design
In 2003, Garrett published The Elements of User Experience: User-Centered Design for the
Web, a widely acknowledged book on user-centered design. The book does not explain how
Web sites are to be designed, it is even not about Web technology at all. Instead, Garrett lays
out a conceptual framework for talking about the user experience in a systematic fashion. We
applied this framework to the context of counseling systems in health care. Our developed
iterative three-staged specification process is the proposal of a concrete implementation of
Garretts framework in this specialized domain.

To understand and see the relation between Garretts framework and our specification
process, we provide a brief introduction to Garretts framework in Section 3.1. We present the
metaphor, which inspired and underlies our specification approach, in Section 3.2. Our
specification process is then introduced in Section 3.3. We explicate the relation to Garretts
framework in Section 3.4.

3.1. The elements of user experience: a conceptual framework

Garrett structures his framework into five planes: a strategy plane, a scope plane, a structure
plane, a skeleton plane and a surface plane, see Fig. 1. Each plane builds upon the planes
underneath. From bottom to top, the issues to deal with turn from abstract to concrete. The
planes are split in two halves, representing two viewpoints on Web-based systems: the left
half considers the Web as a software interfacea viewpoint, which has become popular with
the so-called Web 2.0; the right half considers the Web as a hypertext systema viewpoint,
which reflects the historical and architectural roots of the Web.

On the strategy plane, the most abstract plane, the user needs and the site objectives
are to be defined. Both aspects are the foundation for all decisions to be made on
upper planes. Defining objectives includes having success metrics that indicate
whether the objectives are met or not.

On the scope plane, the strategy is broken down into functional specifications and
content requirements. A functional specification specifies precisely what the Web site
actually does. Content requirements capture the types of media, which are to be used,
and their context of use.

The structure plane further details scope through interaction design on one hand and
information architecture on the other hand. Interaction design is concerned with the
description of possible user behavior and the systems response to that behavior. Most
important in interaction design is to create a consistent conceptual model of the
systems interaction behavior. The information architecture concerns the
organizational and navigational schemes of content, which enable a user to move
through a Web site efficiently and effectively. In analogy to interaction design, the aim
is to create a consistent conceptual structure for the user. Garrett has developed a
visual language for creating diagrams capturing the structure plane.

On the skeleton plane we distinguish information design, interface design and

navigation design. In interface design, we deal with the arrangement of buttons, check
boxes, drop-down lists and the like. Navigation design is a form of interface design
especially concerned with presenting navigation spaces. Information design refers to
the presentation of information for effective communication. All three aspects build
up the logical parts of the skeleton and come together in the layout of a page.
Typically, page layouts are described with the help of so-called page wireframes. A
wireframe is a bare-bones depiction of all components of a page and their
arrangement.

The surface plane defines the actual appearance of the elements handled with on the
skeleton plane. While the skeleton plane deals mostly with arrangement, the surface
plane deals with visual presentation. It is what we see on a Web site.

The elements of user experience.

We understand our iterative three-staged specification process as an implementation of
Garretts elements of user experience.

3.2. A metaphor
Before we go on, we provide a brief introduction to our specification approach by means of a
metaphor. As a matter of fact, our approach was developed with this metaphor in mind. The
metaphor helped our team a lot not to get lost in the technical details which inevitably come
along with a specification process and a specification language.
Compare the conception and making of a counseling system to writing a script or a
screenplay for a film. The screenplay writer (author) decomposes the script into episodes
(which we call chapters) and scenes (so-called pages) an episode is made of. A first version of
a screenplay might consist of chapters and pages only in order to draft the idea and the rough
conception of the film. One can then go on and continue refining the scene. For each scene,
the required actors and requisites (resources) are to be identified and the setting needs to be
sketched (something we call a logical style). Furthermore, we have to describe the actions in
a scene: How do the actors interact and how do they make use of the requisites? Finally, we
have to be specific on the details: What exactly does the setting look like? The logical style is
enhanced by a concrete style.
The pages of our screenplay metaphor represent dialog pages. The actors and requisites are
resources like texts, videos, audios, images, timers and buttons. The setting of a dialog page
describes the potential arrangement of visual elements in a sort of wireframe, which we call
logical style. The wireframe consists of so-called slots, placeholders for visual elements.
Later on the logical style is refined by a concrete layout, a concrete style, specifying the
format and appearance of the visual elements in a dialog. The actions in a scene can be
compared to the events in a dialog page. They specify when and where the resources come
into play in a dialog. It is also defined how the system reacts on user interactions, like
pressing a button.

3.3. An iterative, three-staged specification process

Each stage in our process is decomposed into a number of steps. The first two stages also
distinguish the aspect of interaction from the aspect of the user interface. Each step comes
along with questions and/or instructions that guide one through the specification process. As

you will notice, intermediate iterations are already built-in into the process. Take, for
instance, step 1f in the conception stage under Interaction. Once you reach this step, you
are asked to reflect on a possible restructuring of page specifications using the copy-attribute
of our specification language. The copy-attribute can be used to create master pages. Further
details are provided in Section 4.
1. Conception stage
Interaction
a. Break-down
How does a strategy break down into chunks of pages, i.e. chapters?
Decompose chapters into individual dialog pages.
b. Interconnect
What is the purpose, the intention of each page?
How are the pages/chapters interconnected?
c. Declare resources
Which resources are needed for a specific dialog page?
d. Specify actions
Specify the behavior of a dialog page.
e. Specify reactions
Specify reactions to user initiated events.
f. Revise break-down
Is there a use case for master pages?

User interface
a. Break-down
Which kind of logical styles are needed?
b. Identify layout elements
How many slots does a dialog page have?
Whats the media type associated with a slot?
c. Define intentions of arrangements

Is there a composition schema of slot arrangements?

How do individual slots relate spatially to each other?

d. Detail abstract design
Is the slot (type) associated with a specific class of design?
e. Revise break-down
Is there a use case for a different composition schema of slots?

2. Realization stage
Interaction
a. Collect & produce resources

 Collect or produce declared resources.

b. Setup references
Let the resource declarations refer to real resources.

User-interface
a. Define layout
Where should the slots actually be on a page?
What is their actual positioning on a page?
b. Define appearance
What should pages look like?
What should filled slots look like?

Deployment stage
a. Identify plug-in features
Which kind of additional functionality is useful/appropriate (e.g. logging)?
b. Supply feature modules
Supply required feature module with system.

This specification process is run through in iterations until a satisfying result is achieved. The
degree of satisfaction is measured by the objectives set for the counseling system. We
differentiate between micro-iterations and macro-iterations. We speak of a micro-iteration if a
process step is repeated until a potential user, namely a patient, positively acknowledges the
result. For example, in the step of defining the appearance of a user-interface in the
realization stage (step 2b) immediate user feedback can be used to change and adapt the
appearance in an instant and again request feedback. A macro-iteration refers to a repeated
walk-through of all stages, see also Fig. 2. This is, for example, meaningful after analyzing
and evaluating the logging data according to certain criteria. The logging data reflects the
way the counseling system is used and will unveil whether the system has created the desired
user experience. The conception and design of a counseling system should be considered in
flux; an agile processas describedis needed to seriously address patient concerns and
offer them a counseling system that adds value to their well-being, their health and health
literacy.

Specification process: after each micro- and macro-step, the users feedback triggers
iterations.
We emphasize that we favor early involvement of users in the development process of a
counseling system. For example, early prototypes of the system (conception stage) can
already be tested together with volunteers and their feedback can be immediately fed back
into the specification process at an early conceptual stage. Our toolset can easily be extended
in order to effectively involve users (patients) in the specification process. What is missing in

our toolset right now is a suitable frontend for the conception stage. Even though our
specification language is simple, an authoring environment for the creation and editing of
script and style specifications with some visual/graphical support would be beneficial. Such
an environment could (a) help enforce the specification process and (b)more importantly
let users immediately participate in the specification process. This would open up the
development of counseling systems to a new level of user involvement in aspiration of usercentered design.

3.4. The conceptual framework revisited

The outlined specification process can be related to Garretts conceptual framework, see
Section 3.1. However, a simple one-to-one mapping falls short for the following reasons:
First, for a counseling system not all aspects are applicable like for a full-blown Web
application. Second, because of this special domain, we made some decisions which prestructure the domain of counseling systems. In other words, our approach removes the
complexities of web design and simplifies Garrettss approach to the essentials required for
the design of computer-based counseling systems.
To be specific, our specification process favors a similar top-down design process as Garrett
does: the user needs and the counseling objectives need to be clarified first (strategy); the
script has to be broken down into chapters and pages including mission statements (scope);
the pages refine the interaction design regarding the systems behavior and responses to the
user (structure); the logical styles define the interface and navigation design by means of an
arrangement of interface elements (skeleton); concrete styles and the media storage define the
visual design (surface).
The first two of the three stages we defined (conception and realization stage) condense four
of the five planes of Garretts framework. The conception stage resembles the scope and the
structure plane, the realization stage the skeleton and surface plane. This distinction is
supported by the specification of a logical style and a script in the conception stage as well as
a concrete style in the realization stage. More details on these artifacts are to be found in the
following Section 4.
The logging facilities we provide with our tool let us evaluate aspects of user experience.
Combined with usability engineering methods, like Thinking Aloud (THA), the specification
process can be iteratively repeated for improvements. This is something, Garrett does not
elaborate on further, yet we consider it essential.
In the following section, we move on to the specification artifacts to be created by authors of
a counseling system. The specifications use a sort of Domain Specific Language (DSL).
When designing a DSL, the language design captures a process used in that domain to some
extent. The way statements are related and nested outside-in partly reflects how steps are
taken forward in a process. This also explains the close relationship of our iterative threestaged specification process and the underlying schemata of our specifications. It is our way
to capture this special domain of counseling systems for use in health care.

4. Specifying computer-based counseling systems

At the heart of our implementation of the iterative three-staged specification process are two
documents, both being specified in XML (eXtensible Markup Language): one document
specifies the intended user interface in logical styles, the other specifies the HCI (Human
Computer Interaction) in a script and refers to the logical styles. In further steps, the
specifications are enhanced and adapted towards a concrete platform using a specific
technology. An overview of this process from a technical perspective is given in the
following subsection. Subsequent subsections detail information about the above mentioned
core documents and the produced counseling system. In the last subsection, we justify our
language design in respect to other user interface description languages.

4.1. Overview of the implemented specification process

In our approach we distinguish three stages in the process of specifying a Computer-Based
Counseling System (CBCS), shown in Fig. 3: a conception stage, a realization stage and a
deployment stage.

Overview of the specification process, involved artifacts and tools.

4.1.1. Conception stage
In the first stage, the conception stage, an author orin our casea team of authors creates
two specifications using XML: one document specifies the intended user interface of the
counseling system, the other the interaction behavior. Unique to our approach is that the user
interface is specified by logical styles. A logical style defines an arrangement of placeholders
(which we call slots) on a dialog page, see Fig. 4. A slot can be loaded and unloaded with
visual content. The arrangement of slots per page reflects just an intention of the layout of the
visual elements; the arrangement is not mandatory. In this sense, logical styles are a
formalization of the idea of paper prototypes for the design of user interfaces.

A simple example of a logical style.

Fig. 4 shows a simple style: an arrangement of four slots. The slot at the very top is a
placeholder for some content of type text. The slot can be referred to via the name text.
Below are three more slots, placeholders for some content of type button. They can be
referred to by their respective names yes, no, and next. For more details, please consult
Section 4.2.

The specification of the interaction behavior, which we call script (remember the metaphor of
a screenplay), decomposes the interaction with a user into so-called dialog pages. Each page
refers to a logical style, it specifies the resources required on the page, it defines the actions
the counseling system performs on this page and how the system reacts on user generated
events like pressing a button. This might result in a jump to another dialog page.
Fig. 5 visualizes the specification of actions associated with a page. First, there are two
actions running in parallel. One action plays a resource of type audio, which is referred to
in the pool of resources as Question. The other action shows a resource of type text
referred to as Question. There are no name conflicts since the resource types differ. More
specifically, the show-action addresses a certain slot in a style and puts the resource into that
slot. For the slot specification see Fig. 4. When the actions are done, a timer is played. Then,
again in parallel, two buttons are shown i.e. the two button resources Yes and No are
filled into the corresponding slots. For more details, see Section 4.3.

An example of actions specified for a dialog page.

Taken together, the specification of logical styles and the specification of a script are
executable. This can be used for prototyping purposes and early testing of dialogs and user
interactions. We did not have the chance to develop any tools for this, so we did not make use
of this optionyet such an early execution of specifications would be extremely helpful.
4.1.2. Realization stage
In the second stage, the realization stage, we put flesh to the bones. The specification of
logical styles is enhanced by a specification of concrete styles. A concrete style implements,
so to speak, the logical style. A concrete style gives a precise definition of the placement of
slots on a dialog page and their appearance. How this is done and which technology is to be
used for that purpose depends on the platform and personal preferences. The specifications of
the conception stage are abstract in the sense that they are platform independent (though
executable).
In the realization stage, decisions regarding the appearance of the system have to be made. In
our case, we decided to use Web-based technology and prepare for distributed use over the
Internet. For this reason we used HTML (HyperText Markup Language) and Cascading Style
Sheets (CSS) to substantiate logical styles. In an experimental spin-off of our counseling
system, we targeted Flash-based technology, which is an example of another realization
platform. In addition to the concretization of logical styles, all the resources, which are listed
in the interaction specification, need to be related to the real thing, namely audios, videos
and images. Therefore, the media have to be produced, assembled and stored in a central
place.
The core element in the realization stage is the generator. The generator takes the
specifications of the conception stage, concrete style definitions and the media resources as
an input and outputs the actual counseling system for the target platform. Our generated

counseling system consists of a number of HTML pages including JavaScript (JS), actually
one HTML page per dialog page in the interaction specification. The HTML pages use the
concrete style definitions and the media resources.
The key role associated with the realization stage is digital media design. Due to budget
limitations, we had no access to a professional media designer but could afford a professional
speaker for the audios. The concrete styles, the videos and audios were produced by our team.
4.1.3. Deployment stage
In the deployment stage, the output of the realization stage (the actual counseling system)
gets installed on physical hardware and is ready for use in experiments, field studies and the
like. To provide extra functionality, modules for navigation and logging (both implemented in
JavaScript) are delivered with the counseling system. We installed the counseling system on
TabletPCs with a screen resolution of 1024 768 pixels and built-in speakers. The screen is
touch-sensitive and can be used with a pen only; it does not react on touch with a finger.
During a counseling session with a patient, the keyboard is not available; it is covered by the
screen. The pen is the only input medium for the patient.
In the following subsections we provide further information about the specification of styles
and scripts and the generated counseling system.

4.2. Specification of styles

First of all, the layout of an HCI dialog is described using so-called logical styles. A logical
style captures the intention of what a page in an interaction dialog should look like. The focus
is on a logical organization of placeholders (called slots), which can be loaded or unloaded
with content, referring to resources like text, images, videos and buttons. The concrete
realization of a logical style is separate from this.
The logical organization of slots in a style is given by two commands: stacked and
juxtaposed. The command stacked puts one slot above another (vertical arrangement),
juxtaposed sets them next to each other (horizontal arrangement). Here is a simple
example:
<style name="YesNoQuestion">
<stacked>
<slot name="text"
type="text"
class="Text"/>
<juxtaposed>
<slot name="yes"
type="button"
class="Button Yes"/>
<slot name="no"
type="button"
class="Button No"/>
<slot name="next"
type="button"
class="Button Next"/>
</juxtaposed>

</stacked>
</style>

In the example, we have a style named YesNoQuestion. It describes an arrangement of four

slots, with a slot called text placed above three other slots (yes, no and next); these
three slots are positioned next to each other, see also Fig. 4. A type is given per slot,
indicating which kind of resource the slot is reserved for. The class-attribute provides abstract
information about the appearance of a slot. For instance, slot yes is associated with an
abstract design called Button and refined by a design called Yes. The class-attribute
cascades abstract design information.
For engineering purposes, a copy-element can be used in a style definition. This enables an
author to compose an logical style out of other styles and benefit from reuse (see the
following example). Here, a style is composed of a header style, a images style and a
question style. The question style refers to the style exemplified before.
<style name="QuestionWith3Images">
<stacked>
<copy ref="Header"/>
<copy ref="3Images"/>
<copy ref="YesNoQuestion"/>
</stacked>
</style>

The key point for the specification of styles is to distinguish two stages of user interface
design: in the conception stage, we first agree on the placeholders and their intended
positioning in an interaction dialog. This is primarily a contract about slots available on a
dialog page, their intended layout is secondarythis is close to the idea of paper prototypes
and wireframes. In a second stage, in the realization stage (see also Fig. 3), we specify the
concrete positioning and appearance of slots separately. Concrete styles refine, detail and may
even overwrite the intended layout of slots in the logical styles. Concrete styles cannot add or
remove (just hide) slots. The way of specifying concrete styles is dependent on the target
platform and the technology used for the counseling system. For Web-based platforms CSS is
a natural choice.

4.3. Specification of interactions

The overall structure of an interaction specification resembles the organization of a book or a
screenplay. Especially the metaphor of a screenplay helped the involved authors, physicians
and psychologists, to get used to the idea of specifying interactive counseling dialogs in
XML. The interaction specification is organized in chapters, and each chapter is composed of
pages, each page representing a self-contained interaction scenario with the patient. The
interaction starts with the first page of the first chapter of a script. Besides, some metainformation (authors, revision information etc.) can be supplied. Note the reference to logical
styles.
<script version="0.9"
date="2007-05-13"
styles="StilKempkes.xml">
<title>Counseling system</title>
<author name="Thomanek">

Philipps-University Marburg
</author>
<chapter name="Registration">...</chapter>
<chapter name="Welcome">...</chapter>
<chapter name="Questions">...</chapter>
<chapter name="Counseling">...</chapter>
</script>

For each page in a chapter a number of resources are declared. These are at disposal for this
specific dialog. Resources can be audios, buttons, images, texts, timers and videos.
Furthermore, a page is composed of actions. The following actions are available: show,
empty, play, halt, jump, eval (evaluate) and log. Actions can run in sequence or concurrently
in parallel and specify the systems behavior. In addition to actions, reactions can be specified,
which define how the counseling system reacts on user initiated events, like moving the input
device (e.g. a mouse or a pen) or pressing a button on the screen. The body of a reaction is
specified with JavaScript; JavaScript is used as an action language. This provides quite some
flexibility on how to react to user initiated events. As an example, see the following
specification of the dialog page Question, which refers to the logical style
YesNoQuestion:
<page name="Question" style="YesNoQuestion">
<intention>Reflect emotion</intention>
<resources>
<audio id="Question" src="audios/enjoy.mp3">

</audio>
<text id="Question">
Did you enjoy this session?
</text>
<timer id="pause" duration="1"/>
<button id="Yes">Yes</button>
<button id="No">No</button>
</resources>
<actions run="sequence">
<actions run="parallel">
<play res="audio" ref="Question"/>
<show slot="text"
res="text" ref="Question"/>
</actions>
<play res="timer" ref="pause"/>
<actions run="parallel">
<show slot="yes"
res="button" ref="Yes"/>
<show slot="no"
res="button" ref="No"/>
</actions>
</actions>
<reaction res="button"
ref="Yes"
event="onclick">
jump("Counseling","Great")
</reaction>
<reaction res="button"
ref="No"

event="onclick">
jump("Counseling","Bad")
</reaction>
</page>

The specification starts with a mission statement, which describes the intention of this page.
Then, five resources are introduced: an audio, a text, a timer for one second and two buttons.
On call, the page first plays the audio and at the same time shows the text of the question in
slot text. After that the timer delays further actions by one second. Then the buttons Yes
and No show up in slots yes and no at the very same time. Note that slot next (see
logical style YesNoQuestion) simply remains unused. The flow of actions is also depicted
in Fig. 5. The user can intervene at any time. If the user clicks on the Yes button (it must
have shown up in a slot before being accessible), the next page the counseling system jumps
to is in chapter Counseling called Great. Likewise, the next page is Bad in chapter
Counseling, if the user clicks on button No.
There is a copy-attribute available for the specification of pages; the attribute is not used in
the example above. It serves the same purpose as the copy-attribute for slots does: to facilitate
reuse and foster composition of pages out of other pages. A typical use case would be the
definition of a master page other pages refer to via copy. The master page introduces some
standard resources and some standard reactions, which can be overwritten if required.

4.4. Generating the counseling system

From the specification of logical styles, the specification of a script, concrete specifications
for the dialogs look & feel (concrete styles, i.e. CSS definitions) and a pool of media
resources, the counseling system is automatically generated for a specific target platform. In
our case, a Java program generates HTML-based Web pages, which run in full screen mode
on a TabletPC. Behavior is added to a web page using JavaScript. Since JavaScript is used as
an action language within scripts, the code is copied to the Web pages by the generator. The
counseling system is prepared for remote use over the Internet. Fig. 6 shows a screenshot of
the CBCS in action running within Microsofts Internet Explorer 7. Our system relies on a
Web browser supporting SMIL (Synchronized Multimedia Integration Language). The flow
of actions can be mapped to SMIL in an almost one-to-one manner.

Example screenshot of the counseling system in action.

Note that the lower part of the screenshot is specified by a logical style similar to the one
shown in Fig. 4. If one compares the two figures, it becomes clear how a text-based XML
style of specifying requirements reconciles with visual aspects of design for end users. The

text-based XML style renders a rudimentary intention of a visual layout. It is a proper

approximation of the final end result and can be used for early prototyping purposes.
Considering that the generation of the counseling system is just a matter of seconds, one can
experience the effect of specification changes in an instant.
The generator embeds two modules in the counseling system to provide navigation and
logging capabilities. Extensions are programmed in JavaScript. The navigation module
enables quick and easy jumps to any dialog page of a counseling session via a navigation
menu. It is accessible via a hot key and available for testing purposes only. The logging
module records all events in real-time, system generated events as well as user initiated
events, and sends them to a logging server. A sample excerpt is shown in Fig. 7. The first
column is a session id out of six digits. Next comes the date and the time down to the
millisecond. Then there is the logged event in XML format including a list of parameters.

An excerpt of logged events.

If used over the Internet, real-time logging allows an observer to monitor a counseling
session between the system and a patient on a remote computer. This feature might be useful
for conducting online experiments with the counseling system. With the event log on the
logging server, counseling sessions can be precisely reconstructed and replayed. The log data
can be analyzed and evaluated from various points of view, e.g. how much time a patient
spends on a dialog page etc.

4.5. Relation to other user interface description languages

There are some description languages for the definition of user interfaces and user
interactions. Most of them are markup languages based on XML, e.g. UIML (User Interface
Markup Language), XUL (XML User Interface Language), XBL (XML Binding Language),
XAML (Extensible Application Markup Language) or XFrames (XML Frames).1
We studied these languages in detail and borrowed some ideas from XUL and XBL, but we
have deliberately chosen to develop our own approach for the following reasons:
1. Some of these languages are platform dependent like XAML from Microsoft for
Windows. We strove for platform independence but with an eye on web-based
browsers. That is why we use JavaScript as an action language.
2. Our language is restrictive in its capabilities to design user interfaces by intention.
Our users are the elderly and we anticipate them to have no computer experience at
all. An author of a counseling dialog should be prevented from designing complicated
interfaces and complex interactions. Therefore there are no widgets for menus or
selection lists, for example. Our system favors and stimulates the use of images,
audios and videos to create a communicative user experience.
3. Most user interface description languages strive for a clear separation of content, style
and behavior; this is considered to be state-of-the-art. We strictly followed this

principle and took over XULs box model for layouts, its idea of adding style sheets
and, to some extend, picked up XBLs notion of bindings.
4. We were in need of a simple action language. JavaScript came in very handy, see first
bullet point. Not all user interface languages are associated with an action language.
5. With our approach we provide means to incrementally specify and refactor (via the
copy tag in styles and the copy attribute in scripts) a counseling system. The idea is to
start from a very coarse grain level and to refine interactions and/or styles stepwise.
As long as the XML documents are well formed and valid, they are basically
executable. In other words, our language design is connected with a method as
outlined above. We do not know of a user interface language with similar qualities in
this respect.
6. The simplicity of our language design allows us to apply a mathematical formalism, a
process calculus, to our conceptions and do some formal reasoning. Although this is
research in progress, it looks promising and makes our system theoretically sound.
Some information on this can be found in the next section. Todays user interaction
languages typically do not satisfy mathematical soundness.

5. Conclusions
In this paper, we presented a structured approach to specify computer-based counseling
systems in health care. The approach consists of an iterative three-staged specification
process and is substantiated by a set of specification schemata, a media storage and a
generator. The generator takes all the specifications and the media resources and outputs an
executable counseling system for use on TabletPCs. The specification process aims at
involving potential users as early as possible and favors user-centered design.
We plan to extend our toolset into two directions: first, an authoring environment would help
improve the work process in the conception stage. Working with XML is not really an option
for CBCS authors in the long run and does not promote pair authoring with potential users.
From an authoring environment, we expect to gain new insights in the collaboration process
between authors of counseling systems and their users.
Second, on the backend side, we would like to be able to configure our generator to support
different kinds of target platforms like PDAs, mobile phones, brochures etc. This will also
have an impact on the specification process.
Another issue is that we are aiming at basing our specifications on a sound mathematical
formalism, namely a process calculus. The goal is to apply formal reasoning on a complete
interaction and user interface specification. For example, we want to

verify whether all resources (video, audio etc.) are properly used,
detect inconsistencies between actions in time and slots in space (called styles),
check whether all paths of interaction are reachable (there are alternatives) and
whether an interaction session with a patient will terminate, i.e. will come to an end.

In our current implementation of the CBCS generator, we implemented such checks

pragmatically. From the viewpoint of a computer scientist, however, the beauty lies in
proving such properties formally. Besides, a formal basis of our specification approach is key
for producing highly adaptable but still reliable counseling systems. This is an important

requirement if you think of counseling systems a physician can compose out of counseling
modules on the fly, configured and personalized for the patient and customized for a certain
target medium like a Web browser, PDA (Personal Digital Assistants), mobile phone or
brochure. The released product has to be stable and should not suffer from underspecification,
broken paths of consultation and other deficits. We think that a formal underpinning is an
essential cornerstone in a user-centered specification process. It helps create a painless
user-experience; something the user will benefit fromwithout ever knowing about it.

Acknowledgements
The first generation implementations of generators and verification tools based on the
specifications described here were developed by competing teams of students during summer
term 2007 at Heilbronn University, who participated in the LabSWP course. Thanks to all for
their hard and fantastic work.