SEARCHING FOR UNITY AMONG DIVERSITY: EXPLORING THE "INTERFACE" CONCEPT
In Proceedings ACM / IFIP Conference InterCHI '93 (Human Factors in Information Systems), Amsterdam, April, 1993, 263-268.
Kari Kuutti
University of Oulu
Dept. of Information Processing Science
Linnanmaa, SF-90570 Oulu FINLAND
E-mail: kuutti@rieska.oulu.fi
Liam J. Bannon
Univ. of Copenhagen
Dept. of Computer Science
Universitetsparken 1, DK-2100 Copenhagen,DENMARK
E-mail: bannon@diku.dk
ABSTRACT
Despite widespread interest in the human-computer interaction (HCI) field, there remains much debate as to appropriate conceptual frameworks for the field, and even confusion surrounding the meaning of basic terms in the field. HCI is seen by many as focusing on the design of interfaces to computer systems, yet exactly what is implied by this focus on "interfaces" is unclear. In this paper we show how a better understanding of what is meant by the interface is possible via the concept of abstraction levels. We show how this levels approach can clarify some ambiguities, and also how it can be related to different phases in the evolution of the human-computer interaction field itself. In this context, we are able to account for the recent interest in activity theory as a possible alternative framework for HCI work, while stressing the need for HCI research and design to consider each of the separate, but related, levels.
KEYWORDS: interface, user interface management systems, abstraction levels, activity theory
INTRODUCTION
"This chapter has considered bridging between specifically cognitive theory and behavior in human-computer interaction. This form of bridging is but one among many that need to be pursued. For example, there is a need to develop bridging representations that will enable us to interrelate models of user cognition with the formed models being developed to support design by software engineers. Similarly there is a need to bridge between cognitive models and aspects of the application and the situation of use. Truly interdisciplinary research formed a large part of the promise, but little of the reality of early HCI research. Like the issue of tackling nonideal user behavior, interdisciplinary bridging is now very much on the agenda for the next phase of research" (Barnard [3], pp. 122-123).
"For the most part, useful theory is impossible, because the behavior of human-computer systems is chaotic or worse, highly complex, dependent on many unpredictable variables or just too hard to understand. Where it is possible, the use of theory will be constrained or modest, because theories will be so imprecise, will cover only limited aspects of the behavior, will be applicable only to some parts or some systems, and will not necessarily generalize; as a result, they will yield little advantage over empirical methods" (Landauer [18], p. 60).
CHARACTERISING THE INTERFACE
Much of the discipline of human-computer interaction necessarily revolves around the design and use of the human-computer interface. By this is usually meant all aspects of the interaction between the computer system and the person, and not only that part of the computer system that deals with input and output. Indeed, for many people, the whole field of human-computer interaction (HCI) is synonymous with the design and use of interfaces to computing systems. However, discussions of the "interface" involving, for example designers and users, or even different members of an interdisciplinary design team, can become rather confusing if the differences in use of the term [see, e.g. Grudin, 10] are not made clear at the outset. There have been a number of calls from interdisciplinary design groups for clarifying confusions surrounding the use of "interface" and other terms in HCI, through the development of a common dictionary of concepts, so as to alleviate problems of mis-communication between people from different disciplinary backgrounds. Apart from problems surrounding practical enforcement procedures for such a grand unifying plan, the very idea is, we believe problematic. The problems cannot be resolved simply by making more exact definitions. This is because the use of the terms is spread across a variety of disciplines, and it is impossible to enforce a single meaning of a term already in use across these quite distinct, even if overlapping communities. The meanings of terms that are shared in a community of practice are not easily changed by stipulative definitions from some legalistic body, as these meanings are embodied in use in the different communities and quite resistant to such attempts at changing definition and usage. The least that we could do would be try to make the contexts of use of the term clearer for all the parties involved, so that they can recognise that use of the same term at different times, by different groups, does not imply similar meanings.
Interface separability
While the HCI area is acknowledged to be an interdisciplinary one, the loudest voice has usually belonged to psychologists. A line of demarcation between programmers and psychologists in software design is sometimes drawn by focusing on the separation of the "interface" from the underlying "functionality" of the system. As Robinson [28] notes: "The interface stands as the boundary between what is the work of HCI and what is the work of the software engineer. The "true" nature of the system - what it does - is defined by the state of the software 'behind' the interface...the neutral and objective functionality of the 'internal' state (of the machine) may be realised by alternative interface designs" . Such an approach has had the unfortunate effect of reifying the interface concept for much of the HCI community as the prime object of study. This reification has also tended to result in an undue emphasis on rather "surface" aspects of interface design, within many of the different interpretations of the interface that are commonly used. Thus studies on how to redesign menus, or make more meaningful command abbreviations become seen as prototypical. Yet, paradoxically, this reification of the interface as the domain of HCI has actually marginalized its impact. For example, Seymour Papert [26] recently commented: "...if only the interface (is changed), and what lies behind it and what you can do with the system isn't changed, you're only scratching the surface. The interface is only the surface.."; and Mike Hammer [13] put it bluntly: "In reality, user interface is a second-order factor...".
Over the past few years, a number of people have pointed to the neglect of the task context in which human-computer interaction is taking place, and an undue emphasis on lower level interface issues [2, 5, 8, 12, 24, 31]. They argue that much of the HCI world pays too little attention to the underlying functionality of the computer applications and their usability in everyday work contexts. The idea that we can separate out the design of the interface from the design of the functionality of the system, and perhaps also the coding of the interface from the coding of the rest of the application has generated a lot of discussion over the last several years. As we have seen, it can be seen as a possible territorial division of responsibility between software engineers and HCI people, as well as having implications for the software development process, and the modularization of code. The popularity of User Interface Management Systems (UIMS's) significantly contributed to the impression of this separability, despite some warnings about the limitations of such systems, even by their proponents [e.g. see Tanner & Buxton, 30]. In designing a program or system, we obviously must pay attention to the needs of the user and the use situation, and to how the design will meet these needs. The idea that in such situations a neat separation between interface and functionality can be accomplished is open to question.
So far we have discussed some problems with the meaning of the "interface" term as well as the choice of the "interface" as the object of study for HCI. The simple interface-functionality separation begs many questions. What we need is some kind of a general framework that provides a more grounded and conceptually coherent set of concepts within which to discuss the design of computer systems which people can use in their daily work. In the next section we introduce one such framework, which has been used in the information systems design community, and which we believe can provide a useful starting point for developing such a framework.
THE INTERFACE IS NOT A UNITARY CONCEPT
One reason for the evolving meaning of important terms in the field is linked to the shifting focus of interface research and development. For example Grudin [11] has argued for a five-phase shift, starting from 'the interface at the hardware' and ending with 'the interface at the work setting', each phase having a different viewpoint and emphasis. It is thus not surprising that the idea of clarifying meanings through discussing the interface from several perspectives, or levels, has appealed to a number of researchers [4, 7, 9, 16, 27, 29, 34]. There are some problems with these attempts, however. Although the use of different perspectives may help in clarifying different approaches to the interface, it does not necessarily help in relating them to each other because of the lack of any unifying background. Even in those cases where a hierarchical, layered model has been proposed [7, 29], the result is more ad hoc. Perhaps the most useful is the Rasmussen [27] five-level abstraction hierarchy, which is based on the general functional properties of a technical system.
There is, however, yet another tradition concerning use of different perspectives, namely, that of the information systems (IS) community. It has a closer relationship to interface issues than the "technical systems" discussed by Rasmussen and we suggest that it might be beneficial to use the experience collected there in clarifying some of the confusions noted above. It can also serve as an example of a practically -oriented, long-term, project to develop what we mean by "integrative perspectives" in a related field.
Integrative perspectives in information systems
There has been a long history in the IS field relating to the development of a set of interrelated models which together could be capable of grasping the multifaceted nature of information systems - in design and use. The nature of these model-sets corresponds closely to our idea of "integrative perspectives". Different researchers call these perspectives with different names such as "abstraction levels" [Iivari, 15], or "object system contexts" [Lyytinen, 21]. Because the following discussion of IS views is based primarily on Iivari's work, we use his terminology, although we do not fully subscribe to his notion of "levels"* .
What are "abstraction levels"? The term refers to a widely accepted principle that in order to handle the complexity of IS design it must be divided into several levels or subdomains, which can each be treated relatively independently, each having their own models, concepts, methods and background theories (See Iivari, 1989 for an explication). The three levels of abstraction commonly discussed in the IS community are: organisational, conceptual, and technical. The organisational level contains a description or model of organisational practice to be supported by the IS, and a description of IS functions. Sometimes the definition of this domain is called the requirements of the system. Traditionally, this has been developed by the system analyst, but during recent years more participatory forms of development have surfaced. The conceptual level is the most central in most development methodologies, containing abstract, conceptual models of both the object domain ('universe of discourse') and the system itself. Sometimes the definition of the domain has been called the specification of the system. Finally, the technical level contains practical, concrete objects and processes: databases, programs, machine and communication architectures, input and output devices etc. The links between the domains consist of different transformation procedures, formal and informal [For more on these subdomains and relations between them, see e. g. 25] . It does not matter if it is impossible to discuss topics at the organisational level using the concepts and vocabulary of the technological level and vice versa, as long as we can establish the transformational procedures needed in order to cross the borders. In the next section we will briefly note how such a structure could be utilised within HCI to clarify some of the interface issues which we have been discussing.
The interface in terms of integrative perspectives
Following the IS example above, we suggest that it might also be beneficial to have several different definitions of interface - one for each level. Note that this layering is fundamentally different from attempts to make a separation between the 'interface' and the 'application'. In our suggestion the demarcation line is not drawn between the interface and application, but between the different design domains of an application, each containing also an interface as an integral part. The nature of the relationship between what is assumed to belong to the 'interface' and the 'application' parts need not remain the same from level to level.
What, then, are the appropriate definitions of the interface for each level? First, the 'uppermost' level must be redefined. In our opinion, the term 'organisation' is too broad, yet we wish to go beyond individual work support, so we discuss the interface at the work process or use situation level. At this level we are quite happy with a definition put forward by Andersen [1]: "Instead of seeing it (i.e. the interface) as a part of the program I propose that we view it as a relation between program and use context....It does not make sense to say that a system in isolation has an interface; interfaces "emerge" when the system is used...". Thus, from the user's viewpoint in the use situation, the interface is the system. There is no possibility to separate interface from functionality, for the interface is the way a user's work is supported by the system. At the conceptual level, the interface is that part of a system or application which must be understood and mastered in order to utilise the system meaningfully for some purpose in some definite use situation. An implication is that the role of the interface can vary in different applications. In fact, we have a whole spectrum of applications: At one end we have applications which have no human interface whatsoever, e.g. EDI (electronic data interchange) programs. At the other end of the spectrum we have programs which can be claimed to contain nothing but the interface, e.g. scientific visualisation, where it can be argued that the whole application belongs to the interface (Kuutti & Bannon, 1991). Finally we have the interface at the technological level. Newman and Sproull's (1979) definition of the interface in their classic text comes close to what we mean here: "(the interface is) that part of the program that determines how the user and the computer communicate".
We can now see how the relationship between 'interface' and 'application' can have different and even seemingly contradictory interpretations within different design domains. At the work process level they are unified, at the conceptual level probably partially overlapping, and at the technological level they may be fully separated. The relative independence of the different domains can be maintained only when we can establish 'links' - practical transformation procedures - between the domains. Such links are not yet in existence in most cases, though we can interpret the work on UIMS's as an attempt to develop automatic transformation procedures between the conceptual and technological level, so that the design and manipulation of (some aspects of) interfaces can happen at a conceptual level and the result is automatically transformed to the technological level (e.g. window managing, menu building etc.).* We simply must be careful that the UIMS does not restrict the attainment of the design goals stated at the work process or conceptual levels. Because many UIMS's are grown 'bottom-up' - the main emphasis being the management of code - this may be a potential source of problems.
Having discussed issues surrounding the use of the term interface in HCI and hopefully clarified some of the confusions, we now turn briefly to discuss how we could re-conceptualise the very field of HCI in what we believe to be an interesting way, one that points out the links between existing HCI research traditions.
THE LINK BETWEEN INTEGRATIVE PERSPECTIVES AND HCI RESEARCH TRADITIONS
In this Section we show the relationship between the integrative perspectives outlined above and ongoing HCI research. Firstly, the conceptual level in our perspective fits well with the bulk of HCI research based on the cognitive psychology of information processing - mental models and their correspondence with the real world etc. Secondly, our physical/technical implementation level corresponds well with the concerns of early "low-level" human factors studies, vestiges of which remain in specific areas of current HCI work. Finally, the recent discussion about the need for "better social contextualization" of HCI work (6] is clearly an attempt to extend HCI in the direction of our work process level. Thus we can characterise the situation as follows: (Figure 1)
Figure 1. A proposed 3-phase model of the enlargement of the HCI research domain (adapted from Kuutti, 1992)
Having demonstrated the relationship between these perspectives and different aspects of HCI, we now face the question of its utility. Given that currently HCI suffers from a lack of any firm theoretically informed design methodology, from a practical viewpoint all we can say of our approach is that at least in the field of IS practice, it has been possible to integrate and use these three levels in the design process, and so there is some hope that they might prove useful in HCI also. From a theoretical viewpoint, we wish to outline briefly an argument that there exists a general theoretical framework that can subsume the different integrative levels we have identified.
Integrating perspectives through activity theory
Having seen some benefit to taking a levels approach to understanding apparently confusing concepts in HCI, we still require a coherent theoretical framework within which each of these levels can be adequately elaborated. The framework must also provide means for linking these different perspectives into a more general conceptual structure. While there may be several candidate frameworks, here we concentrate on showing how the general psychological theory known as Activity Theory, or the cultural-historical approach, might be useful. This Soviet-inspired tradition has recently received some attention in HCI circles [2, 5, 17, 18, 22] as it appears to provide some coherent framework for integrating across the different HCI research traditions that we have outlined.
One of the fundamental conceptualisations in Activity Theory is that activities - the basic units of social life - have a hierarchical inner structure. Activities consist of single actions or chains of actions, which in turn consist of operations.When we participate in an activity, what we are actually doing is just performing conscious actions. The actions cannot really be understood, however, without a frame of reference created by the corresponding activity. An activity may be realised using different actions, depending on the situation, while one and the same action can belong to different activities. Before an action is performed in the real world, it is consciously planned - using a model. The better the model, the more successful the action. This phase is called orientation. Actions are realised as chains of operations, which are well-defined routines used by the subject subconsciously as answers to the conditions faced during the performance of the action. All operations start out as actions initially, but when the corresponding model is good enough and the action has been practised long enough, the orientation phase will fade and the action will be collapsed into an operation, which is much more fluent. At the same time a new action is created which will have broader scope and will contain the recently formed new operation as a subpart of itself. On the other hand, when conditions change, an operation can again "unfold" and return to the level of conscious action (i.e. it is not simply a conditioned reflex).
Thus we can say that Activity Theory forms a coherent theoretical system which contains the three levels or perspectives described earlier: activities as contexts of interactions, conscious actions where conceptual interaction is taking place, and finally operations, which are dependent on the pertinent conditions, at the physical interaction level. What makes the Activity Theory approach of special interest is that it explicitly attempts to manage the relationships between the different levels, rather than simply labelling them. Since there are few such general conceptual frameworks available to our knowledge, further work on developing this approach in the specific context of HCI concerns seems worthwhile. Whether this will lead to more practical advice for designers is still an open question.
CONCLUSIONS
This paper has discussed certain problems within the field of HCI which we believe are caused by confusion over basic concepts and terms. In an effort to alleviate some of this confusion and clarify the important underlying arguments, we propose a three-level framework within which to discuss the field. This "integrative levels" approach has been used successfully in other fields. We apply this idea in HCI to the interface concept, showing how it can help alleviate some of the current disputes concerning its meaning. We then apply it at a more general level, to the whole of the HCI field, and show how it can structure some of the ongoing shifts in the focus of research over the years. In this context, we can explain the recent interest in the use of activity theory in HCI. Our perspective points to the importance of considering all three levels in HCI research and development work, both separately and combined.
REFERENCES
13. Hammer, M. (1984) The OA Mirage. Datamation, Feb. 1984, pp. 36-46.
24. Norman, D.A. (1990) "An interview with Don Norman" by H. Rheingold. In Laurel (1990), pp.5-10.
26. Papert, S. (1990) Interview in "Byte´s 15th Anniversary Summit", Byte September 1990, p. 230.