CHAPTER VII. OVERVIEW - WHAT HAVE WE ACHIEVED AND WHERE DO WE GO NOW? What have we learned? In this chapter we give a summary of our approach to understanding human use of computers, and make some notes about our approach, so that you can take it further if you wish, when you meet real-life applications in the future. 1. SUMMARY 1.1 Summary of Chapters The starting question was with what attitude we should approach HUC. The decision was made to seek to understand everyday use of computers, rather than limited aspects thereof. So a few cases were examined, including one of which the analyst (this author) had intimate everyday knowledge. This led to: » Use of computers is human functioning, not just technical. This analysis revealed several different types of thing in each aspect, which led to distinguishing several human functionings. Overall human use of computers is constituted of several human functionings, bound up with each other: » HCI - human-computer interaction » ERM - engagement with represented meaning-content » HLC - human living with computers. This put us in a position to seek deeper understanding of each. First we noticed that each exhibits diverse aspects. The philosopher Herman Dooyeweerd has studied aspects of everyday experience, and we have used his suite of 15 aspects as a template to help us understand each of these in turn: » Quantitative - » Spatial - » Kinematic - » Physical - » Biotic (Organic) - » Psychic - » Analytic - » Formative - » Lingual - » Social - » Economic - » Aesthetic - » Juridical - » Ethical - » Faith - These are aspects of everyday reality of human living and working. They are spheres of meaning and law. Chapter II concluded with a discussion of what aspects are, and especially their ability to help us understand normative issues (good, bad, quality, etc.). In chapter III we examined HCI in more detail. We looked at each aspect of the user's experience of interacting with the computer especially its user interface (UI). We found some aspects which many texts overlook, such as the vision or deep beliefs that underlie the design of HCI, and the notion of a generous UI. This view can be very useful if gaining a full evaluation of, for example, a website. The difference between distal and proximal UI was discussed. In chapter IV we examined ERM in more detail. Represented meaning is mediated via symbols of the HCI, but these include much more than merely things on screen. The main quality criterion of ERM is to do justice to the topic as well as the user, and this can be understood in terms of every aspect. As an example of this, we looked in detail at a computer game. In chapter V we examined HLC in more detail. Human living with computers concerns the impact of IS in our lives, and with the issues of overall success or failure. This is tricky because of indirect and unexpected and long-term impacts, but Dooyeweerd's aspects can again prove useful. Each normative aspect can help us understand something of success and failure, such that an IS might bring benefits in one aspect but detrimental impact in others. The visual device of the aspect tree can help us gain an overall view. 1.2 Summary of Aspects We can summarise the aspects of each of HCI, ERM and HLC. We use the example of a medical database, holding details of patients, their encounters with medical staff, problems, treatments given, etc. Quantitative - HCI: Amount of white, red, blue, etc. on screen; number of windows; number of buttons; number of triangles on screen; ... ERM: Number of patients in DB; number of problems of current patient; amount of treatment given; ... HLC: Computerized medical records allow doctors to see more/fewer patients in the day; ... Spatial - HCI: Layout of buttons and windows on screen; size of windows; ... ERM: Height of patient, as recorded in DB. HLC: Size of doctor's desk and space taken up with computer and mouse; doctor is further away from patient because of computer; ... Kinematic - HCI: Movement of mouse and mouse pointer; ... ERM: HLC: Doctor has to keep turning away from patient to look at things on computer; ... Physical - HCI: Mouse doesn't work very well on smooth surface of desk; keyboard keys are sticky; ... ERM: Weight of patient, as recorded in DB. HLC: Power cuts! Biotic (Organic) - HCI: Mouse is just right size to fit the hand; keyboard keys are just right size for fingers. ERM: Health of patient (the various diseases the patient might have) as recorded in DB. HLC: Peering at screen all day gives eye-strain. Psychic - HCI: Doctor can see screen, pushes mouse around and operates keyboard; colours on screen; ... ERM: Mental and cognitive health of patient as recorded in DB. HLC: Using the medical record system makes doctor angry/happy. Analytic - HCI: Doctor can distinguish symbols on screen. ERM: Patients are distinguished from one another by identification number; drugs are distinguished from one another by codes; ... HLC: This doctor is known as the only one in the practice who is angry/happy with the medical record system; ... Formative - HCI: Format of screen, with menus at top, then toolbars, then information about patient in two columns; ... ERM: Using DB meaning-content (information) to trying to diagnose the patient's problem; (information about) the patient's regime of treatment; ... HLC: Trying to persuade patient to give up smoking; planning the next day's work; ... Lingual - HCI: A table of numbers on screen: can doctor understand what they mean? ERM: (Information about) a letter sent to hospital on patient's behalf; ... HLC: Questioning the patient and giving advice; phoning the hospital; ... Social - HCI: Logo of medical practice on the screen; the icons on screen adhere to agreed usability standards; ... ERM: (information about) Patient's relations in family etc. HLC: Doctor is friendly (or not) to patient; roles of doctor and patient with respect to each other are assisted by medical record system; ... Economic - HCI: Wasted space on screen (or not); download time of patient's record or other web pages; ... ERM: (information showing that) doctor's diary is getting full, making it difficult to fix next appointment; (information about) cost of treatments; ... HLC: Patient appointments are only 7 minutes long; treatment that the patient needs costs a lot and drains the practice budget; ... Aesthetic - HCI: Style of UI, including whether colours pleasant or not; ... ERM: Information about patient in DB is consistent. HLC: Using the medical record system is fun/boring. Juridical - HCI: The right information is present on screen; affordance; ... ERM: Information presented on screen is accurate; ... HLC: The medical record system helps/prevents doctor giving appropriate medical service to patient; ... Ethical - HCI: A lot of care went into design of UI, so that it is extremely easy to use (or not!). ERM: (information about) free medical services for patient; ... HLC: Patient cannot afford treatment, so doctor offers to pay for it; medical record system slows down consultations but doctor is (not) willing to work extra time to help patient; ... Faith - HCI: The vision of the designer of the medical record system comes through in the style of UI. ERM: (information about) religion of patient HLC: The doctor believes in the medical record system (or not). Note: Those are just fictitious, imagined examples, and do not describe any known system. {*** The student should take the above template, and apply it to some information system of their choice, such as a website or a computer game. ***} 1.3 Benefit of This Approach Being able to distinguish HCI, ERM, HLC as three types of multi- aspectual functioning in this way has several benefits. It can help us separate out different issues in HUC, but more specifically: » It explains why something that is easy to use or technically advanced might still fail to bring benefits in use, and why supposedly old-fashioned software like legacy systems can bring real benefits. » Recognition of ERM separate from HCI, HLC clarifies how to deal with virtuality. In particular this approach gives us a framework by which to understand the paradox of virtual objects like powerful spells from MUD (multi-user dungeon) games being bought and sold on eBay. Both ERM and HLC are real multi-aspectual functioning. » We have a clear basis for differentiating what the software is intended for from what we actually use it for each time. » It can be useful in helping us tease apart the issues that emerge in changes in use of software. » It can be useful in practice in helping to guide IS development, and enriching it by employing aspectual analysis of all three of HCI, ERM and HLC. » It can be useful in the formulation of useful research questions and even whole research programmes in HUC, in that it urges us to consider all three, even though we might focus on one, lest our research becomes confused. It warns us that attempting to understand HCI in relative isolation from ERM and HLC might result in flawed, or at least narrowed, research that generates unsustainable results. This approach is very different from traditional approaches to human factors. The reader, especially the one who knows something of these approaches, might ask whether our approach here is valid, whether it has any benefit over traditional approaches, and how it links to traditional approaches. It is not necessary to abandon traditional approaches, but rather they can be situated with this approach. 2. OUR APPROACH: EVERYDAY, NOT THEORETICAL Why have we designed the whole module around Dooyeweerd's aspects? Because it allows us to take an everyday approach to HUC, rather than being limited to a theoretical approach. Traditional approaches to human factors, whether HCI or HLC (ERM is seldom discussed), begins with the technology and then tries to move into more human issues. In HCI this usually means thinking in psychological terms. In HLC this usually means thinking in social terms, with a further widening from the 'micro' perspective of individual to the 'macro' perspective of impact of IS on society as a whole. But the psychological and social are only two of the fifteen aspects above, which means that traditional approaches are very narrow. (In fact, some other aspects are partly recognised, but the tend to be 'squeezed' into (or reduced to) these two aspects, which rather limits and distorts thinking about them.) The problem is that traditional approaches have taken a scientific or theoretical approach to understanding human use of computers, which first tries to develop theory and then tries to 'apply' that theory. The approach taken here is very different. It takes an 'everyday' approach, in which the whole diversity of everyday experience is acknowledged in a non-reductionist way. It was precisely this that Dooyeweerd tried to do in his philosophy: to find a way of understanding the diversity and coherence of our everyday experience. 2.1 Problems with Theoretical Approaches The problem is that traditional approaches have taken a scientific or theoretical approach to understanding human use of computers, which first tries to develop theory and then tries to 'apply' that theory. The approach taken here is very different. It takes an 'everyday' approach, in which the whole diversity of everyday experience is acknowledged in a non-reductionist way. The problem with theoretical approaches is as follows. For example, ergonomics, Davis' [1986] Technology Acceptance Model (TAM) and Latour's [1987] Actor-Network Theory (ANT) each raise and address important issues. But such ways of understanding use focus on a narrow range of issues. This is not a deficiency in them, because most do not claim to do more than that, but it is a danger. The danger is that that very focus can lead researchers and practitioners to assume that nothing else is meaningful, and so other issues become downplayed, suppressed and ignored. For example, ergonomics downplays the higher levels of HCI, and completely ignores issues of benefit in use. TAM is much wider, purporting to cover both ease of use and usefulness, but it tends to do so in a managerial way. ANT claims to escape this, and especially to focus on both micro and macro levels, but can downplay the normative difference between benefit and detriment. The same tendency to divert attention away from some important issues attends theoretical frameworks in any area. Information security is not an area that is covered in this module; that is left to other modules. But security experts Bruce Schneier and Niels Ferguson understand the problem of narrow approaches. As they say in the preface of their book Practical Cryptography [Ferguson and Schneier, 2003], "Arguing about whether a key should be 112 bits or 128 bits long is rather like pounding a huge stake into the ground and hoping the attacker runs right into it. You can argue whether the stake should a mile or a mile-and-a-half high, but the attacker is simply going to walk around the stake. Security is a broad stockade: it's the things around the cryptography that make the cryptography effective." In development of IS to support business tasks the knowledge that must be elicited is multi-faceted [Jacob and Ebrahimpur, 2001,p.78]: "The majority of the managers have a long history in the company and successful leadership of projects is dependent on long tenure since the preference is for managers with a generalist competence profile. In the words of one interviewee: One needs to have as broad a knowledge base as possible. It is the outer parameters that one must have knowledge about." Though loosely defined, 'outer parameters' indicates facets that are often overlooked. In interdisciplinary applications of IS 'outer parameters' abound. The 'everyday' of both practice and research is rich and full of surprises arising from 'outer parameters'. If we are to understand any area of information systems, then we must be able to cope with the diversity of the everyday and be open to surprises as they arrive. Theories and theoretical models can provide insight into specific issues, but they should never be allowed to divert attention away from other important issues. For this reason, for example, cost-benefit analysis is grossly insufficient as way of understanding IS use. 1.2 Everyday Approach to Understanding The type of understanding sought in this work is that of what philosophers have called the lifeworld, or 'pre-theoretical' or 'naïve' experience (which are all used here almost synonymously with 'everyday' without any negative connotation). Theoretical knowledge has been made explicit. A lot of everyday understanding is intuitive, cultural, embodied in aspiration and attitude, much of which cannot be made fully explicit. This module has sought to respect the importance of all such things in understanding HUC, and to be sensitive to such things in the everyday experience. As far as this author is aware, such an approach to understanding is not common in most IS research. An everyday approach to understanding HUC (or any other topic) must take seriously the characteristics of the lifeworld, or everyday knowledge. These are discussed in chapter I of Basden [2008], and may be summarised as follows: » Everyday knowledge is background understanding that is shared by society, or at least a community of people; it allows people to communicate. Even science relies on it. The kernel meanings of Dooyeweerd's aspects are grasped with the intuition, and constitute a background understanding of reality right across the world. » Everyday experience is diverse in terms of what is meaningful. As mentioned above, if we look at it using a theoretical approach, we focus on only one sphere of meaning and ignore the others. It is like looking through a lens, and failing to see things outwith the focus of the lens. Dooyeweerd's aspects provides a basis for seeing this diversity. » Everyday experience involves a "pre-given reality with which we must cope" [Schutz and Luckmann, 1989,p.1]. This implies we should enable the researcher and practitioner to 'listen' to the world of their area as it presents itself to them, without trying to force it into a priori conceptual structures they bring to it. What some call subjectivist ways of looking at IT/IS can have difficulty here. Dooyeweerd's aspects are 'pre-given reality' (though in a different deeper way than Schutz and Luckmann and others might expect). » Everyday experience is engagement. A theoretical attitude involves standing at a distance from the world, over against it, as it were. Dooyeweerd's understanding of how we live within the aspects involves direct engagement with the world, rather than standing over against it (which Dooyeweerd called a Gegenstand relationship). This is why Winograd and Flores' work was important, but it can be enhanced by linking it with our approach. » The everyday lifeworld exhibits meaning and normativity. Many theoretical approaches ignore these, and try to understand everything in terms of mechanical causality or personal interpretations that are, ultimately, arbitrary - both of these approaches lack meaning and normativity. The approach we have taken here focuses on meaning and normativity; this has been made possible in a systematic way because Dooyeweerd's aspects are spheres of meaning and normativity, as well as being categories. Dooyeweerd's aspects provide a convenient way of separating out issues that need to be kept distinct, but that is not the main reason why we have designed the whole module is designed around Dooyeweerd's aspects. Dooyeweerd intended his aspects to be precisely aspects of the everyday experience. It is for this reason that we have used them. 3. PHILOSOPHY It will be noticed that we have referred to philosophy - a topic that most people think is very highbrow and abstract, which only a few people can understand. But you, the student who has been following this module, have thereby been led into thinking philosophically. It wasn't so hard, was it? Philosophy is concerned with deep questions, like what is the nature of the things we come across? We have looked at the nature of human use of computers, and its three components: HCI, ERM, HLC. Philosophy is concerned with diversity and unity. We have found a way to understand the diversity of what we experience, and its unity as IS use. Philosophy is interested in what is necessary for things to be or occur as they do. HCI, ERM and HLC are all necessary in human use of computers, and the aspects are necessary in each. Philosophy helps us expose assumptions. We have exposed assumptions about what is important in HUC. For example, we have introduced the third issue of ERM as well as HCI and HLC. For example, we have exposed the Western worldview, by which HCI is judged or designed. The main reason we have been thinking in these ways is in order to furnish you wish conceptual techniques and tools for use in practice. The main one is the suite of aspects, with which you can ensure you do not overlook any major issues that are important. But if this slant towards philosophy has interested you, then you can take this further. First, it is intended to offer a philosophy module as a Final Year Option from September 2009. Second, you can read about the nature and role of philosophy in chapter I or Basden [2008] ('Philosophical Frameworks for Understanding Information Systems') and about Dooyeweerd's philosophy in chapters II and III. Most of this module has been taken from chapter IV of that book. The third way is to look at The Dooyeweerd Pages website. This is a site intended for explanation and exploration of Dooyeweerd's philosophy, and is continually being amended or added to. It is held on: http://www.dooy.info/ The philosophy of Dooyeweerd is rather different from most, because it is based on very different presuppositions that underlie most Western philosophy. We have not looked at these presuppositions, but Dooyeweerd called them ground-motive, four of which have driven Western thought since the time of the ancient Greeks. You can find out about them, if you wish, in chapter II of Basden [2008], or on the web page: http://www.dooy.info/ground.motives.html But if all you want is to understand the aspects more, look at http://www.dooy.info/aspects.html I wish you every success with your understanding and use of what we have covered in this module. Andrew Basden, 20 September 2008, 3 September 2009. 20 September 2010.