Monday, October 27, 2008

It’s All About Performance

Short Response Essay by Lillian Spina-Caza

Computer Technologies Designed for Performance

Whether it be the performance of particular tasks using mainframes in the 1960s for “filling airline seats…or printing payroll checks” (Grudin, 19), or for improving performance of individuals through word processing or spreadsheet applications using minicomputers in the 1970s, computer technologies have always been designed with performance in mind. It is a given that for organizations to perform well, all of the systems, processes and people supporting them need to perform well, thus making optimal performance a critical organizational goal. It wasn’t until the mid-1980s and the advent of computer-supported cooperative work or CSCW, however, that the meaning of performance shifted -- from performance as task or functionality -- to performance as social or group endeavor. Once dialogue between people became privileged over dialogue between systems, communication evolved as a critical component of cooperative work, thus it is no surprise that technologies such as Internet, email, video and audio conferencing, and text tools like instant messaging (IM) and chat were quickly adopted for business applications.

As Olson and Olson (2007) write in the Handbook on page 546, “groupware [as] software designed to run over a network in support of the activities of a group or organization for carrying out activities,” was originally made to provide greater geographic and temporal flexibility. It was also created with new modes of socializing in mind. Some of the new social communication technologies that emerged were successful (email, IM, and chat) while others – like video conferencing – were not as widely embraced (548). The reason why some communication technologies are better received than others, according to Olson and Olson is, I would also argue, directly tied to performance. A/V problems associated with poor audio, poor video, camera placement, ac or noise interference, and delay issues, have all resulted in poor acceptance of video conferencing as a technology. Ironically, as Olson and Olson point out, video does not produce the “being there” phenomenon that many had hoped for (553). The expense and effort of producing quality video currently outweigh the benefits of using this technology to establish social presence. Performance is critical to the successful adoption of any technology, new or old.

Social Actors and their Props

With the emergence of groupware applications in the mid-1980s, “the social, motivational, and political aspects of workplaces become crucial” (Grudin, 22); in other words, one might say the drama behind the scenes took center stage. Whereas the mainframe was once the only stage for all of the critical action, now it was individuals performing in concert with each other – using technology – who found themselves in the limelight. Grudin (1994) points out when the move to networked PCs and workstations became widespread, new markets opened up for groupware to support communication and coordination. This move resulted in a paradigm shift away from off the shelf, single-user products to computer support for groups, requiring developers to consider “group dynamics for the first time” (22). Instead of placing computers in leading roles (i.e., as “mainframes” or main characters), people interacting with computers came to be viewed as actors, the tools they work with taking on secondary or supporting roles. It is understandable why the “actors” at this new stage of technological development also became the central focus of new product design centered on activity practices.

Christiansen (1996) suggests activity “is the term for the process through which a person creates meaning in her practice…” (177). Once activity became tied to meaning-making, it also became important to realize how tools as artifacts are situated or contextualized within activity to create meaning. As Christiansen explains, “You may observe and interview actors in a community of practice, but you will not come to understand why they use the artifacts the way they do until you have come to understand what kinds of activity are used in their practice” (177); this type of understanding is at the heart of participatory design. It is no wonder then, if people are viewed as “acting” with technology, that the performance metaphor stretches to include designers, who like the technologies they create, play key supporting roles. In addition to learning from “economists, social psychologists, anthropologists, organizational theorists, educators, and anyone else who shed light on group activity” as Grudin suggests, product developers also began following the performance metaphor along its natural trajectory, turning to drama and theater to gain new insights about human actors and the activities they engage in when using computer technologies.

Performance Sets the Stage for Participatory Design

It is not surprising that the performance metaphor shapes a “third space” or place where product developers can learn more about the practices associated with activity. As Muller explains in “Participatory Design,” third space experiences are hybrid experiences or “practices that challenge assumptions, are open to reciprocal learning, and facilitate polyvocal or many-voiced discussions across and through differences" (1062). One way designers can gain insights into why people use artifacts the way they do requires, as Christiansen points out, a better understanding of the kinds of activity are used in their practice – the use of drama and videos or the tools of performance can aid in this type of exploration. Muller suggests a number of techniques borrowed from theatre that are valuable for bringing to light activity practices, including ideas suggested by Boal’s Theatre of the Oppressed (1974, 1992) that aid a group or community to find its voice(s) and articulate its position(s) (Muller, 1071).

Other helpful dramatic tools used for creating third space experiences to inform design practices include: “Forum theater” or a type of theater where non-professional actors perform skits with less than desirable outcomes in front of interested parties, and audience members become authors and directors who can alter skits to achieve desired outcomes (1071). “Tableau” is a technique where performers are told to freeze during play and are asked to describe what they are “doing, thinking, planning, and hoping” (1071). “Interface Theatre,” created by Muller et al. in 1994, has software professionals act out user interfaces in a large auditorium, using the theatrical stage as the screen where each actor plays the role of a concrete interface component (i.e., Kim the Cursor, Marty the Menubar, and so forth). Another participatory design practice adopting “performance” as a method for improving design is the “Situated and Participative Enactment of Scenario” that asks designers to take part in a “projective series of improvisations with 'the magic' thing in users’ homes and workplaces” (Muller, 1071). All of these techniques are performance-driven, much like the people and technologies they are used to describe. Performance, it can be claimed, is a metaphor that comes full circle in the realm of HCI.


Christiansen, E. (1996). “Tamed by a Rose: Computers as Tools in Human Activity.” In Nardi, B. A. Context and Consciousness: Activity theory and human-computer interaction. (pp. 175-198). Cambridge: MIT Press.

Grudin, J. “Computer-Supported Cooperative Work: History and focus.” IEEE. May 1994.

Muller, M.J. (2007). “Participatory Design: The third space in HCI.” In Sears, A. & Jacko, J. (Eds.). The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications, 2nd Edition. (pp. 1061-1082). Lawrence Erlbaum.

Olson G. & Olson J. (2007). Groupware and Computer-Supported Cooperative Work. In Sears, A. & Jacko, J. (Eds.). The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications, 2nd Edition. (pp. 545-558). Lawrence Erlbaum.

CSCW: Computer-Supported Cooperative Work

The topic of Computer-Supported Cooperative Work (CSCW) is derived from an earlier system of office automation. The notion that we can work cooperatively, within groups has been around since the 1970's. We want to learn from others and get and share ideas. Successful companies know that teamwork is imperative for the success of a company, and that each team player has at least one thing to contribute to this. The study on History and Focus written by Jonathan Grudin, University of California, Irvine shows us how we vary by culture.

I can understand how CSCW gains insight from the field of anthropology, educators and those who participate in group activity. We have so many applications we subscribe to today. We use facebook, myspace, open office, gmail documents, skype and so many other sources of communication today. This is not just single-user based applications, though we use them individually. We use them to connect to a specific group.
According to Grudin, group work was not developed in the technology created in the 70's, in this case then, how did technology learn human behavior? Jay has created a short story for this topic and has given us the option to create more to the story, to comment on the story, and even the option not to participate. For this lesson in group work, I think it is great to have the opportunity to participate, so thanks Jay for this insightful chance. The story can be totally twisted, which is awesome, and I hope it goes in that direction.

For us to focus only on the 'work' effort of CSCW is very generalized. Since CSCW supports the small group effort, it can be regarded in most concentrations. Not only that, but so many areas have an influence in the development of this product. Information Systems people are familiar with the social dynamics of networked PC's and individual workstations and the greater good of organizations. They can assist in creating small groups with workstaions by creating a sense of community. When we share the need of key goals and direction, we are cutting down on the friction of being to general.

Grudin explains that in large IS environments, the (vast majority of users) decades of experience will shed light on the non-technical problems. Is this really because of the users bringing this insight to attention? I can understand that within a small group of users, the technological problems can become an issue as they (the user) may not have the experience to use the programs.

Another difference into the CSCW area is how it relates to users by country. Grudin sites that there are many differences to the way we (here in the U.S.) approach CSCW compared to European countries. One of the differences lays in finance. In the United States, research and development are supported and more interwoven with universities. This supports the reason that the funding is coming from a more varied source (independent research, private research grants, and endowments) than within Europe, where their funding is more goverment sponsored. The research in Europe also focuses on large-scale systems development. While I'm not exactly sure what that may mean, I would guess it means that they are progressing faster than we are here. In the U.S., it almost seems like we think backward. According to Grudin, many U.S. researchers build technology and then look for ways to use it. Wouldnt this be a waste of time and effort? I think many developers in HCI would like to have their ideas be used on the first time of introduction, but really I would hope to believe that they would perform in-depth user studies to find the need first. Culture plays an integral part in this effort. In Europe, their many cultures play a part in the need for a groupwork social dynamic. During conferences and social gatherings you can tell that the Europeans are professionals who would like to share their research, experience and current results. At conferences, most who are attending will present their work. Compare this with the U.S. culture who present their work for larger audiences (may or may not be presenting), are more polished and emphasize results.
It is interesting that we share group work with people all over the world. Some of the correspondence seems effortless, while others are prevented by firewalls. Designers creating the applications have so many issues to think about, it is amazing that we communicate so much~

work cited:
Jonaghan Grudin, University of California, Irvine. "Computer-Supported Cooperative Work: History and Focus", May 1994