| unity |
About uCoop
uCoop is an exploration of multiuser networked cooperation. In uCoop, connected users are forced to cooperate in order to navigate a website.
>> View uCoop live... (Requires an internet connection and Flash Player 7)
uCoop is a Macromedia Flash application built with the Unity 2 Multiuser Development Kit, developed by Colin Moock and Derek Clayton. The following article, written by Colin Moock, discusses the concepts and theory behind uCoop.
In my multiuser work I often talk about "ambient user activity"--the incidental noise, appearance, and signs of life generated by humans as a by-product of being in a crowd. I argue that ambient user activity is part of the fundamental human experience. It defines our conciousness as social beings and as individual members of the human collective. As such, I believe it should and will become part of the commonplace computing experience.
Over the course of several years, I have identified four types of multiuser activity:
Out of the preceeding four types, my previous works (uPresence, uTulip, Ambient User Sound) have focused mainly on the first three. uCoop, by contrast, focuses on User Interaction. The goal of uCoop is not to allow users to interact; rather, it is to force users to interact.
Seduction
Users that connect to uCoop are initially presented with an entirely blank page that emphasizes the emptiness of the typical solitary web experience. The user is initially, "lost", just as we are each lost without the human collective.
The empty page is accompanied by a slow background noise produced by the environment itself, akin to the natural environmental noises of wind or rain. When the user moves his or her mouse pointer, a drum beat plays. The user learns that his own activity generates sound.
If others are connected when the user connects, no interface is shown. However, the positions of all users' mouse pointers are broadcast to all connected users. If the user's mouse pointer moves within 400 pixels of another user's pointer, the other user's pointer begins to fade into view (user representation/community). The opacity of the other user's mouse pointer increases as the two users move closer together. Users separated by more than 400 pixels are not shown to each other. They are considered "too far to see," much as a person several kilometers away in real life is not visible.
Users are also represented to each other aurally. When two users' mouse pointers move within 400 pixels of each other, the pointers emit a drum beat. The two individual beats overlap, causing a new beat. A maximum of three pointers can combine to form a collective rhythm at any one time (this constraint is imposed by the Flash Player's limited sound playback capabilities). If the pointers stop moving, the drum beat also stops, even if the pointers are within 400 pixels of each other.
The limited range of available modes of expression (motion, drumming), forces users to recognize themselves in each other (I am like that pointer, that pointer is like me). The recognition is perhaps attained more easily in the context of uCoop than in the real world, where physical appearance and demographics such as race, religion, and language lead individuals to forget the aspects of one's self that are necessarily implied in the other).
As two users move closer together, the volume of the remote user's pointer increases. When the user moves within 50 pixels of another user's pointer, the other user's pointer changes colour and flashes, and a rattling sound plays. With both visual and audio cues, users are lured towards each other.
uCoop attempts to seduce the user into the intimate act of touching another user's mouse pointer. The product of that intercourse is the birth of the navigation system. Users must physically connect in order for the site's interface to appear. Cooperation is mandatory.
Cooperative Navigation
Once the navigation menu is displayed, the user can select a destination. When the user's pointer moves onto or off of the menu, a drum sound is played--both locally and also remotely for any other connected users. Hence, each user is aware of (by hearing) the actions of other connected users, much as one is aware of other people walking through a room by hearing their footsteps.
As in most typical web interfaces, the user selects a destination from the navigation menu by clicking the desired link.
However, unlike most web interfaces, clicking a link does not immediately send the user to the destination. Instead, it sends a message to all other connected users indicating that the user wants to visit the selected destination.
Each request to visit a destination appears as a clickable "request button" to other users.
The user is sent to the desired destination only when another user clicks the request button. Users must rely on the help of others in order to navigate the site. Cooperation is mandatory.
Deviance
Of course, the idea that a site can only be navigated cooperatively raises the obvious question: what happens if some users don't cooperate? For example, what if one user won't touch another user (i.e., won't help activate the navigation menu) or won't fulfil a navigation request?
Similar break downs of the social safety net occur frequently in real life. One person might not open the door for another. Someone might drive slowly in the fast lane, blocking others from passing. In situations where lack of cooperation is socially problematic, specific roles typically emerge to solve the problem or make the experience easier for the participants.
For example, in the 2003 blackout of the Northeastern United States and Southeastern Canada, traffic lights stopped functioning by the thousands. In response, many average pedestrians spontaneously took on the task of directing traffic. This same spontaneous cooperative instinct has given us police patrolling the highways, hotels bellhops, airports baggage security staff, etc.
Similarly, social moderation roles should emerge naturally in a cooperative computing environment such as uCoop. For example, if the content of moock.org were important enough to a particular organization, that organization might station a person permanently at the site to fulfil navigation requests. Perhaps many websites should, themselves, provide such a service--a real human helping users find what they want. After all, department stores often have greeters who can immediately direct customers to their destinations. The logical extension would be to have video sales staff appear directly on those stores' websites, ready to offer the user a cooperative experience (i.e., customer service).
In uCoop, such service is intentionally not offered. Users are left to experience the development of a social system. A user might suffer under the cruel control of those who choose to be uncooperative. Or a user might feel the delight of being assisted by other users. The former experience is designed to frustrate the victim, compelling him or her to consider the need for moderators and assistive roles in the multiuser environment. The latter experience is designed to highlight the sterility of typical non-multiuser computing experiences and the need for cooperative social experiences online.
Computer-based experiences typically feel "inhuman" because they lack key social aspects of human life: helping each other, working together, conflict. For example, suppose someone is driving down a highway and runs out of gas. They pull over and wait for others to offer assistance. Two hours later, someone stops and offers a ride to a gas station. The person whose car has broken down feels relief, happiness, gratitude, and excitement. These feelings are typically absent from an average web-browsing experience. But in uCoop, a user can be stranded in exactly the same way--attempts to navigate to a page can be ignored by uncooperative users. Coorespondingly, a user can also be "rescued" by a cooperative user. Eventually, someone else will connect and fulfil the stranded user's request, producing the same feelings that were experienced by the car owner when offered a ride to the gas station.
Being in a crowd
uCoop gives users the social experience of "being in a crowd" (communion) by displaying user pointers, playing a sound when users approach each other, and playing sounds when users interact with the navigation menu.
Several other features in uCoop also contribute to the experience of "togetherness":
The experience of using uCoop, then, varies according to the number of participants and the personalities of those participants. It can be a serene, solitary experience not unlike walking into an empty house, or it can be a frantic, chaotic experience--the online equivalent of moving through a bustling marketplace. In short, uCoop mirrors the experience of sharing a public space in real life. It gives some sense of what a multiuser web could be like, lying in stark contrast to the current web browsing experience which feels something like exploring a vast deserted city--the artifacts of human existence are evident, but the inhabitants are no where to be found.
To help evaluate the importance of shared experiences in the online world, let's examine another example. Consider a line up at a store the night before the launch of a the Playstation 3 video game console. The people in the line experience anticipation and excitement while waiting together, perhaps for many hours. They share stories of their previous gaming experiences and try to guess what the new console will offer. Perhaps some people in the line even become long-term friends. At midnight, the doors to the store open. The people at the front of the line rush gleefully into the store, spurred on by a cheering crowd behind them.
Now compare the real-world line up with the current online equivalent: a person sitting alone in an apartment waiting to order the Playstation 3 from a typical non-multiuser ecommerce website. The user browses to a static page. When the product becomes available for ordering, the user enters a credit card number and submits the order. The user receives an automated email from the website confirming the details of the order. The next day, the user receives the Playstation 3 in the mail.
The single user experience lacks all the emotion and community of the real-world line up.
At the very least, shouldn't the ecommerce website offer a chat on the order page where users could share stories like their real-world counterparts? How about an online queue where users have to stay on the order page to feed a virtual pet? When the product ships, those with the heathiest pet are moved to the front of the queue or receive a free game. Maybe the pet should be owned by teams of four so users have to cooperate?
Prescribed user activity
The examples of user representation discussed so far have been literal. For example, user mouse pointers are represented with literal pointer icons. Using a menu causes a remote drum sound to play. But the online world also offers the interesting possibility of non-literal representations. For example, all female users might be represented as circles, and males as squares. Or, users might be represented as abstract lines or musical notes.
uCoop explores non-literal user representation by growing a flower for each user connected to the application. Each flower is unique. The longer the user stays connected, the larger the flower grows. Each flower also bend towards the mouse pointer that it represents, and mirrors the pointer's movements.
The flowers of uCoop map the literal data produced by a user onto an arbitrary representation. The online world offers the unique ability to produce real-time metaphor in this way. By forcing a given representation onto a group of users, we can perhaps perceive some pattern in the group that isn't readily apparent in the literal representation. For example, the flowers let us understand an individual experience (visiting a website) in terms of birth, growth, and death.
Likewise, consider this image:
Without knowing the source of the image, one might easily guess that it shows a night sky full of stars. Or perhaps a black-and-white rendering of lichen growing on a rock. In fact, the image is a satellite view of the lights generated by the central United States at night time. By visualizing the country's entire population only in terms of its use of electricity, we can easily see the pattern that would otherwise go unnoticed. We can understand ourselves as lichen on the planetary scale. For the full satellite image, click here (courtesy National Oceanic and Atmospheric Administration).
In addition to arbitrarily specifying how a user will be represented online, we can also control user interaction by narrowing the palette of available behaviours. By limiting user actions, we can achieve the online equivalent of asking someone to pick up a cup of water without using their hands. The limitation lets us study specific forms of collectivity to the exclusion of other factors, in a constrained human experience. The contraint itself can be used as an automated moderation device where deviance is unwanted. For example, the Groovy Girls website includes a chat system where phrases must be selected from a menu. This prevents the abuse of a sensitive demographic (children).
User transformation
Although cooperation is the focus of uCoop, users can also transform the environment simply by using it. Each time a user navigates to a destination in the navigation menu, that destination's ranking increases. Destinations with more visits are rendered darker than destinations with fewer visits.
Interestingly, the colour of the destinations may be a self-fulfiling prophecy. Users are more likely to pay attention to the darker links and, hence, more likely to visit them. The paths to areas of the site form exactly like a path across a field. A path does not always follow the most efficient route; it simply shows the route most often travelled.
By ranking the destinations with colour instead of position (i.e., instead of moving popular destinations to the top), users can see both the creator's intended logical grouping of the destinations and also the grouping by popularity.
And if I'm alone?
uCoop is a study of multiuser interactivity. If only one user is connected to the uCoop at any given time, the system behaves as though it has no multiuser component. When the user is alone for more than five seconds, the navigation menu is displayed. Further, clicking on the menu immediately loads the selected destination. The five-second delay allows time for other users to connect, which immediately activates the multiuser behaviour of the system. If a user has a pending navigation request when he or she becomes the only user left on the site, then the request is immediately granted (i.e., the user is sent to the destination automatically).
Further Study
For more information about Unity-based multiuser web applications, see the Unity homepage. For a list of other Unity-based multiuser applications, see the Unity Showcase.
