Articulating Theoretical Contributions of Social Informatics from a Sociotechnical and Design Perspective

Table of Contents

• Administration and Instructions

• Questions

• Question 1 - A Brief History of the Sociotechnical Approach to Design

  • Works Cited

• Question 4 - How the Sociotechnical Approach to Design Handles Change Over Time

  • Works Cited

• Question 3 - Principles to Underpin Designing a Scientific Collaboratory

  • Works Cited

• Question 5 - Affordances and Affordance Analysis

  • Works Cited

• Question 6 - Boundary Objects

  • Works Cited

Administration and Instructions

This is the written portion of the field exam in Social Informatics for Spring 2008. The Written examination begins: 9am, Monday, March 24, 2008, and is completed by 9am, Monday, April 7, 2008. The final version of the exam must be submitted by 9am April 7th.

An electronic version may be submitted as a Word attachment to email addressed to the Chair of the Doctoral Studies Committee, Dan Schiller, and to all members of the exam committee, Caroline Haythornthwaite, Les Gasser, and Michael Twidale.

A printed copy must also be submitted to the GSLIS office before closing April 7th.

This exam consists of seven questions. You are required to answer five of them. Each answer is accorded equal weight. Note that the total length of the completed exam is not to exceed 7500 words (approximately 25-30 pages of double spaced text, excluding references). A two-hour oral exam will be scheduled to follow at the earliest time possible for committee and candidate.

Questions

What follows are the seven questions I was provided:

1. The socio-technical or social informatics (SI) approach emerged from a need to respond to systems design shortcomings, and changes associated with the information age. Considering the development of this approach, consider 3-5 major milestones in SI thinking. Describe how they originated and what they contribute to SI.

2. Context is highly influential in SI considerations, and its influence has been considered at the individual, group, and organizational levels. Discuss 3-5 ways context matters for SI, including discussion of theoretical or practical lenses used to approach understanding context (e.g., an ecological approach).

3. A research team has just formed and you have been asked to create the infrastructure for the support of their collective work. Describe the principles that would underpin your selection of Information and Communication Technologies (ICTs), and your recommendations for their use for this team. You may explicitly reference a particular real or envisioned team in your discussion.

4. Groups learn as they work together – they learn about each other, their technologies, and how to work with and through those technologies. Discuss how an SI approach to systems design, use and/or implementation accounts for (or fails to account for) change over time.

5. HCI, CSCW & SI make much of the use of the term "affordances." Explain the concept and its pros and cons for analyzing, designing and/or implementing technologies.

6. "Boundary objects" are cited as ways to cross disciplinary or expertise divides. Explain the concept as originally described. Discuss its applicability to a context of your choosing. Discuss its pros and cons as an analytical, theoretical and/or design framework.

7. Remembering and forgetting are two aspects that affect how we use, understand, and relate to online systems. Discuss from a design (e.g., HCI), evaluation (e.g., user studies, analyses of system use), and/or disciplinary (e.g., science practices) perspective how memory plays into the use and usefulness of systems for collaborative work.

Question 1 - A Brief History of the Sociotechnical Approach to Design

1. The socio-technical or social informatics (SI) approach emerged from a need to respond to systems design shortcomings, and changes associated with the information age. Considering the development of this approach, consider 3-5 major milestones in SI thinking. Describe how they originated and what they contribute to SI.

The history of the sociotechnical approach to design of work and other activities is long and complicated, involving a number of developments over time, and spanning disciplines including management and organizational studies, computer science (CS), and, of course, library and information science (LIS). The recent emergence of social informatics (SI) as an interdisciplinary field of study is but one of the latest manifestations of this approach, with a focus on information communication technologies (ICTs). In this essay, I will provide a brief overview of this history with an emphasis on the major theoretical developments, or milestones, in the development of sociotechnical thinking.

Initiated by work in the late 1940s (see Trist & Bamforth's 1951 inaugural publication), sociotechnical systems theory (SST) was first developed by researchers at the Tavistock Institute in the United Kingdom (Trist 1981; Mumford 2006). The principle contribution of this early work was the recognition that prior organizational theories were flawed in their assumptions that humans were just thinking machines, and all that was required to create a successful work force was a high enough financial incentive. Instead, Trist & Bamforth (1951) demonstrated that interweaving of the social and the technical (in this case, mining machine technology, work flows built around the affordances of the technology, competitive pay scales, and a lack of incentives to encourage cooperation among other issues) was a major factor not only in determining the quality of social life for the miners, but also in determining the efficiency of the mining operation and the safety of the mining environment. Further work in restructuring the mining environment both socially and technologically led to a much safer, more pleasant, and more efficient mining environment (Trist 1981), and from this work, the action research paradigm of SST was born. This early work was built upon by many different researchers, first at Tavistock, and then at research institutions around the globe. The understandings gained from this SST approach accumulated over time, until in the 1970s & 1980s a series of publications provided definitive reviews of the lessons learned (Cherns 1976; Trist 1981; Emery & Trist 1973; see Mumford 2006 for an overview), some of which have been replicated here, see Table 1-1 and Table 1-2.

This SST action research paradigm led directly to the second major development in the sociotechnical approach. In the 1960s Emery and Trist were invited to Norway after a sudden, grass-roots demand erupted for worker control in the country. In collaboration with Thorsrud, they imported the SST approach to work design (Trist 1981). In this work they pioneered work-linked democracy—the direct participation of workers in the work design process. This practice spread to Sweden in the 1970s, and in the same decade requirements for workplace democracy became embedded into national law in Scandinavia. It was these laws which led directly to the development of the participatory design (PD, a.k.a. co-design) movement when information technology was introduced into the Scandinavian workplace (Ehn 1993). In this manner, the sociotechnical approach was ported to information technology design. The lessons learned by the sociotechnical systems theorists and the participatory designers were similar. Both recognized the importance of involving workers directly and fully in the design process. Both developed methods for performing successful design founded on principles, rather than "best practices" or predictive theories. And both developed theories about design that included perspectives that ranged from the macrosocial to the small group level (Kensing & Blomberg 1998; Trist 1981; Bodker, Kensing & Simonsen 2004). However, while some of the early PD work involved reinventing the Tavistock wheel, PD also had some clear contributions; many of the principles they developed are distinct from and supplementary to those developed in SST (compare: Trist 1981; Bodker, Kensing & Simonsen 2004).

While it is unclear how directly SST impacted PD (the lack of naming continuity suggests less rather than more), the word "sociotechnical" was eventually ported into PD as well as related (and overlapping) design fields such as computer supported cooperative work (CSCW) and systems analysis by researchers who were familiar with SST (e.g., Eveland & Bikson 1988). In these fields, however, the word has come to be used typically in a much more general and evocative sense of needing to pay attention to both social and technical aspects of the system (e.g., Hansen 2006), rather than referring to the theoretical findings of the Tavistock tradition. It is this more general sense of "sociotechnical" that has typically been adopted in SI (e.g., Kling 2001/2003).

This theoretical disconnect has some unfortunate consequences. One of the major findings in SST is the principle of incompletion—design work is never finished (Cherns 1976). However, most PD projects (and most technology design projects in general) have a clear end-date, where the design work is considered completed, and rarely is there any kind of on-going design activity embedded into the workplace setting to allow the sociotechnical environment to evolve with the changing needs of the workers. This is clearly problematic, since even if the technology is designed perfectly for the environment the workers are in, the very introduction of the technology will change the nature of the work, and thus it will need to be adapted again in response (Dourish & Button 1998; Cherns 1976). There are many reasons for having design endeavors end, including finite resources being devoted to design work, a lack of recognition of the need for continued design work by managers who shape the work environment, etc. (all of which have been causes of failure of SST design work: Trist 1981). However, had the PD tradition applied the principle of incompletion, their work may have been more successful.

Similarly, there are a number of criticisms of SST (see Hackman 1981). One criticism of the SST tradition is that the application of their theory is at times too dogmatic; e.g., the types of interventions they advocate such as autonomous work teams are not always appropriate, and the emphasis on groups as opposed to individuals as the unit of analysis overlooks the sometimes deleterious effect that groups can have on individual development, an avowed human right according to SST (Hackman 1981). Aside from the devotion to worker participation in systems design, which is the practical concern that is the foundation of the movement, the PD tradition and related fields have been considerably more flexible in contextualizing their intervention strategies.

While SST theorists often had considerable success in applying their methods, at least in the time during and immediately after they conducted their work (Mumford 2006; Trist 1981; though long-term effects can be questioned: Hackman 1981; Mumford 2006), the technology focused designers were less fortunate. One of the major, inescapable facts they faced was that CSCW systems often failed despite considerable effort by reflective practitioners and researchers (Grudin 1988; Star & Ruhleder 1996). It was from this experience that the importance of the social + technical was rediscovered by these researchers, and it was the continued resistance by many in CS to the sociotechnical approach that led to the reactions which motivated the formation of the SI movement.

Rather than be discouraged by this recurring failure, CSCW (and related) researchers used it as an opportunity to take sociotechnical thinking to a new level, beyond what the sociotechnical systems theorists had attempted by supplementing their design work with ethnographic methods from anthropology and sociology. While initial research simply identified causes of failures (e.g., Grudin 1988; Orlikowski 1993), other, especially later, work developed more general theoretical constructs that identified sociotechnical (in the loose sense of the word) phenomena which existed in many if not most sociotechnical settings. These theoretical constructs could be used both analytically to explain what was occurring in a particular case, and as sensitizing constructs to identify potential causes of failure in the initial phases of the design work. Such theoretical constructs include invisible work (Star & Strauss 1999; Suchman 1995); articulation work (Suchman 1996; Schmidt & Simone 1992); infrastructure (Star & Bowker 2002; Star & Ruhleder 1996; Star 1999); heedful interrelating (Weick & Roberts 1993); workarounds (Gasser 1986); technological frames (Orlikowski & Gash 1994); etc. These phenomena-oriented constructs, coupled with similar constructs imported from other fields such as sociology (e.g., strong, weak, and latent ties: Haythornthwaite 2002; Granovetter 1973; Haythornthwaite 2005), allowed CSCW researchers to move beyond simply articulating lessons learned and principles which, if followed, would (theoretically) lead to good design. This allowed design work to move beyond simply following principles, to engaging in theoretically backed critical understandings of local situations from which informed decisions could be made as to what principles were appropriate to follow, and how. Thus, from this development, a science of the sociotechnical began to be developed whose theory could be actively used in design work; the study of design was no longer just a science of design activity which might produce specific recommendations for practitioners to follow. This does not mean, however, that it is currently practical to do so (Rogers 2004; Schmidt & Wagner 2004).

As this theoretical development was taking place, there was a growing recognition, motivated both by experience and by theoretical developments in related disciplines like science and technology studies (STS) and anthropology, that the cybernetic account of sociotechnical systems as systems which contain separate technical and social subsystems (present in the Tavistock tradition, and often articulated in reviews of the approach, e.g., Iivari & Hirschheim 1996) is too simplistic a model to account for the complexities of the sociotechnical. This final milestone of the sociotechnical approach was made explicit in the SST literature by Kaghan & Bowker (2001), in their exploratory integration of actor-network theory (ANT) with standard SST. However, such a recognition was already present if less explicitly articulated in CSCW research from a series of theoretical perspectives, including ANT (Latour 2005), distributed cognition (DCog; Hutchins 1995), activity theory (AT; Engestrom 2000), and situated action theory (SAT; Suchman 2006). While each theoretical approach differs in their manner of resolving the sociotechnical as an object of study, the major contribution of these approaches is the recognition of the value of Garfinkel's ethnomethodology (Suchman 2006; Dourish & Button 1998) and of Latour's (2005) criticism of "standard" sociology: the valuable object of study (especially for design) is not the black-box of the social, the technical, or the sociotechnical; rather, it is how everyday human activity, cognition, technology use and construction, etc., are performed such that the phenomena we observe which we label using one of these macroterms is produced. The significance for design activity is profound, as such focus encourages researchers to engage with the mechanics of what occurs, and not just with the classifications of phenomena that are observed.

Question 4 - How the Sociotechnical Approach to Design Handles Change Over Time

4. Groups learn as they work together - they learn about each other, their technologies, and how to work with and through those technologies. Discuss how an SI approach to systems design, use and/or implementation accounts for (or fails to account for) change over time.

It is one of the strengths of the social informatics (SI) and sociotechnical approaches to design that they are able to address the issue of change in group activity over time. Groups are never static entities. Individual human learning happens all the time: as outsiders are introduced to the group and they learn about how to participate in the group; as insiders develop more refined collaborative practices and they learn from experience how to do their activities more effectively; as the nature of the group's goals change over time and group members must learn new ways of addressing those goals; as new technologies are introduced to facilitate members' activity they learn how to use them to accomplish their work; and as the environment in which the group is situated changes, individuals need to learn how to adapt to the changes as part of their group. There are many aspects of the sociotechnical approach which address and account for these dynamics as they happen over time. This essay will focus on design approaches, but design requires a consideration of use and implementation, so these aspects of understanding group dynamics will play a part in the discussion.

Probably the most important sociotechnical principle that accounts for group dynamism is the recognition that sociotechnical design is a fundamentally equivocal (Daft & Lengel 1986; Weick 1979) or wicked (Rittel & Webber 1973; Wolf, Rode, Sussman & Kellogg 2006) problem. This means that there is no single "right" way to produce a design. Rather, a "good" design is a result of decisions that are made about the value of the design, and about desired work practice, as the design is developing over time. The evaluation criterion for a design is how well it works for the people utilizing the design as they are trying to accomplish their work. Thus, not only are groups not static, but it is their dynamic nature that makes design possible in the first place. If groups were static, then the decisions that need to be made about what they want their group practices to be could never be made, because such decisions require a change in the nature of the group's activity.

In order to help "tame" the wicked nature of design, the participatory design (PD) tradition has developed the principle of a coherent vision for change (Bodker, Kensing & Simonsen 2004). The idea behind this principle is that any design activity must be guided by a vision for what needs to be accomplished, in order to provide a means for defining what values will guide the design process, thus reducing its wickedness. This vision, however, is something that must be negotiated among participants in order to be successful in being coherent for all stakeholders, and for providing motivation for participation in the design process. Furthermore, the vision is subject to negotiation, change, and evolution, and a significant part of the design work is clarifying the vision, and specifying what it means. Thus, the goals of the project can and do change over time, and the meaning of the vision is constantly being renegotiated by participants in response to design and environmental developments.

At first glance, the principle of coherent vision seems to conflict with situated action theory. As Suchman (2006) points out, plans are mechanisms for guiding actions: ways of articulating goals, ways of creating possible routes toward achieving a particular goal, and ways of articulating what actually happened after the fact. Yet, when actually in the situation, attempting to follow a plan while embedded in the immediacy of the moment, one is inevitably confronted with unexpected situations, and plans often must be altered or abandoned, no matter how useful they might have been to conceptualize the activity in the beginning. As Suchman (2006) takes pains to establish, this does not contradict the value of creating plans, or a vision for change, because plans still play a coordinating role, as long as there is no expectation that they will be strictly followed. Thus, local activity such as design decisions, implementation decisions, and adoption patterns can be interpreted by placing them into the existing planning framework, either by arguments of how they exhibit the plans, or how the plans need to be changed. In this manner, the coherent vision for change can be used as a continually negotiated boundary object to coordinate the actions of different communities of practice within the design endeavor, accounting for how understandings of what needs to be designed change over time in response to group learning (Star & Griesemer 1989; Bowker & Star 1999).

There are three main approaches to supporting good sociotechnical design, and each supports understanding and facilitating the dynamics of group change over time in different ways: the practitioner's situated learning approach, the design method approach favored by some researchers, and the design theory approach favored by others. As Rogers (2004) demonstrates, the approaches are not mutually exclusive, and there are researchers and practitioners who utilize combinations of these approaches in their work. However, the manner in which each accounts for change is distinct.

The first approach is the situated learning that typically happens in professional design organizations and other communities of practice, where new members learn how to do design from existing members via legitimate peripheral participation (Lave & Wenger 1991). In such an environment, a culture of design practice is developed from community experience over time, and relatively robust design practices can develop (e.g., IDEO). However, practices are improved typically via trial-and-error or a experience-based need to innovate (Brown & Duguid 1991), so the process is vulnerable to local maxima and to satisficing behaviors. Thus, legitimate peripheral participation accounts for how new members obtain the knowledge of an existing community of practice (Lave & Wenger 1991; Cox 2005), and the trial-and-error approach explains how knowledge builds over time. However, whether the design practices account for change in the groups being designed for, depends entirely on the practices that have developed in the design group's culture.

The second approach favored by some researchers is to develop good, general (to some degree) design methods that will ensure good design when followed. Examples of this approach include PD (Bodker, Kensing & Simonsen 2004), sociotechnical design (Trist 1981), scenario-based design (Carroll 2000), spiral model of design (Boehm 1986), etc. As Rogers (2004) points out, these methods can be classified in a number of different ways, and each type of method has different implications for how well it handles change. Predictive methods such as GOMS usually are remarkably poor at accounting for any kind of deviation from a prescribed path, despite the fact that such deviations are to be expected in the vast majority of real-world situations. Prescriptive methods like heuristic evaluation are much more flexible, providing guidelines which designers can use and combine with other prescriptive methods in an eclectic composition derived from their current local needs, and adaptable as those needs change. As a result, these methods tend to be much more popular among design practitioners (Rogers 2004).

Rogers identifies but does not classify an additional range of design methods, "including scenarios, storyboards, sketching, low-tech and software prototyping, focus groups, interviews, field studies, and questionnaires and use cases" (Rogers 2004, 123). These methods can also be part of the aforementioned eclectic compositions. However, iterative prototyping methods deserve more detailed consideration. Fallman (2003) argues that iterative prototyping for HCI designers is the equivalent of sketching for architects and industrial designers, as it is not only the means by which rough ideas are sketched out, but also the means by which iterative reflective evaluation of those ideas can be performed. When used to facilitate creative design in response to equivocality (as opposed to engineering design in response to uncertainty; Wolf, Rode, Sussman & Kellogg 2006; Lowgren 1995), however, prototyping serves not only as a sketching mechanism, but also as an evaluation mechanism, akin to the architects models & calculations, and the industrial engineer's calculations. For wicked problems, the sociotechnical designer has no better means of evaluation. Thus, prototyping, by being iterative, can help users learn about the technology and its possibilities, help designers learn about the design space, and by being distributed over time, allow the design process to adopt to changing environmental circumstances.

Fallman's (2003) traditional-style design methods such as the waterfall model, the spiral model, and even traditional participatory design are another category, but these methods are often very poor at handling change over time, since they presume an endpoint to design activities. The sociotechnical design's principle of incompletion (Cherns 1976), however, does account for change over time. Even if a particular design project ends, and resources are cut, as long as the products of the design project are being used, users are likely to appropriate the products in ways that the designers never expected, thus engaging in informal, amateur design activities (Eglash 2004; Brown & Duguid 1991). Thus, while a particular design situation can be classified as "finished", the black box of the completed design can be reopened if subjected to the proper environmental pressures (Latour 1987).

The third approach to design is the theory-building approach, where good theoretical constructs are thought to inform design work in a productive manner. Examples of such constructs include invisible work, articulation work, activity theory, distributed cognition, boundary objects, strong/weak/latent ties, infrastructure, etc. The ability of each of these constructs to handle change over time, however, is idiosyncratic to the theory. While there is not space to review each relevant theory, it should be noted that most of these constructs are sufficiently complex that even a theoretical construct like boundary objects, while at first glance might appear static, is not when properly contextualized (e.g., Bowker & Star 1999).

Question 3 - Principles to Underpin Designing a Scientific Collaboratory

3. A research team has just formed and you have been asked to create the infrastructure for the support of their collective work. Describe the principles that would underpin your selection of Information and Communication Technologies (ICTs), and your recommendations for their use for this team. You may explicitly reference a particular real or envisioned team in your discussion.

Creating a sociotechnical infrastructure to support a newly formed or forming research team is a dynamic process that must be responsive to circumstances as they evolve and develop. As such, it must draw fully upon the ability of the sociotechnical approach to design to deal with change over time (as specified in the answer to Question 4). However, supporting research collaboration is a particularly wicked problem (Rittel & Webber 1973; Wolf, Rode, Sussman & Kellogg 2006) because often the researchers themselves have only vague notions of how they might collaborate, and they have little or no idea what kind of activity the infrastructure will need to support. For this reason, it is impossible to talk about specific selections of information communication technologies (ICTs) to enable the collaboration activities of such a team, because the researchers themselves will have to make decisions about how they want to do their work, decisions which will be the result of on-going articulation work and negotiations between the different participants. Thus, the principle of a coherent vision for change (Bodker, Kensing & Simonsen 2004) becomes especially important in order to start the "taming" process, as the various motivations of individual researchers who are interested in collaboration will need to be articulated, discussed, and somehow formed into a coherent vision.

This initial negotiation phase is likely to last for an extended period of time. However, the infrastructure construction need not be delayed until this phase is complete. That the participants are engaging in this negotiation phase means that one existing coherent vision for change already exists: the need for an infrastructure to support these negotiations. This infrastructure can be constructed and implemented during the negotiations by following rapid cooperative prototyping methods (Bodker & Gronbaek 1991; Trigg, Bodker & Gronbaek 1991). The iterative nature of these methods allows for a non-linear integration of analysis, synthesis and evaluation facilitating a coevolution of problem setting and problem solving (Fallman 2003). As the research team's long-term coherent vision for change gets negotiated, the current infrastructure can either be used as a base to support the development of what they decide they need, or discarded (piecemeal). The rest of this essay concerns this initial construction phase and the considerations to take into account during this phase.

My collaborators and I have found that rapid iteration of high-fidelity prototypes is very useful, not only for minimizing the disruption of the on-going design work and for allowing users to become full participants in the design process, but also for getting people software quickly which they can use to support their daily work activities (Floyd, Jones, Rathi & Twidale 2007; Jones, Floyd & Twidale 2007). When participants are used to the constantly changing nature of the prototype (typical iteration cycles are less than 1 week), they develop expectations that the portions being designed will change. Thus, they do not become attached to a particular version of the prototype if it is less than ideal, and the many options they see implemented at various stages in the prototype development give them a much richer understanding of the possibilities that technology has to offer. From this understanding, they are able to make much better design recommendations to developers, and do not satisfice with less efficient technology. When this iteration process is coupled with extensive collection of feedback facilitated by project leaders and software interfaces, a social infrastructure is constructed where dissatisfaction becomes a motivation to request change, becomes channeled into constructive behavior, and thus a natural feature of the researchers' and the designers' community of practice. The challenge is to have modular components which facilitate rapid iteration cycles; we have found that using a combination of open source software (OSS), other software modules/applications which the developers have source code access, and web services is often sufficient to enable such turnaround times, at least for the initial negotiation phase of the project. When taking such an approach, we have found that the exact ICTs selected initially do not matter so much, as the rapid iteration cycles allow quick substitution or elimination of poor choices.

If this model is adopted, there are a number of other concerns that need to be factored into the infrastructure development process. One of the most important principles of sociotechnical design is the principle of incompletion (Cherns 1976). This is especially true in the collaboratory development activities that are currently occurring in many different fields. Even long-lasting projects such as LTER (30+ years) still are developing their infrastructure (Ribes, Baker, Millerand, & Bowker 2005). Thus, one of the major considerations of any endeavor to build sociotechnical infrastructure is to embed into it an infrastructure for sustained, continuous design. As defined by Star (Star & Ruhleder 1996; Star 1999; Star & Bowker 2002), infrastructure is infrastructure only when it is invisible, when people are able to use it without noticing its presence. Thus the general sociotechnical infrastructure and the design infrastructure embedded within it must be as invisible to the researchers as possible when they are engaged in their collaborative activities, so their activities are minimally disrupted by the design work that is constantly going on. Of course, following the principles of sociotechnical systems theory (SST; Trist 1981) and participatory design (PD; Bodker, Kensing & Simonsen 2004), the design process must exhibit work-linked democracy—the users of the infrastructure must be full participants in the design process if it is to succeed—so an artful balance must be struck. Therefore, the sociotechnical infrastructure including the design infrastructure must become salient at times (discarding its infrastructurial nature), but only when doing so does not disrupt the work it is intended to support (e.g., during reflection prompted by feedback collection).

Another important principle is the modularity of the infrastructure, a concept which is evident, though expressed differently, in both the sociotechnical systems literature and the software development literature. When considered together, the principle for minimal critical specification, the principle of the sociotechnical criterion, the principle of boundary location, and the principle of information flow (Cherns 1976) can be seen to express certain principles of object oriented (OO) design such as encapsulation and polymorphism (Armstrong 2006) as well as certain general principles of software development such as loose coupling and strong cohesion (Apress Publishing 2005). While the SST principles are management oriented, and the OO principles are software developer oriented, they functionally capture many of the benefits of modularity. The strength of the OO approach is that, via information hiding, all of the information that is relevant to local functionality is contained, or encapsulated, within a particular object or class. Thus, each object/class is modular enough that it can implement a particular method in the way that is most appropriate (polymorphism). Each object/class is sufficiently independent of other objects/classes due to loose coupling that one can be modified without affecting the rest of the code, yet each one has sufficient control over its area of functionality that it solely responsible for it, and not responsible for unrelated issues (strong cohesion).

This general, modular structure is captured in the sociotechnical principles (Cherns 1976). The principle of information flow is equivalent to encapsulation, where the messages exchanged between two objects, whether between managers and workers, or technological systems and various stakeholders, should be what is relevant to their jobs, but not more. This is bolstered by the principle of minimum specification which allows polymorphism, in that managers should specify only what work needs to be performed, and leave the implementation of the work up to the workers doing it. The principle of sociotechnical criterion seeks to ensure both encapsulation and polymorphism by indicating that checking mechanisms should be implemented within the encapsulation, and not external to it, thus creating a workforce that is both fully responsible for accomplishing a particular job, and fully knowledgeable about how to accomplish the job. The principle of boundary location is equivalent to strong cohesion, in that job functionality should be modularized in such a way that a particular work force is responsible for the entirety of a job, and only that job. Loose coupling is not explicitly represented in the sociotechnical principles, but is a natural result of implementing them. The importance of the modularity of the infrastructure that is created, is that as user requirements are better understood through the prototyping process, modular chunks of the interface can be improved, replaced, etc., without affecting the rest of the infrastructure, thus allowing the continual design process to occur. Once portions of the infrastructure are optimal, they can be effectively black-boxed until such time as they need to be reexamined (Latour 1987).

In the rapid collaborative prototyping method that is used here, feedback collection is extremely important, because it is not only how the current prototype is evaluated, but also how the requirements are established and specified for the infrastructure in general. For this reason, a number of different mechanisms for feedback collection need to be employed, and the information that is collected must represent the developing work practices of the researchers generally, not just with respect to the current prototype. Thus, a number of methodologies should be applied. First, given the benefits of an ethnomethodological approach, the entire design process should be considered by the design team as a technomethodological ethnography (Dourish & Button 1998). This can be used, for example, to examine the abstractions present in the current prototype in order to see whether the accounts the abstractions provide are useful in exposing the mechanics of the prototype for the researchers in their situated use.

Second, phenomena-oriented theoretical constructs (POTC; see Q1) can be used both as interpretive frameworks to understand the results of feedback collection (both ethnographic and other) work and its possible implications for altering the current design, and as sensitizing concepts when constructing and performing feedback collection activities. Invisible work (Star & Strauss 1999; Suchman 1995) is a useful example. Certainly it is important to be aware of invisible work that the researchers are engaging in when they are collaborating. It is possible that the developing infrastructure is creating invisible work, work that may or may not be productive. It is also possible that the researchers are engaging in invisible work which could be supported by changing the infrastructure, but without being discovered, never will be. Thus, any feedback that is collected should be analyzed to find hints of invisible work that is happening, and at least some feedback collection activities should be designed specifically to reveal invisible work that is being performed. Of course, once the work is made visible to the design team, they must carefully consider, by drawing on the expertise of its participant/researcher members, whether to make that work visible to other stakeholders and participants who will be using the infrastructure, or whether to keep it concealed. Sociotechnical principles mentioned above like information hiding and minimal critical specification should also be factored into this decision-making stage. Of course, sometimes, work that is visible should be made invisible, so as to grant its practitioners more freedom in conducting the work; thus, POTCs can also be used in the negative, to examine whether the kind of phenomena they describe currently does not exist, but might be useful. In the end, the POTCs should form a toolbox of constructs that are regularly used in evaluation/requirements gathering work.

Finally, there are a number of principles that have been discovered in previous studies of research collaboration, which should be incorporated into the infrastructure evaluation. For example, it may be useful to periodically map the developing socio-technical interaction network (STIN; Kling, McKim & King 2003) of the researchers and their larger environment. By doing so, not only might hidden structural components of the network be revealed, but the design team will be able to get a better sense of how the network of relationships the scientists are embedded in is changing over time, which might lead to better understandings of what kind of infrastructurial support they might need. Another example is the finding that "distance matters" (Olson & Olson 2000). This might be a very useful principle for evaluating whether electronic infrastructure and distributed solutions to problems are actually the most appropriate solutions, or whether more face-to-face meetings, working facilities (e.g., warrooms), etc., ought to be established. It might also be used as a guiding principle for applying computer-mediated communication theory and media-richness theory properly to electronic infrastructure design. And, of course, there are many more.

Question 5 - Affordances and Affordance Analysis

5. HCI, CSCW & SI make much of the use of the term "affordances." Explain the concept and its pros and cons for analyzing, designing and/or implementing technologies.

The term "affordances" is used in many different senses in human-computer interaction (HCI), computer-supported cooperative work (CSCW), social informatics (SI), and related fields, and the concept is a bit underdeveloped (Bower 2008). The term "affordance" was originally coined by Gibson in his theories of visual perception (Gibson 1979). Norman introduced the it into the HCI literature with his 1988 book, The Psychology of Everyday Things (Norman 1988/2002). However, his popular-audience writing style led to some significant misunderstandings of what an affordance was, thus he later clarified what he meant (Norman 1999). Because of this early confusion, there are a number of different ways in which the word "affordance" is used in the literature. Thus, in this essay, I will review the various definitions of the term "affordance" and how they are situated in the literature, evaluate how useful each definition is for facilitating design work, and finish by discussing "affordance analysis" as a design technique, and how it can integrate some of the definitions into a useful method.

Gibson's definition of affordance is fairly complex and can be found in Table 5-1. Gibson is not trying to be a philosopher (though for a beautiful philosophical account of affordances see Scarantino 2003). His definition of affordance is clearly meant to be evocative in nature. Thus, while Gibson is trying to provide an alternative model to understanding perception from what his contemporaries were advocating, for the purposes of applying his definition to SI and related fields, there are four important aspects of his definition, which can be found in Table 5-2.

Norman (1999) claims to have imported Gibson's definition of affordance directly into the design literature, and indeed his account is very similar to Gibson. Norman defines an affordance as referring "to the actionable properties between the world and an actor [...] affordances are relationships. They exist naturally: they do not have to be visible, known, or desirable" (Norman 1999, 39). Norman's definition is also evocative: most of the seeming discrepancies between his definition and the four points of Gibson's definition above become illusory when Norman's examples are reviewed (some authors disagree with this sentiment: McGrenere & Ho 2000; Rogers 2004). However, after Norman's (1988/2002) initial publication, the use of the term, in both the research literature and by practitioners developed a number of interpretations which were not consistent with Gibson's definition. In a review of the research literature, St. Amant (1999) identifies four conceptions present, which can be found in Table 5-3.

Conceptions 2 & 3 are oversimplifications of Gibson's view. They abandon distinctions which are important for design, thus I will not consider them further. Conceptions 1 & 4 seem, fundamentally, to be based in different metaphysical interpretations of the world. The consequences of either metaphysical interpretation seems to be the same, thus, rather than take sides, it is up to the reader to choose the one they prefer.

Rogers (2004) also identifies some alternative interpretations of the affordance construct. According to Rogers, some designers interpret affordances as a call for creating metaphorical representations of physical objects in interfaces to improve usability (e.g., 3-D buttons). She also is concerned whether alternative interpretations, especially those adhering to St. Amant's (1999) conception 4, maintain the ecological nature of the construct that she finds is its strength.

Norman (1999) does not categorize the inconsistent interpretations of affordances that he has observed, but he does respond to some he finds particularly offensive. In general, it seems that the designers Norman is responding to either used the term affordances to refer to non-physical phenomena, confused perception of affordances with affordances (like in 3 above), or used affordances inappropriately to talk about symbolic communication. Aside from objections to oversimplification and inappropriate use, Norman (1999) insists that affordances must refer to phenomena that are physical in nature. He does recognize that there are other important features of user interfaces which are non-physical, but he believes that other theoretical constructs he presents are more appropriate to deal with them: mental models and constraints.

For Norman (1988/2002; 1999), how well the mental model of the design communicates how the design actually works is the most important feature of the design, and where the hard work in the design process actually occurs. Affordances and constrains are presented as two types of analytic tools designers can use to facilitate this process. Affordances are mechanisms by which the users can interact with the design, perceived affordances are user perceptions of affordances whether they correspond to real affordances or not, and constraints are various ways in which use possibilities are limited, and thus can be ways in which the user can be guided into intended uses. Thus, designs should be built such that the appropriate affordances will be perceived by users, and embedded with constraints that will guide use.

Norman (1988/2002) proposes four types of constraints. Physical constraints which limit physical use. Semantic constraints which "rely upon the the meaning of the situation [of use] to control the set of possible actions" (Norman 1988/2002). Cultural constraints which rely upon cultural conventions to suggest a limited number of uses. And logical constraints, which use deductive logic to eliminate possible uses. All of these constraints are useful for directing use behavior, and thus useful for communicating to the user how to effectively use the design, which is Norman's (1988/2002, 1999) explicit primary concern. However, the negative casting of these theoretical constructs suggests that they have positive complements. In the case of physical constraints, affordances, which according to Norman are necessarily (partly) physical in nature, serve that role. Thus, it seems that one source of the miscommunication that Norman reacts so strongly against was an assumption by designers reading his book that each of the other types of constraints also had affordance complements. Thus, physical constraints vs. physical affordances, semantic constraints vs. semantic affordances, etc. Furthermore, since the list of constraints was not suggested to be exhaustive, it seems that other types of affordance/constraint pairs might be possible. While this interpretation of affordances is clearly inconsistent with Gibson's conception of affordance, the question arises, might these constructs be useful extensions of Gibson's theory of physical affordances for designers? It is not so clear that the answer is "no", but it is beyond the scope of this paper to examine the theoretical consequences of such an extension. Certainly, this would not be the first significant extension of Gibson's construct (e.g., social affordances proposed by Cook & Brown 1999).

While Norman (1988/2002) introduced the construct of affordances as an analytic tool for designers to use in their work, his examples utilize the construct primarily for conceptualizing design, and critically thinking about particular design decisions. Gaver (1992) suggested a different model, that the systematic analysis of affordances may be useful as a design technique for evaluating interface consequences, a method often referred to as affordance analysis. The method appears in a select number of other publications; Twidale (2006) for example suggests its use as a rapid evaluation technique. However, the most extensive and most explicit treatment of affordance analysis is in Bower (2008), who formalizes it as a design method.

Bower's (2008) formalization of affordance analysis offers an interesting extension of the method. Previous accounts of affordance analysis had focused primarily on evaluation, either for evaluating existing systems to obtain a better understanding of the affordances present and affordances that might be desired (e.g., Gaver 1992), or for evaluating successive iterations of a prototype not only to follow Gaver (1992), but also for evaluating whether and how effectively successive iterations of a prototype exhibit needed affordances (e.g., Twidale 2006). Bower (2008) not only included iterative evaluation as a component of his method, but he also added several design components.

First, Bower (2008) incorporated a preliminary design component to the method, in order to facilitate the creation of the first prototype. While the steps were relatively straight-forward (identify goals, postulate suitable tasks, determine the affordance requirements of the tasks, etc.), this is an interesting extension to the method because it creates a hybrid between Norman's (1988/2002) and Gaver's (1992) use of the construct.

Second, Bower (2008) started out the project by developing a list of affordances that were relevant to educational software, and then he organized the list into a taxonomy. While this step is not necessary for every implementation of his method (he's already provided a pretty comprehensive taxonomy for e-learning, for example, so future projects may not even need to update it), designers in domains in which such taxonomies do not exist may need to generate them.

The advantage to the second step is that the designer approaches the affordance analysis with a checklist of affordances, thus having the opportunity to be more systematic. However, as Bower (2008) points out, the purpose of the analysis is not to be exhaustive unless it is needed for a particular task. The method is designed to be flexible: either as systematic and exhaustive or as quick-and-dirty as the situation requires. Thus, the taxonomy of affordances is more a ready-reference tool than anything else, and should be customized for any particular design context. Bower's (2008) taxonomy is also interesting because the affordances in Bower's taxonomy are not all strictly Gibsonian, thus providing evidence that extending Gibson's conception of the term may be useful for design practitioners.

Question 6 - Boundary Objects

6. "Boundary objects" are cited as ways to cross disciplinary or expertise divides. Explain the concept as originally described. Discuss its applicability to a context of your choosing. Discuss its pros and cons as an analytical, theoretical and/or design framework.

The concept of a boundary object was first described by Star & Griesemer (1989), and was later elaborated on by Bowker & Star (1999). As described in these two works, boundary objects are objects, whether concrete or abstract, which "inhabit several communities of practice and satisfy the informational requirements of each of them. Boundary objects are thus both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites." (Bowker & Star 1999, 297). Each group that uses the boundary object has its own interpretations of the object: what it means, what it is useful for, etc. These interpretations may vary quite a bit, and even conflict to some degree. However, there are some features of the object as understood through each group's interpretive lens which are similar enough that all the groups can rely on the object to mean certain things, or to motivate certain kinds of performances. The groups can use these similarities to communicate with one another, or to coordinate their actions: the boundary object becomes a part of the fabric of their shared contexts. Thus, boundary objects "are weakly structured in common use" (Bowker & Star 1999, 297) because the participants are confined to drawing on the similarities between their interpretations of the object, "and become strongly structured in individual-site use" (Bowker & Star 1999, 297) because each individual group's interpretation is typically quite rich, and tailored to their own interests.

As Lee (2007) emphasizes, boundary objects are not the only way in which work can be coordinated between different groups. For example, Star & Griesemer's (1989) concept of methods standardization was another way for coordinating work; by following the same method, groups with radically different interpretations of the steps of the method or the purpose of adhering to the method could still coordinate their work, because the product of the method would be equally reliable to each group, even if each group used its own semantics to interpret the product. Star & Griesemer (1989) use Grinnell's standardization of methods for collecting specimens to illustrate how scientists and trappers, who had radically different interpretations of the meaning of the different steps, still could rely on the product of the method if the steps were followed. For example, killing the animal without clubbing it to the scientists meant that the bone-structure of the animal was preserved, whereas to the trappers it meant that the eccentricities of the scientists forced them to abandon standard killing techniques and possibly expose themselves to more risk from the animal. However, when the method was followed, the dead animal could be used as a specimen by the scientists, and the trappers would get paid by the scientists or their representatives. Thus following the method created a reliable product for both groups. Of course, the specimen collection method itself, whatever its semantic (list, description) or material (ink-on paper, memorized by individuals) form, was a boundary object which facilitated communication between the trappers and the scientists. Each recognized the method as consisting of directives for trapping animals, and each recognized the kind of behavior that accorded with each directive and the kind of behavior that violated each directive. This allows conversation about practice to occur, such as the ability of the scientist to threaten to withhold or reduce payment to trappers for specimens which are clubbed to death. Because of the different mechanisms for coordination, Lee (2007) recommends for purposes of clarity that care should be taken as to what kind of phenomena is termed a "boundary object", a practice she suggests does not always happen in the research literature.

Precisely how the groups referred to in boundary objects theory should be defined is not entirely clear. While Bowker & Star (1999) utilize Lave & Wenger's (1991) community of practice construct, they also mention that these groups can be conceptualized using Strauss's (1978) social worlds. Furthermore, Star & Griesemer (1989) do not use any theoretical construct to identify groups, and some of the groups they identify seem to be constituted out of individuals (e.g., Grinnell, Alexander). Given the lack of unity in how the term "community of practice" is used in the literature, even by those who coined it (Cox 2005), it seems safe to conclude that there is some flexibility in defining these groups, and that similar constructs such as folk groups (Toelken 1996) may be equally valid, as long as they define groups based on shared context of some sort, and distinguish groups based on a lack of such context.

The power of the theoretical construct of a boundary object is its utility as an analytical tool. It is an excellent example of a phenomena-oriented theoretical construct (POTC; see Q1, Q3). As such, the theory can be applied in a number of ways. First, boundary objects can be used as a sensitizing concept when engaging in analytic study, either by researchers or by designers performing requirements analysis. By identifying instances of boundary objects, one can improve one's understanding of how work is being coordinated, what important shared understandings exist between groups, and how individual group understandings differ from one another, where they might be in conflict, and where more articulation work might be needed to establish more effective cooperative practice in the future. Second, boundary objects can be used after data has been collected and analyzed to explain why certain emergent patterns in the data exist, thus providing a framework in which they can be conceptualized. This second use can be applied whether or not boundary objects were used as an initial sensitizing concept. The first use provides a mechanism for focusing the analyst's attention; the second use provides a mechanism for interpreting patterns and structures in the collected data. Third, boundary objects can be used to articulate requirements for a particular design. In this case, the need for a boundary object has been recognized and established, and the theoretical construct can be used to help articulate how a particular design will need to function if it is going to be adopted by a certain population of users. Thus, the construct of a boundary object can be used to suggest types of coordination work that need to be supported, and then can be used to evaluate whether a particular proposed design either (a) can be used to support such coordination, or (b) whether it is supporting such coordination once provided to users.

The theoretical construct of a boundary object, however, is not directly useful in design in that it does not provide clear directives. While it is clear that many designs need to function as boundary objects, and that many designs need to facilitate the process of creating or negotiating boundary objects, the theory of boundary objects as originally stated has little to say about how to design, create, or otherwise build boundary objects. Engaging in methods standardization is one way to coordinate behavior, and from such work one or more boundary objects might be created (e.g., the standardized method; Star & Griesemer 1989). Bowker & Star (1999) generalize this point, indicating that any form of standards creation is a negotiation process that will produce one or more boundary objects. However, while the contribution of standards negotiation is clear, it is not clear that this is the only way to create functional boundary objects (despite Lee's 2007 assertion to the contrary) since boundary objects can exist in a temporally bounded locality and such objects are as likely to be emergent from practice as negotiated by various stakeholders. Furthermore, even the process of standards negotiation, while detailed by Bowker & Star (1999), needs more theoretical modeling for its mechanisms to be exposed to the point where it will be useful for designers beyond simple awareness-raising.

As an example of how boundary objects can be used, consider the situation detailed in Table 6-1. The "documents" directory has clearly become a boundary object for the project participants. Most participants would agree that it functions as a document repository for the project, no matter how flawed in structure, and no matter how difficult it is to use it as such. Thus, the "documents" directory has a shared identity that spans the groups, both as a "repository", and as a location where files can be uploaded, browsed, linked to, and downloaded. The character of this repository, what it is, what it should be, what it needs to be, however, has very different interpretations among the different stakeholders.

The administrative assistants, the PhD students, and the professors understand the repository and its purpose in very different, even conflicting ways. The PhD students want order so they can find everything, the professors want to clean it up by eliminating all the non-research-paper documents in the repository in a move that would partially destroy it as a tool for the PhD students and completely destroy it as a tool for the administrative assistants, and the administrative assistants want to use it without having to understand all the details of the project, and would be happy to do so to help reduce clutter if someone would only tell them how. Thus, by analyzing the "documents" directory as a boundary object, the designers can get a sense of both how it currently functions as a successful boundary object, and how any future implementation would need to maintain those functions, even if the single identity the folder now has is distributed among multiple document management systems. Furthermore, it is clear that no standardization work has been done with this directory: it is why the motivation for redesign exists in the first place. Yet the directory still serves as a boundary object, even though it is not very efficient in doing so: the work of the professors, PhD students, and administrative assistants remains coordinated.