Domain-specific Design of User Interfaces
Domain-Specific Design of User Interfaces JAN G ULLIKSEN (
[email protected]) BENGT SANDBLAD (
[email protected]) Center for Human-Computer Studies , Uppsala University, Lägerhyddvägen 18, S-752 37 Uppsala, Sweden. Systems & Control Group, Department of Technology, Uppsala University, PO Box 27, S-751 03 Uppsala, Sweden.
Abstract The use of graphical user interfaces in a computerised work environment is often considered to substantially improve the work situation. The outcome can, however, often be the opposite. Inappropriate use of windowing techniques, scrolling and colours can result in tedious and confusing interaction with the computer. Today's standards and style guides define basic design principles but are insufficient for design of interfaces to end-user applications. Here detailed domain knowledge is indeed essential. A domain-specific style guide (DSSG) is an extension of today's standard with domain-specific primitives, interface elements, and forms, together with domainspecific guidelines. Careful dedicated analysis of information utilisation in a domain is the development basis for a DSSG. The development is performed with an objectoriented approach to facilitate the reuse of interface components and to support consistency and structure. Using a DSSG the development of applications can be performed with a simplified information analysis. Therefore a more effective design process is possible, one in which end users can participate in the design using their own familiar domain-related terminology. Time and costs for the development process can be drastically reduced if domain-specific style guides, design guidelines, and development tools are used.
Keywords Domain Specific Design, Style Guide, Workspaces, Interface Elements, Skilled Workers, Analysis of Information Utilisation.
1. INTRODUCTION – COMPUTER SUPPORT FOR SKILLED PROFESSIONALS New computer technology, methods, and techniques offer better possibilities for development of user interfaces in information systems. In spite of this, it has been argued that the benefit/cost ratio of investment in computer technology could in fact be decreasing. Software development is also costly and time consuming and the resulting software is sometimes neither appropriate or efficient enough to be accepted by skilled workers. We face several different problems. 127
Domain-specific Design and Domain-specific Style Guides
1.1 Problems With the Efficiency of User Interfaces Skilled professionals using computer artifacts in the work process can find unnecessary cognitive workload in the interface a severe obstacle. When computerised information systems are used in a work situation, such as in health care, the purpose of the work i s never to operate the computer. The computer is a tool that will be used and appreciated only as long as it efficiently supports the purpose of the work, for example to provide good health care for the patients. Therefore, the interface should be designed on the basis of optimisation of work activities instead of just optimising the use of the computer. The practical consequence of this is that such a 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 developed. The design must be performed in a way 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 work. In this way the computer system will be ”transparent” and the user can concentrate on work activities. We say that the interface must be obvious to the user [Nygren, Johnson, Lind, & Sandblad, 1992]. Studies of different types of work situations show that properties of the work environment can limit the persons’ efficient use of their skills. We call these l i m i tations cognitive work environment problems and they are often associated with the humancomputer interface. To minimise the cognitive load caused by the interface, design o f it must be based on an analysis of the user’s cognitive load. In our research we have seen examples of computer systems where up to 80% of the working time is spent managing the interface. The problem-solving process is being constantly interrupted by the need for redesign of the interface; opening, shrinking, and moving windows; starting different applications; interpreting information; and so on. This, of course, results in l o w efficiency, a high level of anxiety and stress, bad acceptance, and even health problems. Existing style guides for interface design do not support the design process from a user-centred perspective or a task-oriented approach. Instead they contain general design aspects on a very detailed level. It is possible to design a user interface that is fully compliant with a certain style guide, but still shows severe usability problems (Potter, Cook, Woods, & McDonald, 1990).
1.2 Problems With User Participation Different models for the development process exist. Our research work is based on a user-centred experimental model. The main idea behind this model is that system development is an iterative process. Important components are the dialogue between domain experts, for example the end users, and the computer experts and the use o f prototyping techniques. The domain experts formulate their preliminary requirements in activity terms. These requirements are interpreted by the computer experts who develop a prototype that is being tested and evaluated by the domain experts, who reformulate their requirements, and so on, in a ”spiral” process. However, our experience shows that it is difficult to apply this model efficiently. Limitations in methodology, techniques, and competence cause problems. Most development tools force the participators in the experimental process to utilise the language of the tool and the technical terminology of interface style guides. If the users are not allowed to use the jargon of their profession, they cannot contribute efficiently and the result will not be adaptable to the actual work processes as discussed earlier.
128
Domain-specific Design of User Interfaces
1.3 Problems With High Development Costs Everybody involved in ”real life” development projects where graphical user interfaces are being developed will experience that development time is too long, and the costs too high. One main reason for this is that the level of the development tools and the software components is relatively primitive. Development based, for example, on Motif will always require a long development time until the final product is finished, because most of the design and implementation work is hand made by skilled designers and programmers. It is also very difficult to reuse software components from earlier development projects. If more high level development tools are used, for example different UIMS, this can of course reduce development time, but only if the limitations of the tools are accepted. Because the tools are developed to be general, the interface elements and their behaviour are also of a more general nature (Gulliksen, Johnson, Lind, Nygren, & Sandblad, 1993). If more application-specific elements or behaviours are needed, this will require special efforts and we are back to the original situation. Many of these problems can be overcome, at least to a large extent, if domain specific methods are used.
2.
WHAT IS A DOMAIN-SPECIFIC STYLE GUIDE?
We define a domain as a class of work activities that bears similar aspects on the workers situation and performance regarding interaction with customers, case handling, decision making, information processing, and so on. In administrative, routine work, which is the main focus of our research, we can distinguish, for example, the staff administration domain, the health care domain, the laboratory work domain, the bank and insurance domain, the tax office domain, and so on. In the health care domain physicians, nurses, and administrative personnel collaborates to provide good health care. Professionals interact with patients using information sources such as time schedules, patient records, radiology reports, financial plans, and so on. Common to all of these domains is that the purpose of the work activities is not related to the operation of the computer. The computer is only a tool and provides a means for organising the required information in an easy controllable way. The computer system is seldom used to automatically perform complex decisions such as diagnosis, but instead it is used to organise large amounts of information in an easily accessible way. The key in designing user interfaces for applications in a certain domain is to understand important aspects of how work activities are performed in that domain and especially how the application domain currently is handled by other means, for example, existing computer systems and information retrieval routines. A domain can be broad or narrow. If the domain is defined too narrow its usage will be very limited. If it is too broad, the advantages of using such a style guide will be reduced. (In the extreme, a domain-specific style guide (DSSG), for the domain of all computer applications could be, e.g., Motif). With a DSSG we mean a specification of classes of appropriate interface elements together with guidelines for interface design using these elements for a given domain of applications. Domain-specific design requires a high correspondence between design concepts and interface components to enable efficient implementation. Style guides can serve as a tool to accomplish a uniform, well-functioning design. The concept of domain-specific design can be understood by viewing the differences between application development using a general and a DSSG (Figure 1). 129
Domain-specific Design and Domain-specific Style Guides Today, applications are being developed directly based on a general style guide (e.g., Motif). An application-specific information analysis and a costly and time-consuming development process is performed with difficulties to involve end users. Using a domain-specific analysis, we can design a DSSG and domain-specific guidelines. Based on this we can, with a simplified information analysis, develop applications faster and cheaper, together with the domain experts.
General Interface Style Guide, e.g. Motif Domain-specific Analysis
B
Domain-specific Interface Style Guide Simplified Applicationspecific Analysis and Simplified Development of Application
A
Applicationspecific Analysis and Development of Application
(End-user) Application
Figure 1. The differences between application development using a general (A) and a domain-specific (B) style guide. The process of developing a DSSG is laborious but normally only performed once per domain. An additional application specific analysis has to be performed before an enduser 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 Motif. Involving end users in development and prototyping will be facilitated because i t can be performed in a domain-relevant terminology. For example, in health care the professionals do not work with radio buttons and scroll bars, but with patients, laboratory reports, and drug prescriptions.
3. STRUCTURE OF THE DOMAIN SPECIFIC STYLE GUIDE The development of a DSSG should be based on an existing standard, such as Motif. This standard is complemented with other basic interface components, if needed. These sets together constitute a general basic level of interface primitives. These can, in one or several steps, be combined into composite, domain-specific, interface elements. In the health care domain, for example, we define a patient record element and a laboratory 130
Domain-specific Design of User Interfaces report element, and using these high level elements we can design and construct end-user applications for this domain, such as health care applications for a ward unit. In order to be domain specific, an interface component must contain domain knowledge. For example, a label with a red colour may in certain contexts denote some kind of warning or attention, but it is when we first give that label and colour a semantic meaning within a work context that it becomes relevant to talk about its domain-specific behaviour. As an example, the medical concept of fever can be presented as a text field or as a picture of a thermometer (Figure 2), but this does not make the interface components domain specific. However, the graphical presentation of fever as a thermometer that changes colour over a certain temperature will be a domain-specific element, presenting knowledge of fever coded in colour. A thermometer that does not change colour is not specific for the health care domain, but could be usable in other domains.
38,82°C
Figure 2 (See Colour Plate 7). Two possible mappings of fever, one as a text field ‘thermometer’ and another as a graphical representation of a thermometer.
Primitives, Interface Elements and Forms The visual objects of an interface can be divided into three categories depending on the differences in functionality: •
Primitives are widgets or other basic objects such as lines and rectangles. It i s reasonable to base the definitions on some existing tool kit such as the OSF/Motif widget tool kit and extend this with customised widgets. Primitives are used for layout handling and formatting of the user interface.
•
Interface Elements (IE) are dedicated to represent a certain object class. An IE has a visible presentation part, a template, and another part describing the connection to other objects and operations. IEs can be defined on different levels, and more and more complex elements can successively be developed from more basic ones. On the most complex level an IE will be a form. 131
Domain-specific Design and Domain-specific Style Guides
•
A form is an interface element corresponding to a complete or major part of an end-user application. The specification of a form is the result of a task analysis performed as a part of the development process. A form must be defined so that i t covers a complete work task for the end user. Examples of forms from different domains will be given later. In our terms a form is the interface element of one complete application, where an application is the computer support needed for one work activity. The information system of a domain is the collection of a l l applications of the domain.
Complementing Basic Interface Components
A 'Style Guide', e.g. Motif
General Basic Interface Primitives for skilled workers
General
General Basic Interface Elements
Composite Interface Elements and Forms
More and more Domain-specific
Applications
Figure 3. Interface elements at different levels constitute, together with domain specific guidelines, the domain specific style guide from which we develop applications.
132
Domain-specific Design of User Interfaces
To conclude the structure of the DSSG (Figure 3) a general style guide (e. g. Motif) i s extended with complementing basic interface components, described more thoroughly in Gulliksen, Johnson, Lind, Nygren, & Sandblad [1993]. These together constitute general basic interface primitives for skilled professionals. In the process of domainspecific design, interface elements at different levels are combined and domain knowledge is added to constitute more and more complex elements. In the applicationspecific design process forms and composite interface elements are integrated to a complete information system.
4. DEVELOPMENT OF DOMAIN-SPECIFIC STYLE GUIDES 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 familiar concepts. In the health care domain, for example, laboratory requests and reports, patient records, radiology reports, and so on, 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, which requires a deep knowledge of the tasks to be performed and familiarity with the user’s work situation. The designer has to identify the most frequent tasks in order to organise interface components according to relative frequency and importance. The domain information that the designer is missing, maybe even without his or her own knowledge, can be crucial for the efficiency of the interface. To accomplish an efficient interface, time and effort must be spent on analysis of the task, the work contents, and the utilisation of information. For practical reasons, as well as economical, such a detailed analysis cannot be performed in every new project. Therefore domain knowledge is assembled, continuously supplemented, revised and included in a DSSG.
The Process to Develop a Domain-specific Style Guide In the first step a detailed analysis of information utilisation of work activities in the defined domain is performed. There are a number of problems involved in analysing how professionals utilise information in performing job-related tasks. Because the reason for performing such an analysis is to reduce cognitive workload, the tasks must be defined in relation to individuals and their behaviour. Thus, the first part of the work is to find a representative sample of individuals skilled at the work for which a new computer system is being developed. The tasks, or rather the subtasks, the users perform while working must be specified. What we want to establish is the decisionmaking processes performed by users in relation to the task proper. Unless the future system incorporates modules performing such decisions automatically, which is fairly uncommon, these decision-making processes will also be present in the future system, although supported by other tools. We find subtasks by noting when individuals performing the tasks document something. It could be scribbling, resorting information, writing, clicking, and so on. The beginning of such a sub task is then found by interview techniques. These sub tasks being defined, our method is then to try and establish four things:
133
Domain-specific Design and Domain-specific Style Guides 1. If the future work situation will ever require two or more such subtasks to be performed simultaneously and in that case which subtasks. 2. Which pieces of information (we call them variables) are needed to perform each subtask and how often they are used. 3. The properties of each variable not found in the object data model, for example, properties that are specific to the group of users in question. This can be used for refinement of the data model. 4. How the carriers of the information (computer screens, paper documents, etc.) are handled and organised by the users in each subtask. It is worth noticing that we do not attempt to describe the decision rules used by the individuals while performing a subtask. The important factor here is to establish which variables, and their relative frequency, are needed per subtask or decision-making process. The collection of subtasks and their use, established by (1), define the set of tasks to be defined and incorporated into the interface. The variables used in each task, established by (2), should somehow all be simultaneously presented by the interface when a certain task is selected. The form of the presentation of each variable is determined by the datamodel and (3). Information gathered in (4) helps the designer of the interface choose the representations of the containers of the variables. The analysis of information utilisation must be complete enough to cover all relevant work activities in the domain. We do not only describe what information is being used by whom and when, but also important aspects of how it is handled by the professionals using it in different contexts. This analysis forms the basis for user interface design decisions. Based on this analysis a set of interface components, covering the field of possible applications, is defined and designed. The design is made so that the components can be identified and used with a minimum cognitive load. When using object-oriented techniques, the definition of the interface elements should be made consistent with the object model of the domain. The specification of basic and more complex interface components is a step-by-step procedure. The interface components, together with guidelines for application design using these components, now form the DSSG. When an end-user application is being developed only a simplified analysis o f information utilisation is required and the interface can be prototyped and constructed much faster and cheaper and in dialogue with the end users. The design process i s reduced to establish which forms and interface elements are needed simultaneously. The DSSG gives guidelines on how to combine them in a proper way.
5. IMPLEMENTATION ASPECTS When interfaces to end-user applications are developed it is important that the interface tools used include the domain-specific interface elements. An object-oriented approach is necessary for domain-specific design and development, it ensures a higher degree o f consistency, and it enables a design that is system independent. It is also advantageous to maintain flexibility further in the design process in order to increase viscosity. Viscosity describes how the fixation of different elements relates to the user interface development progress [Green, 1991]. This is the case when designing in domainrelevant terminology with a high degree of viscosity in a late stage of development. This form for user participation can also bridge the ”gulf of execution”, that is, when 134
Domain-specific Design of User Interfaces the user is trying to do something the designer never would have expected [Norman, 1986], because the possibility of predicting tasks to come is improved when designing in a domain-relevant terminology. Appropriate development tools must in other words support the implementation o f such components and have the possibility to include new interface elements designed for the domain. It is also necessary to separate the presentation and semantics of the elements in order to follow the object-oriented approach and maintain structure. The possibility of designing dynamic interface elements that can change presentation form depending on the context, (e.g. depending on values stored in the database) must also be supported by the tool. Rapid prototyping is another feature that heavily facilitates domain-specific systems engineering, especially if performed with the same tool as construction. These are just a few of the many aspects stemming from the implementation issues, and it is not within the scope of this article to go into further detail on this.
6. EXAMPLES FROM A DOMAIN-SPECIFIC STYLE GUIDE Within the HELIOS project [Engelmann, Jean, & Degoulet, 1994; Olsson, Göransson, Borälv, & Sandblad, 1993] in the CEC/AIM program, a DSSG for health care ward applications has been developed. Domain knowledge acquired from research and f i e l d studies within the medical sector is incorporated into this Medical Style Guide. It acts as an extension, or in some aspects a restriction to the OSF/Motif style guide, but mostly it contains supplementary high-level information, that is, domain-specific knowledge. The style guide is a dynamic and continuously updated document. We define five major parts: basic considerations, design methods, design guidelines, interface components, and health care applications. The basic considerations describe different user profiles, basic theories of human information processing, cognitive workload, and the influence on our physical abilities of communicating with the environment. The user can capture information contents and appearance on different levels of abstraction which makes the screen disposition as well as a fixed design important in order to facilitate pattern recognition and the interpretation of information. Applicable design methods are briefly discussed. We have decided on an objectoriented approach with a common platform including design and development tools. A method for modelling cognitive aspects of how information is used is a topic of high importance. An experimental design method that involves the presumptive users in the development process is recommended to assure efficient design. In the design guidelines each important area is described in a general part, for instance general aspects of “visual encoding,” in order to create a common reference for understanding succeeding advice. Further, ”recommendations” and ”avoids” are frequently illustrated, with domain-relevant examples, to explain the given advice. An elaborate description of each specific interface component is provided, concerning colours, character formats, size, location, and so on, in the medical domain. Examples are name field, patient card, prescription, or radiology image browser. The fifth part of the Medical Style Guide contains design guidelines for more complete medical ward applications. In Figure 4 we see an interface element of the broader domain of work situations interacting with humans. The professional user immediately recognises from the pure shape of the fields what information to enter. The light yellow colour coding signals that the data entry fields are search sensitive, a return command after the last entered 135
Domain-specific Design and Domain-specific Style Guides letter triggers a search in the database. The fields for the personal identification numbers are digit separated both to signal what information to enter when not entered, and to perform the check on the number entered instead of when the full number has been entered. If there is a competition of screen space, labels are not needed because the structure of the fields in the context makes the contents preferred obvious.
Figure 4 (See Colour Plate 8). An example of a composite person element specific for a broader domain of work situations handling persons or customers. The first and second row are marked light yellow to signal search sensitivity. If there is a competition of screen space, labels are not needed because the structure of the fields in this context makes the wanted contents obvious. An appropriate set of ward interface elements has been designed and implemented in a toolkit. One example of a domain-specific interface element is the patient element, (Figure 5), developed directly based on the person element previously discussed.
Figure 5 (See Colour Plate 9). An example of a ward domain-specific interface element, the patient. It is an extension of the person element with a medication field and a fixed warning field marked with colour. 136
Domain-specific Design of User Interfaces
In all health care ward applications where a patient appears, this element can be used, specified to its location, behaviour, database connections, and so on. Current medications and important medical information are always shown. Special warning fields containing important information that always are needed are signalled with colour. Of course several alternative patient objects, corresponding to different needs or expectations, can be implemented in parallel into the toolkit. A result from the work on the Medical Style Guide is the need for new primitives and domain-specific interface elements. This is not obvious until one actually tries to specify how the end users perform their tasks and what kind of support they need. New primitives have been suggested, most of them related to the fact that humans handle pages and documents very efficiently. It is natural for skilled professionals in a noncomputerised situation, to handle documents organised into bundles and files. The work on interface primitives is concentrated on supporting this efficient way o f working with data even in a computerised environment [Nygren, Johnson, & Henriksson, 1992; Nygren & Henriksson, 1992]. One example, in terms of widgets, i s 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 and so on. More and more complex interface elements are designed and more and more domain knowledge is included. A special example is the patient record page that contains both search-sensitive data entry fields for input of personal identification numbers or names directly and the specific notes for every day. This special page contains the possibilities of displaying and running visual animations of the results from PET scanning with the video-manoeuvring buttons at the bottom of the page (Figure 6). Based on these complex interface elements, forms are designed. A form is a full application for a specific task, for example, the patient record reader or the test result display facilities. These forms and interface elements together with domainspecific guidelines constitute the DSSG.
137
Domain-specific Design and Domain-specific Style Guides
Figure 6 (See Colour Plate 10). The final information system is a combination of interface elements and different forms (that can be chosen with the form buttons in the right column). At present the medical record form is chosen with the record document combined with an index, the patient card and miniatures of previously read medical records.
138
Domain-specific Design of User Interfaces The final information system is the combination of different forms and interface elements from the DSSG according to the needs of the specific user. Different forms can be chosen from the Helios form bar, to the right of the screen. A form is chosen by selecting the specific button in the form bar, which then turns light grey. A form can be closed in the same manner by clicking the same button. A new suggested interface element is the patient icon menu that emphasises the possibilities of extending the pull-down menu with graphical information. Nurses i n a medical ward unit have quite a good picture of in which room a patient is placed i n their unit, but can have difficulties choosing the patient from a pull-down menu with only the personal identification number available. The possibilities of including other graphical information by colour coding, or by placing other icons in the ”rooms” to signal the presence of a particular apparatus makes this an appealing design (Figure 7).
Figure 7 (See Colour Plate 11). Domain-specific mini-icons in a pull-down menu to symbolise the patients, place- and colour-coded, to supplement information on location as well as type of patient. By inclusion of the personal identification numbers and names, the nurses get more information interpretable on an automatic level then with an ordinary menu with selectable personal identification numbers. It is also possible to graphically code where certain apparatus, such as the ward telephone, presently is located.
7. DISCUSSION Our experience from a number of test applications shows that it is possible, using the techniques already discussed, to significantly reduce the users’ cognitive workload related to the interpretation and manipulation of the interface. Such workloads, which we call cognitive work environment problems, are an increasing hindrance for 139
Domain-specific Design and Domain-specific Style Guides efficient use of information technology in many professional fields, and they lead to frustration, stress, and even health problems. The specification of the domain-specific interface elements must of course be based on a detailed analysis of the actual work activities of the domain under investigation. A basis for what we have called ”analysis of information utilisation” is a task analysis of a more traditional nature. Here the work activities are described and analysed with respect to their contents, work organisation and existing problems of different nature. When the information utilisation aspects are described and analysed this must also be done in an actual work environment. Our approach to this challenge is to involve representatives from the work domain under consideration. The formulation of the descriptions and the analysis work is performed as a cooperation between user representatives and experts in the methodology. The domain-specific approach gives us new possibilities for designing and implementing new primitives, interface elements, and forms, and basing the design o f the user interface on such guidelines, which can minimise unwanted cognitive workload. Our experiences from larger applications of the described domain-specific approach are today rather limited. In one research project the development of a fullscale DSSG has been tested [Borälv, Göransson, Olsson & Sandblad, 1994]. The experiences are that the process is feasible and that the result fulfilled the stated requirements. However, there are some difficulties associated with the development process. The first is related to individual differences between user requirements and requirements of groups and organisations within the domain. Such differences must not be underestimated, but rather accepted as a necessity. This means that different solutions and designs to the same interface element must often be accepted. The result of this i s that the volume of specifications and the number of interface elements increase. The second main difficulty is that it is difficult in practice to involve user representatives to the extent needed. There is a definite need for active and competent user participation. This means that management of the involved organisations must support the development project by assigning enough resources and competence. It also means that it is important to assure that the competence of both partners of the development team, that is, the user representatives and the design experts, is adequate. They must both have a correct understanding of the nature of domain-specific design. When implementing DSSGs we see a need for a new generation of software that makes it easier than it i s today to implement DSSGs and to develop applications based on them. Object-oriented software with a common platform including both design and development tools ensures consistency and system independence and enhances reuse of interface components of different levels. It is our opinion that DSSGs will be an important component of the SEE in many work areas where professionals depend on efficient computer support. The domainspecific development process also reduces time and costs and enhances user participation, using a domain-relevant language. Preliminary tests, outside the health care domain, have been performed for technical maintenance support systems and in the administrative case-handling domain.
8. ACKNOWLEDGEMENT This work was performed with financial support from the Swedish Work Environment Fund, and from the CEC/AIM program, Project No. A2015. The cooperation and contributions from all project members are greatly appreciated. 140
Domain-specific Design of User Interfaces
9. REFERENCES BORÄLV , E., GÖRANSSON , B., OLSSON , E. & SANDBLAD , B. (1994). Usability and Efficiency. The HELIOS Approach to Development of User Interfaces. In U. Engelmann, F.C. Jean, P. Degoulet (Eds.) The HELIOS Software Engineering Environment, Supplement to Computer Methods and Programs in Biomedicine, Vol. 45, pp. 47-64. ENGELMANN, U., JEAN , F.C., & D EGOULET, P. (Eds.) (1994). The HELIOS Software Engineering Environment, Supplement to Computer Methods and Programs in Biomedicine, Vol. 45, Dec. 1994. GREEN, T.R.G. (1991). Describing Information Artifacts with Cognitive Dimensions and Structure Maps. Proceedings of HCI ’91: Usability Now, Annual Conference of BCS Human-Computer Interaction Group. Cambridge University Press. G ULLIKSEN , J., SANDBLAD , B., JOHNSON , M., LIND , M. & N YGREN , E. (1993). The Need for New Application Specific Interface Elements. In G. Salvendy & M. J. Smith (eds.) Human-Computer Interaction, Proceedings of the 5th International Conference on Human-Computer Interaction, HCI International '93, Orlando, Florida, USA, 8-13 August, 1993, Elsevier, pp. 15-20 N ORMAN , D.A. (1986). Cognitive Engineering. In D.A. Norman & S. Draper (eds.) User Centered System Design, Lawrence Erlbaum Associates, Inc., Hillsdale, New Jersey, pp 45 - 48 N YGREN , E. & HENRIKSSON , P. (1992) Reading the Medical Record I. Analysis o f physicians ways of reading the medical record., Computer Methods and Programs in Biomedicine. Vol. 39, pp. 1-12. N YGREN , E., JOHNSON , M. & HENRIKSSON , P. (1992) Reading the Medical record II. Design of a human-computer interface for basic reading of computerised medical records, Computer Methods and Programs in Biomedicine. Vol. 39, pp. 13-25. N YGREN , E., JOHNSON , M., LIND , M. & SANDBLAD , B. (1992). The Art of the Obvious. Automatically Processed Components of the Task of Reading Frequently Used Documents. Implications for Task Analysis and Interface Design. In J.P. Baursefeld, J. Bennett & G. Lynch (eds.) Proceedings of Human Factors in Computing Systems, CHI '92, Monterey, California, May 1992, ACM, pp. 235-239. OLSSON , E., GÖRANSSON , B., BORÄLV , E. & SANDBLAD , B. (1993) Domain Specific Style Guide - Design and Implementation. Proceedings of the MOTIF ‘93 & COSE International User Conference. Washington, DC. P OTTER , S.S., COOK , R.I., WOODS , D.D., & M C DONALD, J.S. (1990). The role o f human factors guidelines in designing usable systems: A case study of operating room equipment. Proceedings of Human Factors Society 34th Annual Meeting (Orlando, FL, 812 October), pp. 392-395.
141
Domain-specific Design and Domain-specific Style Guides
142
