Workplace Collaboration in a 3D Virtual Office

Geetika Sharma Tata Consultancy Services Gautam Shroff Tata Consultancy Services Prasun Dewan University of North Carolina, Chapel Hill

ABSTRACT We describe VirtualOffice, an innovative application of virtual world technology for enabling informal office interactions and collaboration even when some of the participants are physically out of office. Each instance of the system is tied to an actual physical office, so the communication and visual channels created among its users are designed to offer the level of privacy in the corresponding real-world office. VirtualOffice supports auras and automated navigation based on logical seats in the office, rather than geometric distances. The system is implemented using a distributed MVC architecture employing a practical combination of (a) push and pull communication, and (b) cloud-based servers. The system is designed to support remote management by walking around as well as virtually visiting both collaborators and ones own offices, thereby enabling informal conversations that seamlessly bridge the physical and virtual worlds. VirtualOffice also represents a new point in both Benfords and Schroeders taxonomies of collaboration systems that classifies instant messaging, virtual worlds, and video conferencing. A detailed scenario is used to motivate our new design point and compare it with commonly used as well as emerging collaboration applications as well as established virtual worlds such as Second Life, for the specific purpose of informal office collaboration. KEYWORDS: Virtual worlds, collaboration technology INDEX TERMS: H.5.3 [Group and Organization Interfaces]: Collaborative Computing, Synchronous Interaction 1 INTRODUCTION For the vast majority of knowledge workers in the world each work-day begins by going to office. The office is where one's desk is, where team meetings take place, where one meets colleagues, supervisors, and team members, and where one also catches up on organizational gossip. At the same time distributed teams are commonplace these days with variable degrees of separation. For example, teams may be distributed over floors, buildings, cities or countries. It is becoming increasingly common for knowledge workers to conduct a majority of their interactions during the course of a work-day electronically, using email, chat, phone or even video-conferences, without ever meeting face-toface. In fact, a growing number of employees today work from home, and some organizations have even gone to the extent of dispensing with the physical offices for thousands of such remote workers. So, why do the vast majority of knowledge workers still go to office? Are we losing something by working remotely? If so, how can innovative collaboration technology restore this missing 249 D & E Udyog Vihar, Phase IV, Gurgaon, Haryana, India
geetika.s@tcs.com, gautam.shroff@tcs.com, dewan@cs.unc.edu
IEEE International Symposium on Virtual Reality Innovation 2011 19-20 March, Singapore 978-1-4577-0054-5/11/$26.00 2011 IEEE

something for remote workers and distributed teams? Studies [8] have shown that informal interactions through chance conversations significantly benefit collaborative work. Chance interactions take place unobtrusively among collocated members of a team; opportunities for such integrations are created by routine activities such as walking around in an office. In particular, while walking around one might (a) bump into a colleague and start a conversation; (b) overhear an interesting conversation and decide to join it, or (c) might notice what a team member is working on and stop to discuss or help. The walking around may occur implicitly as a side-effect of some other action such as going to the water cooler, or explicitly as part of the management by walking around technique [7], in which managers walk around in an office, talking to individuals to understand the issues they might be struggling with, as well as make themselves available to individuals for discussion. However, as distances between teams increase, the number of opportunities for such casual interaction steadily decreases Distributed teams will connect formally for meetings using any number of formal collaboration tools, such as teleconferencing using shared-data (e.g. Webex, LiveMeeting). However, such meetings normally have a pre-determined agenda where informal chit-chat is both out of place and not naturally supported by formal collaboration tools. The central goal [12] [13] of Virtual Reality technology has been to provide users with a sense of being there and interact in a digitally created environment other than the one they are in physically. Shared or multi-user virtual environments enable interaction between physically distributed users. Casual interaction may be supported by both asynchronous social networking systems such as Facebook and synchronous virtual environments such as Second Life. There has been some recent work in tying asynchronous social networking to organizations. In particular, in [3], the relationships in an organization are used as the basis of creating analogous relationships in the interactive system: Such a system is thus also based around the principle of matching interactive systems to the real world [5]. In this paper, we apply the same principles to the design of a virtual world, called VirtualOffice, that has been built specifically for supporting casual interaction in an organization. VirtualOffice is not intended to eliminate real offices. In fact, its design relies on such offices existing. Each instance of the system is tied to an actual physical office and gives a user the ability to virtually go to the office, in the process creating opportunities for serendipitous and casual interactions. Workers may virtually go either to their own offices or visit others offices. We expect that familiarity with one's own office or an office one has visited before will ease navigation and locating people in the virtual office. Conversely, becoming familiar with the layout of a remote office one has never physically visited would also enrich a subsequent actual visit, perhaps even eliciting a feeling of dj vu. The general idea of integrating the physical and virtual is not new. For example, some 3D-worlds have built bridges between computer and physical entities so that users in a virtual reality can

see inhabitants of a physical world, and vice versa [2]. Our tool represents a new point in Benfords [2] artificiality-transportationspatiality taxonomy for describing synchronous collaboration systems as well as Schroeders [13] presence-copresence-being there together taxonomy for various media. More recently, cross-reality [10] environments, resulting from a marriage of ubiquitous sensor networks and online virtual words have been proposed. They enable the interaction of virtual participants with humans and devices in the real-world, using a variety of sensors, actuators and displays. For example [11] models a physical chocolate factory in a virtual environment and provides real-time information such as temperature and machine state useful for virtual monitoring, customer visits, training and so on. Although, the VirtualOffice is in a sense a cross-reality environment, the use of even unobtrusive sensors such as cameras raises many security and privacy concerns in enterprises. In the rest of the paper, we describe this design point and its implementation in the VirtualOffice system at various levels of abstraction, compare it with related research as well as commercial tools, such as group chat, IM, or Second Life. Finally we present our conclusions and directions for future work. 2 SYSTEM DESCRIPTION 2.1 Overview As mentioned above, the goal of VirtualOffice is to support synchronous informal interaction. There is a large space of existing and potential systems for meeting this goal. We identified several requirements that impose constraints and drive our design: 1. Privacy: By definition, casual conversations are not public. Therefore, it is important to ensure that users (a) have a clear idea of who can hear these conversations, and (b) can control who can hear them. 2. Text and audio conversations: Todays cramped office environments make it essential to support text conversations that do not disturb those not involved. On the other hand, audio conversations are more convenient. Therefore, our goal was to support both forms of communication. 3. Low effort: The system should provide an efficient interface, there should be low effort required to: (a) guard privacy, (b) find conversations one may wish to join, (c) join a conversation, (d) seamlessly move between conversations carried out in the real and virtual office, and (d) use both the 3-D and textual environments simultaneously. 4. Ease of learning: It should be easy to learn various aspects of the system in particular the privacy controls 5. Accommodate varying computing platforms and screen usage: Any tool supporting casual interaction would consume screen space. In addition, if it displays 3D graphics or video, it may also require a complete/separate screen and powerful computing platforms. A major goal in our design was to (a) accommodate even low-end platforms and use minimal screen space, so as to be used by large number of users, and (b) provide advanced features to those (e.g. managers) with more sophisticated platforms who are willing to devote an entire (possibly additional) screen for 3D. It is possible to draw on and extend principles embodied in previous work to partly meet some of these requirements: 1. Sidebar for collaboration information: The notion of a collaboration sidebar as well as commercial implementations by both Google and Microsoft shows that it is possible to use a small amount of space at an edge of the screen to display a collaboration user-interface.

Virtual worlds for collaboration: Work on collaborative graphical [1,2] and textual virtual worlds suggests that the ease of learning can be achieved by providing commands analogous to those we use in everyday life for as navigating in a 3D space or whispering. However, these systems can also be inefficient in terms of usability, and certain artificialities are required to strike a balance. 3. Modeling of a physical environment: Several organizations such as museums create virtual spaces that mirror actual physical spaces; navigating the virtual environment thereby becomes easier for those familiar with the physical space. 4. Distance-based communication: Some virtual environments partly address the privacy issue by, as in the real world, using distances in the 3D space between two users to determine if they can communicate with each other [4]. 5. Domain-Specific: One of the importance principles embodied in our work is that performance, user-effort, and privacy can be significantly improved by recognizing that the modeled environment is a static office with dynamic avatars. Previous works, both individually and collectively do not meet all of our requirements or embody all of our principles. Therefore, VirtualOffice draws on and extends these works: Like museums and other organizations, it creates a virtual space by modeling a real 3-D space. The modeled space, in our tool, is a real-world office. An office consists of a set of connected rooms, and a room consists of desks with workstations to which users are permanently assigned. The design of the tool, in particular, the privacy mechanisms, is intimately tied to this domain. VirtualOffice supports distance-based communication. It supports symmetric communication based on a single aura rather than a separate focus and nimbus as in [1]. Users do not control the extent of their auras. Instead, the domain is used to automatically set the aura. The floor space of the office is divided into a grid so that each cell of the grid accommodates exactly one seat. The seating arrangement of users in the VirtualOffice is the same as employees in the real office, so neighbours in the realworld are also neighbours in the virtual world. A user at a particular cell can normally communicate only with users located at that cell or its eight neighbours. We shall refer to these nine cells as the neighbourhood of the user. Users can amplify this normal aura by shouting to the whole office or reduce it by whispering to persons visiting their cell. Thus, walking around virtually in the office changes the set of people a user can hear or speak to. All users in the neighborhood of a travelling user are made aware of his or her presence by the system, and given enough time to react. This mirrors what happens in reality, that is, one is aware of who is walking around one. Privacy is also addressed since there is no chance of being snooped on. Users can communicate with others in their aura via text chat, as well as with another user visiting their seat via audio chat: Unlike text chat, which is broadcast to all users in the speaker's aura, audio chat is one-to-one by default. Users seated together in the virtual office are unlikely to use the system for audio chat when they can just as well speak to each other normally. However, a user logged in remotely may wish to start an audio conversation with a local user. If the conversation is of interest to the neighbours of the local user, the audio can be played on the speakers of the target's computer. Other users who are physically close to the target can simply walk over to the target and listen in/ participate. In the rare case of more than two physical locations being involved in audio chat, additional users need to request that they be added to the audio chat channel.

2.

Figure 1: Logical Architecture

Virtual Office is a client-server application. There are two varieties of clients to meet the requirement of accommodating varying computing platforms and screen usage. The first is a lightweight text (and audio) client similar to many instant messaging applications; we shall refer to this as the text client, even though it also supports audio. The text client has been designed to run on low-end systems, and does not demand precious system resources required for a user's regular office work. This ensures that insufficient hardware will not prevent potential users from installing and using the application. The text client is expected to be positioned on screen as an unobtrusive vertical sidebar. It models the physical world as a text-based 2D virtual world, using names and status information, rather than seats and avatars, to indicate the presence of a person. It provides textual commands such as goto and shout/whisper to navigate or expand/reduce a users aura. The presence and location of users is available to their neighbours, as well as to any user who is stand, thus mirroring the act of standing in an open hall of cubicles, physically in the real world or virtually using the graphical 3D client described below. The 3D client incorporates a graphical engine for rendering a 3D view of the virtual office. It has been designed for the purpose of virtually viewing and walking around the virtual office. The 3D client also incorporates the functionality of the text-client, so a user interacts with only one client application at a time. Both clients connect to a server, which manages and communicates information across users. Figure 1 shows a layered logical architecture of the system. The most fundamental layer, the (aura-based neighbourhood) grid, decomposes the office into cells, associates seat cells with users, and keeps track of each users online status and current virtual location. The grid layer also publishes methods to change the location and online status of the users, which are invoked by the navigation layer. The navigation layer is distributed between the client and server. The client-side navigation layer simply communicates the commands to the server-side navigation layer, which both issues appropriate operations in the grid layer and broadcasts navigation updates to other clients. The user-interfaces to execute commands are provided by the two client-side layers, text-client and 3D-client. The two clients also interact with the text-chat and audio-chat layers, which are also distributed between the client and server, with the client-side issuing the chat operations and the server-side distributing them. Because the two kinds of chats are aura-based, the layers managing them need access to the grid layer. The 3D client maintains a static 3D mesh, which is a three dimensional description of the corridors, offices, seats, spaces between cubicles, avatars and other objects visualized in the space. Finally, VirtualOffice also allows for impromptu demonstrations through desktop sharing implemented using an open source media server. We envision a number of use cases for VirtualOffice: 1. Virtually going to ones own office: Employees who cannot go to their real office on a particular day (for instance,

because they are travelling or need to stay home) can virtually interact informally with their officemates, possibly even continuing conversations they started in the real world. 2. Management by remotely walking around: Managers in charge of several distributed offices can virtually walk around offices in which they are not currently located. The system was, in fact, first conceived to meet this need. One of the authors of the paper manages three offices in different locations. He has a permanent seat in one of these offices. He continuously walks around in this office, often several times a day, to get progress status and hear concerns. One day a week, he physically walks around the second office, which is within driving distance from the first one. He never walks around the third one, which is in a different city, and thus is not as involved with the employees in it. We expect the tool to reduce the feeling of losing control that managers of remote teams often express. 3. Visiting a collaborators office: Similarly, the tool also allows users to visit offices of customers, suppliers and other collaborators. We expect such visits to be particularly useful in the practical business scenario of outsourced knowledge work that is executed offshore, often thousands of miles away. Connecting with knowledge workers via a 3D virtual rendition of a remote back office may break down constraints in remote collaboration, enabling more agile development. 4. Going both physically and virtually to ones own office: Lastly, even when users are physically present at their offices, they can use the tool to chat with, leave notes for, and check the availability of (local and remote) users without physically leaving their seats. As depicted in some of the scenarios below, the use of semi-synchronous text chat can sometimes even be preferred over voice communication. We have given here the broad requirements, design principles, features, architecture, and abstract target scenarios behind this research project. In the next subsection, we describe and motivate the user-interface of the tool in depth, using a detailed scenario of how it might be used, based on scenarios depicting hypothetical workplace interactions. In the sub-section that follows, we describe the implementation of our system in detail. 2.2 A Day at the (Virtual) Office Consider the following hypothetical scenario of workplace interaction: Bob, Mark, Tim and Jane are developers on the VirtualOffice team who also use the system to collaborate with each other. They sit close-by and are in each others logical auras. Alice is their supervisor, but sits farther away. Mary is in another team, but sits near Tim and has Alice, Tim and Mark in her aura. Peter is the overall head of the group and sits in a cabin but happens to be at a conference that day; and the others have desks arranged in different rows of a single bull-pen, as in Figure 2. As mentioned before, the seating arrangement of employees is the same as in the real office. The text-client of a user shows only a 2D view of the logical location aura around the user (Figure 3), while the 3D-client provides a graphical view of the complete office, and additionally reproduces the text-client as a subwindow, the right of Figure 2. (In this figure, we have inserted names of users to mark their seats in the environment: In actual use names are visible, via the text client, to their neighbors.) 2.2.1 Light Banter Mark comes to office physically, powers on his computer and is automatically logged-in to VirtualOffice. As Mark is physically in office, his virtual avatar is placed at his seat next to Jane, Bob and

Tim. In the real world, the four of them would be in each others visual field of view as well as aural range, so the same is replicated virtually.

Recall that Janes 3D-client has the text-client embedded as a vertical sub-window, which captures text input. However, Jane does not have to move her mouse to the chat-box to enter her text, because, unlike a general 3D world (such as Second Life), our specialized 3D-client integrates the text-client and re-directs all user-input to it as needed: Thus, as Jane starts typing in the 3D window, the client treats it as chat and not a navigation command:

Figure 2: Janes 3D-Client

(III) Jane and Bob feel comfortable chatting informally, since a chat message is sent only to people in the senders logical aura, i.e., those who either normally sit next to the sender, or happen to be virtually around, and the range of these messages mimics the real world. Bob and Mark resume their work and Jane moves her avatar to a corridor location next to Marks seat so as to get a better view of the office. She returns to her paper but as she is able to peripherally see the virtual activities of others whilst reading, she `feels closer to being in the office physically. 2.2.2 Catching Up Tim comes in to office physically, and notices that Mark and Bob are busy. He logs in with the text-client and sees the history of the conversation that took place in his absence. He remarks on Bobs shirt and a bug he found in Bobs code: So, Tim is made aware of casual interactions between his normal co-workers even though he was not in office when they took place, a beyond being there feature, while also retaining normal privacy (since if he had been in office, he would have heard such conversations). (IV) 2.2.3 The Paper Mark, Jane and Alice have co-authored a paper submitted to their companys whitepaper contest. Jane is done with her reading and is wondering whether the results of the contest are out. She moves her avatar to Marks seat and asks him about it via the textclient:

Figure 3: Text-Client Neighborhood View

Jane is working from home: She is sitting at a table with her laptop and reading a paper. She uses the 3D-client to log in at her virtual desk next to Mark and Bob. She is curious to see whats going on in office and decides to walk around. Seeing a visualization of an office as she is familiar with, she instinctively knows how to get around. She navigates her avatar around the office. Pressing an arrow key just once causes Janes avatar to walk to the next logical cell, unlike in many virtual worlds such as Second Life, which force a more fine grained navigation. Along the way she sees the chat messages, names and status of the people in her changing logical aura displayed in the text-client sub-window, as a grid at the top right-hand side of the client. She is visually aware of all other avatars in her 3D field of view that are graphically rendered in the 3D-client, as shown in Figure 1. Bob comes in to office a little later and also logs in with his text-client. Let us now return to Mark who notices that Bob is wearing his second new shirt that week:

(V) Jane whispers to Mark privately because Bob and Tim are not co-authors, and she does not want to disturb them. Thus, users in the same cell can have direct exchanges with each other. Since Mark, Tim and Jane usually take their breaks together:

(I) Thus, users sitting side-by-side in the real world may, in fact, have reasons to communicate with each other in the virtual-world. Further, such communication also allows remote users to get involved in the conversation: Janes avatar is back at her cubicle just as Mark is typing. She reads Marks message and adds to it: (II)

(VI) In the meanwhile, Mary and Alice come in to office. Mary logs in with the text-client. Alice gets into a scheduled long phone call, and she wants to multitask: She learns that the white paper she, Jane and Mark wrote, won the contest. She physically stands up to check whether they are in and notices that Bob is on the phone

and the rest of the seats are empty. She wonders where everyone is and decides to check their status using the 3D-client.

and Marys avatars in conversation and walks up to them. As he gets closer, he also sees their chat messages and realizes that they are talking about an HTTP-server. Peter didnt know that Mary needed an HTTP-server and wants to find out more. The 3D client automatically aligns the avatars and places them appropriately in conversation with each other as shown in Figure 5a. Peter joins the conversation and gives his own suggestions. Meanwhile, through her 3D-client, Jane notices that Peter is doing his walk-around. She navigates her avatar to him and says:

Figure 4: Jane and Alice in Conversation

Alice issues the /stand command that amplifies her aura to show her the status of everyone in the office. Her avatar stands and she gets a larger field of view. She notices that Jane is working from an out-of-office location and that Janes avatar is standing next to Marks seat. She navigates to Jane (Figure 4), who notices movement in her 3D client. Recall that Alice is physically co-located with Mark while Jane is not, yet Jane has a better idea of where Mark is because he had recently been virtually co-located with her!

(IX) Thus, Jane, who is sitting at home, manages to have an impromptu virtual conversation with Peter, who is also physically away, all in the presence of colleagues who are physically in office!

(VII) Next Alice gives the /goto seat command in the 3D-client to make her avatar leave Janes side and teleport back to her virtual seat. Thus, she does not have to use the mouse to walk back, as in other 3D virtual worlds. 2.2.4 Help is at Hand Let us now focus now on Mary, who is part of another team, and needs to write a small HTTP-server quickly. She wonders if anyone on the virtual office team knows how to do so. She uses the /shout command in her text-client to broadcast her question to everyone in the virtual office:

Figure 5a: Discussing the HTTP Server

Alice is still in her teleconference but notices a virtual conversation happening around her. She wants to tell everyone about the whitepaper and decides it is a good time since Mark, Jane and Peter are also around (Figure 5b). As a result of this virtual interaction, Peter offers to take the team out to lunch!

(VIII) Since Mark has written an HTTP-server in the past, he navigates to Marys seat using the /goto command in the textclient: Both the text and 3D clients have the same navigation commands for ease of use. Mark and Mary start chatting about the solution. Mark wants to look at Marys code and asks her to share her desktop. Since the two of them are virtually at the same seat, Mary can issue a /sharescreen command that enables Mark to view her desktop: In response to this command, the VirtualOffice server coordinates with the two clients to set up a connected pair of streaming client and server on their respective systems, allowing desktop sharing. 2.2.5 Management by Virtually Walking Around Finally, let us focus on Peter, the head of the group, who is currently away at a conference. He has some time between sessions and decides to virtually walk around the office, as he often does when he is physically in office. He logs in with the 3Dclient and starts to navigate his avatar around. Peter sees Marks

Figure 5b: Announcing the Paper

This scenario illustrates the nature and application of logical location auras and associated navigation commands. To better understand the research contribution of our work, we use this scenario to compare logical location auras with explicitly-defined static groups, such as in IM (instant-messaging) or group-chat, and geometric auras, such as in Second Life. 2.3 Scenario-based Comparison Unlike location auras, explicitly-defined static groups do not support dynamic binding to implicitly defined groups. In a system supporting such groups, which we shall refer to as a group-based system, the interactions between Mark, Bob and Jane, shown in

(I), (II) and (III), would not have taken place as a group comprising of people who sit close to each other is unlikely to exist and cumbersome to create for a one-off conversation. If Mark and Bob had been chatting in a group-based system, Jane would not be aware of it. The last chat message to Bob in (IV) and the conversation (V) may have taken place in such a tool, but it is unlikely that Tim would have set up a group-chat with Jane and Mark and joked about having coffee together (VI). Thus, Jane would not become aware that they were taking a break. Mary asking for help with the HTTP-server in (VIII) would be cumbersome to setup using a group-based tool, as she would need to add all of the potential helpers to the group. Even if she did so, it is unlikely that she would have added Peter to this group. Thus he would not have seen the conversation between Mark and her or contribute to it as in Figure 4a. Also, Jane would not IM Peter about her progress (IX) if he was away at a conference and logged into IM. The group conversation between Alice, Peter, Jane, Mark and Mary would not have taken place in group-chat, as there would be no reason for Alice to initiate it with this set of people. She would rather have setup a group with herself, Jane and Mark and announced the paper, excluding Peter. A group may exist between members of the entire office, but then informal comments such as a verdict on a shirt colour might not be made in such a forum, as they may be considered out of place. A group-based system would also not allow the ability to dynamically move in and out of conversations. Consider the conversation in (VII), when Alice asks Jane about Marks whereabouts as she sees her virtually standing next his seat. As a group-based system is not a spatial tool, Alice would not have thought that Jane could know where Mark was, and so would not have asked her. Now, let us consider our hypothetical scenario enacted using a system with geometric communication spheres (such as Second Life) which we refer to as a geometry-based system. We assume that a 3D model replicating the office has been created in such a system, as in our implementation. Conversations (I), (II), (III) and (IV) would not have taken place in a geometry-based system for the same reasons that they didnt in a group-based system. Although a geometry-based system does group users based on their proximity, even if everyone whispered, the messages would be heard within a certain radius that could have included other, possibly occluded users. Finally, automation, such Mary automatically turning to face Mark when he arrives at her seat, would not be supported in available geometry-based systems. 2.4 Implementation In this section, we describe the software architecture of VirtualOffice. Virtual interactions including chat and status messages, user locations and navigation, as well as static information such as who sits where, are maintained in a serverside model. The server is implemented in Python using the Google App Engine server, with the model persisted in the Google Datastore. The 3D-client is also a Python application built using the WxPython windowing system and the PyOgre graphics library. The 3D-client comprises of several components. The controller captures user-inputs and communicates them to the server, as well as to two views through a local replica of the central model. The 3D-view displays user avatars rendered in a 3D graphical view of the office using graphical meshes which are pre-loaded on the client machine, and the text-view displays chat messages and the users spatial neighbourhood. Finally, the

observer receives model updates from the server in an efficient manner: In-memory updates are cached on the server to minimize database queries. Further, we use a combination of polling and push updates that minimize network traffic and load when activity levels are low, while being able to broadcast events rapidly when activity levels are high. The observer incorporates a local, light-weight HTTP-server, so that the VirtualOffice server can push messages to VirtualOffice clients rather than forcing them to always poll for updates. Activity in the shared space, such as chat messages or movement, results in the concerned clients receiving messages pushed to them from the server. Note that only the concerned clients receive each message, e.g., those in the neighborhood of the sender, as in the case of chat messages, but all clients in the case of navigation events. On receiving such a message, the observer component switches from push mode to a polling mode so that subsequent messages are rapidly retrieved from the server via normal HTTP requests, which enables the server to more efficiently broadcast events when there is a high level of activity: Relying on push alone could allow a slow or disconnected client to block the server as well as result in an excessive number of messages when activity levels are high. Reverting to polling ensures that the server is efficiently utilized, since it knows that the requesting client is ready to receive a reply, as well as enables multiple database updates to be sent at once in case activity levels are high. Once inactivity is detected, the client reverts to push mode. Such a scheme not only reduces network traffic but also ensures that the server is not overloaded with unnecessary polling requests when there is no activity to report. Next, we describe the model as stored in the Datastore: As mentioned before, the office is divided into logical grid locations, each of which corresponds to one or more physical locations in the office. For most logical locations the corresponding physical location is in the center of the grid-cell; however, for a grid-cell containing a seat, there are two possible physical locations, one at the seat itself and one just beside it, where an avatar visiting that seat will be placed. Each cell also has a fixed set of directions in which an avatar can walk out of it to prevent going through static objects such as walls and cubicles without a collision-detection engine. For avoiding dynamic objects such as avatars, the availability of the next intended position is confirmed before movement. This information is locally available in case of keybased navigation which is always to a cell in the aura. In the case of /goto commands, the position and aura of the intended location is fetched from the server and a free position in aura is chosen. Finally, an important feature of the VirtualOffice architecture is its extendibility: As mentioned earlier, the client application is architected to support multiple view-components; such as the two views in a 3D-client. Each view communicates with the server via set of view-specific messages. Each view can also subscribe to messages belonging to other views. Thus, it is easy to add additional views to augment the functionality of VirtualOffice with additional collaboration components. To incorporate an additional application, one merely includes an additional viewcomponent in the client application and adds the required serverside functionality. The communication layer from client to server as is directly re-used by configuring additional message types and subscriptions. For example, we have augmented the VirtualOffice with a presentation component, whereby a PDF file can be collaboratively viewed by multiple participants. Another example we have considered is a project management component to support a specific methodology, so as to create a virtual

SCRUM-room at the VirtualOffice. Thus, apart from being an innovative tool for workplace collaboration, VirtualOffice is also a platform for building purpose-specific collaboration applications within the same metaphor. 3 COMPARISON WITH RELATED WORK

3.1 Existing vs. New features As mentioned above, though no previous research has been designed to meet all of the requirements of this project, our work draws upon and is related to a variety of tools. The notion of creating a 3D virtual environment based on the physical world is not new. There are systems that provide textual views of 3-D worlds and commands to teleport to objects. The general idea of using auras for communication among users is also borrowed from previous work. For instance, in, Second Life text chat can be heard within a radius of 20 meters, whisper in 10 meters and shout in 100 meters. However, unlike our system, none of the previous 3-D and textual virtual worlds have focused on the concept of a virtual office. This focus has allowed us to create a domain-specific system that meets the requirements given earlier. The result is a set of novel features. Avatars are created automatically based on real people in the corresponding physical environment. It is also possible to tell which of the logged-in users are physically present in the office based on their systems ip address. Users, who are not logged-in, but have seats, have presence in the system, and it is possible use text-chat to leave notes for them. The auras are based on logical seats rather than physical distances. The whisper and shout commands are based on seats rather than physical distances. Teleporting is also based on the seats of office workers. Basing features on logical seats reduces user effort as users do not have to translate logical actions into physical ones. In addition, neighbourhood based aura makes it easy for users to predict who is listening to them, thereby reducing privacy concerns. Basing auras on physical distances allows ones communication to be heard by even unseen, occluded users within the hearing range. Our teleport (goto) can be to a user or a location, unlike general purpose worlds which allow teleports to locations only. It is possible for a user to simultaneously use the text and 3D view, whereas systems such as Second Life do not allow simultaneous login using two different clients nor offer an integrated 3D/text client. As a result, in our system, actions taken in the one are automatically translated into the other. For instance, when users use the /goto command in the text client, their avatar is appropriately placed in the seat cell. An avatar automatically turns to face a visitor. Typed text goes automatically to the text window because hot-keys and other applications of text are not required in our scenario. Conversely, arrow keys can always be used for navigation, even when the user is typing text. In comparison, the user-interfaces of many graphical virtual worlds, such as Second Life, are similar to those of computer games. For example, though navigation is possible using the keyboard, the mouse is still required to initiate communication using text or audio chat. Our approach is more efficient in terms of the number of user actions needed to achieve a simple communication goal, such as text-chat, as well as accessible to users unfamiliar with computer games. Further, we disallow avatar animations and actions inconsistent with the domain, unlike Second Life. This

restriction prevents users from even accidently exhibiting behaviour considered inappropriate in an office such as dancing, and flying [9]. We have also exploited domain specificity in our implementation: The only objects that move in our virtual world are the avatars. As a result, only avatar updates need to be communicated, and the office visualization can be preloaded in the clients. General purpose environments must either compute visual updates based on a users field of view, or send continuous updates of all objects, thereby offering lower-level of performance. Our system also does not have to worry about conflicting updates, such as one user deleting an object and another moving it. 3.2 VirtualOffice in Benfords & Schroeders Spaces Another way of differentiating our work is to place it an abstract design space. Benford et al [2] have developed a taxonomy to succinctly describe and differentiate among distributed synchronous collaborative systems based on three dimensions: transportation, the degree to which users are transported from their physical environment to the collaborative world; artificiality, the degree to which the collaborative environment deviates from a real-life world; and spatiality, the degree to which the world is based on a 3D space. Figures 6a and 6b place our work and related tools in this space: The transportation and artificiality dimension are shown in Figure 6a, and spatiality in Figure 6b. TC-VO and 3D-VO are our text and 3D clients respectively. As illustrated in the Figure 6a, the feeling of transportation can be increased by increasing the size of the image representing the collaborator, using more dimensions to show the remote view, and providing an immersive rather than desktop virtual environment. The degree of artificiality decreases as more and more features are added to mirror a real-world. In comparison to other text worlds, the VirtualOffice text view offers more transportation because it shows a 2D neighborhood grid. On the other hand, the 3D view is deliberately more artificial than traditional 3D virtual environments (which do not offer teleporting) in two respects: Navigation is automatically animated when a goto command is executed, and an avatar automatically turns to face a user who moves to its location. We neglect these two respects in the classification. Builders of virtual environments have observed that users walking through these environments have often expressed the need to teleport1. Our 3D automations reduce the effort required to use the system but require the users to learn these artificialities. The text view offers more artificiality than the 3D view as users (a) can see names of others, and (b) have 360 degree X-Ray vision that allows them to view the status of everyone in their neighborhood, when they are sitting, and everyone in the office, when they are standing. Our 3D view offers greater transportation than systems that show (projected) videos of remote participants, such as CISCOs TelepresenceTM. On the other hand, these systems do not scale well in terms of the number of video streams they can show. All of the other systems allow an arbitrary number of users, an implicit requirement in our project. Finally, consider spatiality: 3D systems offer more spatiality than 2D systems because of the extra spatial dimension. Both 2D and 3D systems supporting distance-based communication not only tie
1

Fred Brooks, personal communication

navigation to space but also communication hence they offer more spatiality than those that do not.

Figure 6a: Benfords Transportation/Artificiality Classification

Figure 6b: Spatiality in Benfords Classification

By comparing the text view and a video-conferencing system with respect to spatiality, as in Figure 6b, we are able to make a new observation - it is possible to create a system that offers less transportation but more spatiality than another system. Previous research has shown that is possible to offer more transportation but the same spatiality. VirtualOffice also represents a new point, figure 7, in the presence, copresence and being there together taxonomy [13]. It is higher than general purpose desktop-based shared VEs along the presence dimension as it models a physical space providing a greater sense of immersion. It is lower in copresence and connected presence as one is aware of the absence of users who belong to a particular office but happen to be logged out.

domain-dependent system such as ours, but also a domainindependent tools such as chat and Second Life, albeit with more overhead. As we have shown here, it also serves as a concrete basis for comparing different office tools. As the features described in this paper have been implemented recently, it has so far been made available only to the team that implemented it. One important use of the system was a couple of walkthroughs, using the 3-D client, done by the second author while travelling abroad: The author was able to exchange status updates and get a feel for the activities under way in the group. Interestingly, he preferred using the 3D client as it allowed him to virtually be there and feel closer to the group, while several team members actually in office preferred the efficiency of the text client. Once the system is robust enough, we hope to get enough experience to suggest improvements to the design and implementation of the system. We believe that our domain specific approach will enable more usable and efficient collaboration tool as well as provide a platform for further situation specific enhancements, such as virtual presentations, or methodology based project meetings mentioned earlier. A future design direction have considered is the use of proximity-based video conferencing, and integration with the concept of the OfficeWalker [6] video-conferencing system, which, unlike our system, is tailored for cubicle-based offices, and allows a user to wait in a hallway before entering a room. We are also planning on allowing avatars faces, clothes and dimensions to be more life-like and recognizable, so as to determine whether such enhancements improve or reduce the adoption of the system within our organization. 5 ACKNOWLEDGEMENT This research was funded in part by NSF grants IIS 0712794 and IIS-0810861 REFERENCES
1. Benford Steve, Fahlen Lennart, A Spatial Model of Interaction in Large Virtual Environments, Proc. ECSCW, 1993, 109-124. 2. Benford Steve, Greenhalgh Chris, Reynard Gail, Brown Chris, Koleva Boriana. Understanding and Constructing Shared Spaces with MixedReality Boundaries. ACM Transactions on Computer Human Interaction, Vol. 5, Issue 3, 1998, 185-223 3. Brzozowski M.J., WaterCooler: Exploring an Organisation through Enterprise Social Media Proceedings of GROUP 2009, 219-228 4. Fahlen L. E., Brown C. G. The use of a 3D Aura Metaphor for Computer Based Conferencing and Teleworking. Proceedings 4th Multi-G Workshop 1992, pp 69-74 5. Nielson J., Mack R.L., Usability Inspection Methods John Wiley and Sons, 1994 6. Obata A., Sasaki K., OfficeWalker: A virtual visiting system based on proxemics Proc. CSCW 1998, pp 1-10 7. Peters T., Austin N., A Passion for Excellence, Random House, 1985 8. S. Whitaker, D. Frohlich, and W. Daly-Jones, Informal workplace communication: What is it like and how might we support it? in Proceedings of CHI 1994. 9. Zutshi A., Sharma G., A Study of Virtual Environments for Enterprise Collaboration Proceedings VRCAI 2009. 10. J. Paradiso and J. Landay, "Guest Editors' Introduction: Cross-Reality Environments", IEEE Pervasive Computing, vol. 8, no. 3, pp. 14-15, July-Sept. 2009. 11. Back Maribeth et. al, The Virtual Factory: Exploring 3D worlds as industrial collaboration and control environments, IEEE Virtual Reality 2010, pp 257-258 12. Richard Bartle, Designing Virtual Worlds, New Riders Publishing, 2004 13. Ralph Schroeder, Being there together, Oxford University Press, 2011

Figure 7: Schroeders Presence, copresence and being there together

CONCLUSIONS AND FUTURE WORK

The novel aspects of this work can be described at various levels. Our highest-level contribution is the idea of mirroring the visual, text-based and audio communication channels in a real office. The next-level contributions are the requirements, design principles, abstract logical architecture, and general scenarios we have explicitly identified for meeting this goal. Our most concrete contribution is the design and implementation of a system that follows these requirements and principles. The classification of the system in an abstract taxonomy of related systems such as MUDs and Cisco TelepresenceTM increases our understanding of the system and the space of collaborative systems in general. Our detailed thought experiment is a contribution in its own right, and serves to motivate virtual offices created in not only a

10