Usability and efficiency. The Helios approach to development of

Abstract

This chapter describes the user interface related services of the Helios project. The design and implementation ofefficient user interfaces is a prerequisite for successful introduction of computer support in health care ward units.Design principles must be based on a basic understanding of cognitive aspects of human-computer interaction, aswell as on detailed knowledge about the specific needs and requirements of the health care professionals.

In the Helios project, a style guide for design of user interfaces has been developed. The style guide definesdetailed design guide-lines together with a set of interface elements specified for the ward domain.

Development tools for construction and implementation of user interfaces to ward applications have been devel-oped and integrated into the Helios SEE. The tools are based on the TeleUSE product, which has been extended andadjusted to the Helios specifications.

A set of new widgets, designed to implement health care interface elements, has been incorporated into the devel-opment tool.

Key words: Human-computer interaction, user interface, interface design, cognitive work-load, style-guide,UIMS.

Usability and efficiency.The Helios approach to development of user interfaces.

E. Borälva, B. Göranssonb, E. Olssona and B. Sandblada*

aCMD, Center for Human-Computer Studies, Uppsala UniversityLägerhyddvägen 18, S-752 37 Uppsala, Sweden

Email: [email protected], URL: http://www.cmd.uu.se/

bUI Design AB, Linköping, Sweden

1. Introduction.

1.1. The importance of a good user interface

Intensive efforts to introduce more and morecomputer support in health care delivery unitshave not always resulted in increased efficiency.On the contrary, high development costs, ineffi-

cient systems and low acceptance are commonlyencountered problems. One important reason forthis is that the design of the system, and especiallyof the human-computer interface, is often notadapted to the specific demands and requirementsof the health care environment. To be efficient,and to be accepted by skilled health care profes-sionals, the information system must support and

* Corresponding author.

.

2 HELIOS Supplement to Comput. Methods Programs Biomed.

n

enal

f,totop-d.-hed

s,er

etose

if,nd

p-

rehy-as

ofndlsof

nthe

not hinder their main focus; the competent careand management of the patients [1].

In health care, as in many other work situationswhere computerized information systems areused, the purpose of the work performed by theinvolved professionals is never to operate thecomputer as such. The computer is a tool that willbe accepted and used only as long as it efficientlysupports the efforts to provide good health carefor the patient.

This means, among other things, that the userinterface to the information system must be de-signed to optimize the health care work activitiesas such and not only to optimize the handling ofthe computer as a tool. Experiences from manydevelopment projects in different countries haveshown that a bad user interface is a common causefor system inefficiency and low user acceptance.The practical consequence of this is that the de-sign must be based on an analysis of how informa-tion is being used in the actual work context forwhich the application (or artifact) is intended. Thedesign must also be made so that the handling ofthe interface can be as automated as possible. Inthis way the computer system will be transparentand the user can concentrate on the care deliverytasks.We say that the interface must be obvious tothe user [2].

1.2. The Helios approach to interface develop-ment

The main purpose of the Helios project is to de-velop an efficient system engineering environ-ment (SEE) for health care ward informationsystems. It has been the responsibility of the Hu-man-Computer research group at CMD, UppsalaUniversity, to provide the project with knowledge,methods and techniques for interface design anddevelopment. The Helios approach to this task canbe summarized as follows:

• Specification of basic considerations anddesign guidelines concerning human-computerinteraction within Helios applications. Knowl-edge from cognitive psychology concerninghow individuals process information, espe-cially in a professional work environment, hasbeen incorporated into methods and techniques

for information analysis and interface desig[2].

• Development of a domain specific style guidfor Helios ward applications. With a domaispecific style guide we here mean an additionlevel on top of existing style guides, e.g. Motiwhere domain knowledge is incorporated inthe specification of interface elements and indesign guidelines [3]. The purpose of develoing such a style guide is, at least, twofolFirstly to improve the efficiency of the development process and secondly to improve tefficiency and “user friendliness” of the warapplications.

• Specification and development of the HelioMedical Information Presentation ServiceMIPS, integrated into the Helios SEE. Tharchitecture of the MIPS will be furtheexplained below.

• Design and specification of new interfacpresentation components to be included inthe MIPS. Since the specification of the Heliodomain specific style guide requires interfacpresentation components not found in Motthese elements must be identified, designed aimplemented.

1.3. Different categories of users and interfaces

We can define Helios users of different kinds:

• The users of the Helios SEE, i.e. the develoers of Helios applications.

• The users of Helios applications. These athe real end-users in the ward, i.e. nurses, psicians etc. using the developed artifacts integrated parts of their work environment.The methods and tools developed in this part

the project are mainly intended for the secogroup of users. However, most of the result is avalid for the first group. It is also the objectives othe first group to design and implement efficieinterfaces for the second group, according to tHelios style guide.

HELIOS Supplement to Comput. Methods Programs Biomed. 3

ga

inndrklsree a

sorks

c-

att,

areim-heel

rkithes

dhory

rett-l

rearyeg

hend

ceb--ityon-

2. Cognitive aspects on human-computer interaction

From cognitive and perceptual psychology wecan learn a lot about how human beings observeand understand their environment, how they com-municate and how they, in a working life context,use their cognitive skills. The following model,(figure 1), is a practical model for our purposes[4], [5], [6]:

We can distinguish between at least two differ-ent cognitive levels. The high cognitive level isconscious and analytical, but has a low capacity,and can only handle one process at a time. Activi-ties on this level are strictly sequential.

On a low cognitive level, on the other hand, wecan perform a large number of parallel activities.Here the information handling is near to sensory-motor activities. The activities have high capacityand their processing is automatic. In order tomake an activity automated it must be familiar tous, i.e. we must learn it “by heart”.

The high level is used especially for readinand understanding numeric and semantic informtion. On the lower level we recognise patternsterms of shape, colour and frequency in time, ahandle automated movements. In our daily wowe are simultaneously using both cognitive leveRepetition of tasks that have a suitable structuresults in a transfer from high to low level, i.e. thactivity becomes automated. Normally we havetendency to organise our work environment that we can concentrate on the “core” of the woprocess, e.g. some problem solving activitie

tef-ea-

he in

n

e-rmr-

High cognitivelevel

Automated,low cognitive

level

-

.

.

Here most often the use of high level cognitive ativities is required. The “supportive” activitiesneeded for performing the work, e.g. looking documents, finding and opening a documengrabbing a pen and noting some remarks etc., organised so that they can be automated. It is portant for the efficiency of the work that as mucas possible of the “supportive” activities can bautomated, in order to let us use the high levcognitive capacity for the more demanding wotasks. Often a computer system interferes wthis, because the handling of the artifact requirhigh level cognitive activities.

We can also distinguish between primary ansecondary information. Abstract information sucas a name of a person or a result from a laborattest is regarded as primary information. We haveto read the information to understand and interpit. The appearance of the information, or its patern (gestalt), formed by colour, pattern, spatiacharacteristics and behaviour, is regarded as sec-ondary information. The interpretation of a pic-ture or a quick glance at a laboratory report aexamples of situations where we use secondinformation. In the latter case a missing valumight give us more information than an existinone. The secondary information is perceived on alow cognitive level rather then read [7].

A design goal must, in other words, be to let tuser make optimal use of his or hers creative aproblem solving abilities to perform the essenof work. The user must be able to perform a sustantial part of the “supportive” information processing on the automated level. The low capacsequential processor should be saved for reasing and problem solving. The most importanthing is that the user can perform his task in an ficient way without any disturbance from thcomputer system. The user should, in every sitution, have the information needed to perform ttask at hand, and also have the feeling of beingcontrol of the action.

Another important aspect of human informatioprocessing concerns the memory. We can distin-guish between the “short term memory” and th“long term memory”. When working with computer systems the characteristics of the short tememory are especially important. Main characte

Fig. 1. A simplified model of human cognition. On the conscious top level we can only perform one process at a time. However, on the lower levels we can handle many

automated activities in parallel.


f a

be-

be asa-nm-he

heheled?

r-

e

areceaininbe

ri-is

toal

s,ta-

istics are that only few information elements (5-8)can be stored simultaneously, that the decay timeis short (approx. 15 sec.) and that it is easily dis-turbed by other cognitive activities. An interfacemust therefore be designed so that the load on theshort term memory is minimized. Short termmemory overload can result in strain, stress andlow performance.

2.1. Cognitive problems in computer supported work.

To perform a task effectively it is important tosimultaneously supply the user with all informa-tion needed for one specific task. It is a fact thathaving to switch between different screens and tointegrate different information sets leads to an ex-tensive cognitive load. A frequent user finds itfrustrating to have to remember pieces of informa-tion while switching between tasks. Such a worksituation makes considerable demands on theuser’s short term memory. A well-designed userinterface should have few levels, and only de-mand a change of level when it is absolutely nec-essary.

When we have studied and analysed differentwork situations in health care we have identifiedseveral different types of cognitive problems asso-ciated with interaction with computer systems.Some of the most important ones are [2], [8]:

• Interrupts of work related cognitive proc-esses, caused by operation of the computer sys-tem.

• Problems to get an overview of existing infor-mation sets. This is often the result when anoverview or only one detail is shown at a time.

• The 'cognitive tunnel view' problem. We havea tendency to over-emphasize the informationwe can see simultaneously, and disregard theinformation we cannot see even if we knowthat it exists, when making a judgment or adecision.

• Unnecessary cognitive overload. We mustremember a lot of things which has no rele-vance to the actual work problem, but arerelated to the control of the computer artifacts.

• Overload of the short term memory.

• Problems to coordinate time related data.

• Problems in identifying the present status oprocess.The design guidelines to be developed must

aiming at minimization of these cognitive problems.

3. Design of user interfaces

3.1. Who is the user of the interface?

The design of a user interface must always based on an analysis of both the work situationsuch and of the end user working with the appliction. A good understanding of the work situatioand of the user is in other words a necessity. Iportant questions, that will effect the design of tinterface, are e.g.:

• Who is the user? Skill level? Education?

• How often will the application be used?

• Is the user performing several tasks at tsame time, such as talking to patients on tphone at the same time as checking scheduappointments or reading in the patient record

• Are other applications used? How is the coodination between different applications?

• How is the work situation organised? Is thuser sitting still? Running in and out?

3.2. Design in the health care domain

Experiences and research indicate that therea number of considerations concerning interfadesign that are specific to the health care dom[1], [9]. It is important to include such aspects the design guidelines and in the style guide to developed. This will be further discussed below.

3.3. A user centred development model

We believe that it is necessary to use an expemental model for systems development. Only thmodel will allow the health care professionals participate in the development project in an reuser centred manner, (figure 2).

The development project involves two groupthe health care professionals ('user represen


p-rknt

ryc-ere-i-

isedesrea--ithifi-

pe

nt toen-

ul-ec-te

u-usetnd

tives') and the computer experts (‘system develoers’). They have different roles, but should woclosely together during the whole developmeprocess.

The result from a task analysis is a preliminarequirement specification formulated in 'work ativity terms'. This is handed over to the computexperts, who try to transform it into a new requirment specification, now formulated in more tradtional 'computer' terms. From this a prototyperapidly being developed. The prototype is handover to the health care professional who can tand evaluate it. From their experiences they anow able to formulate a more detailed specifiction, still in work activity terms. This is again interpreted by the computer experts, together wevaluation data, leading to new computer spec

i-itu-se

s-is-heo-

nalro-n

rds,

in-ch all

el-e- of

s-ace

Preliminary specificationsfrom task analysis

User representatives Computer experts

Interpret

PrototypeTest

Interpret, modify

specification

New prototype

Modify

Etc.

Time System develops

Req

uire

men

t spe

cifi

catio

n in

act

ivity

term

s

Req

uire

men

t spe

cifi

catio

n in

com

pute

r te

rms

t

cations and prototypes etc. Finally the prototytransforms into the final system.

The use of two different sets of requiremespecifications allows the user representativesparticipate in the development project, and evto obtain a leading role in it. Two important prerequisites for this development model must be ffilled. Firstly the user representatives must bgiven proper possibilities to participate and, seondly, the prototyping tools must be efficienenough. Both things are often difficult to achievin practice.

An experimental model also enables a continous development of the computer system, thmaking it possible to modify the system to menew external demands, user requirements, atechnical solutions.

4. A domain specific approach to interface design

4.1. What is a domain specific style guide?

We define a domain as the class of work activties that bears similar aspects on the workers sation and performance regarding interaction, cahandling, decision making, information procesing etc. We can e.g. distinguish the staff admintration domain, the health care ward domain, tlaboratory work domain etc. In the health care dmain physicians, nurses, administrative persocollaborates to accomplish good health care. Pfessionals interact with patients using informatiosources such as time schedules, patient recoradiology reports, financial plans etc.

A domain can be broad or narrow. If the domais defined too narrow its usage will be very limited. If it is too broad the advantages of using sua style-guide will be reduced. (In the extreme,domain specific style-guide for the domain of acomputer applications could be e.g. Motif).

With a domain specific style-guide we mean aspecification of a class of appropriate interface ements together with guide-lines for interface dsign using these elements for a given domainapplications [10].

Domain specific design requires a high correpondence between design concepts and interf
Fig. 2. An experimental model for systems development.


onetse

xt-no-i-

tso-gh-eli-ofct-hee-d

ts,nin

rts:

components to enable efficient implementation.Style guides can serve as a tool to accomplish auniform, well-functioning design. Existing styleguides, however, seldom contain design guide-lines outgoing from a user centred perspective or atask orientated approach. Instead they concentrateon general design aspects.

The process of developing a domain specificstyle guide is laborious but is normally only per-formed once per domain. An additional applica-tion specific analysis has to be done before theend-user application is developed. This will, how-ever, be a fairly simple matter compared to what isneeded when the design is based on a general styleguide, such as e.g. Motif.

Involvement of end-users in the developmentand prototyping will be facilitated since it can beperformed in a domain relevant terminology. Ine.g. the health care domain the professionals donot work with ’radio-buttons’ and ’scroll-bars’, butwith patients, laboratory reports and drug pre-scriptions. When the design decisions are made ina domain related language, the user centred deve-lopment model is improved.

4.2. Development of a domain specific style guide

For efficiency reasons we will define a domainspecific level of design guidelines on top of thebasic guidelines. The process to develop a domainspecific style guide, based on an existing standard(Motif) can be described as follows [10]:

• In the first step a detailed analysis of informa-tion utilization of work activities in the defineddomain is performed. There are a number ofproblems involved in analysing how profes-sionals utilize information while performingwork-related tasks. Since the reason for per-forming such an analysis is to reduce cognitivework-load, the tasks must be defined in relationto individuals and their behaviour. The tasks, orrather the sub-tasks, the users perform whileworking must be specified. What we want toestablish is the decision making processes per-formed by users in relation to the task proper.

• Derived from the specification of the Heliosclass of applications a set of basic interface ele-

ments can be defined. These will be based the Motif widget set as far as possible. The sof basic elements will be the building blockfrom which elements on higher levels can bconstructed. Examples of such blocks are tefields, buttons, input-fields etc. The desigshould be made in such a way that the compnents can be identified and used with a minmum of cognitive load.

• The specification of basic interface elemenand structured, more complex interface compnents, is a step by step procedure. On the hiest level of aggregation the interfaccomponents will correspond to complete appcations.The basic idea for development Helios interface elements is to use an objeoriented approach. The tool selected for tdevelopment also supports this work procdure. This subject will be further discussebelow.

• The rules for design of interface componentogether with guidelines for application desigusing these components, now form the domaspecific style guide.

5. The Helios Medical Style Guide

5.1. Document structure

The style guide consists of three separate pa• Basic considerations and design methods• Design guidelines• Interface elements and attribute settings

5.1.1. Basic considerationsThe first part contains a general introduction

describing user aspects important to interface de-sign. Here we identify different user profileswithin the domain, and resulting considerations.We describe the basic theories of human informa-tion processing, like cognitive abilities and limita-tions, and how these influence our physicalabilities of communication with the environment.

5.1.2. GuidelinesConventional guidelines are necessary to create

a common platform, within as well as between ap-


ede

heonint,-m-st

ingbeil-h and

lalin-

n-d. ofeal

erent tor-t a

ndn.g

of a-

tos

plications. Se for instance [11], [12], [13], [15],[16], [17] for examples.

General guidelines, however, often prove to betoo general to serve as a solution to a specific de-sign problem. They can provide very detailedrules on low design level, which of course is goodand necessary, but they don’t provide enough ofthe information required at the application de-signer. The medical style guide acts as an exten-sion to the OSF/Motif Style Guide [14]. In someaspects it may contain restrictions on OSF/MotifStyle Guide, but mostly it contains supplementaryhigh level information, i.e. domain specificknowledge.

The guidelines part is a specification of the de-sign considerations that should be made when de-signing Helios interfaces. The guidelines shouldbe regarded as the principles according to whichthe interface elements are designed and the princi-ples for configuration of the elements to applica-tions.

In the design guidelines each important area isdescribed in a general part, for instance generalaspects of “visual encoding”, to create a commonreference. Each general description is followed bytwo sections; ‘do’s’ and ‘don’ts’. Both of thesesections are very concise and specific, all generalsubjects are completely deferred to the introduc-tion. The mentioned issues are frequently illus-trated, using domain relevant examples, to furtherclarify the given advice.

5.1.3. Interface elementsThe rules for design of interface elements (IE),

together with guidelines for application design us-ing these components, form the domain specificstyle guide. It’s important to gather and store thisinformation in a way that makes it easily availa-ble. The basic interface elements are thereforesupplied in the toolbox accompanying the user in-terface management system. In this way we cancreate an interactive domain specific style guide.

5.2. A task oriented solution

Lack of domain knowledge can effect cognitiveprocesses in a negative way. The domain knowl-edge acquired from research and field studies

within the medical sector has been incorporatinto the medical style guide developed within thHelios project.

The patient record is a central concept in tmedical domain and its structure is often commamong many hospitals. Medical records contademographic information regarding the patienmedical history, lab reports, sometimes x-ray images, letters, drugs and so on. The interface coponents used in the design process mucorrespond to the concepts used when performthe work task in the target domain, in order to easily associated with the natural concepts famiar to the user. The design must be made in sucway that the components can be identified aused with a minimum of cognitive load.

The following pages will give you a generaidea of how the contents of the Helios medicstyle guide try to cope with these demands on terface design.

6. Design guidelines

6.1. Windows

6.1.1. GeneralIn most graphical systems of today a new wi

dow is used whenever a new action is performeWindow repositioning is a general example

an action that burden our cognitive capacity. If wdesign the interface in a way that leaves the findesign to the user, for instance an interface whconnected information can be found in differeoverlapping windows, the user constantly hasinterrupt the train of thoughts to manage the inteface. With domain knowledge we can in facavoid such situations, and design interfaces inway that supports advanced problem solving adecision making, by keeping needed informatiotogether and avoiding unnecessary interruptions

In the Helios environment we should be aiminat avoiding the drawbacks of common usagewindows. The user should be able to performcomplete task without switching between windows. From now on the base “window” adaptedaccomplish a whole task will be called a Helioform.


li-

inor

otebyotw

itlent

heat

The available screen space will always be lessthan wanted. Therefore it has to be organised in astructured way (figure 3). While working with adocument we often need other documents, imagesor figures as a basis. The user writes for instance amessage, a letter, an admission note or issue adocument. The area where the contents of a docu-ment is manipulated will be called the work-space. The area where other documents etc. aresimultaneously viewed, will be called the infor-mation area.

Upon working with a given task the user oftenneeds to know e.g., what other documents or pro-grams are available. To support the user’s need it’sappropriate to reserve a specific area where theuser can be sure to find this information, an iconarea. A fixed area reserved for these icons serves

as a powerful information carrier when the appcation is familiar to the user.

In many cases a menu is needed for certamain functions. We call the reserved position fthe menu area.

A Helios form typically has a starting positionin the upper left corner of the screen. It is nlocked to it’s initial position unless it covers thwhole screen. The user may drag the window the title bar to a new position. The form does nhave any unnecessary decorations or windomenus as the size is fixed. The name of the tbar is given from the name of the used IE, the foand colour are locked.

6.1.2. DesktopMore than one Helios form can be active at t

same time, but there is only one current form th

Fig. 3. Form layout. The disposition of a form should be carefully worked out. To the left two disorganised forms are shown. To the right two forms with the same amount of information are displayed. In the organised forms all of the information is

visible at the same time. Here the area at the bottom of the screen is reserved for icons.


eis

ehts,r-

cehe

esed

has input focus at a time. A Helios form is man-aged from the FormBar. The default backgroundof the form is white. The colour and heading ofthe title bar of a form shows it’s present condition.The Helios Formbar or Desktop is a specialized IEthat is intended to be used as the end-user’s Form-bar. The Formbar is positioned in the upper rightcorner of the screen. The Formbar has a fixed po-sition, and is consequently impossible to move orresize.

The form icons in the Helios Formbar havethree states: available; active; unavailable (figure4). The icons have a pixmap (available/active/un-available) and a label. Helios forms are invokedby clicking at the corresponding icon. An anima-tion shows how the form is expanded. The formsactive state is reflected by the icon image which isgreyed, the Label becomes a sensitive Labelbut-ton. When an active form has become hidden byother active forms, the user may click on the La-belbutton and the corresponding form will “pop

up” on the top. A form is closed by clicking on thicon outside the Labelbutton. When a form closed it will “return” to it’s initial position andstate in the Formbar.

Each Helios form that is invoked from thFormbar is a child form of the Formbar. Eacform has a fixed size depending on it’s contenand is initially positioned in the upper left corneof the desktop to avoid overlapping of the Formbar. Any Helios form has a specific appearanwith a titlebar and a predefined background. Tuser may freely move a form around.

If more than one form is invoked the activform will most certainly overlap any previouform. The user may move or close an activatform but not change the size of the form.

6.1.3. Recommendations• The foundation for judgement and decision

should be kept together on the same level. Theuser needs the visual reference to remember

Fig. 4. A typical Helios form. This form should contain all interface elements needed to complete a task. This fictitious form contains a patient and a medical record, including images and lab reports.


ori-

ree e

tate

ee

iseor

-c-ntserse-at oflly

or-ofris-

srect

s aeyseri-

details. Visible objects remain in the mentalscheme if only visible ever so little. The rela-tionship between detail and survey can bereinforced by using geometry and movementsin the graphical design.

• If error messages are displayed in pop-upwindows make sure that the message doesn’thide the related information that caused theappearance of the message.

6.1.4. Avoid• Don’t use to many window levels, in most

cases one level is enough! The user will soonbe overwhelmed with micro tasks such asopening, closing and moving overlappingwindows around. The user’s error frequencyis significantly increased with the number ofwindow levels.

• Be cautious with overlapping windows thathide basic information needed to perform atask. The user’s effort to decrease the size ofthe overlapping window or move it mightdestroy the intended gestalt of the interface.

6.2. Icons

6.2.1. GeneralIcons can be used in many different ways and

for many reasons. An icon may show that an ap-plication or a function is available, that documentsof a given type exists or that a certain document isregistered. It must be clearly specified what cer-tain icons mean and they should be used consist-ently. Icons should be created in association withwork related tasks and used to be a reflection ofand illuminate the working conditions in question.

Icons help us survey the screen and keep our entation.

When performing a task and working with foinstance a document, it’s often necessary to sthe other available documents. It’s impossible to

display all these documents in full size at thsame time. Therefore we need more than one swhen we want to display an interface element.

Interface elements can emerge in one of thrconditions: fully sized, stamp-size or micro size.An interface element in it’s natural active statefully sized and shown in full detail. In this statonly, the user may actually read, write, query adjust the element.

An icon should be a reduction of the corresponding interface element. It should be proessed so that the fully sized elements curregraphical characteristics are preserved. The ushould recognize rather than recall the icon. Uthe form and layout of the icon to supply information about the contents of the element (3D). Thenables the user to distinguish one instantiationan element from another. The user may optionachose to add a title to the icon.

The appearance of the icon can mediate infmation of the status of a specific instantiation an element. Age and priority are some charactetics that might be visualized through an icon.

The icon should clearly stand out from it’background. Colours and shape decide the corfigure - background relations.

Micro icons mostly act as place holders and avisual reference. No details are visible and thcan hardly be separated from each other. The uidentifies micro icons by their position. The postion may be connected to a value or an event.

Fig. 5. Icons in micro and stamp-size. To the left the icons show a survey of a sequence of screen sheets. A stack of screen sheets can be displayed as an icon with a shadowed edge that reflects the amount of information available. The icon mirrors

the type of screen sheets included in the stack.


s”

to

e n eet.

Hemineurin

Ringeracetat

Hemineurin

Hemineurin

Hemineurin

Hemineurin

Hemineurin

Ringeracetat

RingeracetatRehydrex

Rehydrex

265

300

500

500

500500

500

500300

500

180

275

1000

300

360 Albumin

Plasma

PlasmaPlasma

Plasma

275

mlmlFluid Medicine

Eraldine 20 mg/d

Evap 360 ml/h

RingeracetatHemineurin

HemineurinRingeracetat 265

300500300

275

1000

Plasma

Plasma

B)A)

Mer 19/6 02:11

Mer 19/6 12:56

Mer 19/6 14:31

Mer 19/6 20:51

Mer 19/6 10:15

Mer 19/6 10:45

Mer 19/6 10:45

Sam 20/6 10:45

Sam 20/6 14:11

Sam 20/6 20:51

Sam 20/6 11:42

Sam 20/6 17:24

Sam 20/6 10:45

Sam 20/6 10:45

Culot globulaire

Albumin

Kroatinin

Urea

Kalium

APT

Glucose

Culot globulaire

Albumin

Kroatinin

Urea

Kalium

APT

Glucose

Date Produits Sanguine Qty Agg. Irr.

8

2

1

1

2

1

1

8

2

1

1

2

1

1

+

+

+

+

Chemical laboratoryHuddinge Hospitaltel 08 - 7845 9339 33

Micro icons can be grouped to create additionalpatterns. Now the micro icon becomes a memberof a family. The pattern in itself carries informa-tion, supports the ability of pattern recognitionand simplifies the orientation. An overview of thedistribution of booked patients for the next threemonths is an example where micro icons might beused to symbolize each patient, the reason for theexamination, consultation room, responsible phy-sician etc.

The way of changing an interface element fromthe passive state (icon) to the active state and theopposite must be consequent. The same thing maybe said of the state selected - unselected (e.g. touse thick highlighted borders to visualize selec-tion).

Animation can be used as reinforcement to clar-ify where the contents of a magnified icon comesfrom and where diminished documents are placed.

6.2.2. Recommendations• Test icons to be sure that the “obviou

meaning of the icon really is evident.• Icons in combination with a title text are most

effective.• Visualize thickness of interface elements to

indicate contents.• Icons should in general be locked to a given

position and a fixed size to simplify the proc-ess of pattern recognition.

6.2.3. Avoid• Do not use icons that doesn’t add anything

the interface.• The user should not be able to customize an

icon.

6.3. Screen Sheet Features

In health care there are often a collection of pa-per documents that are used every day. Both struc-ture and contents of this frequently used material

Fig. 6. Events coordinated in time, here in the form of a lab report. In plate A a conventional scrolled list is used which means that the order in time is impossible to follow without reading and interpreting the information. In plate B the events are

displayed in the order they occur day by day. The pattern thus created reveals in this case something about the condition of the patient.

Fig. 7. White space as information. The empty space can serve as an immediate information carrier. It’s important to

display all information, missing as well as available information, in a structured way. Then a nurse can observthat a value is missing, indicating e.g. that a test has bee

forgotten or not reported, by a quick glance at a screen sh


d

mat, a-

htur

itysk ase.ld in

y

outn-

lyazen-

nted

xxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxx

xxxx

xxx

xxxx

x

xx

xxxx

xxx

xxxx

x

xx

xxxxxxxxxx

xxxxxxxxxx xxxxxxxxxx

xxxxxxxxxx


xxxxxxxxxx

xxxxxxxxxx

xxxxxxx

xxx

xxx

xxx

xxxxxx

xxx

xxxxxxxxxx


xxxxxxxxxx


xxxxxxxxxx


xxxxxxxxxx

xxxxxxxxxx

xxxxxxx

xxx

xxx

xxx

xxxxxx

xxx

xxxxxxxxxx


xxx

xxx

xxx

xxx

xxx

xxxx

xxx

xxxx

x

xx

will be well known. The appearance of a paperdocument automatically tells the user a lot ofthings such as approximate amount of pages(thickness) and spatial relations between docu-ments. The appearance tells the user what kind ofdocument he or she is looking at and the kind ofinformation that can be expected to be foundthere. From the appearance the user can also iden-tify different parts such as borders, headings, text,graphics, images, fields to fill in, and the patternmade of values filled in against a background ofunfilled space. In this way a user easily recognisesa page that has been read before..

When displaying information, scrolling of textis often used because it’s already implemented indevelopment tools. To organise information page-wise is often a better, more direct way to deal witha large amount of information.To turn pages in astack of papers often seems more natural and effi-cient. A dynamic computerized document can bepresented on the screen as a stack of sheets,equipped with a number of similar properties. Itmight be event driven, possible to activate, etc.

From here on we will discuss the computerizedocument as the screen sheet.

Each screen sheet has properties such as forbackground, position of fields, the connection ofcertain field to the corresponding item in the information system etc. A frame, for instance, migadopt a certain line type, line thickness and coloto express the membership of a category.

The layout of a screen sheet support the abilto interpret the state of affairs and use it in the taat hand. The amount of information entered insheet immediately show the status of the caEmpty space where missing information shoube filled in serves as guidance as well as a helpfinding errors. Existing information or an emptfield reveals if an event has occurred or not.

The appearance of a sheet should stand enough to directly give the user an idea of the cotents of this document. This goes for the fulsized sheet as well as the sheet icon. A quick gshould give the viewer a direct idea of the cotents of a specific sheet. The original gestalt,shape and graphic view of a paper documeshould as far as possible be preserved (provid

Fig. 8. Uniform screen sheets. A screen sheet should have a layout distinct enough to make it easy to distinguish from other screen sheets.

Fig. 9. Input fields. In the form to the left the user can immediately see the magnitude of the measures that are to be filled in. The text style is not proportional which makes it easy to read the measures. In the form to the right, which is made for reading,

the grey background indicating input mode is removed.


ntbemeo-ur-

nth.e asures-

. if

Else Nygren 531025 - 7828

Repslagaregatan 21 A753 33 Uppsala

018 - 20 08 46 home018 - 18 28 48 work

22 518 UU - CMD - S

50 %

from 86-09-01

A

Temp

Removed

that the document is well-functioning!), this willfacilitate the users possibility to recognise the cor-responding sheet on the screen.

A sheet can have different modes such as read,write, change or add information. It may as wellhave references (links) to other sheets. All thesefeatures must be possible to change for the userwith the correct authorities.

6.4. Visual encoding

6.4.1. GeneralHumans constantly perceive physical events

from our surrounding world. Impressions fromcolours, sounds and actions are inevitable, we canhardly switch them off. They are often interpreted,swift as a lightning, with the help of previousknowledge and experiences.

Visual encoding is used to graphically displaythe condition of information units as texts, labelsand variables. All the information a user needs toaccomplish a task should as far as possible becoded in a way that reduce the cognitive effort re-quired. There are several ways to code informa-tion to mediate a message. Colour, shape, frames,

t’sut-beed

Pressure 100.....80 36.9 ° Rh+

font, style, position, symbols and function keyscan all be given a significant meaning. Informa-tion can be given several redundant attributes tofacilitate the identification and make the interpre-tation easy and obvious.

Coding might be divided in general and appli-cation specific coding. General codes comprisefrequent operations like selection/deselection, in-dication of selectiveness, active/inactive, current/out of date, default value, recent selection etc.Some of these codes are complementary andshould be coded with corresponding visual codes.

It’s important that the encoding is consistethrough applications. The user should always confident that a certain code has exactly the sameaning in any situation. A code can’t be autmated unless it always means the same thing ding t ime and in d i f fe rent sect ions o f aapplication. We must be especially careful wicodes for chosen item, default values and so on

Visual encoding might be used to display thmeasure of a blood pressure in black basic stylelong as the measure is normal. When the measdeviates from normal the figures might be diplayed in red.

Other properties that might be coded are e.gthe measure is taken manually or automatic, if ichecked, estimated, calculated, predicted or oof-date. An estimated measure might e.g. coded in italic while a checked measure is codwith a straight font.

Fig. 10. An employees registration card. Unnecessary headings are removed since this card is designed for reading. Primary information such as name, the employees type of contract and temporary changes are clearly indicated with a

bold style to attract attention.

Fig. 11. Headers/labels. Measurement units and the value characteristics used as guidance for the user.


hectente

ar-

ssentnnys

The code concepts used must be consistent withthe information that we want to intermediate.Temperature is generally displayed as a verticalscale while for instance time is expressed with ahorizontal scale. We have trouble to identify a col-our with a scale, for instance to decide that “red”is larger than “blue”. Colours are to us most logi-cally connected to different classes. Scale relatedinformation, in a small number of steps, may bevisualized by a colour shade or a gray scale.

In a given work situation it is often important tobe able to associate events with a certain point oftime. It might be a question of when a certainvalue was measured or in what order or in whichinterval something happened. If the user is forcedto actually read and think to coordinate suchevents in time, the interruption will bring aboutloss of time and unnecessary cognitive load (fig-ure 6).

Interface elements should be connected to theconcepts used when performing actions in theuser’s task domain. Case book, case sheet, medi-cal record, patient and X-ray picture are all exam-ples of elements that should be used in health careapplications.

An interface element can be in an active or pas-sive state. In the active state the element has it’sposition in the workspace, it can be studied in de-tail and altered. In the passive state the elementcan be shown as an icon in the overview area, it

can be manipulated, but not studied in detail. Tgestalt of an interface element must be distinenough to enable the user to recognize the elemfrom distance, in diminished form and when thobject is only partly visible.

6.4.2. Recommendations• Use visual encoding to make things easier for

the user. The user should not have to specifi-cally read and interpret values when it is pos-sible to create a graphic vision that mediatesthe information.

• Code the exceptions rather than giving anycondition a code (figure 12). The normal con-dition is always less important and should notattract attention or cause alarm.

• When a value in itself represents both thelabel and the contents it is most important thatit’s always displayed in the same way and infix position. The user should always be cetain of the meaning.

6.4.3. Avoid• Don’t waste space on headers/labels unle

they are absolutely necessary. For the frequuser, a value itself and its position is ofteenough to re-cognise the kind of informatiodisplayed on the screen e g, a zip code alwalooks the same (figure 10).

B)A)

CTCRMRICRCTUSCR

23/10/8823/10/8824/10/8812/06/9012/06/9013/06/9014/06/90

NeuroChestNeuroChestAbdomenAbdomenAbdomen

32224116202

◆❁❁❁◆❁❁

❁ ◆Available Import pending

Modality Date ImagesAnatomy

Fig. 12. Exceptions should be coded rather than the majority. In plate A all images are given a code. In plate B the entries that are pending are indicated by an italic style.


e

e-

r-e

tga-t.e-l-

t-

o

artur toia-tic,ferv-s

d

• Measurement units are excellent labels, e.g.13 dr, 1.2 s or 10 ml/h in a certain contextdoes not need any further explanation. Themeasurement unit in itself might representfurther information such as speed of drops,presented as dr tells us that a drop-counter isused, while ml/h adds that an infusion pumpis used (figure 11).

7. Developing user interfaces in Helios

The Helios SEE is built on a client/server archi-tecture with service components communicatingover a software bus. This software bus containsservices for connection, routing and communica-tion. One of the components on the software busis the User Interface Services. There are basicallyfour areas that we have taken into considerationwhen designing the UIS within the Helios project:• The domain specific style guide.• The design and specification of the domain

specific user interface components.• The tools for implementing the user interface

and the control.• The connection to objects in other services in

the Helios SEE, e.g. image related services ordecision support functions, and their represen-tation in the user interface.

Further, we specified the last three items:• A way to build graphical user interfaces

(GUI) in a WYSIWYG-style.• A way to handle the user interaction.• A way to access and present the objects in the

Helios SEE.Our solution to the problem regarding building

the GUI and define the dialogue management andcontrol, is to use a commercial product. The deci-sion is based on the experience that the develop-ment of such a powerful set of tools is verydemanding and falls outside the scope of our partof the project. We have chosen to use TeleUSE1.We have also decided to concentrate our work onthe design and development of domain specific in-

terface components and their connection to theobjects in the Helios SEE.

7.1. Primitives, Interface Elements and Forms

The visual objects, i.e. the interface compo-nents, in a Helios GUI can be divided into threecategories: Primitives, Interface Elements (IEs)and Forms. The main difference between the threetypes is the functionality:

Primitives: In the Helios context, primitives aree.g. widgets or other ‘native’ objectssuch as lines and rectangles. In thHelios SEE the OSF/Motif widgettoolkit and customized widgets aravailable. Primitives are used for layout handling and formatting of theuser interface.

IEs: An IE is dedicated to represent a cetain object class. An IE has a visiblpresentat ion par t , a t empla te ,designed in the interactive layoueditor and a second part describinthe connection to objects and opertions in the Helios SEE environmenObjects and operat ions can breached through the dialogue language via added external functionaity.

Forms: A form is an interface componencorresponding to a complete application. It is therefore desirable todesign the forms to fulfil all theinteraction requirements needed tperform a complete work task.

It is almost pointless to have a presentation pof an IE without any connection to objects, in ocase medical objects. The IE will have accessobjects in the Helios environment through the dlogue language. An IE is composed of a semana syntactic and a presentation part. The IEs diffrom the primitives in semantics and syntax, giing the IEs domain specific behaviour. The HelioIEs consist of primitives but functionality is addeto make them IEs.

1. TeleUSE User Interface Management System is designed according to the well known Seeheim model [18]. The main scope of TeleUSE is the layout editor and the dialogue lan-guage (D language). TeleUSE is a registered trademark of Telesoft Inc.


Presenter_ANSWER does

Presenter_ANSWER.source_

widget.value:=

Presenter_ANSWER.values[1];

Semantic

Primitives

Objects & operations

Dialogue

Network

Presentation

Syntactic

Kalle Karlfeldt

Semantic: Functionality; objects and opera-tions, e.g. other services in theHelios-SEE.

Syntactic: Dialogue level, the TeleUSE D lan-guage with added external function-ality.

Presentation:Output and input representation,primitives such as OSF/Motif toolkitand other customized widgets.

In (figure 13) above, the IE has a presentationpart that is a Text widget, a syntactic part writtenin the dialogue language and a connection to a se-mantic part through an operation somewhere inthe Helios SEE. The shadowed box indicates thenetwork and the fact that the object can be locatedanywhere on the network. The IE in this exampleis generic and has been designed to display thename of a patient, through an operation in the par-ent object.

In (figure 14) below, the form is designed withIEs showing information about a person.

Most of the operations to manipulate data areused by all applications accessing the domain spe-cific objects. The operations are e.g. to get ob-jects, update objects etc. Some of the operationsare more specialized containing knowledge oftheir environment and domain. Let us take an ex-

Fig. 14. IEs designed into a form.

ample from a user interface designers point ofview; the interpretation of a blood pressure andthe decision if it is normal, high or low. This isnothing that can be decided during the design ofthe user interface. That kind of knowledge mustbe implemented as a general operation for thatclass and coded according to medical expertise.What must be done during the interface design isto decide how the different values i.e. normal,high and low will be presented, e.g. using colourcoding. The proper way to implement this is to de-fine a method that accesses the blood pressure at-tribute and returns a symbolic value. Then thecode associated with an IE can interpret this valueand set the colour attributes according to it. Thiscan be implemented as an IE with the three partsdescribed above.

We can separate the user interface presentationof a value from the actual implementation of it byincluding the domain knowledge into the opera-tions for corresponding domain objects. This willfacilitate the design of the interface and the possi-bility to create alternative designs without havingto write a whole new application. This is also im-portant in order to maintain a consistent database.Our approach is to position as much of the logicneeded for the different IEs or forms into the ob-jects and operations in the different services ofHelios SEE and leave the user interface building,including the dialogue parts, to user interface de-signers.

7.2. New primitives

One result from the work on the Medical styleguide is the need for new primitives as well as forthe domain specific IEs. The demand for theseprimitives is not obvious until one tries to actuallyspecify how the end users perform their tasks andwhat kind of support they need. We have sug-gested a couple of new primitives that we need,most of them related to the fact that humans han-dles pages and documents very efficiently. It isnatural for skilled professionals in a none-compu-terized situation, for example in a medical ward,to handle documents organized into bundles andfiles. Our work on interface primitives is concen-trated on supporting this efficient way of provid-

Fig. 13. The parts of an IE.


ing data even in a computerized environment. Oneexample, in terms of widgets, is the managerwidget Page. The purpose of this widget is to ani-mate the look and behaviour of static ‘paper-bound’ information. There are methods for simu-lating the ‘turning of pages’ etc.

8. The user interface services in Helios SEE

As said earlier the Helios project has decided touse the commercial UIMS TeleUSE. This is a tooldesigned to manage the GUI in an efficient wayduring the life cycle of an application. The mainscope of TeleUSE is the layout editor and the dia-logue language:• The Visual Interaction Programming tool -

VIP is a “WYSIWYG” layout editor fordeveloping GUIs. Including some additionaltools for handling colours, fonts, pixmaps etc.

• The D language is an event driven scriptinglanguage designed to support the dialoguemanagement and control.

One key feature in the TeleUSE system is theability to create templates. These are parts of aninterface that can be saved and re-used. The be-haviour of a template can be described in the dia-logue language.

The TeleUSE environment supplies us with agood basic environment to work in, but we havehad to add functionality to make it fulfil our exactneeds.

The Medical Information Presentation Service- MIPS is an executable that takes a description ofthe user interface and connects it to other servicesin the Helios SEE through the dialogue or controlparts. The user interface is designed using the VIPlayout editor. The editor environment has beencustomized to support the Medical Style Guide.Colours, font lists and other values has been de-fined and are available as symbols in the VIP.Templates of pre-defined user interface parts areavailable as well. There is also support for a datapresentation model that enhance the developmentof forms with regards to an object oriented envi-ronment.

The integration of the external editors, used forconstruction of the forms, is done in a twofoldway; (i) the Visual Interaction Programming Serv-

ice - VIPS and the Interface Manager used for de-velopment time, and (ii) the runtime environmentintegration of a form supported through the dia-logue language. Support for the object orientedmechanism of the Helios SEE has been built in.

9. Discussion

The importance of designing end-user inter-faces in health care that reduce cognitive work-load can not be overestimated. Failure to accom-plish this will result in low efficiency, stress andbad acceptance.

During the Helios project a lot of effort havebeen devoted to identifying such ward specific el-ements that can be of use in future application de-velopment. However, it is not the objective ofHelios to develop a large number of ward applica-tion systems, but to develop the system engineer-ing platform for this. It is therefore the duty offuture developers to extend the domain specificstyle guide with new interface elements on differ-ent levels. Especially modifications due to localand national differences must be continuously up-dated.

Equally important is to base interface construc-tion on a development tool that can incorporatenew domain specific interface elements. The solu-tion we have used in the Helios project can beseen as a compromise. The selection of TeleUSEas a base for the interface part of the SEE wasmade after an evaluation of existing softwareproducts. The work needed for design and con-struction of a new tool could not be made withinthe project. In the future there will be a need to re-evaluate this decision, and to develop tools thatare more directly corresponding to the Helios ob-jectives.

10. Acknowledgements

Helios (AIM 2015) is a project within the AIMprogramme of the Commission of the EuropeanCommunities. The financial support for the workdescribed in this paper has been obtained fromNUTEK, the Swedish Board for Technical Devel-opment.


r.

ic-

s:n:

11. References

[1] B. Sandblad, M. Lind and Werner Schneider: Require-ments for human computer interfaces in medi-cine.Communications in Health Care, North HollandPubl. Co. 1985.

[2] E. Nygren, M. Lind, M. Johnson and B. Sandblad. Theart of the obvious. Proceedings of CHI’92, Monterey,California, May 1992

[3] Olsson E, Göransson B, Borälv E, Sandblad B.Domain Specific Style Guides - Design and Imple-mentation, Proc of the Motif & COSE InternationalUser Conference, Washington D.C. 1994.

[4] W. Schneider and R.M. Schiffrin.: Controlled andAutomatic Human Information Processing: I. Detec-tion, Search and Attention. Psychological Review84:1-66, 1977.

[5] R.M. Schiffrin and S.T. Dumais: The Development ofAutomatism. Cognitive Skills and Their Acquisition:111-140, 1981.

[6] J. Rasmussen. Skills, Rules, Knowledge, Signals,Signs and Symbols and other Distinctions in HumanPerformance Models. IEEE Transaction on Man, Sys-tems and Cybernetics, SMC-13, No3, 1983.

[7] E. Pettersson: Automatic Information Processing inDocument Reading. A Study of Information Handlingin Two Intensive Care Units. Proceedings of the FirstEuropean Conference on Computer Supported Coop-erative Work, London 13-15 Sept. 1989.

[8] J.T. Reason. Generic Error-Modelling System(GEMS). A cognitive framework for locating commonhuman error forms. In: J. Rasmussen, K. Duncan & J.Leplat eds. New Technology and Human Error. Chich-ester & Wiley, 1987.

[9] Nygren, E., and Henriksson, P. Reading the medicalrecord I. Analysis of physicians ways of reading themedical record. Computer Methods and Programs inBiomedicine, 39(1992)1-12.

[10] Gulliksen J., Johnson M., Lind M., Nygren E., Sand-blad B. The need for new application specific interfaceelements. In G. Salvendy and M.J. Smith eds. Pro-ceedings of HCI International’93, pp. 15 - 20, Elsevier1993.

[11] Card S.K., Moran T.P., Newell A., The Psychology ofHuman-Computer Interaction, 1983, Lawrence Erl-baum Associates Ltd., Publishers, U.K.

[12] Foley JD., Van Dam A., Feiner S., Hughes J., Funda-mentals of Interactive Computer Graphics, Chapter 9:Dialogue Design, 1990, Addison-Wesley, ReadingMA.

[13] Helander M., Handbook of Human Computer Interac-tion, 1988, North Holland, Amsterdam.

[14] Open Software Foundation, OSF/Motif Style Guide,Revision 1.1 and draft Revision 2.0.

[15] Shneiderman B., Designing the User Interface, 1987,2nd ed. 1992, Addison-Wesley, Reading MA.

[16] Smith Sidney L., Mosier Jane N., Guidelines foDesigning User Interface Software, 1986, U.SDEPARTMENT OF COMMERCE NTIS, Springfield.

[17] Draft International Standard, ISO 9241, Ergonomrequirements for office work with visual display terminals.

[18] G. E. Pfaff, ed., User Interface Management SystemProceedings of the Seeheim Workshop. BerliSpringer Verlag, 1985.

Documents

Usability and efficiency. The Helios approach to development of