Thinking with Heidegger about Software Usability
Christopher N. Chapman, Ph.D.
Paper presented at: Philosophy in the Contemporary World, 8th Annual Meeting Santa Fe, New Mexico July 22-27, 2001
Author address: Chris Chapman (cchap) 1 Microsoft Way Redmond, WA 98052
[email protected]
Heidegger & software 1
Thinking with Heidegger about Software Usability Abstract I explore the possibility of using Heidegger’s concepts of world and temporality with respect to human interaction with computer software. Prevailing accounts of humancomputer interaction are limited by assumptions of cognitivism and empiricism, which neglect many aspects of computer software use. I extend Heidegger’s notion of “world” to include software worlds, and extend “temporality” to include processes in which people engage with software. With these concepts, we may not only account for the features explained by cognitivist user theories, but also understand other types of significant human behavior with computer systems. I briefly address how these aspects of our experience of software might be addressed by the profession of software usability engineering. Introduction In this paper, I address practical questions in software development from a philosophical perspective. As a software usability engineer who works to improve user interaction with computer operating systems, my concerns here bridge both practical and theoretical aspects of software development. I note problems and limitations with the general concepts that software professionals employ to understand humancomputer interaction. Following the work of earlier researchers, such as Winograd, Flores, and Heim, I suggest that we might be better able to understand software use if we “think along” with concepts derived from work by Heidegger. Using those concepts, I outline specific ontological suggestions and questions that have significance for software designers. Heidegger is, of course, notoriously problematic for philosophers and other readers who expect systematic exposition. This is because his work is typically either presented in an architectonic so abstract that definite practical implications are unclear (e.g., Heidegger 1996 (1927)), or because it is suggestive, metaphorical, and
Heidegger & software 2 unsystematic (e.g., Heidegger 1977 (1954)-a). While these problems leave us open to doubts about interpretive authority, they also give us the freedom to “think with” Heidegger in new areas, as I do here with respect to software. It will help to begin by sketching the field of software usability. Usability is a specialty within the general field of human-computer interaction (HCI). HCI, in turn, falls under the rubric of human factors engineering, which includes both basic research and applied work such as the design of human controls for airplanes and the like. My comments here are directed at software usability, but many aspects of my analysis also apply to those broader fields. In the early years of commercial software development, developers paid attention almost exclusively to questions of technological capabilities, discovery of algorithms, and creation of new categories of software applications. Despite calls from academic computer scientists and human factors experts, the development process gave little attention to questions of how software users interacted with their systems in basic ways and how such interaction might be improved. In the past decade, however, software companies have devoted significant resources to improving the “user experience” with software. In many professional software development organizations, ranging from software consultants to commercial software companies to web site designers, usability engineering is now a core discipline on development teams. The activity of usability engineers follows the course of the software life cycle. Early in the development process, a usability team may focus on understanding users’ tasks in their work environments, and evaluating what obstacles they face in accomplishing those tasks with current computer systems. As development of a new product progresses, usability
Heidegger & software 3 provides human factors and behavioral expertise to the programming team. As the software takes shape and nears completion, usability engineers may test users on successive preliminary versions of software to determine how easy it is for users to learn the software and complete tasks with it, and what developers should change. The experience of the software industry is that usability work yields several benefits: closer correspondence between software and the tasks that users wish to complete, better understanding of end users, and functionally improved software that is easier to learn and to use. It is hoped, of course, that such improvements will be reflected in the marketplace.
The Usability Framework and its Limits There are two fundamental limitations to usability engineering as outlined above. The first limitation that usability exhibits is a variety of cognitivism combined with an assumption of task decomposability. Usability engineering typically assumes that users have mental constructs that represent the tasks they want to complete. Further, it assumes that those tasks can be broken down into subtasks, that the subtasks can be mapped onto discrete actions in a computer system, and that a series of such actions will complete a task. The goal of usable software in this scheme is that users will form an implicit or explicit mental model of this entire task-action process as they learn and use particular software. As one standard text describes, Doing object-action design starts with understanding the task. That task includes the universe of real-world objects with which users work to accomplish their intentions and the actions that they apply to those objects…. Once there is agreement on the task objects and actions and their decomposition, the designer can create the metaphoric representations of the interface objects and actions…. Finally, the designer must make the interface actions visible to
Heidegger & software 4 users, so that users can decompose their plan into a series of intermediate actions, such as opening a dialog box, all the way down to a series of detailed keystrokes and clicks. (Schneiderman 1998, pp. 61-62) In other words, the essential, desirable nature of a software system is to be a metaphorical map of a user’s cognitive schema for performing a given task. The second limitation in traditional usability is empiricism, or more precisely, the assumption that the most important aspects of users’ experience can be captured in empirical measurement of some kind. There are many possible mappings between software and users’ cognitive schemas, so engineers turn to empirical data to disambiguate the possibilities: Careful determination of the user community and of the benchmark set of tasks is the basis for establishing human-factor goals. For each user and each task, precise measurable objectives guide the designer, evaluator, purchaser, or manager. These five measurable human factors are central to evaluation: (1) Time to learn … (2) Speed of performance … (3) Rate of errors by users … (4) Retention over time … (5) Subjective satisfaction … (Schneiderman 1998, p. 15) These objectives potentially conflict, so it is necessary in practice to decide which to emphasize, according to a project-specific cost/benefit analysis. By weighting measurements and combining them, one may even reduce the evaluative data to a single dimension of usability or functionality.1 The complete picture for usability engineering, then, is that software comprises physical systems that embody representations of users’ presumed cognitive structures, and that competing systems may, in principle, be assessed on quantitative dimensions of “usability.” This approach defines the operation of software in terms of how well the software embodies some specified, static set of processes. Thus, software has an
Heidegger & software 5 essence, and is conceived in an essentialist framework. As a usability engineer, such an essentialist, empiricist approach to understanding users and their computer interactions is fundamental to my work, and I believe that this strategy helps to create better software – in whatever sense one wishes to make of “better.” However, this traditional usability approach is limited. There are vital aspects of how people interact with software that cannot be captured by the cognitivist, essentialist model, without resorting to artifice. We can see this by considering three simple examples of software use: games, interface appearance, and software allegiance. First, the cognitivist framework does not account for the behavior of playing computer games, behavior which becomes nearly obsessive for some players. Explaining that games are “fun” begs the question, and an account of game-playing behavior in terms of tasks, goals, and the like, is grossly insufficient. On a real-world account, the goals and tasks displayed in computer games are generally either trivial (e.g., card games) or unrealistic (“shooter” games). If task mastery were the explanatory factor, then we should expect to find accountants obsessively attempting to conquer all the “levels” of their spreadsheets. Something outside a strict cognitive model is occurring. Second, the cognitivist model does not explain what we might call “furbishing” behavior, using software features that allow one to change the appearance of the software, such as the desktop image or sounds played for system events. From a goalor logic-oriented perspective, such things are meaningless at best. To accomplish tasks and facilitate learning, it would be more useful if all similar systems behaved identically. Yet we find that furbishing features are quite popular; the Internet abounds with available “themes” and “wallpapers.” 1
. Similar cognitivist and empiricist approaches may be found in other standard texts (Beyer and Holtzblatt 1998, p.
Heidegger & software 6 Third, the essentialist model does not explain why users show allegiance to a given system that they may admit does not work as well as another available system. For example, when software was migrating from character-based to graphical user interfaces (GUIs), many users persisted in using character-based systems, even though they may have simultaneously believed that there was some advantage in GUI systems. Users even engage in what are called “religious wars,” that is, extolling the virtues of a given system while denigrating an alternative. The software community reflects this in a phrase describing someone who has become emotionally argumentative: “He went all Mac-versus-PC on me.” The prevailing usability model considers users, software, and the nature of interaction between them to be entirely defined in a static manner. That is, the capabilities of the software are viewed as fixed, target user tasks are predefined, and hence the “usability” of the software is, in principle, a stable, demonstrable quantity. This would lead to the expectation that users would switch software systems with little hesitation, purely on the basis of functionality. It would not predict “religious” affiliation. One might argue that these kinds of concerns are unimportant, that they display nothing more than interesting fringe use of computers. However, I believe that questions about whether software is fun, whether it helps people to feel at home when they use computer systems, and whether it inspires passion are not trivial concerns; rather, they point the way to conceptions of software use that promise to enrich users’ experiences.
Heidegger and Computer Software 97; Hackos and Redish 1998, pp. 6-8; Nielsen 1993, p. 26; Raskin 2000, Chapter 4).
Heidegger & software 7 I propose that we may be able to form a richer conception of software usability by following some of the paths laid by Heidegger. Specifically, I believe that Heidegger can help us to think about how users experience software as world-disclosing. These insights suggest ways that usability researchers may understand software interaction better. Heidegger’s work has influenced a few computer scientists and software designers. Hubert Dreyfus employed Heidegger to argue the non-symbolic nature of human cognition, in contrast to classical artificial intelligence approaches (Dreyfus 1992). Although some of Dreyfus’s arguments are not applicable to modern AI, which is more interested in computer capabilities than in mimicking human intelligence, his criticisms of symbolic systems are still relevant. Michael Heim used a Heideggerian framework to examine how our experience of language is changing, both affecting and affected by the shift to writing via computer word processing software (Heim 1999). However, that work focuses more on language in a shared social environment than on use of (possibly non-linguistic) software in general. Terry Winograd has been inspired by Heidegger to argue that systems designers should make their software objects function more like real tools, and he calls for usability engineers to focus on contextual analysis of users in their real environments (Winograd 1995). Winograd’s assessment of Heidegger shares Dreyfus’s emphasis on non-symbolic cognition, and focuses specifically on the understanding of software tools in shared language-based communities. Flores et al describe how such an approach was used in the design of a collaborative software system that allows people to engage in various linguistic acts such as sending messages, scheduling tasks, and making commitments (Flores et al
Heidegger & software 8 1988). They argue that the system has an “ontology,” consisting of the software elements and their relations; the tasks performed in the system are modeled after Austin’s and Searle’s accounts of performative speech (Austin 1962; Searle 1969). Although this work is important and informative, I believe we may extend a Heideggerian perspective to software at a more fundamental level. First, Flores et al present a model limited to performance of social language tasks; this is both subject to some constraints of a task-oriented analysis, and is too narrow to include non-linguistic software use. Second, although they are correct to point out that software design creates an ontology, their presentation does not extend to the more important “fundamental ontology” of software (to borrow a phrase from Heidegger). That is, their account does not illuminate the use of software per se.
Software Worlds The critical concept missing in the essentialist usability analysis of software use is Heidegger’s notion of “world.” Heidegger described people as existing in a way that is fundamentally oriented towards and constituted by their everyday interactions with the surrounding world (Heidegger 1996 (1927)). The world reveals itself to humans both as an immediate ground for human activity (presenting itself as “ready-to-hand” in the standard translation), and as something that may be considered in reflective thought (“present-at-hand”). In turn, it is the fact that humans are capable both of direct action and self-reflection that allows us to have the concept – and hence the experience – of
Heidegger & software 9 world as we do. Thus, our concepts of human existence and of the world in which we exist are mutually determined and inseparable.2 Heidegger’s “world” is an opening for existence that is in parts created by, constitutive of, and shared across a human society. It is the space in which a community’s way of being is manifest. In early work, Heidegger focused on theoretical exposition of what such “being” is (Heidegger 1996 (1927)); in later work, he attended to the cultural determinants of such existence (Heidegger 1977 (1954)-b). In Being and Time, Heidegger outlines four senses of “world:” the collection of all that exists; the ground upon which things exist; the shared space in which human existence occurs; and the a priori structure of such shared space (Heidegger 1996 (1927), pp. 64-65). He is principally concerned with the third and fourth of these, and specifically uses “world” in the third sense (pp. 65f). In that account, a world comprises the surroundings in which people exist through immediate, prereflective experience and action. My claim is that computer software creates worlds in a variant of Heidegger’s sense. These worlds present surrounding environments in which we find objects, objects that we use either fluently and prereflectively or that we find strange and noneffective and that lead us to engage in reflective thought. If one wishes to have a schematic, we might say that software can present objects that are ready-to-hand or present-at-hand, depending upon circumstance and experience. This subsumes the cognitivist account, as task decomposition can be attempted explicitly using present-athand objects, or performed fluidly with ready objects. This account radically extends our understanding of why people may be passionate about software, why they may derive joy or pain from interacting with it, and 2
. My account owes a debt to Dreyfus’s exegesis of Heidegger (Dreyfus 1991), although my “engineer’s” use of
Heidegger & software 10 why they may form attachments to it. When software is considered as establishing a world in Heidegger’s sense – a place in which people live and in which their existential natures are exposed, affected, effecting, changing, and being challenged – then we are not surprised to find that the range of human responses to software that is broader than the cognitivist account would predict. I do not claim that these notions map perfectly to Heidegger’s concepts. First, my account dramatically extends the notion of world, from that of a primarily unitary shared space in which the existence of individuals and a culture occurs, to a set of many spaces presented by a technological medium. Second, this concept of world requires a new account of the social construction of such spaces; software is presented as the product of human engineering, not as the space in which cultural existence is revealed. Third, it is difficult to know how to make sense of the ontological nature of a world that is largely formed by software creators and then secondarily revealed through the actions of software users. Fourth, because any given piece of software might be regarded as unchanging in its essence, Heidegger’s account of human meaning as revealed through existence in a world that we change would clearly require radical translation to apply to software. I believe these problems are less significant than they may seem and that Heidegger’s account of world is flexible enough to accommodate software, but such arguments are not necessary to establish an understanding that is significant for usability work.
The Importance of Temporality
Heidegger departs from Dreyfus’s presentation and goals. The interpretation here is mine.
Heidegger & software 11 The final step in constructing this understanding is to incorporate Heidegger’s notion of temporality. In Heidegger’s exposition, to say that human existence is temporal is to note two integrated features of existence: first, that we exist in an attitude of care, i.e., future-oriented projection towards occurrences of importance, and second, that we do not display static natures but rather that our existence is a dynamic process. “Temporality” reflects future projection as an essential part of human existence, contrasts “time,” which is merely a concept of some linear dimension along which static events occur. Temporality is integral to human existence as such, whereas time is a concept from the ontology of physical things. I propose that the essential attributes of temporality are present in human engagement in software worlds. When people use software, they gradually gain experience that leads them to use it better, to express themselves with it in new ways, and possibly even to think about their activities – and hence themselves – differently (cf. Heim 1999 for an account of this with respect to word processing). These experiences of activity and change both reflect the temporal aspect of human existence and inform our expectations and concerns about ourselves in the future. In other words, when we enter software worlds, we are not merely engaging in solving some specific task using a static tool – as in the prevailing account of software. Rather, we are engaging in a process that will unfold over time and in which we may project ourselves into a future where, in the context of a particular software world, we behave and even conceive ourselves differently exactly because of the software we use. Even if limited in scope, good software opens new possibilities for existence, and we exist differently because of those possibilities.
Heidegger & software 12 This account deepens even our tool-based account of software; if I am a writer, then word processing software holds promise to extend my existence-as-a-writer. It also adds another dimension to understanding non-cognitivist uses of software. The game player is projecting herself into a future in which she hopes to be someone different, to be a “master” player. The advocate of a particular operating system is not merely argumentative; rather, he is expressing the very real value of a future in which he expects to learn, grow, and work as he uses a given system that has provided a home for many years.
Directions for Usability What does this account imply for usability engineering? It suggests that the taskoriented account of computer usage is inadequate – not incorrect, but incomplete. As systems designers, we must understand that our work not only addresses tasks and logical processes, but also creates spaces in which portions of people’s lives are shaped in important ways. It also suggests that an essentialist account of software as a static, disembodied collection of data and algorithms is too narrow. If software defines worlds, then it only exists in interaction with people, and such uses can never be captured as a static definition. Finally, this account suggests that we need to devote more attention to understanding how people interact with software as an unfolding process, how they conceive themselves in trajectories of change and growth. These new concepts do not replace the engineering framework of software design, but I believe that they can help
Heidegger & software 13 us to find a way towards better, more humane, and ultimately more interesting computer software.
Heidegger & software 14 References Austin, J. L. How to Do Things with Words. 2nd ed. Cambridge, MA: Harvard University Press, 1962. Beyer, H., and K. Holtzblatt. Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufman, 1998. Dreyfus, H. L. Being-in-the-World: A Commentary on Heidegger's Being and Time, Division I. Cambridge, MA: MIT Press, 1991. Dreyfus, H. L. What Computers Still Can't Do: A Critique of Artificial Reason. Cambridge, MA: MIT Press, 1992. Flores, F., M. Graves, B. Hartfield, and T. Winograd. "Computer Systems and the Design of Organizational Interaction." ACM Transactions on Office Information Systems 6, no. 2 (1988): 153-172. Hackos, J. T., and J. C. Redish. User and Task Analysis for Interface Design. New York: Wiley, 1998. Heidegger, M. "Building Dwelling Thinking." In Basic Writings, ed. D. F. Krell, 323-339. New York: Harper & Row, 1977 (1954)-a. Heidegger, M. "The Question Concerning Technology." In Basic Writings, ed. D. F. Krell, 287-317. New York: Harper & Row, 1977 (1954)-b. Heidegger, M. Being and Time. Translated by J. Stambaugh. Albany, NY: SUNY Press, 1996 (1927). Cited with German (7th edition) pagination. Heim, Michael. Electric Language: A Philosophical Study of Word Processing. 2nd ed. New Haven: Yale, 1999. Nielsen, J. Usability Engineering. San Francisco: Morgan Kaufman, 1993. Raskin, J. The Humane Interface: New Directions for Designing Interactive Systems. Reading, MA: Addison-Wesley, 2000. Schneiderman, B. Designing the User Interface: Strategies for Effective HumanComputer Interaction. 3rd ed. Reading, MA: Addison-Wesley, 1998. Searle, J. R. Speech Acts: An Essay in the Philosophy of Language. Cambridge: Cambridge University Press, 1969. Winograd, T. "Heidegger and the Design of Computer Systems." In Technology and the Politics of Knowledge, ed. A. Feenberg and A. Hannay, 108-127. Bloomington: Indiana University Press, 1995.
