P. 1
When the chips are own: Social and technical aspects of computer failure and repair

When the chips are own: Social and technical aspects of computer failure and repair

|Views: 201|Likes:
Published by quaylem
This study uses transcripts of interactions recorded between computer technicians and users to investigate the activities related to attribution and problem solving in the context of institutional computer support. We explore how achieving consensual attributions (in the context of diagnosis) is integral to managing moment-to-moment
social demands, and how the outcomes are subject to negotiations about the definition of the problem and the nature of the social contract between interactants. We also show that these immediate interactional interests are subject to the longer-term ‘moral careers’ of the participants which are themselves subject to the roles, obligations, and
concerns that participants have by virtue of their social and institutional positions.
These immediate and longer-term layers of concern are interrelated and contingent,
and all are important elements of how consensual attributions are socially accomplished in this context.
This study uses transcripts of interactions recorded between computer technicians and users to investigate the activities related to attribution and problem solving in the context of institutional computer support. We explore how achieving consensual attributions (in the context of diagnosis) is integral to managing moment-to-moment
social demands, and how the outcomes are subject to negotiations about the definition of the problem and the nature of the social contract between interactants. We also show that these immediate interactional interests are subject to the longer-term ‘moral careers’ of the participants which are themselves subject to the roles, obligations, and
concerns that participants have by virtue of their social and institutional positions.
These immediate and longer-term layers of concern are interrelated and contingent,
and all are important elements of how consensual attributions are socially accomplished in this context.

More info:

Published by: quaylem on May 26, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/01/2011

pdf

text

original

ARTICLE IN PRESS

Interacting with Computers xx (2006) 1–18 www.elsevier.com/locate/intcom

When the chips are down: Social and technical aspects of computer failure and repair
Michael Quayle *, Kevin Durrheim
School of Psychology, University of kwaZulu-Natal, Private Bag X01, Scottsville 3209, South Africa Received 25 April 2005; received in revised form 12 March 2006; accepted 14 March 2006

Abstract This paper explores computer failure as a social event by examining recorded interactions between computer users and help-desk consultants (technicians). It was found, first, that the nature of a failure was negotiated between participants rather than being simply technically evident. Failure was defined from users’ perspectives, in relation to what they were trying to achieve, rather than according to technical parameters. Secondly, negotiations of failure had social consequences for both users and help-desk consultants. Both avoided being seen as incompetent and actively defended their social standing. Thirdly, such social issues sometimes took precedence over technical and practical ones. The implications for HCI theorists and practitioners are twofold: firstly, failure should be accepted as a regular part of computer use in which human–computer interaction continues even though the interface may be non-functional. Secondly, the management of failure could be better addressed if technicians were trained in social as well as technical intervention skills. q 2006 Published by Elsevier B.V.
Keywords: HCI; Human factors; Reliability; Help-desk; Social aspects; Dependable computing; Computer failure

1. Introduction This paper explores a commonplace aspect of computer use that is a frequent vexation to users—computer failure. Anecdotal evidence suggests that almost anyone who uses computer technology on a regular basis experiences failure with some degree of regularity. A survey undertaken by PCWorld magazine, with approximately 16,000 respondents,
* Corresponding author. Tel.: C27 33 2605016; fax: C27 33 2605809. E-mail address: quaylem@ukzn.ac.za (M. Quayle).

0953-5438/$ - see front matter q 2006 Published by Elsevier B.V. doi:10.1016/j.intcom.2006.03.003

ARTICLE IN PRESS
2 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

found that, in July 2000, 56.6% of Personal Computers in American homes had at least one ‘problem’ (Jones, 2000). Even though it is not perfectly clear what is meant by a ‘problem’, these figures make it clear that computer failure is a common experience for the average user. Dvorak (2003) quotes Bill Gates, Chairman of Microsoft, as saying that 5% of Windows machines ‘crash’ twice a day. Dvorak uses this rare statement of reliability from Microsoft to build a flimsy, although not implausible, argument to ‘estimate that there are a minimum of 30 billion Windows system crashes a year’ (p. 1). If Dvorak’s figures are credible, then the theoretical average PC ‘crashes’ approximately once a week. This figure does not seem unreasonable when weighed against personal and anecdotal experience. The BBC News quotes Symantic, an internet security company, as estimating that ‘nine out of ten [users] are regularly annoyed by slow, crashing machines’ (BBC News, 2003a). Other studies have shown Windows NT and 2000 machines have ‘abnormal reboots’ (e.g. after a blue screen) approximately once a month on average (Simache et al., 2002). It seems that failure is a common (and possibly unavoidable) aspect of interaction with computers and therefore deserves analytic attention. Even though modern HCI is often described as ‘user-centred’, the experience of computer failure has been vastly under-investigated in the HCI literature in relation to its empirical frequency—in spite of the fact that most HCI researchers, in their roles as users, probably experience failure quite frequently. Of course, researchers have studied the issue of computer reliability in great detail, where reliability is generally conceptualised as an absence of programming mistakes, errors and bugs and the greatest possible degree of system flexibility and durability. The broad project has been to improve design practices to limit error, and therefore to increase reliability to the greatest extent possible (e.g. Carroll, 1997; Lewis and Norman, 1995; Neumann, 1993; Norman, 1990). In this mode of research, failure can be conceptualised as something that happens when reliability does not—in other words, computer failure is understood as a primarily technical affair. Continuing to understand failure as an empirical and objective occurrence allows two misconceptions to endure: the first is that computer failure is a phenomenon that will be eradicated over time by the rigorous application of sound design principles and is therefore not worth investigating in its own right. For example, Nickerson (1986) asserted that ‘increasing reliability’ is a trend of ‘modern’ computers. However, in spite of great advancements in design techniques and programming practices, the experience of computer failure is still commonplace. Nearly two decades later, computer technology shows few signs of outgrowing failure. There are clearly limits to software and hardware reliability, particularly in low-cost and increasingly complex systems such as the personal computers used by the majority of computer users (Enfield, 1987; Lieberman and Fry, 2001). Within these constraints, it is clear that users of consumer computer products will still experience failure on a regular basis for the foreseeable future (Das, 2003; Siewiorek et al., 2004). The second misconception is that real-world computer failure is a temporary hiatus or intermission in a user’s interaction with a computer system; that interaction is ‘paused’ until the computer system is returned to functionality and HCI can continue. Although this may be true if the observer’s horizons are limited to interaction with a functioning user interface, the interaction with and around the computer often continues after a failure—and often with higher intensity. To take two extreme examples, the BBC reports that one frustrated victim of computer failure pulled out a gun and shot his

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 3

malfunctioning laptop, while another threw his computer against a wall in exasperation (BBC News, 2003b). Although this is not ‘interaction’ as it is generally conceptualised in the HCI literature, these examples make it abundantly clear that human–computer interaction may continue even (and perhaps especially) when computer–human interaction fails. Nevertheless, computer failure, like reliability, is difficult to define or measure. It is tempting to define failure technically, by comparing actual system behaviour with a predefined blueprint of acceptable limits for system functionality, for example, in the IEEE/IFIP definition of failure as ‘a system not performing up to its specifications’. But users do not have access to any such blueprints of acceptable functionality, and increasingly often, such blueprints do not exist (Siewiorek et al., 2004). Subjectively, a failure occurs when a computer does not perform as a user expects or needs it to and there is an increasing realization in HCI literature that failure should be defined experientially (e.g. Murphy and Levidow, 2000; Siewiorek et al., 2004). Moreover, when more than one person is involved in a failure situation then the definition of ‘failure’ is not just subjective, but becomes a matter for negotiation, as will be shown in this analysis. The available literature shows that it is not unusual for end users to turn failure into a social event by approaching friends, family or colleagues for help with their computer problems. In fact, they are far more likely to approach people they know than the helpdesk experts whose job it is to help them (Bannon, 1986; Eveland et al., 1994; Lee, 1986; MacLean et al., 1990). For example, in a study of household computer-use, participants were provided with user-friendly computer equipment (a Macintosh), training, and easy access to a help-desk support line. Even in these ideal circumstances people were more likely to approach knowledgeable friends or family members for help than to call the helpdesk or, failing this, to nominate the knowledgeable other to call the help-desk on their behalf (Kiesler et al., 2000). Even though the empirical studies in the area show that that end users generally respond to computer problems and challenges socially, support is more usually approached in the literature as a component of information systems delivery (e.g. Flew and Kneath, 1994; Shah and Bandi, 2003), and—less often—as an aspect of HCI (Lundgren, 1998; Selber et al., 1996) and usability (e.g. Bharati and Berg, 2003). The bulk of help-desk and support research has focused on how help-desk functions can be aided (e.g. Abraham et al., 1991; Gonzalez et al., 2005; Kriegsman and Barletta, 1993; Marom and Zukerman, 2005; Sauter, 2004) by information support technologies, such as case-based and AI systems, although some (e.g. Rimmer and Wakeman, 1999) have cautioned that such systems may complicate rather than improve support functions. However, the few studies that have analyzed the work of help-desk consultants in fine detail have argued that technical support is inherently driven by social interaction rather than codified knowledge (e.g. Barley, 1996; Das, 2003; Pentland, 1992). For example, Das (2003) concludes that “the mix of moves exercised in technical support strongly depends on the formulation of tasks by those requesting support” (from abstract) and Pentland (1992) argues that the knowledge demonstrated by support technicians is a “situated performance rather than an abstract representation” (p. 527). The present paper extends these analyses to show how computer failure may be as much a social affair as it is a technical problem, and sheds some light on the kinds

ARTICLE IN PRESS
4 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

of interactional intricacies that end users may be faced with after requesting help from computer support staff. To do so, interactions between users and Help-Desk Consultants (HDC’s) will be analysed in detail.

2. Conversations about computer failures The present analysis rests on three simple maxims that will be familiar to discourse or conversation analysts: first, that ordinary talk is an indispensable means of managing social life, second, that speakers are generally held accountable for their utterances, and, third, that speakers choose their utterances with careful reference to their own social accountability (Edwards and Potter, 1993). It is widely agreed that the exact expression of an account matters and that one turn of phrase cannot be substituted for another without a subtle (or not so subtle) shift in meaning (e.g. Antaki, 1994; Edwards and Potter, 1993). On the contrary, language is flexible and a state of affairs may be explained ‘in virtually any manner’ if enough social support can be produced for its defence (Gergen and Gergen, 1980, p. 201). As a result, conversation cannot be considered as simple information exchange, because the way that people talk speaks volumes about their knowledge, abilities and social position. Gergen and Gergen (1980) argue that talk is a means of advancing one’s ‘moral career’ and social standing (after Goffman, 1959, 1961, 1963). People are heavily invested in the outcomes of their talk and neither their choice of words nor their silences are incidental to some underlying cognitive mechanism; people deploy language and make attributions to defend their social positions (Edwards and Potter, 1993; Heritage, 1988). The present study investigated talk in the context of computer failure with the goal of investigating the social functions of such talk. It will come as no surprise that interactions in failure situations are oriented to the technical task of troubleshooting the problem and returning the system to functionality. However, it will be shown that the social situation requires careful management by participants and that these social concerns are just as important as the technical goals of interaction, if not more so.

3. Method and data The study was performed with the assistance of the Information Technology department of a large university. The help-desk supported approximately 2500 computer users spread over four sites, although only one of these was sampled in this study. On the participating site approximately 800 academic, administrative, and student users were supported by five help-desk consultants (HDCs), one of whom was absent for the duration of the study. The other four (one male and three female) were willing participants in the study. All spoke English as a first language. Data were collected by shadowing HDCs on their rounds and tape-recording their interactions with users with the written consent of all participants. In 5 days of sampling,

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 5

16 separate interactions involving 21 different users were observed. Only one user did not agree to have her voice tape-recorded and, due to the fine-grained nature of analysis, this interaction has been dropped from the study. The tape-recorded data was transcribed in detail, resulting in a dataset of approximately 200 pages, or 87,000 words. For the sake of brevity, transcription conventions have been simplified in this paper unless the analysis calls for more detailed features to be reflected (see Appendix A for a notation key). 3.1. Strengths and weaknesses of the data This dataset is immensely detailed, as will become apparent in the analysis. The recording and detailed transcription of everyday interactions allows a fine-grained analysis of this slice-of-life, and enough data was recorded to get a detailed snapshot of how participants may talk about failure in this arena. However, 5 days worth of interaction in a single sphere of activity does not provide a firm footing to make sweeping generalizations about how computer failure is always done. Nevertheless, even though this study cannot make universal claims about computer failure, it can show that failure is an important element of computer use that can be an intense focus of particular forms of social life.

4. Analysis The following analysis makes fairly modest claims about computer failure. However, they are claims that substantially challenge the way that issues of reliability and failure are approached in the field of HCI. Briefly, the following points will be argued: 1. Failure is a matter for negotiation rather than simply a self-evident technical fact. 2. The negotiation of computer failure has other social consequences, particularly in terms of competence issues. 3. Social issues may take precedence over technical ones. While it is impossible in this analysis to argue that computer failure will always occur in similar ways, it is enough to show that social and technical issues overlap to a significant extent. 4.1. Negotiating failure Contrary to the expectation that computer failures should be obvious and technically self-evident, there were many instances where both the existence and the nature of a failure were the subject of negotiation between users and HDCs. Extract 1 demonstrates some of the difficulties of defining computer failure in an everyday social context. The interaction occurs between three protagonists, namely the user (U5), a help-desk consultant (HDC1) and the observer (OBS). The user has called in the HDC to investigate his complaint that the ‘computer is slow’. Lines 1–4

ARTICLE IN PRESS
6 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

occur in the user’s absence and the remainder of the extract is recorded with the user present. For the sake of brevity, extraneous talk has been omitted (represented by asterisks). Extract 1

The HDC, after running some tests, concludes that the machine is not slow (during and prior to lines 2–8) and later relays this conclusion to the user (line 8). The user disagrees, citing his personal experience (lines 11–12) and calling on the opinion of another HDC (line 14) who not only said that the computer is slow, but that it is ‘abnormally’ slow. This forces the HDC to review her diagnosis and agree that ‘it was slow going into Windows’ even though general operation was ‘fine’ (lines 16–17). She confirms the negotiated diagnosis by timing a reboot between lines 19 and 24. The cause of the ‘slow booting’ was later traced to a disconnected network cable that was delaying the booting process as the machine, configured to use Novell network services, unsuccessfully polled the network. In this case the user had not attempted to use network dependent applications and so the failure could be defined as ‘not really serious’ (line 20). The same technical problem with a different user, or even with the same user at a different time would have resulted in an entirely different failure definition. For example, if the user had attempted to launch an email client the failure may have been defined as ‘an email problem’ rather than ‘slow booting’. This extract demonstrates several important features of failure. Firstly, users define failure symptomatically rather than by cause. While this may seem obvious, since users usually lack the specialized knowledge to diagnose technical problems, it contrasts with the way that failure is defined if it is understood as the flip-side of reliability. Secondly, the

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 7

symptoms by which users define failure are established through task performance. For example, if a computer has a faulty internet browser, the latent fault will not be experienced as a failure until the user attempts to browse the internet. Thirdly, the ‘final’ definition of failure is a matter of social negotiation. Of course, there are cases in which failure is undeniable and not subject to debate at all, such as a catastrophic hard-drive crash. At the other end of the scale there are failures so minor that users ignore or work around them. In every case failure is most usefully defined subjectively as it impacts on the user’s experience of computer use. 4.2. Social aspects of failure In the failure situations observed it was evident that the apparently technical process of troubleshooting was subject to social concerns. 4.2.1. The sociality of troubleshooting Firstly, in real-life failure situations, there are few boundaries between troubleshooting and other types of talk. Take the following interaction as an example: Extract 2

Lines 1–7 are a continuation of an extended stretch of dialogue about computer viruses, how the computer may have been infected and how to detect and remove them. Notice how naturally the conversation switches to the weather and then to the effect of dampness on hairstyles. Although diagnosing and repairing a virus infection requires technical expertise, the participants’ interaction is clearly not limited to technical matters. Participants weave together technical and social talk in a way that defies simple analysis. This should remind us that treating the ‘social’ and ‘technical’ elements of failure-related interaction as if they are separate processes is an analytic convenience rather than a manifest reality.

ARTICLE IN PRESS
8 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

4.2.2. Different types of technical talk During analysis (Quayle, 2004) it emerged that the types of information exchanged in typical repair interactions can be roughly divided into two types. The first is socially safe operative information that can be freely exchanged. It usually concerns neutral, observable and physical symptoms and behaviours of equipment. The second is unsafe inspective information that concerns the characteristics and behaviour of participants and is approached by participants with caution. In general, operative talk offers no surprises. Information is freely exchanged by participants and it is used in unsurprising ways. Inspective talk, on the other hand, is very carefully managed. The following examples have been chosen to show how participants generally handle inspective talk with caution. 4.2.2.1. Needing a refresher course. Extract 3 is part of an interaction in which a supervising user has reported that users of a shared computer are unable to write files to a specific directory location. The computer has Windows 2000 installed, and at the time, the IT department was not yet officially supporting it. The problem was investigated with the user present and asking questions. This extract cuts into the exchange just after the HDC has successfully set up a new user account and modified the rights to solve the user’s reported problem. Extract 3

The first sign of inspective talk appears in lines 5–7. The user has just asked the HDC to confirm that the other users of the computer will be able to access the internet (and is thereby asking the HDC to defend her actions). The HDC’s response is not convincing, and the user tries to ask again. Notice how the repeated request is marked as both uncertain (by faltering talk) and certain, by the repeated use of ‘in fact’. However, the user is claiming certainty about his own experience with the computer, rather than in the realm of the current diagnosis (see Gill, 1998). This anecdotal construction is a way of simultaneously deferring to the HDC’s position as an expert (and thereby being cautious

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 9

with inspective talk) and to his own position as a user who is familiar with the machine and has a right to have his questions answered. In the context of supporting a machine running an unfamiliar operating system (Windows 2000), the expert is in a difficult position. She is an ‘expert’ in role, but not in knowledge. Notice how she marks this uncomfortable stance with phrases like ‘I think’ (line 2), ‘should’ (line 6) and ‘shouldn’t’ (line 11) to signal that she does not claim to have infallible knowledge about this operating system. Of course, one of the dispositional qualities expected of a computer expert is that they have extensive knowledge of computers. The HDC is very careful throughout the troubleshooting process to introduce information to specify that any apparent lack of knowledge or skill is confined to Windows 2000 by sporadically saying things like “I haven’t worked on this for a while’ and ‘I’ve forgotten exactly where the users are”. Then, in lines 13–15, she says “I need to put myself on a refresher course for 2000”. The way she phrases this does a lot of work on the types of dispositional attributions that the user can make. Firstly, by saying she needs to go on a course she admits that this is essential knowledge. Secondly, by saying she needs a refresher course she implies that she already has the required knowledge but that she could use some reminding. Thirdly, by saying she needs to put herself on a course she positions herself as someone who is intrinsically motivated to learn the necessary skills. Finally, she specifies that her ignorance is limited to Windows 2000 only. In the context of her role as an expert, the HDC’s obvious lack of knowledge about Windows 2000 is an unsafe social liability and her talk is oriented towards defending her expertise. The user’s response is accommodating. He says that he would ‘like to do a basic course in 2000’ (line 17). This is another utterance that does a lot of attributional work. By saying that he would like to do a course he positions himself as someone who, like the HDC, is eager to learn but as someone who does not ‘need’ to. His desire to do a basic course is most informative in relation to the HDC’s need for a refresher course to remember what she has forgotten. In contrast, he is positioning himself as someone who has never known, thereby affirming the HDC’s expertise. By the end of the interaction the user is positioned as someone who is ignorant but eager to learn, and the HDC is positioned as someone whose memory may be hazy but is nevertheless committed to reacquiring the necessary knowledge and skills. In this extract, the user and HDC edge very carefully around unsafe information— that the HDC is unfamiliar with the operating system—but do so cooperatively in the context of a successful outcome. The HDC actively takes on and defends her role as an expert, and the user cooperatively embraces his role as a supplicant to her higher knowledge. 4.2.2.2. ‘You’ve just got to be very careful’. The next example is not as cooperative. Extract 4 is situated in a search for a known virus. The infection has corrupted the installation of MS Office, which needed to be reinstalled. We join the interaction while the user and HDC are discussing the procedure of removing the virus and restoring the computer to functionality.

ARTICLE IN PRESS
10 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

Extract 4

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 11

At the start of this extract, the participants seem to be discussing purely technical aspects of the failure situation (lines 1–9). However, when the user asks a seemingly technical question about the source of the virus the HDC responds by implying: (1) that the user was not careful enough (line 11), (2) that the user failed to read and respond to relevant notices issued by the HDC’s department (lines 11–30), (3) that the user should save attachments to disk and scan them manually before viewing them (lines 32–41), and (4) that the user should delete ‘strange email’ in future (lines 41– 42). If computer use was a purely technical affair, these instructions would be unproblematic. However, there are several signs of uneasiness between participants in this exchange. Firstly, everyday conversation between equals is marked by regular turn-taking behaviour and long monologues are unusual. However, institutional talk is marked by role-related institutional asymmetries (see Drew and Heritage, 1992), which provides the basis for the HDC’s parent-like admonition. However, there are signs that the HDC is treading carefully. Firstly, her speech is marked as uncertain or tentative by the many elongations (signified by colons, e.g. elonga:::tion) and pauses. More importantly, the HDC often switches between first- and third-person grammatical constructions in quite a revealing way. She begins in the first person, saying “you’ve just got to be careful” (line 11, italics added) and “you know all those notices that we send out” (lines 11–12, italics added). However, she seamlessly switches to third-person construction, saying that ‘they send out those notices’ (lines 15–16) but ‘people.don’t realize’ (lines 16–19). This has the effect of distancing both the authoritative action of sending out notices and the irresponsible response of ignoring them. However, the HDC reveals that she using third-person grammar as a distancing device when she slips between the two in a single sentence, saying ‘people.just go and open it and then it infects your machine’ (lines 16–20). Clearly she is not talking about other peoples’ irresponsible actions at all, but those of the user. She further attempts to ameliorate the potentially injurious nature of her talk by

ARTICLE IN PRESS
12 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

speculating that the reasons for such irresponsible behaviour in general (and therefore the user’s behaviour in this case) may be ignorant negligence (‘they don’t realize’, line 19) rather than negligence pure and simple. By her efforts to ameliorate her criticism we can see that the HDC is oriented to the socially threatening nature of her talk. Remember that, on a technical level, the HDC was trying to give a simple piece of advice: to save attachments and scan them manually to avoid virus infections. However, we have shown that she was also oriented to deeper social implications of this simple technical statement. The user, who had so far been relatively silent, reacted to the HDC’s ‘advice’ by innocuously asking why the virus was not detected by the antivirus software (lines 46–48). The HDC initially tried to blame the user’s version of the antivirus software, but then realized that the software was current (line 50). She then made an argument that the virus infection occurred before the latest update occurred (lines 54–60), but in the process was forced to admit that the update may not have been provided timeously by the IT department. However, in order to make this argument, she was forced to admit that the antivirus software should automatically ‘pick up’ and disinfect the latest viruses. This obviously undermines her previous position that the user was negligent (in lines 11–42). The user’s seemingly innocent question in lines 46–48 forced the HDC to shift the blame away from the user towards the IT department. The important thing to notice here is the way that the participants requested, exchanged and disputed inspective information. Talk about the technical problem was not neutral: it had social implications for both the user and the HDC. Notice how the types of information offered by the user and the HDC, respectively tugged at the types of attributions that could be made and, more importantly, how each of these arguments offers a very different basis for determining responsibility for the virus infection. The user was working towards an attribution to a failure of the antivirus software while the HDC was leaning towards an attributional model that would locate responsibility for avoiding viruses with the user. Although the dialogue, at face value, was about technical issues, the way that participants oriented themselves was strongly oriented to the defence of social positions.

4.3. Social issues may take precedence over technical ones In the previous extract, effort could have been spared if the failure could have been discussed in purely technical terms. This would have involved both the user and the HDC accepting that the anti-virus software is not always reliable and that best practice would be to save attachments and run a manual scan before opening them. However, this would have forced the user to admit a certain amount of negligence and the HDC to admit that the antivirus software supplied by the IT department may not always be effective. The participants’ dialogical struggles reveal the importance of social issues in the apparently technical task of computer repair.

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 13

Another example of this can be seen in the following extract. This interaction takes place in a lengthy engagement where the HDC was called in to repair a faulty disk drive and was unable to find the cause of the problem.

By this point in the engagement the HDC finds herself in a dilemma. Although she is the ‘expert’, she has had no success in resolving the reported fault. She is left with task of defending her social standing without having resolved the problem when the user offers her an escape hatch by suggesting ‘It’s having a bad day’ (line 4). This explanation, if it were mutually accepted, would offer both the user and the HDC a chance to amicably end the engagement. However, it would also imply that the failure was due to factors that were both random and unfathomable. This explanation personifies the machine and endows it with moods—states of being that are unaccountable and de-coupled from cause and effect linkages. In other words, the user offered an explanation that depended on mutual acceptance that a rational attribution was not possible in that case. Instead of accepting this non-rational account, the HDC rather explains the actions she has taken to test various possible causes that could result in this effect (lines 7–12). She offers the alternative that they will ‘just have to shrug [their] shoulders and say [they] don’t know what caused it’ (line 15). She refuses to accept the user’s suggestion that cause-and-effect have somehow broken down and instead constructs the problem as something that could

ARTICLE IN PRESS
14 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

be understood if enough information were available. This reconstruction of the situation does not release her from the engagement (as the user’s suggestion would have), but it does protect her position as someone who could solve the problem if she only had enough data. However, she goes further and offers the alternative explanation, bolstered by her description of the troubleshooting process she has undertaken, that the problem is ‘gone now’ (line 18). This powerfully defends her expert status since, if the problem no longer exists, it is reasonable that even an expert would be unable to detect it. However, it does not release her from the social engagement as accepting the user’s explanation would have, because it implies that the problem could recur and it is her responsibility to discover the circumstances under which it could do so. Even though the HDC attempted to terminate the engagement at this point, the user did not validate her efforts to leave and she ended up working on this problem for a further 30 min without success before she finally managed to secure the user’s release from the social contract. In both of these extracts, participants negotiate the cause of a failure with more respect for their own social positions than for technical and practical aspects of the troubleshooting engagement. In Extract 4, the user and the HDC were sparring to determine the responsibility for the failure. In Extract 5, the HDC rejected a reasonable but irrational explanation at the expense of failing to terminate the interaction and consequently expended a great deal additional time and effort investigating the problem.

5. Conclusion and implications This analysis shows, firstly, that failure is a process that is engaged in by users. It cannot be considered a pause or hiatus in which they do other things while their computer is repaired. Although many problems may be solved by users on their own, this analysis (in line with previous research) shows that computer failure often becomes the background for a type of social life related to returning the computer to functionality. This form of social life is structured around technical concerns but, at the same time, is oriented to important social issues such as the allocation of blame and the defence of social standing. Since computer failure can become a social event it would be inappropriate to view it as merely a technical concern (as is so often the case in knowledge-management and AI approaches to help-desk management). This engagement with failure has three important characteristics that may be interesting to HCI theorists and practitioners: Firstly, failure is often defined through negotiation rather than being technically selfevident. Users and technicians negotiate the symptoms, what these symptoms might mean, and whether such symptoms require attention or not. Although there may be an objective technical fault at the root of a reported failure, the failure should be understood as a subjective and negotiable phenomenon related to the usefulness of the computer to the user (see also Murphy and Levidow, 2000; Siewiorek et al., 2004). For example, a single technical problem, such as a network cable being disconnected, could result in the ‘problem’ of slow booting for a user who only uses a word processor, or in a catastrophic failure for a user dependent on networked applications—the experience of a technical problem as a ‘failure’ depends on the user’s goals and needs. In other cases there was no such ‘objective’ basis for a reported fault,

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 15

and the nature (and even the existence) of the ‘failure’ was a matter decided on through social interaction and debate. Secondly, such negotiations of failure have important social consequences. Users may be blamed or held accountable for failure, even when they are victims of circumstance. At the same time, once HDC’s acknowledge a user’s description of circumstances as ‘a failure’ they become socially responsible for solving it by virtue of their institutional roles and responsibilities. Furthermore, maintaining their position of expertise requires that they avoid blame for the problem and provide convincing evidence of progress towards resolving the failure. The social situation of failure is carefully managed by participants, and talk about failure is carefully constructed to act on the social fabric. The user and HDC are acting from within their respective social positions, and their interactions are oriented to living-out and defending these. This is done in large part by the active use of talk to construct and defend particular social positions within the failure situation. Technical and social concerns are not distinct, and may be addressed simultaneously—often by the same utterances. Thirdly, social issues may (often) take precedence over technical ones. Users and HDC’s may resist definitions of failure that challenge their social standing in any way. Both users and HDC’s may be willing to sacrifice a great deal of time and effort (and sometimes forgo a solution) to avoid definitions of failure that are potentially injurious. The close attention that users need to pay to social issues (such as competence) in interactions with professional computer support staff may partially explain the common tendency reported in the literature for users to invoke official support channels only as a last resort. Although it is possible that there might be gender differences in the way that male and female HDC’s approach the social situation of failure (and the present study drew primarily on data from female HDC’s), the findings are sufficiently in line with prior research (cf. Barley, 1996; Das, 2003; Pentland, 1992) to suggest that the interactional features of technical support in failure situations are relatively universal. Since, failure can be an intensely social phenomenon it cannot be adequately considered to be a technical affair related simply to reliability. It is increasingly clear that, particularly in the low-cost and complex systems used by average users, improving reliability will not eradicate failure for the foreseeable future. (And, in any case, a user can perceive a failure anytime a system fails to respond as the user expects, even if the system itself is behaving according to specifications.) Therefore, an understanding of the situation of failure would be an important addition to a holistic understanding of the psychology and sociology of human–computer interaction. A user-centred computing philosophy should extend to all regular aspects of computer-use. An understanding of the experience of failure, and particularly of its social constraints, should inform the design of failure-support systems. In line with user-centred design philosophies, user-support systems should be designed to minimise both downtime, with its associated losses in productivity, and the negative social and emotional consequences for the user. As such, the management of computer failure may be an important new frontier in the design of interfaces and computer support systems. Given that technical support is often such a social process, user-consultants and technicians should be competent socially as well as technically. The experience of failure

ARTICLE IN PRESS
16 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18

for a user may involve negative elements such as blame and shame that, in general circumstances, require social defence. A user-centred philosophy of failure-support should provide social and technical ways of scaffolding this experience.

Appendix A. Notation conventions Notation conventions for all extracts U1, U2 etc. A user HDC: A help-desk consultant OBS: The observer Underline Emphasis . Pause Huhuh Laughter (U1: Ya?) A short interjection by another speaker CAPITALS Indicate that speech is LOUDER (inaudible) Marks inaudible speech (Probably) The probable transcription of hard-to-hear speech ((Comment)) Transcriber’s comments and additional explanatory information. *** A short section of transcript is omitted The detailed notation of Extract 4 records the following additional features (.) Short pause [2 s] Timed pause, in seconds / Marks a stutter or word correction without a pause, e.g. ‘he/he/help’ Ye:s Elongated sound. Two or three colons for very long elongations, e.g. Ye:::s. words-with-hyphens Rapid speech

References
Abraham, D.M., Spangler, W.E., May, J.H., 1991. Expertech—issues in the design and development of an intelligent help-desk system. Expert Systems with Applications 2 (4), 305–319. Antaki, C., 1994. Explaining and Arguing: the Social Organization of Accounts. Sage, London. Bannon, L., 1986. Helping users help each other. In: Norman, D.A., Draper, S.W. (Eds.), User Centred System Design. Lawrence Erlbaum Associates, Hillsdale, NJ. Barley, S.R., 1996. Technicians in the workplace: ethnographic evidence for bringing work into organization studies. Administrative Science Quarterly 41, 404–441. Bharati, P., Berg, D., 2003. Managing information systems for service quality: a study from the other side. Information Technology and People 16 (2), 183–202. BBC News, 2003a. ’Keep cool’ over computer hassles [On-line]. Retrieved 10-23-2003, Available from: news. bbc.co.uk/go/pr/fr/-/1/hi/technology/3204719.stm BBC News, 2003b. Odd mishaps cause computer grief [On-line]. Retrieved 10-23-2003, Available from: news. bbc.co.uk/go/pr/fr/-/1/hi/technology/3193366.stm

ARTICLE IN PRESS
M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 17 Carroll, J.M., 1997. Human–computer interaction: psychology as a science of design. International Journal of Human-Computer Studies 46, 501–522. Das, A., 2003. Knowledge and productivity in technical support work. Management Science 49 (4), 416–431. Drew, P., Heritage, J., 1992. Analyzing talk at work. In: Drew, P., Heritage, J. (Eds.), Talk at work: Interaction in Institutional Settings. Cambridge University Press, Cambridge, pp. 1–65. Dvorak, J.C., 2003. Magic number: 30 billion. PC Magazine [On-line]. Retrieved 8-12-2003, Available from: www.pcmag.com/author_bio/0,3055,aZ123,00.asp Edwards, D., Potter, J., 1993. Language and causation: a discursive action model of description and attribution. Psychological Review 100, 23–41. Enfield, R.L., 1987. The limits of software reliability. Behaviour and Information Technology 1987, 36–43. Eveland, J.D., Blanchard, A., Brown, W., Mattocks, J., 1994. The role of ‘help networks’ in facilitating use of CSCW tools, Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work, Chapel Hill, North Carolina, United States. ACM Press, New York, NY, USA. Flew, S.R., Kneath, T.H., 1994. Providing quality user support. Journal of Petroleum Technology 46 (6), 484–485. Gergen, K.J., Gergen, M., 1980. Causal attribution in the context of social explanation. In: Gorlitz, D. (Ed.), Perspectives on Attribution Research and Theory: The Bielefeld Symposium. Ballinger, Cambridge, MA, pp. 195–217. Gill, V.T., 1998. Doing attributions in medical interaction: patients’ explanations for illness and doctor’s responses. Social Psychology Quarterly 61, 342–360. Goffman, E., 1959. The Presentation of Self in Everyday Life. Doubleday, New York. Goffman, E., 1961. Encounters. Bobbs-Merril, Indianapolis, IN. Goffman, E., 1963. Stigma. Prentice-Hall, Englewood Cliffs, New Jersey. Gonzalez, L.M., Giachetti, R.E., Ramirez, G., 2005. Knowledge management-centric help-desk: specifications and performance evaluation. Decision Support Systems 40 (2), 389–405. Heritage, J., 1988. Explanations as accounts: a conversation analytic perspective. In: Antaki, C. (Ed.), Analysing everyday explanation: a casebook of methods. Sage, London, pp. 127–144. Jones, M., 2000. PC Reliability & Service: things fall apart. www.pcworld.com/resource/printable/article/ o,aid,16808,00.asp [On-line]. Kiesler, S., Zdaniuk, B., Lundmark, V., Kraut, R.E., 2000. Troubles with the internet: the dynamics of help at home. Human-Computer Interaction 15 (4), 323–351. Kriegsman, M., Barletta, R., 1993. Building a case-based help-desk application. IEEE Expert-Intelligent Systems & Their Applications 8 (6), 18–26. Lee, D.M.S., 1986. Usage pattern and sources of assistance for personal computer users. MIS Quarterly 10 (4), 313–325. Lewis, C., Norman, D.A., 1995. Designing for error. In: Baecker, R.M., Grudin, J., Buxton, W.A.S., Greenberg, S. (Eds.), readings in Human–computer Interaction: Toward the Year 2000, second ed. Morgan Kaufman, San Francisco, CA, pp. 686–697. Lieberman, H., Fry, C., 2001. Will software ever work? Communications of the ACM 44, 122–124. Lundgren, T.D., 1998. End-user support. Journal of Computer Information Systems 39 (1), 60–64. MacLean, A., Carter, K., Lovstrand, L., Moran, T., 1990. User-tailorable systems: Pressing the issues with buttons. In: Proceedings, CHI’90, Seattle, 1–5 April. pp. 175–182. Marom, Y., Zukerman, I., 2005. Analysis and synthesis of help-desk responses. Lecture Notes in Computer Science 3683, 890–897. Murphy, B., Levidow, B., 2000. Windows 2000 dependability, Proceedings of IEEE International Conference on Dependable Systems and Networks. IEEE, New York, NY. Neumann, P.G., 1993. Are dependable systems feasible? Communications of the ACM 36, 146. Nickerson, R.S., 1986. Using computers: human factors in information systems. MIT Press, Cambridge, MA. Norman, D.A., 1990. Commentary: human error and the design of computer systems. Communications of the ACM 33, 681–683. Pentland, B.T., 1992. Organizing moves in software support hot lines. Administrative Science Quarterly 37, 527–548. Quayle, M., 2004. When the chips are down: attribution in the context of computer failure and repair. Unpublished Thesis, University of KwaZulu-Natal, Pietermaritzburg.

ARTICLE IN PRESS
18 M. Quayle, K. Durrheim / Interacting with Computers xx (2006) 1–18 Rimmer, J., Wakeman, I., 1999. Who helps the helpers: technological change in the help-desk. In: Buckner, K. (Ed.), Ethnographic Studies in Real and Virtual Environments: Inhabited Information Spaces and Connected Communities. Edinburgh University, pp. 70–80 (24–26 January 1999). Sauter, V.L., 2004. An exploratory analysis of the need for user-acquainted diagnostic support systems. International Journal of Information Technology & Decision Making 3 (3), 471–491. Selber, S.A., Johnson-Eilola, J., Mehlenbacher, B., 1996. Online support systems. ACM Computing Surveys (CSUR) 28 (1), 197–200. Shah, V., Bandi, R.K., 2003. Capability development in knowledge intensive IT enabled services. European Journal of Work and Organizational Psychology 12 (4), 418–427. Siewiorek, D.P., Chillarege, R., Kalbarczyk, Z.T., 2004. Reflections on industry trends and experimental research in dependability. IEEE Transactions on Dependable and Secure Computing 1 (2), 109–127. ˆ Simache, C., Kaaniche, M., Saidane, A., 2002. Event log based dependability analysis of Windows NT and 2K systems. Proceedings of the 2002 Pacific Rim International Symposium on Dependable Computing (PRDC) 2002, 311–315.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->