1 Introduction

Ubiquitous computing technologies are becoming a reality, with technology and interaction gradually pervading the work environment. Large, shared interactive displays are a particularly interesting area of study and development because of their ability to support collaboration in shared workspace and use, viewing, and interaction by multiple users simultaneously. These displays offer many affordances that make them suitable to group work, including visibility from a distance, a shared interactive work surface, and when networked, the ability to move content and artifacts from individual users’ machines to a shared space as tasks require.

In our research, we investigate the use of one such system, the NASA MERBoard, which was created by designers and researchers at the NASA Ames Research Center for use by scientists and engineers working on the Mars Exploration Rover (MER) missions at NASA Jet Propulsion Labs. In this work, we specifically examine the hurdles and challenges to adoption and integration that the MERBoards faced as a result of their real-world deployment. Because of unexpected constraints imposed by the environment and situation of the deployment, the MERBoards met with difficulties that were external to their design, and often could not have been known or anticipated in advance by the designers.

In a yearlong field study of the use of the MERBoard in the NASA MER missions, we gathered data through onsite and telephone semi-structured interviews with 18 MER scientists and members of the MERBoard design team, and also conducted brief observations of the MER mission environment at NASA Jet Propulsion Labs (JPL). In this article, we unpack several of the challenges that affect the adoption and integration of a shared UbiComp system into work practices, specifically exploring the difficulties presented by a real-world deployment that can come into conflict with designers’ decisions and intended system use. We present background information on the user population, the MERBoard and the MER mission environment. Influenced by the work of Davis et al on technology uptake, we examine the adoption of shared display systems in terms of their perceived benefit and perceived ease of use [1]. Additionally, we present a third factor to consider in analyzing the uptake of shared ubicomp resources in particularly; we posit that perceived appropriability must also be taken into account in analyzing adoption, as availability of a shared technology must be negotiated in order for it to be successfully integrated into use by a members of a workgroup. Finally, we discuss the implications of these findings for real-world deployments of shared ubicomp resources in general.

2 Background on the mission

In January of 2004, the National Aeronautics and Space Administration (NASA) landed two unmanned vehicles on the surface of Mars for the purposes of collecting scientific information regarding the terrain, composition, and atmosphere of the planet. The Mars Exploration Rover (MER) mission has continued for the past 25 months, with the two rovers, Spirit and Opportunity, continuing to transmit data to Earth as they traverse the surface.

The actions of the rovers as well as the data that they collect are guided by mission scientists and engineers, and the mission is based at NASA Jet Propulsion Labs in California. To coordinate their activities, scientists and engineers employ a variety of tools for collaboration and information sharing. In the group workspaces designed specifically for the MER Missions, shared displays, including large projection screens, large interactive plasma displays, and shared workstations with multiple monitor setups, are ubiquitous. Together, these surfaces form a complex multi-display environment that functions as a whole, despite not having been designed as a unified, seamless system (Fig. 1).

Fig. 1
figure 1

The MER mission multi-display environment

Full size image

Of particular interest to us is the MERBoard [2], an example of an emerging class of pervasive computing technologies comprised of interactive large multi-user display systems. Although many such systems have been designed, deployed, and studied in a variety of settings in recent years, the NASA MERBoard system, designed and deployed specifically to support MER Mission science tasks, is unique in its complexity and the extent of its deployment in authentic work settings.

Unlike many other large interactive display systems, MERBoards were deployed to support specific, time-dependent work tasks of real users (Fig. 1). MERBoards were integrated into a fast-paced, round-the-clock and often hectic work schedule to support necessary tasks; this is in contrast to many systems that have been deployed primarily in research or test environments as supplemental support for collaboration, rather than a primary medium for accomplishing work tasks. Additionally, many MERBoards were deployed in parallel, with 18 MERBoards in use at JPL during the initial months of the mission, whereas other research prototypes have often been single instances of the technology or deployed in small numbers. Finally, unlike many other large display groupware systems, MERBoard has been integrated into a work environment that contains many display alternatives, including several other large display options. All of these factors led us to investigate whether and how MERBoard was used and integrated into work activities.

The gathering of scientific information on the MER missions has entailed highly dynamic procedures, especially during the “nominal mission”—the initial 3 months following the rover landings. Working on a 25-h cycle (the length of a “Sol”, or Martian day), teams of scientists and engineers would receive, process, and analyze downlink data from the rovers and Martian satellites, decide the next course of action for the rovers as well as what data should be collected next based on this information, convert these decisions into sequences of instructions for the rovers, and send this information to the rovers via the data uplink. Each of the steps in this cycle was highly collaborative, and required significant coordination between groups of collaborators working on various steps of the cycle, as well as among group members working together on a single task.

3 The user population and the work environment

The collaboration among scientists on the MER mission teams was a particularly interesting subject of study for several reasons. While some of the scientists were on staff at NASA, most of them came from other academic and research institutions specifically to work on the mission. Although they had collaborated remotely on pre-mission work and had come to JPL to work together for training sessions and meeting, they had not worked in a physically collocated setting for extended periods of time in the past. Because these they were working on new tasks without much prior experience in collocated, synchronous collaboration, and because some of the scientists had not known each other prior to the mission, workgroup collaboration practices developed and evolved throughout the course of the mission. Additionally because the science tasks that the mission entailed were largely novel, the tasks procedures had to be learned by the scientists in the pre-mission training and during the mission.

The designers of the MERBoard needed to develop the MERBoard applications prior to the mission so as to have it deployed throughout its duration. Because the workgroups were new and the tasks were novel, the designers of the MERBoard could not design the system based on studies of the workgroup to support existing workgroup practices, nor could they look at how the tasks were done to design to support those procedures. Instead, they designed for a set of known mission tasks and anticipated collaborative needs, having to predict what the scientists would need the interface to do, and what the best interactions to support the tasks would be. The designs were refined during a series of pre-mission training events and field tests, but the design process was difficult due to the changes in the mission tasks and differences between the training environment and the actual mission environment.

The mission science teams included five theme groups, upon whose MERBoard use we focused in this study: Atmospheric Science, Geology, Minerology and Geochemistry, Soil and Rock Physical Properties, and Long-Term Planning. The scientists collaborated within the individual theme groups, as well as working among the theme groups, and the entire science teams met also daily as a whole for reports on the day’s activities (Fig. 2).

Fig. 2
figure 2

A team-wide science meeting involving MERBoard and projection screens as shared visual surfaces

Full size image

The mission engineers were the secondary user group for the MERBoards. In this work, we focus specifically on the use of the MERBoard by the scientists, but we mention the engineers here to give a better overall picture of the complexity of the workgroups and mission environment. Although MERBoard tools were not designed specifically to support engineering tasks, it still offered engineers general-purpose tools, such as the whiteboard and access to mission schedules. The mission engineers, unlike the scientists, were primarily NASA staff or contractors and were therefore more likely to have worked together as a team in the past. Additionally, they were working in a more familiar environment and their tasks bore some resemblance to those on past missions. In contrast to the scientists, the engineers had some existing collaboration practices and experience working with each other, and their tasks were more proceduralized and familiar coming into the mission.

Scientists and engineers generally had distinct responsibilities, although there was considerable collaboration between them. The scientists were responsible for the scientific aspects of the mission, such as analyzing the data gathered by the rovers, deciding what further data goals and exploration should be pursued, and determining at a relatively high level what course of action the rovers should take. In contrast, engineers were responsible for the more tactical aspects of the mission, including determining the rovers’ exact sequences of action, controlling the instruments on board the rovers, sending the information to rovers, and collecting the downlink data.

During the nominal mission, all scientists working on the mission were resident at JPL, with all of the science theme groups for each mission collocated within large science assessment rooms. Within these rooms, each theme group had its own area, each with a MERBoard, several workstations, and two projection screens. Additionally, there was a MERBoard and a pair of projection screens in the front of the room used for presentations and meetings. At any given time during the nominal mission, several dozen scientists were present in the space; this number decreased steadily after the end of the nominal mission. Engineers worked in teams in several other smaller spaces at JPL, including Mission Control and Sequencing areas. These rooms had different configurations of displays, with at least one MERBoard and one projector; some had multiple of each.

During the extended mission that followed the nominal mission, some scientists returned to their home institutions and began to work remotely; science activities were distributed across JPL and other laboratories, while the engineering tasks continued to take place at JPL. As the mission was further extended, science collaborations became increasingly distributed.

Prior to the start of the mission, many of the scientists and engineers participated in a set of mission simulation exercises called the FIDO (Field Integration Design and Operation) trials. During the exercises, the teams engaged in simulated mission activities, on a compressed time cycle. They were also trained on and exposed to the tools and systems that they would be using during the actual mission, including the MERBoard.

4 MERBoard: the design of the system

The NASA MERBoards consist of 50″ touch-sensitive plasma screens with a resolution of 1,600 × 900 pixels. The screens are mounted upon stands at a height that allow users to interact with them while standing up. MERBoards interactions are achieved through touch, stylus, or keyboard input, depending on the application being used.

MERBoard’s architecture was based on plug-ins and was developed specifically for the Mars missions. In addition to some commercial software plug-ins, including Microsoft Office, the MERBoard software consisted of a suite of applications and functionalities including the following:

  • SolTree The SolTree tool was a graphical tree-building program that supported the task of Sol planning (Fig. 3). Using this tool, scientists could create tree structures of nodes and paths to represent possible plans of action for the rovers for the following Sol. SolTree provided the ability to keep track of all details of the plan and annotate them with notes. Scientists create new structures and substructures through a series of pull-down menus, designed specifically for the potential rover actions.

  • Whiteboard The MERBoard provided a general-purpose digital whiteboard that allowed users to do freehand drawing and writing with the stylus or use basic graphical tools from a tool palette. Additionally, users could input text onto the whiteboard surface using the keyboard. The whiteboard had a tabbing mechanism that allowed several different whiteboard sheets to be open at the same time.

  • CIP portal Not specifically a MERBoard application, MERBoard could be used to access CIP, the Collaborative Information Portal, a central repository for mission information, such as schedules, mission planning information, and mission data. CIP also provided a clock that displayed Mars time for both of the rovers, as well as the current time Earth time at JPL.

  • MERSpace and the MERSpace directory Data could be pulled up on the MERBoard or saved into MERSpace, a shared document repository accessible both from personal machines and the MERBoard. Users had individual directories on MERSpace into which documents could be dropped as a way of making artifacts from personal machines accessible on the MERBoard, or as a way of distributing artifacts created on the MERBoard to users. MERBoard accounts could be associated with a personal icon, onto which documents could be dropped.

In previous work, we have analyzed the use of these and other MERBoard functionalities as they evolved during the course of the mission, offer a detailed account of use and interaction in the context of the other display technologies in the environment [3]. We related the changing role of the MERBoard to the fit between the scientists’ tasks and the system design, the affordances of the other displays, and the evolution of mission tasks. In this article, we focus less on the use and interaction with the MERBoard, and instead examine the challenges imposed by external factors that came about as a result of the real-world deployment and constraints of the environment for which the designers could not control.

Fig. 3
figure 3

Scientists discussing a plan using SolTree on the MERBoard

Full size image

5 Related research

This analysis of the real-world challenges affecting the deployment of the MERBoard complements some earlier studies and analyses of MER mission technologies by others and ourselves. Prior to the MER mission, some designers of the MERBoard presented the design of the prototype as well as some findings from early tests and training sessions [2]. Designers of the MERBoard conducted a study of the early months of the mission, focusing on the knowledge and data management practices surrounding document creation and use on the MERBoard [4]. In a recent analysis, we looked at the evolution of the use of MERBoard over time, focusing generally on users’ perspectives of the tasks, tools, and collaborative practices over time, as well as the interplay among the many situated displays in the MER mission environment [3].

Several other interactive multi-user display systems and multi-display environments have been designed for the purposes of supporting work tasks or collaborative work. Like MERBoard, systems such as BlueBoard [5] and Tivoli [6] offer whiteboard-type tools for collaborating on shared artifacts. Designer’s Outpost [7] offers scaffolding tools for the purpose of supporting preliminary website design. Tools such as MessyBoard [8] and the Notification Collage [9] support synchronous and asynchronous communication for collaboration. Projects like CoLab [10], ARIS [11] and iRoom [12] focus on the architecture, system design, and interaction techniques of multi-display environments with a focus on how users can interact across the displays. These systems and environments have been evaluated primarily in laboratory studies, used only in research settings (often the home laboratories of the researchers), or in limited-term experimental trials. While the evaluations of these systems have yielded valuable findings regarding the value and use of large interactive displays for supporting group work [13], we still lack a deep understanding of what role these systems play in natural work environments over time. A recent workshop on multi-display environments (both single-user and collaborative) [14] included position papers that identified common types of multi-display environments [15], as well as technical design considerations for such environments [16]. We believe our work builds upon the existing research by providing an in-depth examination of how one of these systems is used in context and in authentic use and by identifying the challenges that arise as a result of the constraints of a real-world deployment.

6 Integrating a shared ubiquitous computing system into a real-world work environment

Overall, MERBoard met with mixed success in integration with mission activities; the SolTree tool in particular was well adopted in the early months of the mission by the Long-Term Planning theme group, as it provided support for their planning tasks and was therefore a critical path tool for them. Despite this success, other functionalities such as the whiteboard received less use than expected, and the other science theme groups made considerably less use of their MERBoards. In this section, we examine the real-world challenges to use and integration of these technologies. Davis et al have posited in their work on technology acceptance that people’s use of new software is dependent on two factors: the extent to users perceive the software as being beneficial to their work performance (perceived usefulness), and the extent to which the users believe that using the system will be “free of effort” (perceived ease-of-use) [2]. We unpack how these concepts apply to a shared large display for a workgroup, and suggest a third factor that we believe is particularly important to shared ubicomp resources: ease of appropriability.

We also describe how each of these factors met with unanticipated difficulties stemming from issues external to the actual design of the system. The “real-world” deployment of the MERBoard offered many challenges that could not be easily fixed due to mission and NASA constraints that could not have been easily anticipated by the designers of the system. Practical problems caused by factors external to the design of the MERBoard yielded a difficult integration of the displays into the scientists’ regular work practices, as well as difficulties integrating the MERBoard with the other technologies in the work environment.

6.1 Users must be able to perceive the system as valuable

Getting users to realize the potential value of applications on a large, shared display can be particularly difficult for several reasons. Users often must experiment and interact with the applications to get a feel for how they might make use of them in their work activities, but because users do not feel as strong a sense of ownership over a shared resource such as a large, interactive display, they may be less willing to spend time learning the system. Because these displays tend not to be located in users’ personal workspace, but rather in shared workspace, users may also be less willing to explore the system for any length of time [5].

6.1.1 How MERBoard’s design offered potential value to work activities

In the case of the MERBoard, the system provided several potential benefits not offered by other tools and resources in the environment, namely a shared interactive visual surface that allowed users to author, annotate, view, and discuss artifacts collaboratively, as well as losslessly save and distribute these artifacts. Projection screens allowed users to view and discuss artifacts, flip charts and conventional whiteboards allowed scientists to author, view, and discuss artifacts, while laptops could be used only for small collaborations, as well as saving and distributing information. MERBoard, however, offered all of these capabilities in a single system. It was therefore hoped that through using the system, users would discover how all of these functionalities together would help improve the quality of their collaboration and the allow them to work more effectively.

6.1.2 Real world: unexpected challenges to user perception of MERBoard value

In the actual MER mission deployment, several issues external to the actual system design prevented mission scientists from fully realizing the potential of the MERBoard. Learning and training on the MERBoard became big challenges because of time constraints and limited access. Specifically, MER scientists were not extensively trained on the use of the system and therefore did not have so much exposure to using the system before the start of the mission. Once the mission began, scientists were extremely busy and had little motivation to explore or learn to use the system as there were few tasks for which the system was strictly necessary and the system was not mission critical.

NASA subdivided all of the mission systems and software into three classes, which were predetermined before their development. Systems designated as “Class A” were the tools that were deemed to be absolutely mission critical; these systems would house and provide access to all of the main data collected during the mission. The software for the SAP (Science Activity Planner) workstations was an example of a Class A system; the software on the shared SAP workstations in the science assessment rooms were where scientists could gain access to the Mars downlink data, including images taken by the rover and satellite cameras. This software was extremely mission critical; without it, scientists would not have been able to work. Systems designated as “Class B” were those that were deemed important for work and that touched upon the main data but not crucial to the mission. The CIP system was one such system; though CIP, scientists could gain access to important some important mission information such as schedules and other data, but it was not a primary source of downlink data from Mars. The “Class C” systems were those that were not mission-critical and did not touch upon the main mission data, but were instead intended to provide additional optional support. MERBoard and its software fell into the category of Class C. As a Class C system, MERBoard had no direct access to the primary mission data. Scientists could not use MERBoard to access mission data directly, but could manually put data, such as images from the rover cameras, into MERSpace to view it on the MERBoard. Users could use the MERBoard to access data housed in CIP, but needed to use the CIP interface on MERBoard to do so, creating additional overhead for using that tool on the large display.

The class designation yielded a further challenge for the MERBoard integration, in addition to the extra levels of interaction for data access and display. Because MERBoard was a Class C system and therefore not mission critical, it was also a lower priority during the pre-mission operations training. Scientists were given less instruction on the use of the MERBoard and were given less time to practice using it during the mission than the other tools. In order to become proficient with the MERBoard, scientists needed to use it or practice using it during the mission itself, but because it was not on the critical path for the science tasks, with the exception of the SolTree tool for the Long-Term Planning group, many scientists did not make an effort to use it. Their schedules were hectic with many necessary tasks for which they had existing tools or displays that they already knew how to use. One of our study participants explained that the Class A SAP was itself difficult to use, but because it was critical, scientists became proficient with it through regular and necessary use. In contrast, MERBoard was a supplementary technology, used from time to time by a subset of the scientist as tasks required.

6.2 Users must perceive the system as easy to use

Because shared large displays are regarded as a group resource and generally reside in shared workspace as opposed to personal space, users may be less amenable to spending time learning how to interact with them; it may be uncomfortable for them to be standing in shared space making errors and trying to understand how a system works [5]. For this reason, it is particularly important that users perceive these shared ubicomp resources as easy to use. Additionally, such displays are generally not intended to be the primary work display for most users; rather they are generally intended to be a supplementary group work surface in additional to individuals’ personal machines. Therefore, one of the important aspects of ease-of-use for large, shared displays is that users be able to easily integrate them into the work that they do with their primary machines and other work tools. If users find that it is difficult to use their shared display and their laptops in conjunction with each other, they will continue to use their laptops for work, but may cease to use the shared display. Particularly for shared displays, the ability to migrate to and from the display easily is crucial to the perception of ease-of-use.

6.2.1 How MERBoard’s design addressed ease-of-use for content migration

MERBoard offered a shared, interactive visual surface well suited to small group collaborations, and at times scientists wanted to take advantage of its capabilities for collaboration. One of the greatest difficulties with the MERBoard described by the scientists was the interaction necessary to display an individual’s content on the MERBoard; they had to go through MERSpace in order to do so. However, MERBoards designers had anticipated that scientists would be reluctant to use the MERBoard if they could not easily migrate content from their laptops, and had therefore designed a VNC-type remote display control that allowed users who were logged onto MERSpace to access their PCs from the MERBoard, and vice-versa using a one button remote access interaction. This would have allowed users to migrate easily between interacting with content on the MERBoard and their PCs without explicitly needing to transfer data between them.

6.2.2 Real world: technical challenges lead to the perception of use overhead

In practice, the one-button functionality for migrating between laptops and the large display failed in the MERBoard mission deployments because of another real-world difficulty. The complex work environment into which the MERBoard was deployed had unanticipated technical constraints that affected the utility of the MERBoard. Because so many of the scientists were not NASA scientists, but rather visiting scientist from other institutions, they brought laptops from their home institutions to serve as their primary machines during the mission. As a result, the scientists had difficulties with the firewalls at JPL that prevented them from being able to access the MERBoard remotely from their laptops. Scientists could only use the remote access if they were on the wireless network, but JPL provided unexpectedly few wireless connections in the science assessment rooms. Scientists therefore accessed the network through LAN connections which did not permit access to the MERBoard via the remote access, thus rendering the easy content migration interaction unviable. None of the scientists to whom we spoke in our study had ever made use of the remote access and they were unaware that they could migrate content without transferring the data into the MERSpace. Because this was a real-world deployment of a technology that was not deemed mission critical, it could not be expected that the environment would be significantly altered to support the use of the MERBoard.

6.3 Users must perceive the system as available when they need it

Unlike other software and systems that belong to individuals or have primary individual users, shared resources such as these types of large displays have an added factor that affects whether they are successfully integrated into work practices. Although, it is important to consider the extent to which users find a system useful and whether they find it easy to use, in examining the uptake and integration of a shared ubicomp resource by a workgroup, it is also important to consider how users appropriate and gain access to the system, as it is not individually owned or dedicated to a single user. With shared ubicomp systems, users or groups wishing to use the technology must determine whether a system is available for use and possibly negotiate its appropriation. The initial uses of a shared ubicomp resource may prove that the system offers benefit to the user and that the interface is simple enough to warrant its use, but the system will not be integrated into a workgroup’s regular work practices if individuals or subgroups are not able to appropriate the technology when it would be beneficial to do so.

6.3.1 How MERBoard’s design addressed availability

Although MERBoard did not have any features that were specifically designed to indicate availability, the design did offer some implicit indications of when the board was in use. MERBoard’s applications were designed largely for interactivity, as evidenced by the SolTree and whiteboard tools that the system provided; the design therefore assumed that in most cases, people would be visibly interacting with the system when it was being used. Additionally, the display of personal icons on a sidebar in the interface showed who was currently logged onto the system. Had the MERBoard been used only for interactive purposes, it would have been trivial for others to determine whether the system was appropriable, and negotiate availability if necessary.

6.3.2 Real world: unexpected features yield social overhead in appropriation

Because the MERBoard did not have direct access to important mission data, the designers of the MERBoard worked with designers of the CIP portal to make CIP accessible through the MERBoard. As a result, MERBoard designers did not have complete control over what kinds of content would be displayed on the MERBoard. In the final deployment, the CIP portal included a clock that could be displayed on the MERBoard that showed the current Mars time for each of the rovers as well as the time at JPL. This clock consumed the entire screen and was highly visible from a distance. As the mission progressed, the CIP clock became the single most dominant use of the MERBoards by the scientists. While scientists generally described the CIP clock as useful to their work, the dominance of the tool may also have led to poorer adoption of the interactive MERBoard tools.

This passive display of the clock created social overhead that made the MERBoard more difficult to appropriate by scientists who wanted to use the display for active collaboration. Some scientists suggested that people might have wanted to use the MERBoard, but were hesitant to appropriate the board for fear of depriving other group members of the clock. Once the clock was on the MERBoard, people were less likely to use it for other purposes. The scientists may have perceived the clock as being crucial to others’ work and were hesitant to interact with the display for their own benefit if it meant inconveniencing the group at large. One of the chief difficulties that the clocks posed, however, was that in their ambient state, it was difficult to tell whether they were “in use” by members of the workgroup. As a result, some scientists mentioned that small subgroups who were collaborating around a science workstation or a single user’s laptop were hesitant to migrate their work onto the larger shared work surface that MERBoard provided because they feared that they would be appropriating a tool that others were using. Especially because their collaboration would likely be of direct value only to them, while the clock potentially benefited everyone in the space, scientists said they were not sure when it was acceptable to migrate their work or tasks to the MERBoard if it was being used for ambient information display. In the case of the MERBoard, the unexpected addition of this external functionality led to scientists being unable to determine and negotiate the availability of this tool.

When the designers of the system saw the clock provided by the CIP portal, they recognized the potential for the clock to overtake the interactive tools that the MERBoard offered as a primary function. Two separate design teams had designed tools, and the MERBoard designers could not make design decisions for the CIP tool. Additionally, because of the start of the mission was fixed, the deployment of the mission tools, including MERBoard and CIP could not be delayed. NASA imposed a “code freeze” on all development 3 months prior to the launch of the first rover, so a redesign was not possible after CIP and MERBoard had been integrated. Redesign was also not possible during the mission itself, as only maintenance and bug fixes could be done on the “production” versions of the software.

7 Implications for shared ubiquitous computing systems

Clearly, the deployment of MERBoard into a real world setting yielded challenges that the designers could not have anticipated, and led to problems that could not be easily remedied through design. With its tight schedule, unique workgroup, and organizational constraints, the integration of the MERBoard into mission science activities presents an extreme case of a challenging deployment. Iteration to address the challenges was not possible given the nature and structure of the mission, and the designers had power to influence the constraints of the environment or work practices of the scientists. This is in direct contrast to research deployments of shared ubicomp technologies in which designers may have a good deal of control over the environment in which the technologies reside, as well as some degree of personal connection to the users or study participants. Despite the uniqueness of the MER mission deployment, we believe that our findings from this study yield lessons about the potential challenges of deploying shared ubiquitous computing technologies into the real world in general. Specifically, we believe that deploying shared ubicomp technologies into work environments can meet with unexpected technical, organizational, and social hurdles that pose less of a problem in research deployments or tests.

In the sections that follow, we describe some of these difficulties, how they affected the MERBoard deployment, how they pose a problem for shared ubicomp technologies in general, and how they contrast with research deployments. We do not argue that all of these challenges are necessarily unique to ubicomp systems; rather we mention them here as findings of our work that apply to general deployments of shared ubicomp technologies to keep in mind when designing and deploying such systems, and describe how they may pose specific difficulties for ubicomp deployments. However, although some of the challenges here present legitimate problems for single-user or non-ubicomp systems, we believe that their identification as obstacles to the adoption and integration of shared ubicomp technologies is particularly important; because of the lack of a sense of individual ownership or responsibility for such systems, as well as the importance of having a critical mass of users to integrate them into regular use as valuable tools [3]. For each of the real-world challenges that follow, we therefore specify why we believe it has a profound effect specifically on shared, ubiquitous computing technologies.

7.1 Insufficient time or resources for formative study to inform design

In the case of the MERBoard, there was no similar previous mission that the designers could study to inform the design of these tools, nor was there an existing workgroup and set of work practices for which they could design. Although the MERBoard circumstances may constitute an extreme case, it is likely that real-world deployments of collaborative ubiquitous computing technologies would allow less time for studying a workgroup to inform design, in comparison to a research setting deployment. Particularly in cases where the system is contracted, or the deployment is large-scale and commercial, time may be limited, and access to the eventual end-users may not even be possible.

7.2 Infrastructure challenges

The environment into which the MERBoard was deployed presented infrastructure challenges that affected how the system could be used. Firewall difficulties stemming from the use machines from other institutions and unexpectedly few available wireless connections were unanticipated technological constraints. In real-world deployments, as opposed to research deployments, the infrastructure of the environment into which a technology is being deployed may have unknown elements or have unknown constraints. The real-world deployment presents additional challenges, as designers may have no control or influence over the infrastructure of the environment. Shared ubicomp technologies in particular often need to be able to integrate with other technologies in the environment, which may magnify problems caused by unexpected infrastructure issues.

7.3 Constraints on iterative design

The design of the MERBoard is currently being iterated upon for future missions and other NASA purposes, based on the findings from the deployment within the MER mission. However, during the MER mission itself, iteration upon the design was not possible because of the mandatory code freeze to keep the tools static throughout the mission. Again, the deployment of the MERBoard in the MER mission may present an extreme case of constraints upon iterative design, but it is also likely that real-world situations allow for less design iteration within individual deployments than research situations. Companies and organizations may not be willing to expend time, money, or effort to redesign a technology if it is not perceived as critical or valuable by its users. Particularly for shared ubicomp resources for which individual users are less likely to feel a sense of ownership or responsibility, there may be no driving force for design iterations.

7.4 Organizational priorities

NASA’s priority system designated MERBoard as a supplemental technology, thus limiting its access to the most crucial mission data and making it a lower priority than other, more mission-critical systems. Subsequently, training the mission scientists on this technology was also lower priority because it was not necessary for accomplishing many of the science activities. In other organizations, shared ubicomp technologies may also be explicitly or tacitly designated as lower priority tools if they are not crucial for work tasks. Subsequently organizations may expend less time and effort ensuring that potential end-users are trained to use the technologies and made aware of their potential benefits. Similarly, organizations may not encourage or mandate the use of the systems. In contrast, research organizations often explicitly or implicitly encourage use of the system, since system use in and of itself can be considered a work benefit.

7.5 User priorities and motivation

Once the mission was underway, NASA scientists found themselves overwhelmed with new tasks and a hectic schedule. Their priorities were to accomplish their necessary science tasks with minimal overhead using the tools that were available. Because scientists did not have time to learn a new tool if it was not necessary for accomplishing their critical tasks, exploring the system and discovering its benefits were low priorities for the users. In many research deployments of similar systems, the users of the system are colleagues of the designers and therefore have personal motivation to use the system, in addition to any benefit the system may provide in helping them to accomplish tasks. Research deployments of shared ubicomp technologies often have champions who offer training or encourage use of the system for research purposes. In contrast, users of shared, interactive displays in real-world deployments may lack the personal encouragement of peers to motivate them to use or learn how to use a system, and their other tasks may also take priority over expending the effort necessary to learn to use a system that is not task-critical.

8 Conclusions

Despite the promise and unique affordances that large shared displays offer for collaborative work, the real world creates challenges that can hinder users’ perceptions of their value, ease of use, and appropriability. Our study found that the NASA MERBoard was integrated into work practices on the MER mission but not to the extent that was expected, and not to the full potential of its capabilities. Although, we do not suggest that these problems are easily solved once they have been identified, we believe that as ubiquitous computing technologies are increasingly introduced into real-world settings, researchers and designers will accumulate more of a knowledge and understanding of what difficulties can arise as a result, as well as a better ability to anticipate and deal with them. Additionally, we believe that these early forays of ubicomp technologies into real-world settings will help to expose users and organizations to their potential, making them more welcome and accepted, alleviating some of the problems that arise from insufficient support for their use and development. Although, our work has found that the real world can impose major hurdles on a well-designed shared ubicomp system, we believe that continued real-world deployments of these technologies will be key to lowering these hurdles and making these systems valuable and important tools in work environments.