Journal of Biomedical Informatics 42 (2009) 347–355

Contents lists available at ScienceDirect

Journal of Biomedical Informatics

journal homepage: www.elsevier .com/locate /y jb in

Specifying computer-based counseling systems in health care: A new approachto user-interface and interaction design

Dominikus Herzberg a,*, Nicola Marsden b, Peter Kübler b, Corinna Leonhardt c, Sabine Thomanek d,Hartmut Jung c, Annette Becker d

a Institute of Public Health and Medical Informatics, Heilbronn University, Max-Planck-Str. 39, 74081 Heilbronn, Germanyb Department of Software Engineering, Heilbronn University, 74081 Heilbronn, Germanyc Institute of Medical Psychology, Philipps-University Marburg, 35032 Marburg, Germanyd Department of General Practice/Family Medicine, Philipps-University Marburg, 35032 Marburg, Germany

a r t i c l e i n f o

Article history:Received 26 May 2008Available online 7 November 2008

Keywords:Computer-assisted therapyHealth promotionPrimary health careUser–computer interfaceHuman–computer interactionPublic health informatics

1532-0464/$ - see front matter � 2008 Elsevier Inc. Adoi:10.1016/j.jbi.2008.10.005

* Corresponding author.E-mail addresses: herzberg@hs-heilbronn.de (D. H

bronn.de (N. Marsden), cleonhar@med.uni-marburg.Becker@med.uni-marburg.de (A. Becker).

a b s t r a c t

Computer-based counseling systems in health care play an important role in the toolset available formedical doctors to inform, motivate and challenge their patients according to a well-defined therapeuticgoal. The design, development and implementation of such systems require close collaboration betweenusers, i.e. patients, and developers. While this is true of any software development process, it can be par-ticularly challenging in the health counseling field, where there are multiple specialties and extremelyheterogeneous user groups. In order to facilitate a structured design approach for counseling systemsin health care, we developed (a) an iterative three-staged specification process, which enables earlyinvolvement of potential users in the development process, and (b) a specification language, whichenables an author to consistently describe and define user interfaces and interaction designs in a step-wise manner. Due to the formal nature of our specifications, our implementation has some unique fea-tures, like early execution of prototypes, automated system generation and verification capabilities.

� 2008 Elsevier Inc. All rights reserved.

1. Introduction

In an interdisciplinary team of general practitioners, psycholo-gists and software engineers, we developed a Computer-BasedCounseling 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 recog-nized therapeutic principle for most patients who suffer fromchronic diseases [1]—in our case diabetes mellitus and/or coronaryheart disease [2,3]. A lot of research has been done on the questionhow to encourage these patients to start and to maintain physicalactivity [4,5]. There is a growing evidence on the effectiveness ofCBCS for health behavior promotion [6,7]. In particular, those sys-tems seem promising, which are tailored to patients needs [8].

We designed a CBCS for patients with chronic diseases in gen-eral practice. Our system is tailored to the patient’s stage of changeaccording to the transtheoretical model of behavior change [9]. In adialog with the patient, the counseling system concludes the moti-

ll rights reserved.

erzberg), marsden@hs-heil-de (C. Leonhardt), Annette.-

vational level of behavior change and moves over into an adapted,well-fitted consultation. With respect to the patient’s motivationallevel the system interactively explains the effect of physical activ-ity on health. The patient’s pros and cons to maintain a sedentarylifestyle are discussed and strategies to encourage self efficacy,commitment and how to integrate physical activities in everydaylife are proposed. We are currently conducting a pilot study onthe acceptance and on the efficacy of our CBCS with respect to pa-tient outcomes.

The design and development of a computer-based counselingsystem in health care has some unique characteristics. The moststriking one is the heterogeneity of the addressed target group.Being a patient is a weak common denominator. Chronic diseaseslike diabetes mellitus and coronary heart diseases are most preva-lent in the elderly. Other than that we have to assume a broad spec-trum of capabilities and experiences among patients operating witha computer-based system. Obviously, the user interface must be assimple as possible, intuitive and consistent to use. Despite its sim-plicity in use, the service a counseling system provides should notbe trivial. Why should a patient spend his or her time with a com-puter? Why should a patient not abort a counseling session? If thesystem adds some value to the patient’s perception, then we arelikely to succeed in keeping the counseling dialog running andachieving something. The system might provoke a stimulus forbehavioral change; it might change the patient’s attitudes etc.

348 D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355

From research in usability engineering we know that there arefive essential usability characteristics that are vital for anyHuman–Computer Interaction (HCI): learnability (the user can rap-idly begin to work with the system), efficiency (the user attains ahigh-level of productivity), memorability (it is easy to return tothe system after some time of non-use), low error rate (users areprevented from making errors and errors do not have devastatingconsequences) and satisfaction (the system is pleasant to use)[10]. These characteristics are not easy to achieve, especially whenone has to deal with as heterogeneous a user group as in healthcare.

All in all, there are many reasons calling for a methodical andstructured design approach and involvement of potential users inthe development process of a counseling system.

Yet to this point there seems to be no structured approachguiding one through the development process of a counselingsystem in a systematic way—process-wise and specification-wise.In this paper, we are not concerned with a manual, tips, rules ofthumb, heuristics etc. on how to better design counseling sys-tems for patients. What we are after is a process including aspecification language. We developed an iterative three-stagedspecification process for counseling systems in health care,which enables early involvement of potential users in the devel-opment process. Our process is substantiated by a set of accom-panying XML-based (eXtended Markup Language) specificationschemata, a storage pool for media resources and a tool. Theset of specifications consists of two platform independent speci-fications and one or more platform dependent specifications. Thetool automatically generates a functioning counseling system foruse on a TabletPC out of the specifications. Due to the formalnature of our specifications, we support the process with someunique features, like early execution of prototypes, automatedsystem 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 structuredapproach to user-interface and interaction design taken from theliterature. We then present our development metaphor and ourrealization of the conceptual framework, an iterative three-stagedspecification process, which is adapted to the specifics of buildinginteractive, computer-based counseling systems. A detailed expla-nation of the accompanying specification language is given in Sec-tion 4. Here, we discuss the different specification schematamanifesting a new approach to user-interface and interaction de-sign. Finally, Section 5 closes with some conclusions.

2. Related work

As outlined by evidence-based guidelines, patient empower-ment is an essential goal in caring for patients with diabetes mel-litus and coronary heart diseases [11–13]. Healthcare professionalshave recognized the multifold options which computer-based sys-tems offer to enhance patient competence and awareness [14], butup to now, computer-based counseling systems have mostly fo-cused on software which offers individualized feedback regardinga certain topic—with little or no flexibility regarding change oradaption of the system or even transforming it for another device.Systems to persuade people to change their behaviors have beenimplementing using mobile phones or PDAs [15–20]. Computer-based systems on a desktop or touchscreen kiosk [21] have typi-cally been web-based, implemented in Flash Action script andHTML: for example there are counseling systems based on thetranstheoretical model dealing with physical activity [22], obesity[23] or contraceptive use [24]. In addition to the features of thesystems described in these studies, our system will not only allowfor individualized feedback and navigation based on the transtheo-

retical model, but will also log all interactions in real-time, allow-ing e.g. for usability analysis.

The role of evaluation in iterative user-centered design and test-ing has been highlighted in the context of health care systems,which are confronted with a level of uncertainty not found in tra-ditional business environments [25]. Yet based on our research,formal specifications, which can be used to facilitate the develop-ment of information systems [26], have not been used to generatecomputer-based counseling systems. Creating the counseling sys-tem directly out of the specification could help to solve a bundleof problems for which solutions had to be hand-tailored in thepast: generate output for different media, e.g. instant messaging[19] or for a specific target group, e.g. elderly people remainingat home [27].

Unlike systems which are employed in order to reach a certainobjective, i.e. have a clear utility, the use of computer-based coun-seling systems depends largely on their affordance and user-friendliness [28]. Thus usability issues have been crucial to healthsystems from the very beginning [29] and a variety of methodsfrom usability engineering have been adapted to healthcare sys-tems [25]. Benson [30] has proposed the Unified Modeling Lan-guage as stringent description language in order to not alienateusers and being able to communicate within the multidisciplinarydevelopment team. We are taking this one step further by formallyspecifying the human–machine interaction and having the wholesystem generated on the basis of this formal reasoning.

3. A structured approach to user interface and interactiondesign

In 2003, Garrett published ‘‘The Elements of User Experience:User-Centered Design for the Web” [31], a widely acknowledgedbook on user-centered design. The book does not explain howWeb sites are to be designed, it is even not about Web technologyat all. Instead, Garrett lays out a conceptual framework for talkingabout the user experience in a systematic fashion. We applied thisframework to the context of counseling systems in health care. Ourdeveloped iterative three-staged specification process is the pro-posal of a concrete implementation of Garrett’s framework in thisspecialized domain.

To understand and see the relation between Garrett’s frame-work and our specification process, we provide a brief introductionto Garrett’s framework in Section 3.1. We present the metaphor,which inspired and underlies our specification approach, in Section3.2. Our specification process is then introduced in Section 3.3. Weexplicate the relation to Garrett’s framework in Section 3.4.

3.1. The elements of user experience: a conceptual framework

Garrett structures his framework into five planes: a strategyplane, a scope plane, a structure plane, a skeleton plane and a sur-face plane, see Fig. 1. Each plane builds upon the planes under-neath. From bottom to top, the issues to deal with turn fromabstract to concrete. The planes are split in two halves, represent-ing two viewpoints on Web-based systems: the left half considersthe Web as a software interface—a viewpoint, which has becomepopular with the so-called Web 2.0; the right half considers theWeb as a hypertext system—a viewpoint, which reflects the histor-ical and architectural roots of the Web.

� On the strategy plane, the most abstract plane, the user needsand the site objectives are to be defined. Both aspects are thefoundation for all decisions to be made on upper planes. Defin-ing objectives includes having success metrics that indicatewhether the objectives are met or not.

Fig. 1. The elements of user experience.

D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355 349

� On the scope plane, the strategy is broken down into functionalspecifications and content requirements. A functional specifica-tion specifies precisely what the Web site actually does. Contentrequirements capture the types of media, which are to be used,and their context of use.

� The structure plane further details scope through interactiondesign on one hand and information architecture on the otherhand. Interaction design is concerned with the description ofpossible user behavior and the system’s response to that behav-ior. Most important in interaction design is to create a consistentconceptual model of the system’s interaction behavior. Theinformation architecture concerns the organizational and navi-gational schemes of content, which enable a user to movethrough a Web site efficiently and effectively. In analogy tointeraction design, the aim is to create a consistent conceptualstructure for the user. Garrett has developed a visual languagefor creating diagrams capturing the structure plane.

� On the skeleton plane we distinguish information design, inter-face design and navigation design. In interface design, we dealwith the arrangement of buttons, check boxes, drop-down listsand the like. Navigation design is a form of interface designespecially concerned with presenting navigation spaces. Infor-mation design refers to the presentation of information for effec-tive communication. All three aspects build up the logical partsof the skeleton and come together in the layout of a page. Typ-ically, page layouts are described with the help of so-called pagewireframes. A wireframe is a bare-bones depiction of all compo-nents of a page and their arrangement.

� The surface plane defines the actual appearance of the elementshandled with on the skeleton plane. While the skeleton planedeals mostly with arrangement, the surface plane deals withvisual presentation. It is what we see on a Web site.

We understand our iterative three-staged specification processas an implementation of Garrett’s elements of user experience.

3.2. A metaphor

Before we go on, we provide a brief introduction to our specifi-cation approach by means of a metaphor. As a matter of fact, ourapproach was developed with this metaphor in mind. The meta-phor helped our team a lot not to get lost in the technical details

which inevitably come along with a specification process and aspecification language.

Compare the conception and making of a counseling system towriting a script or a screenplay for a film. The screenplay writer(author) decomposes the script into episodes (which we callchapters) and scenes (so-called pages) an episode is made of. Afirst version of a screenplay might consist of chapters and pagesonly in order to draft the idea and the rough conception of thefilm. One can then go on and continue refining the scene. For eachscene, the required actors and requisites (resources) are to beidentified and the setting needs to be sketched (something wecall a logical style). Furthermore, we have to describe the actionsin a scene: How do the actors interact and how do they make useof the requisites? Finally, we have to be specific on the details:What exactly does the setting look like? The logical style is en-hanced 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 describesthe potential arrangement of visual elements in a sort of wire-frame, which we call logical style. The wireframe consists of so-called slots, placeholders for visual elements. Later on the logicalstyle is refined by a concrete layout, a concrete style, specifyingthe format and appearance of the visual elements in a dialog. Theactions in a scene can be compared to the events in a dialog page.They specify when and where the resources come into play in adialog. 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 fromthe aspect of the user interface. Each step comes along with ques-tions and/or instructions that guide one through the specificationprocess. As you will notice, intermediate iterations are alreadybuilt-in into the process. Take, for instance, step 1f in the concep-tion stage under ‘‘Interaction”. Once you reach this step, you areasked to reflect on a possible restructuring of page specificationsusing the copy-attribute of our specification language. The copy-attribute can be used to create master pages. Further details areprovided 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?

edical Informatics 42 (2009) 347–355

(b) Identify layout elements

– How many slots does a dialog page have?– What’s the media type associated with a slot?

350 D. Herzberg et al. / Journal of Biom

(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 ofdesign?

(e) Revise break-down

– Is there a use case for a different composition schema

of slots?

Fig. 2. Specification process: after each micro- and macro-step, the user’s feedbacktriggers iterations. 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?

3. 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 sat-isfying result is achieved. The degree of satisfaction is measured bythe objectives set for the counseling system. We differentiate be-tween micro-iterations and macro-iterations. We speak of a mi-cro-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 therealization stage (step 2b) immediate user feedback can be usedto change and adapt the appearance in an instant and againrequest feedback. A macro-iteration refers to a repeated walk-through of all stages, see also Fig. 2. This is, for example, meaning-ful after analyzing and evaluating the logging data according tocertain criteria. The logging data reflects the way the counselingsystem is used and will unveil whether the system has createdthe desired user experience. The conception and design of a coun-seling system should be considered in flux; an agile process—as de-scribed—is needed to seriously address patient concerns and offerthem a counseling system that adds value to their well-being, theirhealth and health literacy.

We emphasize that we favor early involvement of users in thedevelopment process of a counseling system. For example, earlyprototypes of the system (conception stage) can already be testedtogether with volunteers and their feedback can be immediatelyfed back into the specification process at an early conceptual stage.Our toolset can easily be extended in order to effectively involveusers (patients) in the specification process. What is missing inour toolset right now is a suitable frontend for the conceptionstage. Even though our specification language is simple, an author-

ing environment for the creation and editing of script and stylespecifications with some visual/graphical support would be bene-ficial. Such an environment could (a) help enforce the specificationprocess and (b)—more importantly—let users immediately partici-pate in the specification process. This would open up the develop-ment of counseling systems to a new level of user involvement inaspiration of user-centered design.

3.4. The conceptual framework revisited

The outlined specification process can be related to Garrett’sconceptual framework, see Section 3.1. However, a simple one-to-one mapping falls short for the following reasons: First, for acounseling system not all aspects are applicable like for a full-blown Web application. Second, because of this special domain,we made some decisions which pre-structure the domain of coun-seling systems. In other words, our approach removes the com-plexities of web design and simplifies Garretts’s approach to theessentials required for the design of computer-based counselingsystems.

To be specific, our specification process favors a similar top-down design process as Garrett does: the user needs and the coun-seling objectives need to be clarified first (strategy); the script hasto be broken down into chapters and pages including missionstatements (scope); the pages refine the interaction design regard-ing the system’s behavior and responses to the user (structure);the logical styles define the interface and navigation design bymeans 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 andrealization stage) condense four of the five planes of Garrett’sframework. The conception stage resembles the scope and thestructure plane, the realization stage the skeleton and surfaceplane. This distinction is supported by the specification of a logicalstyle and a script in the conception stage as well as a concrete stylein the realization stage. More details on these artifacts are to befound in the following Section 4.

The logging facilities we provide with our tool let us evaluateaspects of user experience. Combined with usability engineeringmethods [10], like Thinking Aloud (THA), the specification processcan be iteratively repeated for improvements. This is something,Garrett [31] does not elaborate on further, yet we consider itessential.

In the following section, we move on to the specificationartifacts to be created by authors of a counseling system. Thespecifications use a sort of Domain Specific Language (DSL). Whendesigning a DSL, the language design captures a process used inthat domain to some extent. The way statements are related and

Fig. 4. A simple example of a logical style.

D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355 351

nested outside-in partly reflects how steps are taken forward in aprocess. This also explains the close relationship of our iterativethree-staged specification process and the underlying schemataof our specifications. It is our way to capture this special domainof counseling systems for use in health care.

4. Specifying computer-based counseling systems

At the heart of our implementation of the iterative three-stagedspecification process are two documents, both being specified inXML (eXtensible Markup Language): one document specifies theintended user interface in logical styles, the other specifies theHCI (Human–Computer Interaction) in a script and refers to thelogical styles. In further steps, the specifications are enhancedand adapted towards a concrete platform using a specific technol-ogy. An overview of this process from a technical perspective is gi-ven in the following subsection. Subsequent subsections detailinformation about the above mentioned core documents and theproduced counseling system. In the last subsection, we justifyour language design in respect to other user interface descriptionlanguages.

4.1. Overview of the implemented specification process

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

4.1.1. Conception stageIn the first stage, the conception stage, an author or—in our

case—a team of authors creates two specifications using XML:one document specifies the intended user interface of the counsel-ing system, the other the interaction behavior. Unique to our ap-proach is that the user interface is specified by logical styles. Alogical style defines an arrangement of placeholders (which we callslots) on a dialog page, see Fig. 4. A slot can be loaded and unloadedwith visual content. The arrangement of slots per page reflects justan intention of the layout of the visual elements; the arrangementis not mandatory. In this sense, logical styles are a formalization ofthe idea of paper prototypes for the design of user interfaces.

Fig. 4 shows a simple style: an arrangement of four slots. Theslot 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 threemore slots, placeholders for some content of type ‘‘button”. Theycan be referred to by their respective names ‘‘yes”, ‘‘no”, and‘‘next”. For more details, please consult Section 4.2.

Fig. 3. Overview of the specification process, involved artifacts and tools.

The specification of the interaction behavior, which we callscript (remember the metaphor of a screenplay), decomposes theinteraction with a user into so-called dialog pages. Each page refersto a logical style, it specifies the resources required on the page, itdefines the actions the counseling system performs on this pageand how the system reacts on user generated events like pressinga button. This might result in a jump to another dialog page.

Fig. 5 visualizes the specification of actions associated with apage. First, there are two actions running in parallel. One actionplays a resource of type ‘‘audio”, which is referred to in the poolof resources as ‘‘Question”. The other action shows a resource oftype ‘‘text” referred to as ‘‘Question”. There are no name conflictssince the resource types differ. More specifically, the show-actionaddresses a certain slot in a style and puts the resource into thatslot. 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 corre-sponding slots. For more details, see Section 4.3.

Taken together, the specification of logical styles and the spec-ification of a script are executable. This can be used for prototypingpurposes and early testing of dialogs and user interactions. We didnot have the chance to develop any tools for this, so we did notmake use of this option—yet such an early execution of specifica-tions would be extremely helpful.

4.1.2. Realization stageIn the second stage, the realization stage, we ‘‘put flesh to the

bones”. The specification of logical styles is enhanced by a specifi-cation of concrete styles. A concrete style implements, so to speak,the logical style. A concrete style gives a precise definition of theplacement of slots on a dialog page and their appearance. How thisis done and which technology is to be used for that purpose de-pends on the platform and personal preferences. The specificationsof the conception stage are abstract in the sense that they are plat-form independent (though executable).

In the realization stage, decisions regarding the appearance ofthe system have to be made. In our case, we decided to useWeb-based technology and prepare for distributed use over theInternet. For this reason we used HTML (HyperText Markup Lan-guage) and Cascading Style Sheets (CSS) to substantiate logicalstyles. In an experimental spin-off of our counseling system, wetargeted Flash-based technology, which is an example of anotherrealization platform. In addition to the concretization of logicalstyles, all the resources, which are listed in the interaction specifi-cation, need to be related to ‘‘the real thing”, namely audios, videosand images. Therefore, the media have to be produced, assembledand stored in a central place.

The core element in the realization stage is the generator. Thegenerator takes the specifications of the conception stage, concretestyle definitions and the media resources as an input and outputsthe actual counseling system for the target platform. Our generatedcounseling system consists of a number of HTML pages includingJavaScript (JS), actually one HTML page per dialog page in the inter-

Fig. 5. An example of actions specified for a dialog page.

352 D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355

action specification. The HTML pages use the concrete style defini-tions and the media resources.

The key role associated with the realization stage is digital med-ia design. Due to budget limitations, we had no access to a profes-sional media designer but could afford a professional speaker forthe audios. The concrete styles, the videos and audios were pro-duced by our team.

4.1.3. Deployment stageIn the deployment stage, the output of the realization stage (the

actual counseling system) gets installed on physical hardware andis ready for use in experiments, field studies and the like. To pro-vide extra functionality, modules for navigation and logging (bothimplemented in JavaScript) are delivered with the counseling sys-tem. We installed the counseling system on TabletPCs with ascreen resolution of 1024 � 768 pixels and built-in speakers. Thescreen is touch-sensitive and can be used with a pen only; it doesnot react on touch with a finger. During a counseling session with apatient, 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 informationabout the specification of styles and scripts and the generatedcounseling 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 whata page in an interaction dialog should look like. The focus is on alogical organization of placeholders (called slots), which can beloaded or unloaded with content, referring to resources like text,images, videos and buttons. The concrete realization of a logicalstyle is separate from this.

The logical organization of slots in a style is given by two com-mands: stacked and juxtaposed. The command ‘‘stacked” puts oneslot above another (vertical arrangement), ‘‘juxtaposed” sets themnext to each other (horizontal arrangement). Here is a simpleexample:

<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 de-

scribes an arrangement of four slots, with a slot called ‘‘text” placedabove three other slots (‘‘yes”, ‘‘no” and ‘‘next”); these three slotsare positioned next to each other, see also Fig. 4. A type is givenper slot, indicating which kind of resource the slot is reservedfor. The class-attribute provides abstract information about theappearance of a slot. For instance, slot ‘‘yes” is associated with anabstract 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 astyle definition. This enables an author to compose an logical styleout of other styles and benefit from reuse (see the following exam-ple). Here, a style is composed of a header style, a images style anda question style. The question style refers to the style exemplifiedbefore.

<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 twostages of user interface design: in the conception stage, we firstagree on the placeholders and their intended positioning in aninteraction dialog. This is primarily a contract about slots availableon a dialog page, their intended layout is secondary—this is close tothe idea of paper prototypes and wireframes. In a second stage, inthe realization stage (see also Fig. 3), we specify the concrete posi-tioning and appearance of slots separately. Concrete styles refine,detail and may even overwrite the intended layout of slots in thelogical styles. Concrete styles cannot add or remove (just hide)slots. The way of specifying concrete styles is dependent on the tar-get 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 resemblesthe organization of a book or a screenplay. Especially the metaphorof a screenplay helped the involved authors, physicians and psy-chologists, to get used to the idea of specifying interactive counsel-ing dialogs in XML. The interaction specification is organized inchapters, and each chapter is composed of pages, each page repre-senting a self-contained interaction scenario with the patient. Theinteraction starts with the first page of the first chapter of a script.Besides, some meta-information (authors, revision informationetc.) can be supplied. Note the reference to logical styles.

<script version="0.9"

date="2007-05-13"

D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355 353

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 beaudios, buttons, images, texts, timers and videos. Furthermore, apage is composed of actions. The following actions are available:show, empty, play, halt, jump, eval (evaluate) and log. Actionscan run in sequence or concurrently in parallel and specify thesystems behavior. In addition to actions, reactions can be specified,which define how the counseling system reacts on user initiatedevents, like moving the input device (e.g. a mouse or a pen) orpressing a button on the screen. The body of a reaction is specifiedwith JavaScript; JavaScript is used as an action language. Thisprovides quite some flexibility on how to react to user initiatedevents. As an example, see the following specification of the dialogpage ‘‘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 de-scribes the intention of this page. Then, five resources are intro-duced: 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 delaysfurther actions by one second. Then the buttons ‘‘Yes” and ‘‘No”show up in slots ‘‘yes” and ‘‘no” at the very same time. Note thatslot ‘‘next” (see logical style ‘‘YesNoQuestion”) simply remains un-used. The flow of actions is also depicted in Fig. 5. The user canintervene at any time. If the user clicks on the ‘‘Yes” button (it musthave shown up in a slot before being accessible), the next page thecounseling 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 ofpages; the attribute is not used in the example above. It servesthe same purpose as the copy-attribute for slots does: to facili-tate reuse and foster composition of pages out of other pages.A typical use case would be the definition of a master page otherpages refer to via copy. The master page introduces some stan-dard resources and some standard reactions, which can be over-written if required.

4.4. Generating the counseling system

From the specification of logical styles, the specification of ascript, concrete specifications for the dialogs’ look & feel (con-crete styles, i.e. CSS definitions) and a pool of media resources,the counseling system is automatically generated for a specifictarget 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 Java-Script is used as an action language within scripts, the code iscopied to the Web pages by the generator. The counseling sys-tem is prepared for remote use over the Internet. Fig. 6 showsa screenshot of the CBCS in action running within MicrosoftsInternet Explorer 7. Our system relies on a Web browser sup-porting SMIL (Synchronized Multimedia Integration Language).The flow of actions can be mapped to SMIL in an almost one-to-one manner.

Note that the lower part of the screenshot is specified by alogical style similar to the one shown in Fig. 4. If one comparesthe two figures, it becomes clear how a text-based XML style ofspecifying requirements reconciles with visual aspects of designfor end users. The text-based XML style renders a rudimentaryintention of a visual layout. It is a proper approximation of thefinal end result and can be used for early prototyping purposes.Considering that the generation of the counseling system is justa matter of seconds, one can experience the effect of specifica-tion changes in an instant.

The generator embeds two modules in the counseling systemto provide navigation and logging capabilities. Extensions areprogrammed in JavaScript. The navigation module enables quickand easy jumps to any dialog page of a counseling session via anavigation menu. It is accessible via a hot key and available fortesting purposes only. The logging module records all events inreal-time, system generated events as well as user initiatedevents, and sends them to a logging server. A sample excerptis shown in Fig. 7. The first column is a session id out of six dig-its. Next comes the date and the time down to the millisecond.Then there is the logged event in XML format including a list ofparameters.

If used over the Internet, real-time logging allows an observer tomonitor a counseling session between the system and a patient ona remote computer. This feature might be useful for conducting on-line experiments with the counseling system. With the event logon the logging server, counseling sessions can be precisely recon-structed and replayed. The log data can be analyzed and evaluatedfrom various points of view, e.g. how much time a patient spendson a dialog page etc.

Fig. 6. Example screenshot of the counseling system in action.

354 D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355

4.5. Relation to other user interface description languages

There are some description languages for the definition of userinterfaces and user interactions. Most of them are markup lan-guages 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 (XMLFrames).1

We studied these languages in detail and borrowed some ideasfrom XUL and XBL, but we have deliberately chosen to develop ourown approach for the following reasons:� Some of these languages are platform dependent like XAML

from Microsoft for Windows. We strove for platform inde-pendence but with an eye on web-based browsers. That iswhy we use JavaScript as an action language.

� Our language is restrictive in its capabilities to design userinterfaces by intention. Our users are the elderly and weanticipate them to have no computer experience at all. Anauthor of a counseling dialog should be prevented fromdesigning complicated interfaces and complex interactions.Therefore there are no widgets for menus or selection lists,for example. Our system favors and stimulates the use ofimages, audios and videos to create a communicative userexperience.

� Most user interface description languages strive for a clearseparation of content, style and behavior; this is consideredto be state-of-the-art. We strictly followed this principle andtook over XUL’s box model for layouts, its idea of addingstyle sheets and, to some extend, picked up XBL’s notion ofbindings.

� We were in need of a simple action language. JavaScriptcame in very handy, see first bullet point. Not all user inter-face languages are associated with an action language.

� With our approach we provide means to incrementally spec-ify and refactor (via the copy tag in styles and the copy attri-bute in scripts) a counseling system. The idea is to start froma very coarse grain level and to refine interactions and/orstyles stepwise. As long as the XML documents are wellformed and valid, they are basically executable. In otherwords, our language design is connected with a method asoutlined above. We do not know of a user interface languagewith similar qualities in this respect.

1 See uiml.org, mozilla.org/projects/xul, w3.org/TR/xbl, msdn.microsoft.com/en-us/library/ms752059.aspx for XAML, and w3.org/TR/xframes.

� The simplicity of our language design allows us to apply amathematical formalism, a process calculus, to our concep-tions and do some formal reasoning. Although this isresearch in progress, it looks promising and makes our sys-tem theoretically sound. Some information on this can befound in the next section. Todays user interaction languagestypically do not satisfy mathematical soundness.

5. Conclusions

In this paper, we presented a structured approach to specifycomputer-based counseling systems in health care. The approachconsists of an iterative three-staged specification process and issubstantiated by a set of specification schemata, a media storageand a generator. The generator takes all the specifications and themedia resources and outputs an executable counseling system foruse on TabletPCs. The specification process aims at involving poten-tial users as early as possible and favors user-centered design.

We plan to extend our toolset into two directions: first, anauthoring environment would help improve the work process inthe conception stage. Working with XML is not really an optionfor CBCS authors in the long run and does not promote ‘‘pairauthoring” with potential users. From an authoring environment,we expect to gain new insights in the collaboration process be-tween authors of counseling systems and their users.

Second, on the backend side, we would like to be able to config-ure our generator to support different kinds of target platforms likePDAs, mobile phones, brochures etc. This will also have an impacton the specification process.

Another issue is that we are aiming at basing our specificationson a sound mathematical formalism, namely a process calculus[32]. The goal is to apply formal reasoning on a complete interac-tion 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 apatient will terminate, i.e. will come to an end.

In our current implementation of the CBCS generator, we imple-mented such checks pragmatically. From the viewpoint of a com-puter scientist, however, the beauty lies in proving suchproperties formally. Besides, a formal basis of our specification ap-proach is key for producing highly adaptable but still reliable coun-seling systems. This is an important requirement if you think ofcounseling systems a physician can compose out of counselingmodules on the fly, configured and personalized for the patientand customized for a certain target medium like a Web browser,PDA (Personal Digital Assistants), mobile phone or brochure. Thereleased product has to be stable and should not suffer from under-specification, broken paths of consultation and other deficits. Wethink that a formal underpinning is an essential cornerstone in auser-centered specification process. It helps create a ‘‘painless”user-experience; something the user will benefit from—withoutever knowing about it.

Acknowledgements

The first generation implementations of generators and verifi-cation tools based on the specifications described here were devel-oped by competing teams of students during summer term 2007 atHeilbronn University, who participated in the LabSWP course.Thanks to all for their hard and fantastic work.

Fig. 7. An excerpt of logged events.

D. Herzberg et al. / Journal of Biomedical Informatics 42 (2009) 347–355 355

References

[1] Karmisholt K, Gøtzsche PC. Physical activity for secondary prevention ofdisease. Dan Med Bull 2005;52(2):90–4.

[2] Gregg EW, Gerzoff RB, Caspersen CJ, Williamson DF, Narayan KM. Relationshipof walking to mortality among US adults with diabetes. Arch Intern Med2003;163(12):1440–7.

[3] Taylor RS, Brown A, Ebrahim S, Jolliffe J, Noorani H, et al. Exercise-basedrehabilitation for patients with coronary heart disease: systematic review andmeta-analysis of randomized controlled trials. Am J Med2004;116(10):682–92.

[4] Pinto BM, Friedman R, Marcus BH, Kelley H, Tennstedt S, Gillman MW. Effectsof a computer-based, telephone-counseling system on physical activity. Am JPreventive Med 2002;23(2):113–20.

[5] Hillsdon M, Foster C, Thorogood M. Interventions for promoting physicalactivity. Cochrane Database Syst Rev 2005;25(1):1–7.

[6] Patrick K, Calfas KJ, Norman GJ, Zabinski MF, Sallis JF, Rupp J, et al. Randomizedcontrolled trial of a primary care and home-based intervention for physicalactivity and nutrition behaviors: PACE+ for adolescents. Arch Pediatr AdolescMed 2006;160(2):128–36.

[7] Williams GC, Lynch M, Glasgow RE. Computer-assisted intervention improvespatient-centered diabetes care by increasing autonomy support. HealthPsychol 2007;26(6):728–34.

[8] Revere D, Dunbar PJ. Review of computer-generated outpatient healthbehavior interventions: clinical encounters in absentia. J Am Med InformAssoc 2001;8(1):62–79.

[9] Prochaska JO, Velicer WF. Behavior change. The transtheoretical model ofhealth behavior change. Am. J. Health Promotion 1997;12(1):38–48.

[10] Holzinger A. Usability engineering methods for software developers. Commun.ACM 2005;48(1):71–4.

[11] del Hoyo-Barbolla E, Kukafka R, Arredondo MT, Ortega M. A newperspective in the promotion of e-health. Stud Health Technol Inform2006;124:404–12.

[12] Bundesärztekammer, kassenärztliche Bundesvereinigung, Arbeitsgemeinschaftder wissenschaftlichen Fachgesellschaften. Nationale Versorgungsleitlinie Typ-2-Diabetes [National Guideline Diabetes Typ II]; 2006. Available from: http://www.diabetes.versorgungsleitlinien.de.

[13] Bundesärztekammer, kassenärztliche Bundesvereinigung, Arbeitsgemeinschaftder wissenschaftlichen Fachgesellschaften. Nationale Versorgungsleitlinie KHK[National Guideline Coronary Heart Disease]; 2006. Available from: http://www.khk.versorgungsleitlinien.de.

[14] Boisen E, Bygholm A, Cavan D, Hejlesen OK. Copability, coping, and learning asfocal concepts in the evaluation of computerised diabetes diseasemanagement. Int J Med Inform 2003;70(2–3):353–63.

[15] Consolvo S, Everitt K, Smith I, Landay JL. Design requirements for technologiesthat encourage physical activity. In: CHI’06. New York, NY, USA: ACM Press;2006. p. 457–66.

[16] Fogg BJ. Persuasive technology: using computers to change what we think anddo. San Francisco, USA: Morgan Kaufman; 2003.

[17] Lee G, Tsai C, Griswold WG, Raab F, Patrick K. PmEB: a mobile phoneapplication for monitoring caloric balance. In: CHI’06. New York, NY,USA: ACM Press; 2006. p. 1013–8.

[18] Silva JM, Zamarripa S, Moran EB, Tentori M, Galicia L. Promoting a healthylifestyle through a virtual specialist solution. In: CHI ’06. New York, NY,USA: ACM Press; 2006. p. 1867–72.

[19] Sohn M, Lee J. UP health: ubiquitously persuasive health promotion with aninstant messaging system. In: CHI’07. New York, NY, USA: ACM Press; 2007. p.2663–8.

[20] Toscos T, Faber A, An S, Gandhi MP. Click clique: persuasive technology tomotivate teenage girls to exercise. In: CHI’06. New York, NY, USA: ACM Press;2006. p. 1872–8.

[21] Nicholas D, Huntington P, Williams P. Delivering consumer health informationdigitally: a comparison between the Web and touchscreen kiosk. J MedicalSystems 2003;27(1):13–34.

[22] Singh V, Mathew AP. WalkMSU: an intervention to motivate physical activityin university students. In: CHI’07. New York, NY, USA: ACM Press; 2007. p.2657–62.

[23] Mauriello LM, Driskell MM, Sherman KJ, Johnson SS, Prochaska JM,Prochaska JO. Acceptability of a school-based intervention for theprevention of adolescent obesity. J. School Nursing 2006;22(5):269–77.

[24] Peipert J, Redding CA, Blume J, Allsworth JE, Iannuccillo K, Lozowski F,et al. Design of a stage-matched intervention trial to increase dualmethod contraceptive use (Project PROTECT). Am J Med2007;28(5):626–37.

[25] Kushniruk A. Evaluation in the design of health information systems:application of approaches emerging from usability engineering. Comp BiolMed 2002;32:141–9.

[26] Ortiz-Cornejo AI, Cuayahuitl H, Perez-Corona C. WISBuilder: a framework forfacilitating development of Web-based information systems. In: Proceedingsof the 16th international conference on electronics, communications andcomputers. Conielecomp’06; 2006. p. 46.

[27] Hubert R. Accessibility and usability guidelines for mobile devices in homehealth monitoring. SIGACCESS Access Comput 2006(84):26–9.

[28] Curé O. Evaluation methodology for a medical e-education patient-orientedinformation system. Med Inform Internet Med 2003;38(1):1–5.

[29] Boisen E, Bygholm A, Hejlesen OK. Activity theory and medical informatics:usability, utility, and copability. Stud Health Technol Inform 2002;90:826–31.

[30] Benson T. Prevention of errors and user alienation in healthcare IT integrationprogrammes. Informatics in Primary Care 2007;15(1):1–7 .

[31] Garrett JJ. The elements of user experience: user-centered design for theWeb. Berkley, CA: New Riders; 2003.

[32] Magee J, Kramer J. Concurrency—state models and Java programming. 2nded. West Sussex, England: Wiley; 2006.