Abstract

This article offers an analysis of the process of co-evolution as observed in the computer-mediated collaborative systems and practices of a university museum. It presents results from a longitudinal case study of the design and development of a collaborative process to pack and move a museum's collections over a period of five years. Drawing upon a specific set of collaboration records spanning 18 months, the article identifies three factors that influenced the co-evolution of the computer-mediated collaborative systems and practices in use at the museum. The article concludes by examining the potential impact of these factors on the design of computer-mediated collaborative systems, in order to shed light on the wider issue of co-evolution of collaborative systems and practices in all organizations.

Introduction

One difficulty with developing computer-mediated collaborative systems is that collaborative systems should be designed to evolve as the collaborative practices supported by those systems change. The needs of collaborative workers are not normally static, and even systems that initially meet their needs will have to change if they are to continue to enable and support collaborative practices over time (Dourish, 2003; Sikkel, Ruel, & Wieringa, 1999). As collaborative systems evolve to support new practices, however, those practices often change to reflect the new capabilities of the collaborative systems, a process called co-evolution (O'Day, Bobrow, & Shirley, 1996; Orlikowski, 1992a; Rogers, 1994; Yates, 1993).

The co-evolution of collaborative systems and practices presents certain challenges to the developers and users of computer-mediated collaborative systems (Andriessen, Hettinga, & Wulf, 2003; Dourish, 1995). Evolving collaborative systems and practices constantly can be time-consuming and expensive, but not supporting change can lead to stagnation and the eventual failure of collaborative work. If the "socio-technical gap" between the social practices that the collaborative systems are designed to support and the technical capabilities of the collaborative systems themselves becomes too large, then the ability of the system to support work can fail and work practices suffer as a result (Ackerman, 2000).

To help users cope with the challenges of co-evolution, many studies have examined how collaborative workers and designers complete tasks in the face of unexpected events, adapt standard, off-the-shelf software to their own unique environments, and develop systems capable of supporting unanticipated needs (Gasser, 1986; Robinson, 1993; Suchman, 1996). These studies have shown that successful collaborative systems have several common characteristics that help users and designers cope with the problems of co-evolution. Some of these shared characteristics are:

1. They provide affordances that allow users to adapt systems to meet their own unique needs over time (Bødker & Grønbaek, 1991; Trigg & Bødker, 1994).
2. They are usually designed with the understanding that evolution is inevitable and that systems should allow for unpredictable yet necessary changes (Schmidt & Bannon, 1992).
3. They tend to encourage users to become directly involved in the development of their own systems (Mackay, 1992; Nardi, 1993).

Designing computer-mediated collaborative systems with all of these capabilities, however, can be very difficult. While many studies have documented the outcomes of co-evolving collaborative systems and practices, few studies have fully explored the process of co-evolution (Huysman et al., 2003; Torpel, Pipek, & Rittenbruch, 2003). Thus, even though the overall difficulties posed by co-evolution have been well documented, we still have much to learn about the actual process through which co-evolution occurs. No universally-accepted conceptual model exists to explain the co-evolution of complex collaborative systems (Andriessen et al., 2003). In part, this is due to the lack of detailed, longitudinal studies of organizations where co-evolution is in progress, as well as the inherent difficulties of gathering data about the complex processes whereby computer-mediated collaborative systems evolve.

One way to better our understanding of the co-evolution of collaborative systems and practices may be to study relatively simpler collaborative technologies which their users can more easily understand and modify, and which researchers can more easily study and analyze. Very simple technologies, even those not originally designed as collaboration tools, have proven very effective for encouraging collaborative work under the right circumstances (Nardi & Miller, 1991). These technologies often succeed where more complex collaborative systems fail, in part because they can make it easier for users to evolve systems when changes in collaborative practices demand changes to collaborative systems (Arias, Eden, Fisher, Gorman, & Scharff, 2000). A study of how collaborative workers use simple computer-mediated technologies to support co-evolution, therefore, could have valuable implications for the designers of all types of computer-mediated collaboration systems.

The study presented in this article analyzes the process of co-evolution as observed in the computer-mediated collaborative systems and practices of a university museum. From 1998 to 2002, the author conducted a longitudinal, instrumental case study of a museum which used a combination of very simple technologies-paper forms and relational database systems-to co-evolve collaborative practices and systems that supported the inventorying, packing, and shipping of museum artifacts during a move from old to new facilities (Marty, 2002). The simplicity of these collaborative technologies made them easy to manipulate; workers at the museum could implement and test new ideas on the fly, co-evolving systems and practices quickly and easily. This provided museum staff members with low-cost, low-risk methods of iteratively improving their collaborative systems as their collaborative practices evolved, and vice versa. In addition, by encouraging users to become more involved in the co-evolution of their systems and practices, museum staff members were able to develop more robust computer-mediated collaboration systems over the time period of the study (Twidale & Marty, 2000).

This article draws upon this analysis to present an overview of one particular portion of this museum's computer-mediated collaborative practices and systems: those which supported the museum's packing process. It discusses the evolution of this process over a period of 18 months, and provides examples of the co-evolution of packing practices and systems as implemented at the museum. Based on a qualitative analysis of collaboration records from this time period, the article identifies three factors primarily responsible for supporting co-evolution of the museum's collaborative packing systems and practices. The article concludes by discussing the potential impact of these factors on the design of computer-mediated collaborative systems in general and for encouraging the co-evolution of systems and practices in all organizations.

Literature Review: Co-Evolution and the Socio-Technical Gap

Ackerman (2000) uses the term "socio-technical gap" to describe "the great divide between what we know we must support socially and what we can support technically" (p. 303). As researchers who study Computer-Supported Cooperative Work (CSCW) are well aware, there are many reasons for conflicts between social or organizational practices and the technical capabilities of collaborative work systems (Bowker, Star, Turner, & Gasser, 1997). In general, technical systems are rigid, predefined, and resistant to change, while social practices are fluid, open to interpretation, and constantly evolving (Bentley et al., 1992; Grudin, 1994; Hewitt, 1986). Technical systems are usually designed with the assumption that their users will follow explicit, pre-specified rules, while actual work practices tend to involve exceptions and unexpected events as a norm (Heath & Luff, 1992; Luff, Hindmarsh, & Heath, 2000). These differences underscore the challenge faced by designers and users who expect collaborative systems to change to reflect new user needs, while those same needs change to reflect the new capabilities of the system.

The Challenge of Co-Evolution

As a consequence of the socio-technical gap, computer-mediated collaborative systems rarely offer technical capabilities that fully match their users' social needs. The users of collaborative systems, therefore, tend to adapt their social practices to the technical capabilities of the system; at the same time, however, they expect those technical capabilities to evolve to keep pace with their changing needs (O'Day et al., 1996). This relationship is typically called "co-evolution" (cf. Janzen, 1980; Rogers, 1994; Yates, 1993), or "co-adaptation," since "individuals both adapt to the technology, but also adapt it for their own purposes" (Mackay, 2000, p. 179). While we will use the term "co-evolution" in this article, this relationship—whatever one chooses to call it—is a central component of traditional socio-technical systems theory (cf. Allen, 1993; Bonen, 1981).

The co-evolutionary process has been studied in a variety of organizations (Abbott & Sarin, 1994; Bannon & Bødker, 1991; Bowers, Button, & Sharrock, 1995; Hewitt, 1986; Marchionini, 2002; Okamura, Fujimoto, Orlikowski, & Yates, 1994). Designing and developing collaborative systems that are capable of supporting and actively encouraging co-evolution is one of the known challenges to developing computer-supported cooperative work systems. Despite its inherent difficulty, researchers have been studying methods of developing collaborative systems that support co-evolution for two main reasons. First, it is important that computer-mediated collaborative systems reflect the actual work practices of the systems' users (Bowker et al., 1997; Dourish, 2003). Many studies of collaborative systems have demonstrated that users will refuse to use collaborative systems that do not support their needs (Grudin, 1989; Luff et al., 2000; Orlikowski, 1992b; Suchman, 1983). Although determining users' needs in advance can seem straightforward, traditional requirements capture techniques can ultimately prove to be very difficult; simply asking people to identify their needs does not tend to provide sufficient information to design systems that actually meet users' needs, and even if systems meet users' needs initially, these needs tend to change over time (Hughes, King, Mariani, Rodden, & Anderson, 1994; Jirotka & Goguen, 1994; Rogers, 1997; Sommerville, Rodden, Sawyer, Bentley, & Twidale, 1992).

The second reason is that it is important that computer-mediated collaborative systems be able to evolve along with the users' changing needs (Arias et al., 2000; Marsic, 2003). Designers cannot build a collaborative system that never changes and expect that it will continue to meet users' needs over the years to come, nor can they build a system assuming a priori that they know everything about the users' needs and that those needs will never change. Computer-mediated collaborative systems that cannot change along with the needs of their users will eventually stop supporting the users' requirements. The best way to ensure that computer-mediated collaborative systems continue to meet user needs throughout the lifecycle of the system is to take an iterative approach to designing the system that involves representative users in all stages of the design process (Rosson & Carroll, 2001). While this may sound obvious, it can very be difficult to continually evolve systems and processes in the workplace, even with expert mediators and system designers working closely with users (Rogers, 1994).

Coping with Constant Change

A concern of many CSCW researchers is that of the problem of developing collaborative systems capable of co-evolving to meet needs that cannot be predicted in advance. In addressing this problem, researchers have taken a wide variety of theoretical stances and research approaches (Bannon & Schmidt, 1991; Schmidt & Simone, 1996). From this research have come many potential solutions and many exemplary collaborative systems developed to explore methods of encouraging co-evolution. An attempt to provide even a cursory survey of this research literature in its entirety would be far beyond the scope of this article. We therefore limit ourselves to a few key points.

Most CSCW researchers and developers understand that no representation of workflow in any organization can be necessarily complete (Gerson & Star, 1986). It is necessary, therefore, to pursue approaches that allow collaborative systems to evolve over time. Gasser (1986), for example, looks at how workers use different strategies (or workarounds) to accommodate the unexpected when performing work. Sikkel et al. (1999) examine the evolutionary implementation of groupware systems. Schmidt and Simone (1996) identify coordination mechanisms that enable people to complete tasks even in the face of unexpected events. Robinson (1993) studies how designers can build workflow systems capable of supporting the unanticipated needs of their users (cf. Pekkola, 2003). Other researchers have explored how organizations can support and encourage such activities among their employees (Dourish, Holmes, MacLean, Marqvardsen, & Zbyslaw, 1996; Grinter, 1996; Schmidt & Bannon, 1992).

One valuable line of inquiry has focused on how system designers can build systems that encourage a "tailoring culture" (Bødker, 2000; MacLean, Carter, Lovstrand, & Moran, 1990; Wulf, 1999). Trigg and Bødker (1994), for example, have looked at how workers adapt standard, off-the-shelf software to their own unique environments. Dourish (2003) argues that tailoring or "appropriation" is inherent to collaborative practices, asserting that "appropriation lies at the intersection of technical design and social practice" (p. 467). Elsewhere, Dourish (1995) argues that "research on customisation and coadaptivity shows that this evolution has its roots in the social aspects of work and is enabled, in part, through the sharing of customisations" (p. 45). This approach to socio-technical collaboration has helped researchers understand how "articulation work" adjusts collaborative practices to account for unexpected events, as well as other types of "invisible work" that operate behind-the-scenes to ensure that the visible, up-front work gets accomplished (Bowers, 1994; Button & Sharrock, 1994; Star & Strauss, 1999; Strauss, 1985; Suchman, 1995).

There has also been significant work done on the effect of co-evolution on computer-mediated communication systems (Ackerman, 2000). For instance, studies of the impact of electronic mail on communication in organizations illustrate how workers co-adapt new technologies and their social practices (Eveland & Bikson, 1988; Sproull & Kiesler, 1986). Similarly, studies of electronic mail filters, such as "Information Lens" (Mackay et al., 1989), or news group filters, such as "Group-Lens" (Resnick, Iacovou, Suchak, Bergstrom, & Riedl 1994), illustrate how "individuals do not simply respond to technology, they re-interpret it and adapt it for their current needs, often in ways unanticipated by the designers of the system" (Mackay, 2000). Researchers have examined the functioning of co-evolution in virtual communities or social worlds such as MUDs or MOOs (O'Day et al., 1996), in electronic classroom environments (cf. DeSanctis & Monge, 1998; Duin, 1991; Hiltz, 1994), and in many other areas of computer-mediated communication (Chen & Rada, 1996; Chidambaram, 1996; Hollingshead, McGrath, & O'Connor, 1993; Huysman et al., 2003; Karsten, 2003; Walther, 1995).

Seeking a Conceptual Framework for Evolving Use

Despite this multitude of approaches, one common complaint in the literature is that research into the co-evolution of computer-mediated collaboration systems has been hampered by the lack of a conceptual model that explains the process of co-evolution between collaborative systems and practices (Jørgensen, 2001). Without this understanding, it is extremely difficult to develop systems capable of evolving over time to meet ever-changing organizational needs. According to Dourish (1995), if the developers of collaborative systems are truly to support evolving collaborative work practices, they must

be concerned with the longer-term view of the evolution of the system. […] The issue for system designers, then, is to develop a set of techniques for constructing software systems that enable the distribution of the design phase throughout the whole life cycle of a system, and which support software adaptation and evolution. (pp. 45-46)

To accomplish this, we need more studies of co-evolution, especially long-term longitudinal case studies that draw upon multiple theoretical approaches, to try to understand the process of co-evolution. Focusing on the co-evolution process, instead of the outcomes of co-evolution, offers researchers their best opportunity to understand the factors that influence co-evolution, yet few studies have taken that approach (Andriessen et al., 2003).

Perhaps one reason that few articles study the process of co-evolution in action is that it can be very difficult to develop or obtain access to the right sort of study. There are three problems that the researcher must overcome when studying the evolution of collaborative systems. First, data that document evolutionary processes can be difficult to acquire: It is common for researchers to have access to data that document the state of collaborative systems and practices before and after the introduction of systems into organizations, yet not so common to have access to data that document the processes that take place between those start and end points. Second, co-evolutionary changes to collaborative systems and practices generally occur slowly, over a long period of time, which can make them very difficult to study. Finally, the inherent complexity of most computer-mediated collaborative systems tends to hide the co-evolution process behind the scenes, making it very difficult for the researcher to uncover the underlying reasons behind events.

One potential solution to these problems is to study the co-evolutionary processes that occur in very simple collaborative technologies where all changes are highly visible and easily documented. Studies of simple technologies not originally intended for collaboration, such as spreadsheets, have proven useful for highlighting collaborative processes that would have been much more difficult to identify in more complicated systems (Nardi & Miller, 1991). Having access to simple, open technologies that change in obvious ways should also make it easier for researchers to observe the co-evolution process in action over a long period of time.

This study, therefore will examine the evolution of relatively simple technologies used in a university museum to explore the factors that influenced the co-evolution process. It will explore the following research questions: What are some of the factors that influence the process of co-evolution so that collaborative systems and practices can evolve gradually over time, each influencing and being influenced by the other? How can users and developers of such systems encourage the co-evolution process in a way that results in more robust collaborative systems and practices overall? Answering these questions will take us one step closer to having a better understanding of the co-evolution process in action. Although we will remain far from the ultimate goal of developing a conceptual framework to explain this process in all organizations, the results of this study will shed light on the broader issue of co-evolution in general.

Research Methods: Studying the Process of Co-Evolution in a University Museum

The Spurlock Museum is the museum of world cultures at the University of Illinois at Urbana-Champaign. From 1997 to 2002, staff members at this museum worked to move 45,000 artifacts across campus from old to new facilities. These collections had previously been stored and displayed in the attic of a 100-year-old building, with little space, no climate control, and poor lighting. In March 2000, construction was completed on a brand-new modern museum facility, with nearly three times the square footage of the previous facility. The museum staff had only five years to inventory, pack, and move their artifacts, while simultaneously working with exhibit designers and architects to design, build, and install all of the exhibits in the new facility.

Museum staff members had never done anything like this before , and they had in place neither the collaborative systems nor collaborative practices necessary to support this move. They had to train employees to inventory and digitize information about their artifacts (the museum's only previous attempt at a full inventory had been in 1973). They had to develop methods of packing their collections so that they could be safely moved across campus. They had to develop procedures to track and move thousands of boxes to the new facility without losing a single artifact. To support all of these activities, they needed to design and develop computer-mediated collaborative systems and practices from scratch in a very short period of time (Marty, 1999, 2000).

The development and subsequent evolution of these collaborative systems and practices provides valuable data that can be used to inform a study of co-evolution. The collaborative systems developed by museum staff members to coordinate the process of moving the museum were a combination of paper forms and very simple database systems (built using Filemaker Pro). These simple technologies were used to track the whole moving process through all of its components: inventory, packing, shipping, exhibit design and installation, etc. These systems also had to support the collaborative practices of the many different stakeholders working in different areas of the museum (registration, collections, exhibit design, etc.) as they worked together to move the museum. Since museum staff members had never done anything like this before, they did not know in advance exactly what they had to do, so over time their practices evolved, and their systems evolved with them.

From 1998 to 2002, the author conducted a longitudinal, instrumental case study (Stake, 1995; Yin, 2002) to study the evolution of the museum's information systems as they coped with these challenges (Marty, 2002). During this time, the author worked at the Spurlock Museum as Director of Information Technology, and served as a participant observer in the iterative design process, conducting ethnographic observations of the co-evolution process in action (Benson & Hughes, 1983; Hutchins, 1995). For these reasons, the author had access to a wide variety of data, including manuals that document the practices of the museum staff, all iterations of the museum's collaborative systems, and transaction logs that show how museum employees interacted with their systems at all stages over a period of five years. This availability of these data offers a unique opportunity to shed valuable light on the process of co-evolution in action.

Drawing upon Multiple Theories to Explore Co-Evolution in Action

The primary theoretical basis for this study was grounded theory informed by a number of additional theories of how technical systems are adapted in social settings (Strauss & Corbin, 1998). Recently, several researchers have argued that the use of multiple theories to guide the data collection and analysis is necessary to clarify instances in the data which illustrate the co-evolution process in action (Andriessen et al., 2003). Many different theoretical frameworks have been proposed in the research literature to evaluate the co-evolution of collaborative systems and practices.

Researchers have used Adaptive Structuration Theory (DeSanctis & Poole, 1994) to explore the way groups appropriate information technologies in different ways (cf. Dourish, 2003). Adaptive Structuration Theory has helped many CSCW researchers explore how users adapt systems to meet their needs (Poole & DeSanctis, 1990). Activity Theory (Kuutti, 1992) has also been useful for explaining the relationship between tasks and artifacts and the context in which actions take place (Carroll, Kellogg, & Rosson, 1991). Similar to the appropriation process in Adaptive Structuration Theory, Activity Theory helps explain how "the dynamics of mutual adaptation of contradictions, inconsistencies, and 'mismatches' results in changing tools, members, rules, or objectives…" (Andreissen et al., 2003, p. 375). In addition, the Theory of Self-Organizing Social Systems (Foerester, 1984) offers a potentially valuable framework for exploring the relationships between technical and social systems that CSCW researchers have only just started to explore (cf. Eriksson & Wulf, 1999).

While each theoretical framework has its own advantages and disadvantages, there are two things they all share in common. First, each takes into consideration the fact that collaborative systems evolve incrementally over time. As each new system is developed, it must be integrated into the existing set of relationships that forms the current infrastructure of the organization (Star & Ruhleder, 1996). Star (1999) states that infrastructure

is fixed in modular increments, not all at once or globally. Because infrastructure is big, layered, and complex, and because it means different things locally, it is never changed from above. Changes take time and negotiation, and adjustment with other aspects of the systems are involved. (p. 382)

Second, each theoretical framework offers researchers a similar understanding of where co-evolution occurs in organizational processes. Each in their own way and their own terminologies, focus on those moments where users have to resolve inconsistencies, contradictions, breakdowns, or other situations where the normally transparent differences between systems and practice become visible. Thus, to understand co-evolution in process, researchers should look for examples of inconsistencies that illustrate those transition periods or periods of adjustment.

Finding these inconsistencies in computer-mediated collaborative systems can be very difficult because conflicts between system and practice are not easily recorded or discoverable (for the reasons discussed above). The simple technologies the museum staff used, however, along with their habit of meticulously recording information about their process of moving the museum as part of developing and using the museum's collaborative systems, helps bring these inconsistencies to the forefront. The available data clearly illustrate those places where the practices and systems used by the museum staff to move their museum differed over time. By examining these data throughout the entire process, the co-evolution of the museum's systems and practices can be observed and studied.

Searching for Inconsistencies to Understand the Co-Evolution Process

In order to reduce the available data to a more manageable level, this study examines the co-evolution of one specific set of collaborative system and practices: those developed to support the packing of the museum's collections. From August 1998 to March 2000, museum staff members packed 27,166 artifacts into 1,408 boxes, while the collaborative systems and practices that supported the packing process evolved through many different iterations. By examining the evolution of this process during this time period, we can identify the factors that influenced the co-evolution of collaborative systems and practices at this museum, in the hope that an examination of these factors will shed light on the wider issue of co-evolution of collaborative systems and practices in organizations in general.

The records left behind by the museum staff as they packed each of the 1,408 boxes document the collaborative systems and practices in place at the exact instance in time when each box was packed. By comparing these records from box to box, we can find inconsistencies among collaborative systems and practices that indicate co-evolution was in progress. This provides us the opportunity to study the co-evolution process at the Spurlock Museum in two different ways.

First, we can study those places where the co-evolution of systems and practices caused inconsistencies, where the way the systems were used in practice did not match the way the systems were "supposed" to be used. The museum's database, for instance, might continue to require a particular type of information to be recorded as a box is packed, even if museum employees have already changed their practices to document different information. Since changes to collaborative systems and practices typically lagged behind each other by several days, if not weeks, places where we find these inconsistencies indicate the process of co-evolution in action. By examining how museum staff members dealt with these problems, we gain insights into how organizations can cope with changing systems and practices where employees try to accomplish a task not technically supported by the system, or vice versa.

Second, because the museum's collaborative systems comprised two separate technologies (paper forms and electronic databases), we can study those places where the evolution of these collaborative systems resulted in discontinuities between these two system components. When changes in the museum's collaborative practices necessitated changes to the museum's collaborative systems, these paper and electronic components were not always modified at the same time: A new field, for example, might be added to a paper form days (or weeks) before the corresponding field was added to the electronic database. These mismatches among system components, therefore, are also good indicators of places where co-evolution is occurring. By examining how the problems caused by these differences were resolved, we can learn a great deal about how organizations can support and manage the co-evolution process.

Having identified those instances where the museum's collaborative practices and systems were experiencing discontinuities, therefore, we took a grounded theory approach to analyzing the processes by which museum staff members resolved these differences and co-evolved their collaborative systems and practices. Analyzing the packing of each of 1,408 boxes, we used a process of coding and memoing, as outlined by Strauss and Corbin (1998), to develop an understanding of the museum staff members' activities and to create a list of dimensions that influenced the co-evolution of systems and practices in the museum. This kind of analysis was an iterative, on-going process where records from each box were analyzed as part of a continual process of exploring the data to identify emergent themes and dimensions. By studying how museum staff members handled their own examples of co-evolution, we identified several factors that influenced the co-evolution of collaborative practices and systems at the museum. The results of this analysis, therefore, will provide us with a better understanding of the co-evolution process, which can be used to help improve more complicated computer-mediated collaborative systems in the future.

Results: Co-Evolution at Work in a University Museum

The packing process at the Spurlock Museum was a collaborative workflow system that coordinated the efforts of 10 full time staff members and several dozen part-time students and volunteers working to move the museum's collections (Marty, 2002). As with all the other moving activities at the museum, the packing process involved multiple technologies and multiple users. The collaborative systems included two types of technologies: paper forms and relational database systems. The users of these systems included museum staff members primarily working in two different museum departments, Registration and Collections (see below).

The collaborative systems and practices that supported packing evolved over time, as museum staff members learned new methods of interacting with the artifacts and with each other. In order to explore this process of co-evolution, we will first examine the collaborative systems and practices used by the museum staff to pack the museum as these existed at the culmination of the museum's packing process. Then, we will examine the process by which these systems and practices co-evolved over 18 months, exploring detailed examples of the co-evolution process in action. Finally, we will discuss how these examples illustrate significant factors at work in the museum that influenced the co-evolution process.

Collaborative Systems and Practices for Packing a Museum

The process of packing the museum's collections was the responsibility of two museum departments: "Registration" and "Collections." Artifacts ready to be packed were identified by Registration staff members and brought into the packing area by Collections staff members. Throughout the packing process, museum staff recorded their actions on a Packing Data Sheet-the physical (paper) component of the collaborative system that supported packing (see Figure 1 for a sample, completed Packing Data Sheet). The first step in completing a Packing Data Sheet was to fill in the number of the box being packed (all boxes were assigned sequential numbers) and to mark additional information such as whether the box had been pre-fabricated or constructed specifically for these objects. A Collections staff member then packed artifacts within the box, using a variety of packing methods (indicated by "Packing Type"). As each artifact was packed in the box, the artifact's accession number was recorded in the "Box Contents" area. The general "Material Types" found in the box were marked as well as whether the box contained artifacts susceptible to infestation. Once the box was completed, a supervisor approved the box, and recorded any additional comments in the area marked "Packing Remarks." One copy of a completed Packing Data Sheet was sent to Registration, while one copy remained with the box in Collections.

Registration staff members entered information from the Packing Data Sheet into the Packing Database-the electronic component of the collaborative system that supported packing (see Figure 2 for a sample, completed Packing Database record). Having retrieved the correct record, Registration employees entered the Box Type, Packing Type, Material Types, and Integrated Pest Management information directly into the Packing Database. They then recorded the names of the people who packed and supervised the box, along with the dates of these activities. At this point, the employee switched to a different database (one used to record information about the museum's collections) and retrieved the object record for the first item packed in this box as recorded under Box Contents on the Packing Data Sheet. For each item packed in the box, the Registration staff member would enter the number of the box in which the artifact was packed. Once finished, the staff member returned to the Packing database and double checked the box's inventory. Finally, the Registration employee recorded his or her name and the date on the bottom of the Packing Data Sheet by the words "Entered By." On some future date, an additional Registration employee, sometimes the museum's Registrar, rechecked the data in the record, comparing the electronic values to the entries on the Packing Data Sheet.

Once the data were entered into the Packing Database, the Packing Data Sheet was returned to Collections. If there were any problems with the sheet, Collections staff members would try to resolve them (cf. Twidale & Marty, 2000). If there were no problems, the Packing Data Sheet would be returned with a "Packing Label" that contained an inventory of the artifacts packed within the box. If the Packing Label matched the Packing Data Sheet this was noted in the "Label Check" area and the label was affixed to the side of the box. At this point, the box was sealed, removed from the Packing area, and placed elsewhere in the museum to await the move (a process called "zoning"). The final location (or zone) of the box was recorded on the Packing Data Sheet, which was then returned to Registration where this information was entered into the Packing Database.

The Co-Evolution of the Packing Process at the Spurlock Museum

This process of packing the museum evolved over 18 months as the collaborative systems and practices that supported it co-evolved. The way museum staff members packed a box at the beginning of this process was not the way they packed a box at the end of the process. Nor were the collaborative systems used by museum staff members when they began to pack the museum the same systems they used when they finished packing the museum. The co-evolutionary changes to both collaborative systems and practices can be seen by examining the different iterations of the Packing Data Sheets and the Packing Database used by museum staff to track information about packed boxes over the time period of this study.

As museum staff members refined their notions of what information should be tracked as each box was packed, a new iteration of either the paper form or electronic database was created to match these new needs. While packing the museum's collections, Spurlock staff members created five iterations of the Packing Data Sheets (referred to below as PDS Iterations 1 to 5) and seven iterations of the Packing Database (referred to below as DB Iterations 1 to 7). A rough timeline of this evolutionary process is presented in Table 1.

To help readers follow the discussion, we have also provided an interactive timeline that offers the ability to step through each iteration of the museum's collaborative systems:

For a detailed discussion of the evolution of these systems and their use as part of the packing process, see Marty (2002), who analyzes in detail the step-by-step evolution of the museum's collaborative systems. For the purposes of this article, each iteration of the museum's information system should be seen as the understood, officially "correct" method of packing a box at any given time. As museum staff members packed each box, however, they frequently diverged unexpectedly from this "ideal" method of packing. For instance, the Packing Data Sheet might be used in unexpected ways by the museum staff, or the normal use of the Packing Database might produce an unexpected result, and museum staff members would need to adapt to a new situation. This need to cope with the unexpected use of existing systems often increased the overall stability and robustness of the museum's overall collaborative practices and systems (cf. Twidale & Marty, 2000). Each new iteration of the Packing Data Sheets or the Packing Database, therefore, reflects an improved understanding on the part of museum staff members about the process of packing their collections. We turn now to a discussion of several examples of co-evolution at the museum, separated into two categories: inconsistencies between systems and practices; and inconsistencies among system components.

Co-Evolutionary Inconsistencies Between Collaborative Systems and Practices

As the museum's collaborative practices for packing changed, the museum's collaborative systems for packing changed as well, and vice versa. As these changes occurred, the museum's collaborative systems frequently lagged behind their collaborative practices, and vice versa. The museum's packing records document those cases where the way the museum's collaborative systems were supposed to be used differed from the way museum staff members actually used them in the process of packing a box. Out of the 1,408 boxes analyzed, approximately 400 boxes showed some indication of this form of inconsistency, where museum employees had to manipulate the system to account for discrepancies between collaborative systems and practices. If changing museum practices, for example, required museum staff members to record some new piece of data on a Packing Data Sheet, yet a designated field for that information had not yet been added to the paper form, museum staff members often had to append that new information somewhere on the Packing Data Sheet.

Example 1: Packing Label Check

When a Packing Data Sheet had been successfully entered into the Packing Database, a Packing Label was generated, listing the inventory numbers of the box's contents. Before this label was affixed to the box, it was double-checked against the contents written on the Packing Data Sheet. If correct, both Packing Label and Packing Data Sheet were checked off by Collections staff members, initialed and dated. This "checking off" activity was not initially a formally required activity on the part of Collections staff members; it was simply a convenient way for Collections employees to keep track of which boxes had had their Packing Labels checked. For this reason, there was no formal field on the Packing Data Sheet for recording this information; the check was simply recorded wherever there was room. As more and more information started to be tracked on the Packing Data Sheets, they often became covered with collections of checkmarks, initials, and dates, and it soon became difficult to know which checkmark referred to what activity. Only an expert would know, for instance, that Figure 3a shows a "label check" being performed by "MMP" on August 16, 1999, for Box 800 (see highlighted area of form). Eventually, Collections staff members added a field to the fifth iteration of the Packing Data Sheet (PDS Iteration 5), making it very clear which checkmark on the Packing Data Sheet corresponded to the "Label Check" (Figure 3b).

Example 2: Zoning a Packed Box

When a box was zoned, i.e., when it was sealed and stored in the museum to await the move, the destination of the box was recorded on the Packing Data Sheet and entered into the Packing Database. In the very first iterations of both paper and electronic formats, information was recorded differently: Employees using PDS Iteration 1 were only required to record the box's location, while employees using the first iteration of the database system (DB Iteration 1) were also required to record the name of the person who moved the box into a zone as well as the date that this happened. The Packing Database, therefore, was originally set up to record more information about zoning a box than was the Packing Data Sheet. The existence of this capability in the database had an immediate effect on the Collections employees who were zoning boxes.

Despite the lack of any formal fields on PDS Iteration 1 for recording this information, Collections staff members immediately began making annotations directly on the Packing Data Sheet about who zoned the box, and when, believing that this information might be important later on (see Figure 4a). These annotations were not recorded in any systematic fashion: Sometimes only a date was recorded, sometimes initials and a date, and it was often unclear who exactly was doing what to the box (as there was a difference between entering data and zoning a box). This confusion was cleared up with the introduction of PDS Iteration 2. This new iteration of the Packing Data Sheet demonstrates the speed at which new ideas could be integrated into the museum's evolving information system: It took only four days from the time when the very first boxes were zoned to the creation of the new Packing Data Sheet. The new iteration (PDS Iteration 2) not only formalized the informal initial/date pairs, it clarified the zoning vs. entering problem, carefully delineating who did what (see Figure 4b).

This modification had a very interesting side effect. With the introduction of PDS Iteration 2, the Packing Data Sheet became more formal than the Packing Database. The Packing Database was designed with the implicit assumption that the person entering the information into the database would be the same person who had zoned the box in the first place. As it happened, this was often the case, especially in the early months of packing. Over the next few months, however, the museum staff gradually settled into a routine in which Collections staff packed and moved boxes, and Registration staff performed data entry. Registration employees could have solved this problem by introducing another field into the system; instead, they annotated their entry into the existing field, extending it to include their initials as the person who performed data entry. In this way, a formal change on the Packing Data Sheet prompted an informal change to work practices, i.e., in the way Registration staff worked with the Packing Database.

Co-Evolutionary Inconsistencies Within Collaborative Systems

When changes were made to one part of the museum's collaborative systems (e.g., the Packing Database), corresponding changes usually needed to be made in the other part of the museum's systems (e.g., the Packing Data Sheets). The addition of new fields on the Packing Data Sheet, for instance, usually necessitated additional fields in the Packing Database. Similarly, new methods of recording data in the Packing Database often required new fields on the Packing Data Sheets. These changes, however, often took time to propagate from one format to the other, usually because Packing Data Sheets were completed in Collections a month or more before they were entered into the Packing Database in Registration. Because of this lag time, places where the Packing Data Sheets and Packing Database are inconsistent serve to document changes to the packing process, highlighting places where practice and systems are evolving differently. Out of the 1,408 boxes analyzed, approximately 250 boxes showed some indication of this form of inconsistency, where the structure of the Packing Data Sheets does not match the structure of the Packing Database. By exploring the interactions between the Packing Data Sheets and the Packing Database as they evolved from iteration to iteration, we can gain greater insights into those places where co-evolution was happening.

Example 3: Packing Type Mismatch

When the first few Packing Data Sheets (PDS Iteration 1) were entered into the Packing Database (DB Iteration 1), the Packing Database had a specific checklist of six options for possible Packing Type options (Figure 5a) while the Packing Data Sheet had only a free text field (Figure 5b). This difference created a disconnect between the electronic and paper components of the museum's systems. Even though these six options had already been identified, Collections employees still had to handwrite the packing type in the space provided. This had the potential to lead to confusion, as Collections staff members had the option of writing something in that space other than those six predetermined packing types (Box 246, for instance, was packed as "Tray/Partial Cavity," a confusing corruption of the allowed packing types). Even if Collections employees used the correct vocabulary, the information could still be written in a misleading fashion. Often, the way in which the packing type was written meant that the museum's Registrar had to intervene and correct the information. To avoid these potential problems, and to make things easier for museum staff members, the six possible packing types were added to the next iteration of the Packing Data Sheet (PDS Iteration 2) as a checklist (Figure 5c). This example, therefore, illustrates how differences between paper and electronic versions of fields could be quickly reconciled to simplify the tasks of all museum employees, with the result that the museum's overall systems were improved.

Example 4: Material Type Mismatch

At one point in the evolution of the packing process, the museum's Collections Manager decided that it would be useful for museum employees to record what material types were packed in each box (information that made the museum's Integrated Pest Management procedures more effective). A "Material Types" field was added to Packing Data Sheets (PDS Iteration 4) and the Packing Database (DB Iteration 3). At the same time, a checklist of options was created for this field. For unknown reasons, two different checklists were created for both the Packing Database and the Packing Data Sheets. The Packing Database (Figure 6a) used a list of seven material types: Ceramic (C), Metal (M), Stone (S), Textile (T), Organic (O), Paper (P), and Composite (X). On the Packing Data Sheet (Figure 6b), however, the Material Type field had only four possible values: Organic, Inorganic, Textiles, and Paper/Book (with no single letter codes attached to these terms). This difference between the two components of the museum's collaborative systems remained unresolved for slightly over two weeks, during which time nine boxes were packed, until the Database was changed to match the Packing Data Sheet (Figure 6c). Museum employees working in Registration had to cope with this inconsistency and decide how to proceed in entering these nine Packing Data Sheets into the Packing Database. Thus, they developed workarounds to the problem (e.g., explaining these discrepancies in a database comments field) which allowed them to proceed with data entry, returning to enter data in the new Material Types field once the inconsistency was resolved.

Towards an Understanding of Factors Supporting Co-Evolution in the Museum

These four examples illustrate certain characteristics of the museum's collaborative systems and processes that influenced the process of co-evolution in the museum. Examining these examples in light of the principles of co-evolution discussed above can help shed light on the underlying factors of the museum's systems and practices that encouraged co-evolution during the 18 months of this study.

In Example 1, an informal collaborative practice (label checking on the Packing Data Sheets), one not formally supported by the museum's systems, was formalized (by adding a field to the Packing Data Sheet), as this practice co-evolved with the museum's systems. What was before an optional, although common, activity in practice evolved into a required activity. This example shows how individuals, given the ability to create their own modifications to a form, may make changes for their own personal purposes that become formalized over time into a routine activity, encouraging the process of co-evolution.

In Example 2, formal differences between the intended usage of two different parts of the museum's collaborative systems (DB Iteration 1 and PDS Iteration 1) prompted unexpected changes to the museum's collaborative practices (informal annotations on PDS Iteration 1), which led to the co-evolution of the museum's systems as a new, formal set of fields was added to the second iteration of the Packing Data Sheet (PDS Iteration 2). Over time, these new fields, in turn, changed the collaborative practices of museum employees as they used the Packing Database. Thus, two different approaches to recording information about the same activity (zoning a box) led to a process of co-evolution that resulted in an overall improvement to the museum's collaborative systems and practices.

In Examples 3 and 4, changes to the museum's collaborative practices required similar changes to the museum's collaborative systems (the addition of new fields to both the Packing Data Sheets and the Packing Database), yet a time lag among requirements capture and implementation (a typical disconnect between system designers and system users) led to periods of inconsistency where the new fields were implemented one way in the Packing Data Sheets and a different way in the Packing Database. During these times, museum staff members had to find ways to cope with this situation until the inconsistencies could be resolved. While the museum's collaborative systems could not maintain such inconsistencies for long, the ability of the museum's employees to alter their collaborative practices to cope with unexpected and unanticipated problems in their collaborative systems helped strengthen the museum's systems and practices overall.

These and other examples uncovered during the analysis of 1,408 instances of the packing process suggest that three key factors contribute to the museum staff's ability to influence the co-evolution process and encourage museum employees to create systems that could evolve along with their changing needs and practices. These factors, and their implications for computer-mediated collaboration systems, are now discussed in more detail.

Discussion: Factors Influencing the Co-Evolution of Collaborative Systems and Practices

Analysis of the packing process at the Spurlock Museum led to the development of the following three factors that play an important role in influencing the co-evolution of collaborative systems and practices in organizations. Each factor, we argue, describes a different aspect of those environments most likely to support a process of co-evolution that will result in overall improvements to both systems and practices. In the museum, these factors were a natural outgrowth of the simple technologies used by the museum's employees; they illustrate important aspects of the museum's environment that encouraged the co-evolution process. If these factors could be enabled in more complex computer-mediated collaborative systems operating in other organizations, they could help designers create open systems capable of evolving at the hands of users, along with the needs of users, as those needs change.

Co-Evolution is Encouraged when Potential Changes to Collaborative Systems and Practices can be Tested Informally by Users First, then Formally Implemented by Designers Later

As illustrated by the examples above, the paper forms and relational database systems used by museum staff members to pack their museum were relatively easy to manipulate. Collaborative workers could implement and test new ideas on the fly, co-evolving systems and practices quickly and easily. This provided museum staff members with a low-cost, low-risk method of iteratively improving their collaborative systems as their collaborative practices evolved, and vice versa. They could test new ideas out before they implemented them, a low-cost solution to the cooperative prototyping approach (cf. Bødker & Grønbaek, 1991). They could adjust their systems to accommodate problems, coping more easily with unexpected needs as they arose (cf. Robinson, 1993). These capabilities encouraged museum staff members to participate in the co-evolution of their own collaborative systems and practices.

This finding reinforces the idea of a "tailoring culture" (MacLean et al., 1990), where users are encouraged to tweak, adapt, or otherwise modify their systems to meet their own unique needs. Organizations where such activities are encouraged generally benefit by having more robust collaborative systems. The problem, however, is that features which allow collaborative workers to tailor activities on the fly are not often built into computer-mediated collaborative systems. The technologies used at the museum, in contrast, encouraged tailoring activities for one simple reason: The ability to tailor the systems did not have to be explicitly constructed by the system's designers, as it was already there. By scribbling notes in margins, affixing sticky notes , or entering comments into a database, users could become easily involved in designing the next iteration of their own collaborative systems. From this perspective, the activities of the museum staff can be seen as a type of prototyping, where experimentation was encouraged and ideas could be tested informally first and formally implemented later.

The relative ease and safety in which museum staff members could implement and test improvements to their collaborative systems and practices, therefore, promoted an environment of innovation in the museum where the co-evolution process flourished. Encouraged to become more involved in the co-evolution of their systems and practices, museum staff members were, in the end, able to develop more robust collaborative systems (cf. Twidale & Marty, 2000). If this process of informal experimentation followed by formal implementation were encouraged in more organizations, this would improve the robustness of computer-mediated collaborative systems over all.

Co-Evolution is Encouraged when Changes to Collaborative Systems and Practices can be made Piecemeal by the Users, and Distributed Among Different Parts of the System and Different Museum Employees

Throughout the time period of this study, museum staff members at all levels (from senior staff to student employees) were encouraged to suggest and implement changes to the museum's information systems. From iteration to iteration, new activities were able to evolve on their own, informally, over time, being neither externally dictated nor exclusively proposed by senior museum employees. Frequently, these changes occurred as quasi-grassroots innovations, infiltrating the museum's collaborative systems and practices from the bottom up, slowly, and over time, instead of being implemented from the top down, globally, and all at once. It was not uncommon for improvements to the packing process, which a student employee had developed informally to assist in his or her individual work, to appear as a formal component in the next iteration of the museum's collaborative systems, and to be used by employees across the museum.

Changes to collaborative systems could occur gradually, and did not have to be carefully planned out in advance by senior staff members in the museum. Likewise, any errors or problems that resulted from these changes could be resolved over time, and museum employees were therefore under less pressure to make proposed changes as perfect as possible from the moment the changes developed. This aspect of the museum's working environment played a major role in enabling the museum's collaborative systems to co-evolve along with the museum's collaborative practices. As museum employees learned how to pack their collections by packing their collections, their systems were able to co-evolve right along with them.

This concept reinforces prior findings that users should be involved in the development of their own systems at all levels (Hughes et al., 1994; Mackay, 1992; cf. Schuler & Namioka, 1993). While encouraging participatory design in more complicated computer-mediated systems can be difficult, once again the simple technologies used at the museum helped to streamline the process. The dual nature of the technologies used at the museum meant that changes did not have to be implemented quite as formally as might be required in other organizations. When museum staff members needed to introduce a new procedure into the packing process, they did not need to halt all of their packing activities so that all required modifications could be made at once, across their entire collaborative system. They could, for instance, modify one aspect of the Packing Database and a different aspect of the Packing Data Sheet, even while different iterations of the Packing Data Sheets were being used throughout the museum. Since they did not have to decide in advance how to implement every single change they wanted to make across the board, they could make changes one at a time, piece by piece, and component by component. This approach to systems design and development not only encouraged the process of co-evolution, it helped the museum's systems and practices converge over time on the most effective way to pack the museum.

Co-Evolution is Encouraged when the Inconsistencies Between System and Practice Which Arise Naturally as Users Modify their Collaborative Activities can be Resolved by Users Over Time, Without Always Requiring the Intervention of System Designers

As museum staff members co-evolved new iterations of their collaborative systems and practices, their piecemeal approach to implementing changes frequently resulted in inconsistencies either between systems and practices or among different components of their collaborative systems. The museum's approach to handling these inconsistencies, however, allowed workers to cope with potential problems independently. As demonstrated in the above examples, changes to collaborative practices could manifest in different ways in the Packing Database and the Packing Data Sheets without overly disrupting the packing process. Working at their own pace, individual employees were able to handle inconsistencies in the museum's collaborative systems without adversely affecting the museum's collaborative practices. By encouraging workers to reconcile differences among different components of their systems on their own, the mere presence of those inconsistencies frequently had an overall positive effect on the museum's systems.

For example, if changes to the museum's collaborative practices manifested themselves in the museum's collaborative systems in two slightly different ways (as seen in the above examples), this inconsistency was frequently more helpful than harmful. If one method turned out to be more rigorous than the other, the less rigorous approach might assume some of the capabilities of the other, thereby making the museum's collaborative systems more robust overall. While sometimes this was simple a case of the better idea replacing the worse idea, more often than not these different approaches influenced each other in such a way that the end result was different from-and actually better than-either of the two original approaches individually. This process functioned similar to the concept of "parallel design," where multiple, possibly contradictory approaches to design can result in new ideas that lead to overall system improvements.

With many complex, computer-mediated collaborative systems, the intervention of system designers would be necessary to support such activities. With the simple technologies used at the museum, however, museum staff members were frequently able to modify systems on their own. When proposing changes to a paper form, one feels safer, perhaps, that the changes one introduces will not accidentally cause the entire system to come crashing down. Encouraged to become directly involved in the creation of their own collaborative practices and systems, museum staff members (perhaps quite naturally) created systems that they themselves could change, quickly and easily, with a fair degree of confidence that they understood what they were doing and how it would affect the museum's other employees. The ability to resolve inconsistencies between collaborative systems and practices safely and independently, therefore, helped to promote an environment where co-evolution was encouraged.

Conclusions: Implications for the Future of Computer-Mediated Collaborative Systems

It is very likely that encouraging these three factors in more complex computer-mediated collaborative systems may require the use of extremely sophisticated technologies which are capable of duplicating the types of interactions that can perhaps be more easily accomplished with paper forms and simple database systems. Few collaborative systems currently available allow users to extend system functionalities as easily as do paper forms on which users can affix a sticky note or scrawl a comment in a margin. Nevertheless, it is our belief that designers who attempt to implement these factors when developing collaborative systems will eventually create more robust collaborative systems able to co-evolve along with changing needs and practices over time.

There will, naturally, always be a disconnect between the technical capabilities of collaborative systems and the social practices they are designed to support (Ackerman, 2000). If, however, we are to develop systems that actually support work, we need to understand how to handle the sociotechnical gap, how to keep it under control, and how to build systems that will be able to cope with it over time (Dourish, 2003). Despite plenty of studies that document the problem of co-evolution, more studies are still needed that explore the process of co-evolution in order to determine how it can be supported and encouraged as a positive force for organizational change. It is our hope that this study of factors influencing the co-evolution process in a university museum (operating with few employees on a shoestring budget with simple technologies) will provide insights for the designers of more complex computer-mediated collaborative systems who wish to incorporate similar functionalities into their own designs. As we have seen, examining how users handle complicated problems with simple tools can provide valuable clues that might be more difficult to uncover in studies of more sophisticated sociotechnical systems.

A case study of simple computer-mediated collaborative technologies in a university museum is of course not going to tell us exactly how to develop those more complicated collaborative systems. But when we can see how well co-evolution can be encouraged in a world of paper forms and simple databases, we can better understand how to help users co-evolve different types of systems, an understanding that should help others develop more complex systems to enable such work. Seeing how people use simple tools to co-evolve collaborative systems and practices can be easier, yet just as helpful as studying the process with more complicated collaborative systems in other organizations. It is our hope that by providing concrete examples of how the use of relatively simple technologies encouraged the co-evolution of collaborative systems and practices in a university museum, we can help other researchers take a further step towards developing a useful conceptual framework for studying the process of co-evolution.

Acknowledgments

The author would like to acknowledge the many contributions of the staff and students of the Spurlock Museum. Without their hard work, this project would never have been possible.

References

Abbott, K. R., & Sarin, S. K. (1994). Experiences with workflow management: Issues for the next generation. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 113-120). Chapel Hill: ACM Press.

Ackerman, M. S. (2000). The intellectual challenge of CSCW: The gap between social requirements and technical feasibility. In J. M. Carroll (Ed.), Human Computer Interaction in the New Millennium (pp. 303-324). New York: ACM Press.

Allen, C. (1993). Reciprocal evolution as a strategy for integrating basic research, design, and studies of work practice. In D. Schuler & A. Narnioka (Eds.), Participatory Design: Principles and Practice (pp. 239-256). Hillsdale, NJ: Lawrence Erlbaum Associates.

Andriessen, J. H. E., Hettinga, M., & Wulf, V. (2003). Introduction to the special issue on evolving use of groupware. Computer Supported Cooperative Work, 12 (4), 367-380.

Arias, E. G., Eden, H., Fisher, G., Gorman, A., Scharff, E. (2000). Transcending the individual human mind: Creating shared understanding through collaborative design. In J. M. Carroll (Ed.), Human Computer Interaction in the New Millennium (pp. 347-372). New York: ACM Press.

Bannon, L., & Bødker, S. (1991). Beyond the interface: Encountering artifacts in use. In J. M. Carroll (Ed.), Designing Interaction: Psychology at the Human-Computer Interface (pp. 227-253). Cambridge: Cambridge University Press.

Bannon, L., & Schmidt, K. (1991). CSCW: Four characters in search of a context. In J. Bowers & S. D. Benford (Eds.), Studies in Computer Supported Cooperative Work: Theory, Practice, and Design (pp. 3-16). Amsterdam: North-Holland.

Benson, D., & Hughes, J. A. (1983). The Perspective of Ethnomethodology. London: Longman.

Bentley, R., Hughes, J., Randall, D., Rodden, T., Sawyer, P., Shapiro, D., & Sommerville, I. (1992). Ethnographically-informed systems design for air traffic control. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '92. Chapel Hill: ACM Press.

Bødker, S. (2000). Coordinating technical support platforms. Communications of the ACM, 43 (11), 215-222.

Bødker, S., & Grønbaek, K. (1991). Cooperative prototyping: Users and designers in mutual activity. International Journal of Man-Machine Studies, 34 (3), 453-479.

Bonen, Z. (1981). Evolutionary behavior of complex sociotechnical systems. Research Policy, 10 (1), 27-44.

Bowers, J. (1994). The work to make a network work: Studying CSCW in action. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 287-298). Chapel Hill: ACM Press.

Bowers, J., Button, G., & Sharrock, W. (1995). Workflow from within and without. In Proceedings of the European Conference on Computer-Supported Cooperative Work, ECSCW '95 (pp. 51-66). Dordrecht: Kluwer Academic Publishers.

Bowker, G., Star, S. L., Turner, W., & Gasser, L. (1997). Social Science, Technical Systems, and Cooperative Work: Beyond the Great Divide. Mahwah, NJ: Lawrence Erlbaum Associates.

Button, G., and Sharrock, W. (1994). Occasioned practices in the work of software engineers. In M. Jirotka & J. Goguen (Eds.), Requirements Engineering: Social and Technical Issues (pp. 217-240). London: Academic Press.

Carroll, J. M., Kellogg, W. A., & Rosson, M. B. (1991). The task-artifact cycle. In J. M. Carroll (Ed.), Designing Interaction: Psychology at the Human-Computer Interface (pp. 74-102). Cambridge: Cambridge University Press.

Chen, C., & Rada, R. (1996). Modeling situated actions in collaborative hypertext databases. Journal of Computer-Mediated Communication, 2 (3). Retrieved June 8, 2005, from http://jcmc.indiana.edu/vol2/issue3/chen.html

Chidambaram, L. (1996). A study of relational development in computer supported groups. MIS Quarterly, 29 (2), 143-165.

DeSanctis, G., & Monge, P. (1998). Communication processes for virtual organizations. Journal of Computer-Mediated Communication, 3 (4). Retrieved June 8, 2005, from http://jcmc.indiana.edu/vol3/issue4/desanctis.html

DeSanctis, G., & Poole, M. S. (1994). Capturing the complexity in advanced technology use: Adaptive structuration theory. Organization Science, 5 (2), 121-147.

Dourish, P. (1995). Developing a Reflective Model of Collaborative Systems. ACM Transactions on Computer-Human Interaction, 2 (1), 40-63.

Dourish, P. (2003). The appropriation of interactive technologies: Some lessons from placeless documents. Computer Supported Cooperative Work, 12 (4), 465-490.

Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P., & Zbyslaw, A. (1996). Freeflow: Mediating between representation and action in workflow systems. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '96 (pp. 190-198). Chapel Hill: ACM Press.

Duin, A. H. (1991). Computer-supported collaborative writing: The workplace and the writing classroom. Journal of Business and Technical Communication, 5 (2), 123-150.

Eriksson, D. M., & Wulf, V. (1999). Self-organizing social systems: A challenge to CSCW. Cybernetics and Human Knowing, 6 (2), Retrieved September 1, 2004, from http://www.imprint.co.uk/C&HK/vol6/v6-2ind.html

Eveland, J., & Bikson, T. (1988). Work group structures and computer support: A field experiment. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '88 (pp. 39-51). New York: ACM Press.

Foerster, H. V. (1984). Principles of self-organization in a socio-managerial context. In H. Ulrich and G. J. B. Probst (Eds.), Self-Organization and Management of Social Systems (pp. 2-25). Heidelberg: Springer.

Gasser, L. (1986). The integration of computing and routine work. ACM Transactions on Office Information Systems, 4 (3), 205-225.

Gerson E. M., & Star, S. L. (1986). Analyzing due process in the workplace. ACM Transactions on Office Information Systems, 4 (3), 257-270.

Grinter, R. (1996). Supporting articulation work using software configuration management systems. Computer Supported Cooperative Work, 5 , 447-465.

Grudin, J. (1989). Why groupware applications fail: Problems in design and evaluation. Office, Technology, and People, 4 (3), 245-264.

Grudin, J. (1994). Groupware and social dynamics: Eight challenges for developers. Communications of the ACM, 37 (1), 92-105.

Heath, C., & Luff, P. (1992). Collaboration and control: Crisis management and multimedia technology in London underground line control rooms. Computer Supported Cooperative Work, 1 (1), 429-439.

Hewitt, C. (1986). Offices are open systems. ACM Transactions on Office Information Systems, 4 (3), 271-287.

Hiltz, S. R. (1994). The Virtual Classroom: Learning Without Limits via Computer Networks. Norwood, NJ: Ablex.

Hollingshead, A. B., McGrath, J. E., & O'Connor, K. M. (1993). Group task performance and communication technology: A longitudinal study of computer-mediated versus face-to-face work groups. Small Group Research, 24 (3), 307-333.

Hughes, J., King, V., Mariani, J., Rodden, T. & Anderson, H. (1994). Moving out from the control room: Ethnography in systems design. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 429-439). New York: ACM Press.

Hutchins, E. (1995). Cognition in the Wild. Cambridge, MA: MIT Press.

Huysman, M., Steinfield, C., Jang, C-Y., David, K., Veld, M., Poot, J., & Mulder, I. (2003). Virtual teams and the appropriation of communication technology: Exploring the concept of media stickiness. Computer Supported Cooperative Work, 12 (4), 411-436.

Janzen, D. H. (1980). When is it coevolution? Evolution, 34 (3), 611-612.

Jirotka, M., & Goguen, J. (1994). Requirements Engineering: Social and Technical Issues. London: Academic Press.

Jørgensen, H. (2001). Interaction as a framework for flexible workflow modeling. In Proceedings of the ACM Conference on Supporting Group Work, GROUP '01 (pp. 32-41). New York: ACM Press.

Karsten, H. (2003). Constructing interdependencies with collaborative information technology. Computer Supported Cooperative Work, 12 (4), 437-464.

Kuutti, K. (1992). Identifying potential CSCW applications by means of activity theory concepts: A case example. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '92 (pp. 233-240). New York: ACM Press.

Luff, P., Hindmarsh, J., & Heath, C. (2000). Workplace studies: Recovering work practice and informing system design. Cambridge: Cambridge University Press.

Mackay, W. (1992). Co-adaptive systems: Users as innovators. In CHI '92 Basic Research Symposium. New York: ACM Press.

Mackay, W. (2000). Responding to cognitive overload: Co-adaptation between users and technology. Intellectica, 30 (1), 177-193.

Mackay, W., Malone, T., Crowston, K., Rao, R., Rosenblitt, D., Car, S. K. (1989). How do experienced information lens users use rules? In Proceedings of the ACM Conference on Human Factors in Computing Systems, CHI '89 (pp. 211-216). New York: ACM Press.

MacLean, A., Carter, K., Lovstrand, L., & Moran, T. (1990). User-tailorable systems: Pressing the issues with buttons. In Proceedings of the ACM Conference on Human Factors in Computing Systems, CHI '90 (pp. 175-182). New York: ACM Press.

Marchionini, G. (2002). Co-evolution of user and organizational interfaces: A longitudinal case study of WWW dissemination of national statistics. Journal of the American Society for Information Science and Technology, 53 (14), 1192-1209.

Marsic, I. (2003). Flexible user interfaces for group collaboration. International Journal of Human-Computer Interaction, 15 (3), 337-360.

Marty, P. F. (1999). Museum informatics and information infrastructures: Supporting collaboration across intra-museum boundaries. Archives and Museum Informatics, 13 (2), 169-179.

Marty, P. F. (2000). Museum informatics: Sociotechnical infrastructures in museums. Bulletin of the American Society for Information Science, 26 (3), 22-24.

Marty, P. F. (2002). Museum informatics and the evolution of an information infrastructure in a university museum. Dissertation Abstracts International, 63 (11), 3774. (UMI No. 3070380).

Nardi, B. (1993). A Small Matter of Programming. Cambridge, MA: MIT Press.

Nardi, B., & Miller, J. (1991). Twinkling lights and nested loops: Distributed problem solving and spreadsheet development. International Journal of Man-Machine Studies, 34 (2), 161-184.

O'Day, V. L., Bobrow, D. G., & Shirley, M. (1996). The socio-technical design circle. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '96 (pp. 160-169). New York: ACM Press.

Okamura, K., Fujimoto, M., Orlikowski, W., and Yates, J. (1994). Helping CSCW applications succeed: The role of mediators in the context of use. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 55-66). New York: ACM Press.

Orlikowski, W. (1992a). The duality of technology: Rethinking the concept of technology in organizations. Organizational Science, 3 (3), 398-427.

Orlikowski, W. (1992b). Learning from notes: Organizational issues in groupware implementation. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '92 (pp. 362-369). New York: ACM Press.

Pekkola, S. (2003). Designed for unanticipated use: Common artifacts as design principle for CSCW applications. Proceedings of the ACM Conference on Supporting Group Work, GROUP '03 (pp. 359-368). New York: ACM Press.

Poole, M. S., & DeSanctis, G. (1990). Understanding the use of group decision support systems: The theory of adaptive structuration. In J. Fulk & C. Steinfield (Eds.), Organizations and Communication Technology (pp. 173-193). Newbury Park, CA: Sage.

Resnick, P., Iacovou, N., Suchak, M., Bergstrom, P., and Riedl, J. (1994). Group-Lens: An open architecture for collaborative filtering of Netnews. Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 175-186). New York: ACM Press.

Robinson, M. (1993). Design for unanticipated use… In Proceedings of the European Conference on Computer-Supported Cooperative Work, ECSCW '93 (pp. 187-202). Dordrecht: Kluwer Academic Publishers.

Rogers, Y. (1994). Exploring obstacles: Integrating CSCW in evolving organizations. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 67-66). Chapel Hill: ACM Press.

Rogers, Y. (1997). Reconfiguring the social scientist: Shifting from telling designers what to do to getting more involved. In G. Bowker, S. L. Star, W. Turner, & L. Gasser (Eds.), Social Science, Technical Systems, and Cooperative Work: Beyond the Great Divide (pp. 57-77). Mahwah, NJ: Lawrence Erlbaum Associates.

Rosson, M., & Carroll, J. (2001). Usability Engineering: Scenario-Based Development of Human-Computer Interaction. Redwood City, CA: Morgan Kaufman.

Schmidt, K., & Bannon, L. (1992). Taking CSCW seriously: Supporting articulation work. Computer Supported Cooperative Work, 1 (1), 7-40.

Schmidt, K., & Simone, C. (1996). Coordination mechanisms: Towards a conceptual foundation of CSCW systems design. Computer Supported Cooperative Work, 5 , 155-200.

Schuler, D., & Namioka, A. (Eds.). (1993). Participatory Design: Principles and Practices. Hillsdale, NJ: Lawrence Erlbaum Associates.

Sikkel, K,. Ruel, H., & Wieringa, R. (1999). Towards a method for evolutionary implementation of groupware. In A. Opdahl, K. Pohl, & E. Dubois (Eds.), Proceedings of the Fifth International Workshop of Requirements Engineering (pp. 187-192). Presses Universitaires de Namur.

Sommerville, I., Rodden, T., Sawyer, P., Bentley, R., & Twidale, M. (1992). Integrating ethnography into the requirements engineering process. In IEEE International Symposium on Requirements Engineering '93 (pp. 165-173). Los Alamitos, CA: IEEE Computer Society Press.

Sproull, L., & Kiesler, S. (1986). Reducing social context cues: Electronic mail in organizational communication. Management Science, 32 (11), 1492-1512.

Stake, R. E. (1995). The Art of Case Study Research. Thousand Oaks, CA: Sage Publications.

Star, S. L. (1999). The ethnography of infrastructure. American Behavioral Scientist, 43 (3), 377-391.

Star, S. L., & Ruhleder, K. (1996). Steps toward an ecology of infrastructure: Design and access for large information spaces. Information Systems Research, 7 (1), 111-134.

Star, S. L. & Strauss, A. (1999). Layers of science, arenas of voice: The ecology of visible and invisible work. Computer Supported Cooperative Work, 8 (1/2), 9-30.

Strauss, A. (1985). Work and the division of labor. The Sociological Quarterly, 26 (1), 1-19.

Strauss, A., & Corbin, J. (1998). Basics of Qualitative Research. Thousand Oaks, CA: Sage.

Suchman, L. A. (1983). Office procedures as practical action: Models of work and system design. ACM Transactions on Office Information Systems, 1 (4), 320-328.

Suchman, L. A. (1995). Making work visible. Communications of the ACM, 38 (9), 56-64.

Suchman, L. A. (1996). Supporting articulation work. In R. Kling (Ed.), Computerization and Controversy (pp. 407-423). San Diego: Academic Press.

Torpel, B., Pipek, V., & Rittenbruch, M. (2003). Creating heterogeneity: Evolving use of groupware in a network of freelancers. Computer Supported Cooperative Work, 12 (4), 381-409.

Trigg, R., & Bødker, S. (1994). From implementation to design: Tailoring and the emergence of systematization in CSCW. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW '94 (pp. 45-54). Chapel Hill: ACM Press.

Twidale, M., & Marty, P. (2000). Coping with errors: The importance of process data in robust sociotechnical systems. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work, CSCW 2000 (pp 269-278). Chapel Hill: ACM Press.

Walther, J. B. (1995). Relational aspects of computer-mediated communication: Experimental observations over time. Organization Science, 6 (2), 186-203.

Wulf, V. (1999). Let's see your search tool! Collaborative use of tailored artifacts in groupware. In Proceedings of the ACM Conference on Supporting Group Work, GROUP '99 (pp. 50-59). New York: ACM Press.

Yates, J. (1993). Co-evolution of information processing technology and use: Interaction between the life insurance and tabulating industries. Business History Review, 67 (1), 1-51.

Yin, R. K. (2002). Case Study Research, Design and Methods. Newbury Park, CA: Sage Publications.

About the Author

Paul F. Marty is Assistant Professor in the College of Information at Florida State University. His research interests include museum informatics, computer-supported cooperative work, information behavior, and usability engineering. He studies museums as sociotechnical systems, and is particularly interested in the evolving role of the information professional in the museum and the social implications of introducing new technologies into the museum environment.
Address: College of Information, 101 Louis Shores Building, Florida State University, Tallahassee FL 32306-2100 USA