Domain Specific Style Guides Design and Implementation Eva Olsson, Bengt Göransson, Erik Borälv, Bengt Sandblad Center for Human-Computer Studies, Uppsala University, Uppsala, Sweden Phone: int + 46 18 18 33 21 Fax: int + 46 18 18 78 67 Email:
[email protected]
Abstract
Keywords
The introduction of graphical user interfaces in a computerized work environment is often considered to substantially improve the work situation. The outcome is, however, very often the opposite. The possibilities for bad design and inefficient user interfaces is multiplied with the help of windowing techniques, scrolling and colours. However, the now established de facto standards and complementary style guides have meant a step forward towards improved quality of user interfaces. They are helpful for basic design but prove to be insufficient for design decisions concerning higher abstraction layers. Here detailed domain knowledge is absolutely essential for the design of efficient user interfaces. It is almost impossible for a designer to be an expert in even one single domain. Therefore domain knowledge must be obtained from the real domain experts, i.e. from the professionals performing the work. To accomplish this we have used methods based on detailed analysis of work activities, analysis of information utilization and user expectations. The design of a user interface must always be based on an analysis of both the work situation as such and of the users working there, mainly focused on the involved cognitive processes. Our work is concentrated on the design of the interface and the resulting requirements on style guides and user interface components.
User interface design, style guide, domain specific, work task, interface elements
Introduction In this paper we discuss user interface design issues and requirements on methods and tools. The concept of domain specific style guides and interface components proposed here is the outcome of earlier research [1] and the current project Helios-2 within the AIM (Advanced Informatics in Medicine) program of the CEC. The main motivation behind the Helios-2 project is to: Support the development of medical application software, by developing a pre-industrial SEE (Software Engineering Environment) dedicated to the medical world. To reach this goal the project must develop an open and modular SEE allowing the implementation and execution of medical applications. The group at the Center for Human Computer Studies, Uppsala University, is responsible for the development of methods and tools for design and construction of human computer interfaces as a part of the UIMS (User Interface Management System) of Helios-2.
Domain Specific Style Guides -Design and Implementation
Efficient interfaces Computer systems of today often cause an increased cognitive load on the user and reduce the amount of capacity available for the main task [2]. We have seen examples of computer systems where up to 80% of the working time is spend managing the interface. The problem solving process is constantly interrupted by the need for “re-designing” the interface, that is opening/shrinking/moving windows around, starting different applications to find data needed etc. This, of course, results in a low efficiency and a high level of anxiety and stress, bad acceptance and even health problems. Studies of different types of work situations show that properties of the work environment can hinder the persons performing the tasks to efficiently use their skills. We call these hindrances 'cognitive work environment problems' and they are often associated with the human-computer interface.To minimize the cognitive load caused by the interface, the design of the interface must be based on an analysis of the cognitive load on the user. In a work situation, where computerized information systems are used, e.g. health care, the purpose of the work performed by the professionals is never to operate the computer. The computer is only a tool that will be used and appreciated as long as it efficiently supports the purpose of the work, e.g. to provide good health care for a patient. This means that the interface must be designed on the basis of optimization of the work activities as such instead of just optimizing the use of the computer. The practical consequences of this is that the design must be based on an analysis of how information is being used in the actual work context for which the application (or artifact) is intended. The design must be made so that the management of the interface can be as automated as possible - then the user can make optimal use of his or her creative and problem solving abilities to perform the essence of the work. In this way the computer system will be ‘transparent’ and the user can concentrate on the work activities. We say that the interface must be obvious to the user [3]. Style guides have served as a complementing tool to accomplish a uniform, well-functioning design. Until today style guides have seldom mentioned anything about design outgoing from a user centered perspective or a task orientated approach. They rarely contain practical advice concerning cognitive design aspects and requirements of a specific task. Instead they concentrate on general design
aspects. Existing standards for interface design should be used as a basis for any design, and in those areas where they prove to be insufficient other specifications have to be added [1]. The realization of interface design using domain specific considerations requires a high correspondence between design concepts and interface components to enable an efficient implementation. Unfortunately, there is today not a sufficiently diverse set of interface components available to fulfil the variety of user interface requirements. We will also discuss the necessity of style guides, extended with domain knowledge, and the resulting demands on interface components and the SEE.
Domain Specific Style Guides Why domain knowledge A prerequisite for successful interface design is the understanding of the tasks the users need to perform. Interface components must correspond to the concepts used when performing actions in the user’s task domain and they must have a natural association with the familiar concepts. In the health care domain for example, lab. requests and reports, medical records, X-ray images etc. are all established concepts that must be reflected in a design. To manage this, the designer has to be well acquainted with the target domain. That includes to have a deep knowledge of the task to be performed and familiarity with the user’s work situation. The designer has to identify the most frequent tasks in order to organize interface components according to relative frequency and importance. The domain information that the designer is missing, maybe even without his own knowledge, can be crucial for the efficiency of the interface. To accomplish an efficient interface, time and effort must be spent on an analysis of the task, the work contents and of the utilization of information. For practical reasons, as well as economical, such a detailed analysis cannot be performed in every new project. Therefore domain knowledge must be assembled, continuously supplemented, revised and included in a domain specific style guide. How to create a domain specific style guide A domain specific style guide is a document that for a defined work domain specifies a class of interface components together with guidelines for development of user
Domain Specific Style Guides -Design and Implementation
interfaces with these interface components. The purpose of defining domain specific style guides is twofold. First to enable development of efficient user interfaces that minimize cognitive work-load and, secondly, to significantly reduce development efforts and costs. A domain can be broad or narrow. If the domain is defined too narrow its area of application will be very limited. If it is too broad the advantage of this methodology will be reduced. The process to develop a domain specific style guide can be described as follows:
• In the first step a detailed analysis of information utilization of work activities in the defined domain is performed. There are a number of problems involved in analyzing how professionals utilize information while performing job-related tasks. Since the reasons for performing such an analysis is to reduce cognitive workload, the tasks must be defined in relation to individuals and their behaviour. The tasks, or rather the subtasks, the users perform while working must be specified. What we want to establish is the decision making processes performed by users in relation to the task proper.
• Based on the analysis a set of interface components, covering the application areas selected, is defined and designed.The design is made so that the components can be identified and used with a minimum of cognitive load.
• The specification of basic and more complex interface components is a step by step procedure. This subject will be further discussed below.
• The rules for design of interface components, together with guidelines for application design using these components, now form the domain specific style guide. The process of developing a domain specific style guide is laborious but is normally only performed once per domain. An additional application specific analysis has to be done before the end-user application is developed. This will, however, be a fairly simple matter compared to what is needed when the design is based on a general style guide, such as e.g. Motif. Here we see the need for three different kinds of roles, or competence levels, in the development process: (i) the development of the domain specific style guide, (ii)the development of new interface components whenever the style guide must be updated (which will require advanced programming skills) and finally (iii) the development of the end user applications.
If efficient tools are being used, this can now be a comparatively simple process. A task oriented solution The domain knowledge acquired from research and field studies within the medical sector has been incorporated into the Medical Style Guide developed within the Helios project. This style guide acts as an extension to the OSF/ Motif Style Guide [4]. In some aspects it may contain restrictions on OSF/Motif Style Guide, but mostly it contains supplementary high level information, i.e. domain specific knowledge.The Medical Style Guide is a dynamic and continuously updated document. The Medical Style Guide is divided into five major parts; basic considerations, design methods, design guidelines, interface components and health care applications. The first part contains a general discussion concerning different user profiles, aspects and considerations. It describes the basic theories of human information processing, like cognitive levels, and how these influence our physical abilities of communicating with the environment. Information contents and appearance can be captured on different abstraction levels and the consequences are reviewed here.The importance of screen disposition and fixed design in order to facilitate pattern recognition and related processes is treated as well. A number of applicable design methods are briefly discussed. A method for modelling cognitive aspects of how information is used is a topic of high importance. Within the Helios project we have decided on an object oriented approach and a common platform including design and development tools. We also recommend an experimental design method that involves the presumptive users in the development procedure to assure an efficient design. A more comprehensive part is the design guidelines. Here each important area is described in a general part, for instance general aspects of “visual encoding”, to create a common reference for understanding subsequent advice. Each general description is followed by two sections; ‘recommendations’ and ‘avoids’. Both of these sections are very concise and specific, general discussions are completely deferred to the general introduction. These issues are frequently illustrated, using domain relevant examples, to further explain the given advice.
Domain Specific Style Guides -Design and Implementation
Interface components, i.e. specific components needed in the design of user interfaces in the medical domain, are described. Examples are components such as name field, patient card, prescription and X-ray image browser. Here an elaborate description of each component is provided, concerning specific subjects such as colours, character formats, size location and so on. The fifth part of the Medical Style Guide will contain design guidelines for more complete medical ward applications.
From the domain specific style guide towards an implementation The process of including more and more domain knowledge into the interface design requires components of different levels - with regard to semantics and graphical capabilities. The purpose of the different levels is to reach abstractions high enough to be able to talk about the interface components at the same conceptual level as in the domain specific style guide. When do we reach domain specific implementation?
A widget can never be domain specific in itself. Not until we have added semantics in the form of domain knowledge to a widget can we call it domain specific. A label with a red colour may in certain contexts denote some kind of warning or attention, but has no real semantics in OSF/Motif terms. It is first when you give that label and colour a meaning within a context that it becomes relevant to talk about its semantics, or its domain specific behaviour. What makes an implementation domain specific?
The connection between the target domain and the interface component determines whether the component is domain specific or not. If the semantic part (Fig. 1) relates to the same things or concepts as the domain specific style guide, it is relevant to talk about a domain specific component. Component levels - abstractions When designing interface components one must define different levels, or abstractions, for the components in question. The abstractions span from the basal X primitives, such as lines, dots or widgets, to the most advanced ones - the final applications.
We would first like to discuss the abstractions on an abstract level. The abstractions should correspond to concepts defined in the domain specific style guide. The level of concepts related in the style guide must obviously, later at the stage of implementation, somehow have a corresponding ‘item’ in the real world of interface components. The reasons for distinguishing different levels is obvious; e.g. a nurse does not relate to their work in terms of radio buttons or labels, but rather in terms of patients, medical records and drug prescriptions.
• The lowest level of abstraction does not contain any other knowledge than about strict appearance. It consists therefore of a syntax level that handles graphical requests from its user, in this case the X level, and of the semantics of these requests. Interface component parts.
Visual part
(Figure 1)
Semantics Syntax Presentation
• An imaginary next level contains a syntactic part on a higher level as it has got more of (semantic) knowledge. The knowledge can e.g. be to handle an identity card with picture, name, address, etc. Example
As an example of this “layering” in a C-language and OSF/Motif widget context an int could be seen as being at the most primitive level, the next level being a CallbackStruct and the whole widget struct being at the topmost level of the OSF/Motif Style Guide. The concept of fever can for instance be defined as a digital number in the domain specific style guide (Fig. 2), but this does not make an interface component domain specific just by the fact that it has a digital representation.The interpretation (given a medical context) of fever can in one design be a number, but the medical concept of fever is several abstractions higher than that of digits in the OSF/ Motif style guide.
Domain Specific Style Guides -Design and Implementation
Two possible mappings of fever, one as a text field ‘thermometer’ and another with a graphical representation. (Figure 2)
38.82°C Concept of fever
have also decided to concentrate our work on the design and development of domain specific interface components and their connection to the objects in the Helios SEE. Primitives, Interface Elements and Forms The visual objects, i.e. the interface components, in a Helios GUI can be divided into three categories: Primitives, Interface Elements (IEs) and Forms. The main difference between the three types is the functionality: Primitives:
In the Helios context, primitives are e.g. widgets or other ‘native’ objects such as lines and rectangles. In the Helios SEE the OSF/Motif widget toolkit and customized widgets are available. Primitives are used for layout handling and formatting of the user interface.
IEs:
An IE is dedicated to represent a certain object class. An IE has a visible presentation part, a template, designed in the interactive layout editor and a second part describing the connection to objects and operations in the Helios SEE environment. Objects and operations can be reached through the dialogue language via added external functionality.
Forms:
A form is an interface component corresponding to a complete application. It is therefore desirable to design the forms to fulfil all the interaction requirements needed to perform a complete work task.
Developing user interfaces in Helios The Helios SEE is built on a client/server architecture with service components communicating over a software bus. This software bus, called HUB (Helios Unification Bus) [5] contains services for connection, routing and communication. One of the components on the software bus is the UIMS service. There are basically four areas that we have taken into consideration when designing the UIMS 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 interaction.
• The connection to objects in other services in the Helios SEE, e.g. image related services or decision support functions, and their representation in the user interface. Further, we specified further 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
It is almost pointless to have a presentation part of an IE without any connection to objects, in our case medical objects. The IE will have access to objects in the Helios environment through the dialogue language. An IE is composed of a semantic, a syntactic and a presentation part. The IEs differ from the primitives in semantics and syntax, giving the IEs domain specific behaviour. The Helios IEs consist of primitives but functionality is added to make them IEs.
SEE. Our solution to the problem regarding building the GUI and taking care of the implementation of the dialogue, is to use a commercial product. The decision is based on the experience that the development of such a powerful set of tools is very demanding and falls outside the scope of our part of the project. We have chosen to use TeleUSE1. We
1. TeleUSE User Interface Management System is
designed according to the well known Seeheim model [6]. The main scope of TeleUSE is the layout editor and the dialogue language (D language). TeleUSE is a registered trademark of Telesoft Inc.
Domain Specific Style Guides -Design and Implementation
The parts of an IE: Semantic Syntactic
(Figure 3) Objects & operations Network
Presenter_ANSWER does Presenter_ANSWER.source_ widget.value:=
Presentation Presenter_ANSWER.values[1];
K Karlfelt
Dialogue
Primitives
Semantic:
Functionality; objects and operations, e.g. other services in the Helios-SEE.
Syntactic:
Dialogue level, the TeleUSE D language with added external functionality.
Presentation: Output and input representation, primitives such as OSF/Motif toolkit and other customized widgets. In the figure above (Fig. 3), the IE has a presentation part that is a Text widget, a syntactic part written in the dialogue language and a connection to a semantic part through an operation somewhere in the Helios SEE. The shadowed box implicates the network and the fact that the object can be located anywhere on the network. The IE in this example is generic and has been designed to display the name of a patient, through an operation in the parent object. In the figure below (Fig. 4), a complete (simple) form is designed with IEs showing information about a person. IEs designed into a form:
(Figure 4)
Most of the operations to manipulate data are used by all applications accessing the domain specific objects. The operations are e.g. to get objects, update objects etc. Some of the operations are more specialized containing knowledge of their environment and domain. Let us take an example from a user interface designers point of view; the interpretation of a blood pressure and the decision whether it is normal, high or low. This is nothing that can be decided during the design of the user interface. That kind
of knowledge must be implemented as a general operation for that class and coded according to medical expertise. What must be done during the interface design is to decide how the different values i.e. normal, high and low will be presented, e.g. using colour coding. The proper way to implement this is to define a method that accesses the blood pressure attribute and returns a symbolic value. Then the code associated with an IE can interpret this value and set the colour attributes according to it. This can be implemented as an IE with the three parts described above. We can separate the user interface presentation of a value from the actual implementation of it by including the domain knowledge into the operations for corresponding domain objects. This will facilitate the design of the interface and the possibility to create alternative designs without having to write a whole new application. This is also important in order to maintain a consistent database. Our approach is to position as much of the logic needed for the different IEs or applications into the objects and operations in the different services of Helios SEE and leave the user interface building, including the dialogue parts, to user interface designers. New primitives One result from the work on the Medical style guide is the need for new primitives as well as for the domain specific IEs. The demand for these primitives is not obvious until one tries to actually specify how the end user performs their tasks and what kind of support they need. We have suggested a couple of new primitives that we need, most of them related to the fact that humans handles pages and documents very efficiently. It is natural for skilled professionals in a none-computerized situation, for example in a medical ward, to handle documents organized into bundles and files. Our work on interface primitives is concentrated on supporting this efficient way of providing data even in a computerized environment. One example, in terms of widgets, is the manager widget Page. The purpose of this widget is to animate the look and behaviour of static ‘paper-bound’ information. There are methods for simulating the ‘turning of pages’ etc.
Discussion Our work within the Helios project has so far been concentrated on research and specification, but will now be more
Domain Specific Style Guides -Design and Implementation
directed towards implementation. The resulting system will provide developers in the health care ward domain with a SEE that will drastically improve the efficiency of both the efficiency of the development itself and the quality of the resulting end-user applications.
3. Nygren E., Johnson M., Lind M., Sandblad B. The art
It is our opinion that domain specific style guides will be an important component of the SEE in many work areas where professionals depend on efficient computer support. Preliminary tests, outside the health care domain, have been tried for e.g. technical maintenance support systems.
5. Jean FC, Jaulent MC, Degoulet P, Ciongard J. Distribu-
of the obvious. Proceedings of CHI’92, Monterey, California, May 1992. 4. OSF/Motif Style Guide 2.0, α-draft, Open Software
Foundation. tion and communication in the software engineering environments: Application to the HELIOS software bus. In: Proc. 15th SCAMC 91. New York: McGrawHill. 1991; pp. 506-510. 6. G. E. Pfaff, ed., User Interface Management Systems:
Acknowledgement The HELIOS consortium is a consortium of seven University and Industrial partners created within the framework of the AIM (Advanced Informatics in Medicine) programme of the Commission of the European Communities. The consortium is involved in the development of medical software engineering tools and applications. Members of the consortium are: • Medical Informatics Department, Broussais University Hospital, Paris, France • CAP Gemini Innovation, Grenoble, France • Deutsche Krebsforschungszentrum, Heidelberg, Germany • Geneva University Hospital, Geneva, Switzerland • Center for Human Computer Studies, Uppsala University, Sweden • Medical Informatics Department, Linköping University, Sweden • Cooperative Engineering Centre, Digital Equipment B.V., Amsterdam, The Netherlands
References 1. Gulliksen J., Johnson M., Lind M., Nygren E., Sand-
blad B. The need for new application specific interface elements. In G. Salvendy and M.J. Smith eds. Proceedings of HCI International’93, pp. 15 - 20, Elsevier 1993. 2. Norman D.A. Cognitive Engineering. in Norman &
Draper (eds) User Centered Systems Design. Hillsdale NJ. Erlbaum.
Proceedings of the Seeheim Workshop. Berlin: Springer Verlag, 1985.
Domain Specific Style Guides -Design and Implementation
