John C Tang
email: johntang@microsoft.com

Jed R Brubaker
email: jed.brubaker@uci.edu

Catherine C Marshall

What Do You See In The Cloud? Understanding the Cloud-Based User Experience through Practices

Keywords: File synchronization, file sharing, online editors, collaboration, cloud user experience

End users have begun to incorporate cloud-based services into their collaborative practices. What spurs and constrains this adoption? Are the cloud services understood adequately and used effectively? How might we intervene to promote a better connection between user practices and cloud services? In this study, we focus on collaborative practices that surround the adoption, use, and understanding of two popular, but sometimes contrasting, cloud services for creating and sharing content: Dropbox and Google Docs. We conducted 22 indepth interviews with people who used these services, including collaborators who used the services together, and people who had migrated from Google Docs to Google Drive. We found that users thought of the cloud in terms of the practices it helped them accomplish. Their understanding of the cloud was often shaped by the particular file storage and sharing technologies the cloud was replacing (remediation). Furthermore, collaborating with others through the cloud sometimes revealed different assumptions about how the cloud worked, leading users to develop socially negotiated practices around their use of the cloud. We use this analysis to identify some specific opportunities for designers to help users build more accurate conceptual models of the cloud and use its capabilities more fully: (1) when users are adopting the cloud to enact a practice; (2) when users are replacing an existing technology with the cloud; and (3) when users are encountering others' practices through collaboration.

Introduction

Cloud-based file synchronizing (syncing) and sharing services have become a central element of everyday computing infrastructure. Ubiquitous access to storage, lowoverhead file sharing, coordination between devices, and real-time collaboration facilities have prompted significant end-user adoption of these services. These services, like other cloud computing technologies, are realizing Weiser's vision of ubiquitous computing, in which computation is accessible everywhere, but seamless and quiet in its presentation [START_REF] Weiser | The computer for the 21st century[END_REF]. However, this invisibility may also present some challenges to users of cloud-based syncing and sharing services. Despite the availability of these services, research indicates that many people still harbor significant misconceptions about how these services work and may not understand the features they offer [START_REF] Marshall | That syncing feeling[END_REF].

To identify opportunities for improving the design and uptake of cloud-based services, we investigated how users understand and incorporate the services in their individual and collaborative practices. In particular, we were interested in three areas: [START_REF] Biggs | Google Drive Is Live With 5GB Of Free Storage And Google Docs Hookup[END_REF] how people adopt cloud-based syncing and sharing services; (2) how people work together through these cloud services, and how their understandings of the services influence those of their collaborators; and (3) how designers can pinpoint appropriate opportunities to help users better connect their practices with functionality offered by cloud services.

To give ourselves a concrete starting place, we focused on peoples' experiences with Dropbox and Google Docs. Both are widely used services that provide ubiquitous access to files and support collaboration through shared storage in the cloud, but they go about it in ways that put varying conceptual demands on their users. Google Docs offers a browser-based environment for access to and co-creation of content directly in the cloud [START_REF] Google | An overview of Google Docs[END_REF]; users need only conceive of cloud repositories as a distinct shared place to do their work (although they must learn to use the new editors). By contrast, Dropbox synchronizes local files among devices and people to provide ubiquitous access to content [START_REF]What is Dropbox?[END_REF]; while interaction with the editors and local file system is familiar, fully understanding Dropbox requires grappling with a complex notion of file synchronization. The recent release of Google Drive [START_REF] Biggs | Google Drive Is Live With 5GB Of Free Storage And Google Docs Hookup[END_REF], which marries a Dropbox-like syncing client with the remote editing capabilities of Google Docs, provided us with a window onto how users' cloud experiences evolved as they migrated from Docs to Drive.

Our analysis draws support from Bolter and Grusin's theory of remediation [START_REF] Bolter | Remediation: Understanding New Media[END_REF]. Remediation highlights the relationship between media forms and their predecessors, and hints at how the new media forms are understood in terms of the old. Bolter explains, "designers of a new media form seek to borrow the cultural valence of one or more earlier forms. In most cases, however, they also want to define criteria by which the new form can surpass its predecessor, in order to give their audience a reason to adopt the new form." [START_REF] Bolter | Formal Analysis and Cultural Critique in Digital Media Theory[END_REF] Remediation, which initially focused on media itself, has been extended to studies of media practice. According to Lanzara, "[t]he appearance of a new medium in a domain of practice produces a perturbation in the complex ecology of agents and activities, objects and tools, uses and meanings that constitute the practice." [START_REF] Lanzara | Remediation of practices: How new media change the ways we see and do things in practical domains[END_REF] In this study, we examine how individuals make sense of cloud services and incorporate them into their practices by applying their understandings of the services' remediated predecessors. As with other forms of infrastructure, these new services are "always built on an installed base" [START_REF] Bowker | Sorting Things Out[END_REF], so that individuals can scaffold their understanding of these technologies using experiences with their predecessors.

We begin with a brief description of the study and its participants. Next we organize our results according to two central themes: service adoption and reconciling collaborators' varying conceptual understandings the services. In the discussion section, we synthesize these stories into key findings, focusing on the relationship between cloud technologies and existing and developing social practices. We conclude with implications of our findings, highlighting key challenges in both the design of cloudbased services and opportunities to educate users how to better incorporate the cloud in their practices.

Study Description

We conducted semi-structured, open-ended interviews with 22 people who use Dropbox and Google Docs (and in some cases, Google Drive) in individual and collaborative situations. Table 1 summarizes each participant's pseudonym, age, gender, background, and cross-references which collaborators we interviewed. Participants were primarily U.S. based, although one participant was from Canada and another was from New Zealand; they had used the services for between 3 months and 6 years.

Table 1. Summary of participant characteristics and pseudonyms. Participants were recruited through the authors' social media networks; direct contacts were excluded from participation.

Interviews lasted from 30 to 120 minutes (60 minutes on average) and were conducted over video chat or phone. The interviews focused on participants' adoption and ongoing experiences with Google Docs and Dropbox, as well as how their use of these services changed over time. Because some participants had been using either or both services for a long time, we asked them to find their oldest files in each service's Because we were interested in how collaborators influenced each other's understanding and use of the cloud services, we asked participants if we could contact the other people involved in the stories they told during their interviews. Five of the 22 participants were recruited this way. In one case, we interviewed three members of the same group; the others were dyads (who were sometimes part of larger groups).

Pseudonym

Since our initial participants (17/22) did not have significant experiences with Google Drive's recently introduced local syncing client, we specifically recruited a final set of participants (5/22) who had migrated to it. Given the substantial change in the conceptual model from Google Docs to Drive, we thought it was an interesting opportunity to see how users reacted to the availability of a local sync client. These interviews were conducted the same way as the others, except that Drive was included in participants' comparisons of cloud services.

All interviews were transcribed and participants were assigned the pseudonyms that are used in this paper. The interviewer (the second author) briefed the other authors about participant narratives immediately after the interviews took place. The analytical coding was performed jointly among the three authors; additional review of the transcripts was performed as necessary so that everyone was familiar with the details of the interview data. We performed inductive analyses of the interviews using grounded methods. Using open coding and memoing practices (as described in [START_REF] Corbin | Basics of qualitative research[END_REF]), we grouped individual participant narratives into preliminary categories and labeled them. Labels and categories were in part emergent and in part influenced by our a priori interests in the adoption and collaborative use of these services, as well as the impact they had on existing practices. These categories were then refined using a constant comparison method that "combines inductive category coding with a simultaneous comparison of all social incidents observed" [START_REF] Goetz | Ethnographic Research and the Problem of Data Reduction[END_REF]. We also examined the interview data on a per-participant and per-collaboration basis to reveal adoption and use storylines and specific instances of remediation.

Results

In this section, we describe how participants develop their understanding of cloud syncing and sharing services and the ramifications of these understandings. We begin by exploring how participants adopt the services, either in response to problems that arose in the course of existing work practices, or through changes in the constellation of devices they use. We then show how the understandings and practices established during adoption affect ongoing use. Finally, we demonstrate how previous experiences with remote storage technologies produced some subtle misconceptions for participants, and examine the implications of these misconceptions for individual and collaborative use.

Adoption as Problem Solving

Participants described first learning about these services via online blogs (e.g., TechCrunch), from their peers, or in the context of project work with colleagues.

Most were vaguely aware of these services prior to using them. For example, Dillan and Lance both reported that they were first introduced to Google Docs when Gmail opened attachments in it. For most participants, however, meaningful adoption (as opposed to brief engagement) was the result of "upgrading" their way of doing things to overcome specific limitations or cumbersome aspects of their current practice, which in turn influenced and constrained how they interpreted the technology. For example, Dean adopted Dropbox to overcome email restrictions. As a graphic designer, he often needs to send remote collaborators Photoshop and Illustrator files that are too large for email attachments: "It was just an easy way to share files, rather than having to use YouSendIt, or WhaleMail, or any of those other sort of temporary big file e-mail systems."

For some, the limitations are latent. Sanjay, for example, was aware of Google Docs' centralized approach and facilities for real time collaboration. But it was only after he started co-authoring a report with a colleague in another country that he found the motivation to adopt the service. Limitations may prompt the adoption of more than one cloud service. Sanjay later adopted Dropbox too so he could automatically share reports saved to his local file system. As Sanjay's scenarios demonstrate, adoption was often spurred by collaborative project work. The initial collaborations reported were often small, ad hoc, projectspecific, and rarely resulted in artifacts that were seen as archival. Even in more traditional professional environments, the collaborations remained lightweight (although adoption can be management-mandated). Trisha explained how her boss, who traveled, introduced her team to Dropbox, and how casual use became commonplace. Through use, Dropbox evolved from a literal dropbox to a shared repository.

We really use [Dropbox] a lot for… PowerPoint presentations that we can upload there so that when he's on the road … he has access to our latest fig-ures… And it started out from just like "Oh, we're just going to use it for a couple communication things or a couple staff documents," and now we're basically constantly sending everything into Dropbox. It's become our de facto shared drive.

Regardless of how individuals were introduced to the services, the motivation for their initial use shaped their subsequent understanding and expectations. Google Docs most frequently remediates editing suites like Microsoft Office, while Dropbox remediates storage and file transfer between devices or people, similar to uses identified by Dearman and Pierce [START_REF] Dearman | It's on my other computer![END_REF]. As a result, subsequent use was often constrained to a narrow (albeit critical) set of cases.

Adoption in Evolving Device Ecologies

Not only did participants adopt cloud services to support existing practices when the old methods failed them; they also found themselves in situations in which evolving technological ecologies-including the introduction of new devices or the loss of old ones-prompted discovery and adoption of these services.

The introduction of new mobile devices seems tied to cloud service adoption. This observation is well-aligned with the results of Sohn et al.'s study [START_REF] Sohn | A Diary Study of Mobile Information Needs[END_REF]. Participant Martha purchased a tablet to support her graduate studies; this in turn prompted her to adopt Dropbox when she found she was unable to use a thumb drive to transfer files to the device. She had learned about Dropbox from a blog post returned by a search for "How to get files onto iPad." Adding a device created a problem that was solved by adopting a cloud service.

New devices can also spur new practices, which in turn provide an opportunity for incorporating cloud services. This adoption path was common for our Google Drive participants. Bruce learned about Google Drive after finding it preinstalled on his new Android phone; to his delight, he discovered that he was able to pull up an agenda on his phone and conduct a meeting without a laptop. Similarly, Andy, a service technician, explained how important Google Drive had become for on-site access to notes, manuals, and other documentation:

At first it was just something that I installed just to see what it was all about, and then when I realized I could … look at the same documentation on my laptop as I could on my phone… the phone has become this extremely useful tool.

Device loss was another change that prompted adoption. In Nathan's case, the loss of his USB drive forced him to reconceptualize the function of Dropbox. He had already adopted Dropbox for backup, but he still moved files between school and home using a thumb drive. This function only became apparent, however, when "I misplaced the USB at one point, and that's when I realized 'Oh, I'll just put it all on Dropbox.'" Dropbox functionality did not change, but Nathan's practices (and thus his use) did.

New technology, as well as failures in existing technology, can promote adoption of cloud-based services and cause participants to reflect on what these services do. Hardware or new apps can present solutions to problems participants did not know that they had. Across our participants, we saw that understandings of these services most commonly broadened when participants' everyday practices were disrupted, and their focus was on the service itself, rather than the activity the service supports. By contrast, stand-alone information campaigns, such as those accompanying the introduction of Google Drive, did not seem to promote adoption or influence an individual's understanding of what Google's new service offered. Participants ascribed the migration to branding ("the logo changed") or found it inscrutable ("something about it is slightly different and I can't put my finger on it whatever that is"-Sarah)

Conditional Adoption

When participants described how they used the cloud, many saw the cloud through the lens of the limitations the services imposed and how they had changed the conditions of their work. This perception, in turn, either restricted the scope of their adop-tion (as when Google Docs replaced Word) or caused participants to compensate for disruptions in their normal practice (possibly by moving in and out of the service).

Limited by the Basics. Because Google Docs remediated desktop editing suites (and not a shared document repository), many participants lamented the service's limited functionality and polish, and did not use it beyond simple documents like brainstorming output, meeting notes, and roommate expenses. For a few like Martha, who owned a small business, Google Docs was not viable for anything beyond notes:

"[If]
we're writing a proposal," she explained, "it has to look professional."

For those drawn into Google Docs for its synchronous collaboration functionality, a tension was created between it and the full-featured editor it was remediating. According to Karen, "The main issue is formatting… I have to copy and paste it all into Word. When you're getting towards the final revision, [Docs] just isn't feasible." Thus users adopted a cut-off point at which they would migrate from Docs back to a full-featured word processor to format the final document. However, this late-stage editing is often when the collaborative functionality of Google Docs is most needed. Some participants compensated for this by using Google Docs and shared Dropbox folders in tandem. Participants like Jacob described copying content from a Google Docs document into a Word file saved in Dropbox. Yet, while this approach retains some collaborative functionality, as both Martha and Melissa explained, using Dropbox this way limits concurrent access to the document.

Google Docs' inability to address the demands of pre-existing editing practices limited the extent to which participants were willing to commit to the service, and limited their willingness to acclimate to (and see the value of) Docs' novel functionality. Instead, participants were left weighing the benefits of Google Docs (often, the predicted contributions of collaborators) against its inability to format their content. The role of the remediated technology was clear: "Real time collaboration in Word would be the ideal world. I can't think of anything more fantastic than that." (Karen)

Acclimating to the Cloud. Participants discussed a variety of new practices they adopted to collaborate using cloud services. First, as other researchers have reported in their studies of shared repositories and workspaces [START_REF] Dourish | Building bridges: Customization and mutual intelligibility in shared category management[END_REF][START_REF] Rader | Not) Ours: Social Influences on Group Information Repositories[END_REF], the shared storage must be kept intelligible and consistent (so collaborators can find what they are looking for and negotiate practices to coordinate access so changes are not overwritten). Second, as we would expect from other studies of collaboration (e.g., [START_REF] Dourish | Awareness and coordination in shared workspaces[END_REF]), collaborators must accommodate to a new level of visibility of their work and actions. This effect may become more pronounced when the collaborators are not peers (e.g., professors and their students, managers and their reports). The two effects are often intermingledthe document in its incoherent state is rendered abruptly available and visible by the new cloud services, either synchronously in Google Docs, or as an incomplete version when Dropbox syncs.

We observed multiple instances of how the remediated technology (in this example, Word) created an expectation of (and perhaps a genuine need for) change coordination facilities. Sarah described how her team's adoption of Google Docs resulted in breakdowns with one collaborator: "She always was worried that her work wasn't there or that she was being overwritten and she wasn't sure who was writing what." Some participants coped with the perceived difference between their writing practices and those supported by the service by copying files in and out of the cloud. Sao, a graduate student, copied an important grant proposal out of the cloud and onto her local storage so her edits would not interfere with those of other collaborators. She explained that she prefers to do her initial drafts in Word, and then transfer her content into a shared Google Doc when she is ready to respond to feedback from her colleagues and make minor changes. Major edits, however, are always done outside of Google Docs:

Sometimes you will change a lot of things. And sometimes you want to take a long time to think about what you're going to write… So I first write on my own Word document and then later copy and paste to Google Docs.

Many participants commented on the authoring styles of their collaborators, which were abruptly rendered visible by the real-time collaboration in Docs, as well as the changes it caused in their own. Sanjay, while a strong advocate Google Docs' collaboration functionality, explained that under some circumstances he felt like he was under surveillance: "Let's say the deadline is tomorrow, the advisor is doing his part, and there is still things to do in my part. I can't sign off… it might look bad."

Troubled Conceptions

If participants' understandings of cloud syncing and sharing services develop in the context of the problems they solve or the practices and technologies they replace, and collaborative adoption proceeds in a hand-to-hand, viral way, then we might wonder about the effects of misconceptions: Do they hinder adoption? Do they limit successful use? Are they transmitted with the services? Do they lead to asymmetries in adoption, thus interfering with the overall benefit of services [START_REF] Grudin | Groupware and social dynamics: Eight challenges for developers[END_REF]? In this section, we explore the sources and effects of misconceptions.

"Cloud" just means remote, right? Thinking that files synced via Dropbox or Google Drive were not stored locally was a surprisingly common misunderstanding if participants had previous experience with remote or network storage. Dean, a graphic designer, harbored a misconception that stemmed from his prior use of an FTP server that he had set up to share files with his collaborators. Initially he described Dropbox as a portal between his computers, but later in the interview, he revealed that he uses Dropbox to "keep as much as possible off of my local hard drive" to prevent his primary computer, an aging laptop, from getting too bogged down, and that he assumed files that appeared to be local in the Dropbox folder actually lived in the cloud:

I assume that all of that shit lives on Dropbox's servers in the cloud and those [file icons] are basically links to the files... And if I just double click this text file I'm opening my text application and it's pulling the file from Dropbox's server. But the file is not living locally on my machine.

How do these misconceptions that an individual brings from experience with a remediated technology play into subsequent collaborations? Are these misconceptions corrected through interaction with collaborators, or do they remain in the background? We examine data from collaborations to find out.

Conceptions in Collaboration.

In individual use, incorrect or incomplete understandings of cloud services appeared to have limited implications. However, we had anticipated that these misconceptions would come to light during collaborations where users might encounter and be held accountable to the conceptual models maintained by their collaborators.

While we suspect that these conversations occur, the relative number of successes our participants reported in their collaborations struck us. One such surprise came when we interviewed Dean's primary collaborator, James. While James also had a somewhat incomplete understanding of Dropbox, his practices around the tool avoided any conflict with Dean. James copied files in and out of their shared Dropbox folder, and only edited them after copying them to a location outside of Dropbox. This practice enabled him to have a master and a renamed version with his changes:

If I'm editing a poster that Dean and I are working on together, if he puts [the file]… that he just touched, in [Dropbox], I'll copy it to my desktop and then open it in Photoshop. I want to preserve his changes, [but] I want to be able to delete stuff, or just have [a] backup, or make my changes. So I'll leave it [the original file], so it's like a primitive version control.

James subsequently complained that "Dropbox is… a little too much like a drawer, where something is either in or out of the drawer." Because James never edited a file in place in the shared Dropbox folder, he effectively avoided the very kind of version conflicts that might have caused Dean to reflect on his theory that he was working on a separate downloaded version of a remote file. Although these compatible misconceptions remained invisible in Dean and James' collaborations, the proliferation of files in their shared folder effectively exacerbated any problems Dean was experiencing as a result of a full hard drive.

By contrast, another collaboration (an academic research group that included participants Karen and Steve) negotiated a social workaround only after incompatible conceptions and misconceptions surfaced in a series of breakdowns. The group had reached a situation in which co-authors were working with out-of-date versions and overwriting one another's changes. These conflicts grew out of incompatible conceptual models. For Karen, Dropbox remediated a practice of emailing files to herself to ensure she had up-to-date versions on all of her computers:

I have a computer in my lab at my university and I was using a laptop and then my personal desktop. ...Usually I was e-mailing things to myself. And if I forgot to e-mail it to myself or I e-mailed the wrong version then I was constantly redoing work I had already done because it was on the wrong machine.

On the other hand, Steve (an undergrad who eventually administered the group's Dropbox folders) modeled his understanding of Dropbox on version control systems such as Subversion1 . Subversion helped Steve make sense of how Dropbox syncs local and remote files, but also left him with the mistaken belief that Dropbox sometimes merged changed versions of files:

The only thing… is [Dropbox] didn't really merge conflicts very well… if you and I are working on the same document at the same time and we both save it and it can't merge it together, it will save your copy as [AUTHOR NAME]'s conflicted copy and mine as Steve's conflicted copy.

Steve went on to provide a detailed (albeit mistaken) account of how Dropbox attempts to automatically merge changes and only produces conflict files when it is unsuccessful. This is similar to how code repositories like Subversion work: when changes are committed to the repository, any changes that can be merged automatically are. When they cannot be, users are asked to resolve conflicts before committing a particular file.

While Karen, who was also familiar with version control systems realized, "there's no real version control to merge things back together," Steve believed that the others in the group harbored misconceptions about Dropbox's ability to merge changes:

One of the professors…that [Karen] and I both worked under…didn't seem to understand that Dropbox was capable of merging. And so she would open up a document and resave it with her initials appended to it. And so over time you'd have eight documents with her initials on it and then somebody has to go through and merge her stuff into the original document when all she really had to do was open the original document. So she's a good example of not using it properly.

This was a complicated problem that involved both social components (the coauthors were not coordinating changes with one another) and technical ones (group members were syncing infrequently, in part because they had varying understandings of how to take better advantage of Dropbox). A breakdown over an important document (a grant proposal) led to the adoption of an explicitly social solution that did not resolve any (mis)conceptions, as Karen explains:

We have to call and say I'm working on this portion. This is how I'm going to save my folder or the document and what the name will be. … So we actually include initials and time stamps and file names so that we have a way of tracking [who did what when].

Steve explained the resolution to the version conflict problem: in exchange for additional personal space on Dropbox, he became "the official Dropbox guy" who "had to merge crap all of the time. So once a week I'd go check it and say oh, you know, there's eight conflicts… and I would get rid of all of those." Just as in James and Dean's case, it was easier for participants to develop practice-based workarounds than it was to revise their mutual understanding of the cloud service. But in so doing, they missed an opportunity to learn how the cloud could better support their collaboration.

Discussion

What stands out in our results is the primacy of practices. They not only spur adoption-people adopt the cloud to solve problems-but they also suggest that people may use the cloud without really understanding how it works. In some ways, this is unsurprising: naturally people adopt practices, not features. And often they are using the cloud to remediate or maintain a practice, not a technology. But what we see is the consequential nature of what the cloud is replacing. If cloud syncing and sharing services are replacing FTP servers, then users are far more likely to understand the new service in terms of the old one. Their expectations are thus set, sometimes in ways that make them resistant to evolving understandings or extended use of these services. In this section, we reflect further on the relationship between user practices and cloud services, and examine more closely what this says about user education, addressing misconceptions, and the conditions for successful adoption and continuing use.

Practices Overshadow the Cloud

Across the board, participants reported that using Dropbox and Google Docs was straightforward and that the services were easily understood. However, participants often failed to see opportunities to expand their use of these services. This is in part because they focused on their work instead of on the tools they were using to do the work. Trisha provided an example of this tension when she explained that Dropbox would enable her team to maintain a single versioned master of a document "…instead of having 17,000 different versions of a single file as you update it, in theory there's one, although we actually have not been using it that way." Despite her awareness of this capability, her group continued to name versions: "it'll say like 'edits by' and then initials at the end, which is kind of silly… because then it's like you're using way more space than you need, but once people start doing something one way and get used to it, it's really hard to make them stop." Google continues to add novel functionality to make its collaborative environment more robust. Yet, participants reported their dismay at the lack of support for the practices they already havein the case of Google Docs, authoring content in a sufficiently robust clientmore than their excitement for new modes of working. Our findings suggest that the inability of Google Docs to meet the standards of the technology it is remediating (i.e., the desktop office suite) limits most participants' desire to replace their existing tools with Google Docs, and for many, their ability to benefit from the collaborative features Docs provides.

Although these services have novel functionality that individuals' stories suggest they would find beneficial, they were largely unaware of this functionality. Instead, users focused on the essentials as defined by their tasks: Formatting and speed in Google Docs, and sharing files and managing storage quotas in Dropbox.

Understanding via remediation. Bolter and Grusin assert, "Each new medium is justified because it fills a lack or repairs a fault in its predecessor, because it fulfills the unkept promise of an older medium." [START_REF] Bolter | Remediation: Understanding New Media[END_REF] Participants turned to remediated practices and technologies to make sense of the cloud. Projecting their understanding of how prior technologies enabled them to accomplish their practices onto how the cloud operates shapes the way they can understand the novel features that cloud-based services offer. The users' focus on their particular practice of interest narrows their view of what cloud services can do, which can in turn contribute to an incomplete or inaccurate conceptual model of how it works.

When to educate users. The ideal time to educate users about new functionality is when their focus is on practices associated with the tools and tasks in which they are engaged. For example, practices around using the tool, such as setup or maintaining the total storage within the tool's free quota, are when the user's attention is on the tool and not trying to accomplish a productivity task. Mary illustrates this point in describing how the Dropbox scavenger hunt helped her understand how to use it:

I told him to do the scavenger hunt, because not only do you get like the free storage, which was great, but then you also get to learn about like how to use it in like kind of a fun, interesting way where you're not just watching like a video, no matter how exciting they try and make it.

This Dropbox technique not only catches users when they are focused on managing the tool, but also gets users to enact practices they have learned (rather than just watching a video of them) to earn more storage space to ease their management work.

By contrast, Google's in-browser notifications about the transition from Docs to Drive, for example, were largely dismissed when they were encountered in the process of going to Google Docs to work on a file for a task. Furthermore, the wording of the transition notification ("Google Drive is the new home for Google Docs") suggests that no new practice is needed to migrate from Docs to Drive. Consequently, we found most users who had migrated to Drive were still using it in much the same way as they used Docs, without taking advantage of the new features that Drive offered.

Users were more likely to learn about the new features in Google Drive when they installed the mobile app (or found the app preinstalled) on their Android phone. At this point, they were focused on integrating a new mobile device or feature into their practices, making it an opportune time to learn more about how the cloud could help them. Taken together, these stories identify different types of teachable moments as users go about their work or as they manage cloud-based services.

The Social Effects of Clouds

Our previous study explored models [START_REF] Marshall | That syncing feeling[END_REF]. For example, one collaborator would rely on a synced folder for archival storage, and the other would do housekeeping and delete a portion of this implicit archive. In this study we sought multiple perspectives on the same collaboration to breakdowns in participants' collaborations that could be attributed to the collaborators' conflicting conceptual see how they worked through these breakdowns.

While we continued to find examples of collaborators' conceptual mismatches, in this study, we were struck by how the participants worked around or managed their misconceptions. Generally, we found that many of the workarounds were social, and did not necessarily involve reconciling conflicting models. For example, Steve was designated as "the Dropbox guy" to resolve version conflicts and merge changes. It is probable that neither Steve, Karen, nor the professor revised their conceptual models.

We expected (or hoped) that encountering these kinds of problems as a group might provide teachable moments during which someone would invest the effort to understand how things are supposed to work and educate the rest of the group. Instead, we largely found that groups reverted to familiar practices that relied less on the cloud's ability to sync and manage changes and more on manually or socially managing updates, which they understood how to control. Thus, instead of refining or updating their collective conceptual model of cloud functionality, groups would construct social explanations and practices that avoid the features that they did not understand.

Compatible misconceptions.

In scenarios like Dean and James's, we see how two collaborators operate with conceptual misunderstandings that, nonetheless, do not result in breakdowns. While compatible misconceptions may be innocuous, during some interviews, it was clear that these misconceptions would likely lead to a breakdown in the future. For example, groups whose members believe that Dropbox supports simultaneous editing will eventually encounter conflicts where changes will need to be merged by hand.

Ad hoc Collaborations.

The majority of participants' cloud-based collaborations would best be described as "ad hoc." Since the cloud easily transcends organizational boundaries and firewalls, it is well-poised to facilitate ad hoc collaborations; in fact, the ability to cross firewalls is often a precondition for the adoption of syncing services [START_REF] Marshall | Supporting Research Collaboration Through Bi-Level File Synchronization[END_REF]. As a result, two issues are worth noting: First, while Dropbox and Google Docs are often most productively used by groups, users may initially adopt these services individually.

Second, while these cloud services are often used outside traditional enterprise structures, they rely on collaborators having accounts with the services' providers. Participants often talked about the ease of using Dropbox and Google Docs for a quick project because "everyone had an account" (Aaron), but this technological ease can violate some implicit seams that participants use to productively distinguish one use venue from another. Trisha, for example, noted concerns about tools that spanned across work and home: I didn't want to necessarily use it for my own personal stuff and accidentally save something in the work folder. Because when we first signed-up for Dropbox [at work], I was using it with my personal address because I already had an account, and I just didn't want to mix work and personal life more so than I'd already been doing.

These large-scale services appear to be enabling a broad set of new collaborative practices, but also present challenges for traditional enterprise work situations in which these services might not be viable. Perhaps to the dismay of network administrators, many participants in traditional enterprise settings spoke of using these tools to circumvent organizational policies to, as Lance said, "get things done."

Implications

The adoption of Google Docs and Dropbox and the conceptual understandings individuals develop of the services highlight issues around when and how systems make features and processes visible, as well as how to connect these with users' practices.

The drive towards seamlessness can leave users ill-equipped to adequately understand the nuanced behavior of their tools or make appropriate decisions when they encounter problems [START_REF] Ratto | The Ethics of Seamlessness: Resources and Future Directions[END_REF]. We make two arguments on this front: First, designers of cloudbased services can improve user experiences by exposing technical functionality and processes in relation to people's practices. Second, service providers can facilitate the development of cloud-based practices by taking advantage of teachable moments to educate users about their functionality.

Seeing the Cloud Through Practices

Cloud services need to aid users in connecting their practices with what these cloud services are actually doing. As previous research has noted [START_REF] Marshall | That syncing feeling[END_REF], the lack of process transparency may prevent individuals from broadly adopting cloud-based services.

Our findings suggest that simply exposing the functional behavior of these services may be insufficient. Instead, designers should provide more robust user feedback on processes but in relationship to user practices and their working context and not in terms of system processes or features. The Google Docs text editor provides an excellent example of how system processes can be exposed in a way that aligns with user practices. The addition of coauthors' cursors in Doc's word processor, for example, and synchronous appearance of a coauthor's text provide little room for ambiguity about the collaborative editor's functionality: co-authors are changing the same document. When and how Google Docs saves content is less clear. When connected to the Internet, saving is unimportant: Google automatically saves content as it is added. In fact, Google has removed "Save" buttons and menu options from their editors. Saving becomes ambiguous, however, when individuals proactively want to save their contentfor example, when the user's Internet connection has been lost. In this case, Docs notifies the user that it is trying to reconnect to Google's servers, but does not explain how changes made in the meantime will be merged, or what options individuals have to preserve their work if the interruption in network connectivity persists.

Turning to Dropbox, we see a good example of how the process of creating a shared folder connects with user practices. When users share a folder (either directly on Dropbox's website or via their operating system's context menu), the user is pre-sented with a webpage on which they can provide the email addresses of those they would like to invite to the folder. An invitee, upon receiving the email invitation, can click a link to accept the invitation, at which point the invitee is notified about the addition of the new shared folder both in a web browser and the local syncing client. When sharing a folder, the user's practice (e.g., email invitation, files appearing in a folder) and the system's functionality are highly aligned.

However, once a folder is shared, functionality is far less clear. A number of participants described confusion about the relationship between their Dropbox folder and the rest of their hard drive. Dragging a file from Dropbox to another folder moves the file rather than copying it. James' comment about Dropbox acting "like a drawer" stems from this interaction. What is not immediately clear to users is that moving a file outside of Dropbox affects all collaboratorsit effectively removes the file from everybody's Dropbox. Moreover, this breakdown was compounded when participants found social explanations for technical breakdowns. Dropbox could address this confusion by simply alerting users that moving files out of shared folders will remove access to those files by other collaborators.

Our implication that processes should be exposed relative to user practices presents some significant challenges for services that operate at either the system or the interface level. Dropbox, for example, intentionally limits the focus of its syncing client to the file system and remains agnostic to programs and user practices outside of how they read and write to the hard drive. Yet, many of the collaborative practices around using Dropbox involve editing those files using productivity tools. Since Dropbox's implementation does not afford providing any process transparency in the context of those editors, users can get confused about how Dropbox manages concurrent or conflicting changes while editing those files. Conversely, the web-based editors in Google Docs made it transparently obvious when concurrent editing occurred. Yet Google Docs removed commands for file management (no Save command), making it unclear how to save work when an Internet connection is interrupted or lost. Cloud service designers need to consider the full scope of user practices to help users understand how to fully integrate the cloud's capabilities into their work.

Learning How to Look at Clouds

Given the scope of changes to cloud syncing and sharing services over the last year, we expected to see user practices and understandings change in response. Instead, we found that participants' conceptualizations of these systems remained relatively unchanged. Since users' practices have been established and largely remained stable, changes in the cloud services by themselves were not enough to engage users in the work of learning about them. Revisiting an earlier example, it was noticeable how most of our participantsactive users of cloud serviceswere unaware of the particulars around the transition from Google Docs to Google Drive, despite prominent notifications. Indeed, given the lack of immediate impact on their practices, many thought that the change to Drive was simply a rebranding of the service.

If our aim is to enable broader use of the cloud, our findings demonstrate that improving the design of cloud services alone is insufficient. Service providers must also educate users about how their practices can take greater advantage of the cloud. People may not notice new features even when they are prominently announced. Moreover, the rate at which the cloud services are changing challenges users' ability to keep up with those changes or even identify "expert users" to help work through conceptual breakdowns, as they have in the past [START_REF] Kellogg | Evaluating user and system models: Applying scaling techniques to problems in human-computer interaction[END_REF]. Our study identified four different kinds of teachable moments when users were more amenable to learning about new features or capabilities of the cloud. We go through each type in turn.

Teachable moments around adoption. Adoption presents a clear period during which initial understandings are being formed. Critical windows for forming understandings are not limited to service adoption. The addition of new devices also caused participants to reassess their use of cloud-based tools. Indeed, the most successful instances of Google Drive adoption reported by our participants were the result of discovering the Drive application pre-installed on a new mobile device.

Teachable moments around remediation. Services should expect and account for the fact that new users bring existing practices with them. By understanding which prior technologies and practices a cloud service remediates, providers can anticipate user expectations that can inhibit deep adoption; in this way, they can also prevent misconceptions. Perhaps providing different on-ramps tailored for the common tools that are being remediated by the cloud would help connect users' practices with cloud features of most interest to them, and would help anticipate and circumvent many standard misconceptions.

Teachable moments around cloud management. User understandings were pliable when practices were focused on managing the services themselves. Dropbox's disk quota, for example, presents an overarching user problem that requires that heavy users "maintain" their storage from time to time. Dropbox rewards users with additional storage for completing a variety of tasks, most of which introduce users to Dropbox functionality or prompt them to tell others about Dropbox. Numerous participants described learning about Dropbox from its "Tour", "Simple tasks", and "Scavenger hunts." Dropbox takes advantage of a limit that they have imposed on their users to encourage them to learn more about the service and teach others about it.

Teachable moments around collaboration. Collaborating with others naturally exposes other people to the consequences of actions in the cloud. Updating or deleting files in the cloud will affect what others see. These collaboration consequences could be used to help users understand how the cloud is mediating their collaboration. Besides the visibility of concurrent editing in Google Docs, there are other ways in which the cloud could create teachable moments during collaboration. File deletion presents an opportunity to show users the effect of this action on their collaborators (i.e. they will no longer have access to it). Alerting users as to when and why conflict resolution files are created would help users understand the limits of synchronization. A "sync inspector" that more transparently indicates who last edited the file (and on which device) would help users have a better sense of how changes from various people and devices are being coordinated through the cloud (Cimetric [START_REF] Marshall | Supporting Research Collaboration Through Bi-Level File Synchronization[END_REF] is an early attempt at providing such a sync inspector). Browsing sync history could also help users diagnose why they do not have access to the expected file version (for example, the one they saved on another device), since they might be able to identify when a sync was missed, which might help them narrow down possible causes for a sync failure. While collaboration naturally exercises many of the cloud features needed to keep files in sync, users need more help to observe and understand these processes to appreciate how the cloud is working to support collaboration.

Conclusion

Our study demonstrates the ways in which individuals adopt cloud-based syncing and collaboration services into their work practices. We found that practices from remediated technology fundamentally shaped the ways participants understood and used cloud functionality. Individuals adopt cloud services to solve problems or when incorporating new technology into their routines. However, when cloud services do not fully support users' existing practices, they may only partially adopt cloud functionality. Moreover, given the limited transparency of cloud processes, experience from remediated technologies or collaborating with others who have mismatched conceptions often resulted in misconceptions that also limited their use of the cloud. We identify opportunities to improve cloud experiences, both by redesigning aspects of the services and by appropriately educating users about how their practices might benefit from the cloud. Designers of cloud-based services need to strike a balance between visibility and seamlessness. Decisions around visibility should be made based on users' practices and not the system processes. Perhaps the more salient opportunity stems from identifying specific teachable moments for educating users how to more fully incorporate the cloud into their practices. We identified these teachable moments as they occur during adoption, remediation, management, and collaboration. As cloud services and users' cloud practices continue to develop, we expect that these implications will help to improve current and future cloud services.

http://subversion.apache.org/


Julian Seifert
email: julian.seifert@uni-ulm.de

Dennis Schneider
email: dennis.schneider_l@uni-due.de

Enrico Rukzio
email: enrico.rukzio@uni-ulm.de

Extending Mobile Interfaces with External Screens

Keywords: Mobile phones, distributed user interfaces, interaction

Mobile phones allow for the use of all kinds of applications, and their mobile applications often provide similar functionalities as desktop applications. However, they are constrained by the limited screen size of the mobile device. Accordingly, designs of mobile user interfaces require optimization for small screens. As a consequence, users are provided with less context and often have to switch views or resize content such as maps or pictures. We present MobIES * , a novel approach for extending mobile user interfaces by using external screens (e.g., the mobile phone and a large screen). Users can utilize more space and can thus overview a larger information context. We present a novel interaction and application concept and describe how user interfaces can be spanned across displays. Further, we contribute an original approach for using Near Field Communication to detect the devices' spatial relation. We report on a user study which compared MobIES with standard mobile settings. Results from the system usability scale show that interaction with MobIES is subjectively more usable. Furthermore, it provides higher perceived information clarity and supports faster sharing of information to others.

Introduction

Today's mobile phones enable users to perform a large variety of tasks in mobile contexts. Given the increased computing power, battery capacity, and data connectivity, users can perform the same tasks as by using traditional personal computers (e.g., browsing the web, viewing and editing photos). One of the limiting factors is the screen size of the mobile devices [START_REF] Chittaro | Visualizing information on mobile devices[END_REF]. The screen size affects users mainly in two ways: First, only a limited amount of information can be displayed on the screen at once. Hence users often have to change the view (i.e., zooming in or out, switching between different screens). Second, collaboration with co-located persons is inherently limited, as only a certain amount of people can comfortably view the information.

In this paper, we contribute MobIES, a system that allows users to extend their mobile applications through temporarily spanning the user interface across multiple screens. In short, the technique requires users to touch the border of an available screen (e.g., a public display, TV, or desktop screen) with their phone during the interaction. The system detects this event and initiates the distribution of the user interface across the mobile and the external screen (see Fig. 1). Subsequently, users benefit from the extended screen space which facilitates tasks such as viewing a map, browsing the web, or showing and exchanging pictures to and with other users. When the phone is removed from the border of the external screen, the user interface returns to the original mobile mode. That is, users can take advantage of existing screens in their environments without the need to carry additional hardware.

The contribution of this work is twofold: in this paper, we present the concept and prototype implementation of MobIES and further, we present findings of a user study investigating the system by comparing it with the mobile condition.

Related Work

Early work on seamlessly connecting devices of different classes investigated how users can share information from their PDAs with others on a large shared device to support collaboration [START_REF] Greenberg | PDAs and shared public displays: Making personal information public, and public information personal[END_REF]. Integration of personal mobile devices with pre-installed devices in the environment has also been explored [START_REF] Rekimoto | Augmented Surfaces: A Spatially Continuous Work Space for Hybrid Computing Environments[END_REF]. Ullmer et al.'s mediaBlocks showed how data attached to mobile tokens can be transferred to external devices [START_REF] Ullmer | mediablocks: physical containers, transports, and controls for online media[END_REF]. Hinckley et al. demonstrated how multiple devices with touch screens allow users to drag-and-drop items from one device to another using the stitching technique [START_REF] Hinckley | Stitching: Pen Gestures That Span Multiple Displays[END_REF]. Connecting large screens to mobile phones has been investigated [START_REF] Rashid | The cost of display switching: a comparison of mobile, large display and hybrid ui configurations[END_REF] while other work focused on creating larger logical screens by combining several devices such as tablet computers [START_REF] Lyons | Multi-Display Composition: Supporting Display Sharing for Collocated Mobile Devices[END_REF] and considering the spatial relation of devices and users to each other [START_REF] Lucero | Pass-Them-Around: Collaborative Use Of Mobile Phones For Photo Sharing[END_REF]. Near field communication (NFC) has been used to detect the relative position of mobile devices to larger displays (e.g., [START_REF] Hardy | Touch & Interact: Touch-based interaction of mobile phones with displays[END_REF][START_REF] Reilly | Marked-up maps: combining paper maps and electronic information resources[END_REF]). Yet no work considered placing NFC tags around an external display which allows a novel way of interaction by using the displays of both devices together. Baur et al. present virtual projection which enables users to transfer data (e.g., pictures) from their phone to a large screen and display it thereon [START_REF] Baur | Virtual projection: exploring optical projection as a metaphor for multi-device interaction[END_REF]. This approach allows users to take advantage of existing displays in their environment. However, the user's interaction is limited to the mobile device. Another approach is to distribute application interfaces on different devices and associated displays [START_REF] Grolaux | Attach me, detach me, assemble me like you work[END_REF]. For instance, using mobile devices and large shared displays at which the phone is used as tool by touching the shared display in order to execute actions [START_REF] Schmidt | A cross-device interaction style for mobiles and surfaces[END_REF]. Our approach enables users to interact simultaneously with the phone and the extending display. In contrast to the discussed work, MobIES focuses on mobile situations in which the users have the need for more screen space to perform a specific task. The distribution of the user interface of the mobile application onto both devices -both allowing for interaction -increases the user's capabilities.

Concept

The concept of MobIES is based on users temporarily creating a physical and spatial connection between their mobile device and an external screen to create a larger logical display that consists of the mobile interface and an extended interface on the external screen. We assume that displays in the users' environments can temporarily be used (e.g., public displays, kiosk terminals, TV sets, interactive surfaces, and even screens in cars or airplane seats). User interfaces of mobile applications can display only a limited amount of information (Fig. 2 (left)). By connecting the phone with an external display more screen space is available, thereby allowing for the distribution of the user interface on two screens (Fig. 2 (middle)). Existing work that investigated connecting mobile phones and external screens did not consider the potential of using the mobile and the external screen simultaneously for displaying information. The event of connecting the phone with the display can be sensed, for instance, by using NFC tags that are placed around the external display which is a novel way to use NFC tags for device location detection.

While the phone is connected with an external display, sharing and exchanging data such as pictures, documents, or contact cards can be performed in a straightforward way. Given that the external display supports touch-based interaction, users can simply drag-and-drop items from the external part of their mobile application to the public space. For instance, this can be used in order to leave a message on a bulletin board. In addition, two users can exchange data by both connecting their devices to the same display and drag-and-dropping items from one phone to another (Fig. 2 (right)).

Implementation

Our prototype of MobIES consists of two main components. First, a server application running on a PC connected to a host application that is displayed on the stationary touch screen (Dell ST2220T, 22" screen (1920×1080 px)). Second, a mobile client (for Android) running on the user's phone (Nexus S; 4" screen (800×480 px)). The server and the client manage the communication (via TCP over a wireless network) between the distributed application parts. Each application (e.g., a photo album) consists of a mobile component implemented as an Android application and a matching remote part implemented using the Microsoft Surface Toolkit. Depending on which application is active on the mobile phone when the phone touches the rim of the large display, the server launches a matching instance of the remote part of the application in the host application.

NFC tags are used to detect when a phone is placed on the border of the large display. NFC is supported by large number of different mobile devices (e.g., Samsung Nexus and Nokia devices). Every 50 millimeters, an NFC tag is placed on the display rim (see Fig. 3). When a phone equipped with an NFC reader is placed on the rim, it reads the tag content. This includes the position on the border, the display server's IP, and the name of the wireless network. If the phone is not connected to the server application, the phone client establishes the connection with the wireless network and connects to the server. Finally, the phone client sends back the tag position and the ID or the currently active mobile application to the server which then launches the remote part of the application.

Using NFC tags allows for the extension of any existing screen to support MobIES interactions. This includes non-touch-enabled displays (e.g., public displays), as users can perform input on the phone while the external display extends the screen space.

Evaluation

We conducted a comparative user study to investigate to what extent MobIES supports users in performing typical mobile tasks. In particular, we were interested in gaining insights concerning usability and how participants perceive this extension of the user interface through holding the phone next to the extending screen compared to the familiar practice of using only mobile phones. For the experiment, we implemented based on Schneider et al. [START_REF] Schneider | Mobies: extending mobile interfaces using external screens[END_REF] three applications that allow users to experience the MobIES concept. These include a photo album, a map, and a web browser application. All applications could be used with an additional external display or as a stand-alone mobile application using only a mobile phone. Using only the mobile phone without the extension of the user interface on an external display was used as a comparative condition for the practical tasks (in the following referred to as the mobile-only or MO option). The features of the applications cover standard functionalities inspired by existing Android applications.

In the mobile mode, the photo album application enables users to organize photos taken with the phone in different albums. After selecting an album, contained items are displayed as small thumbnails. Touching a thumbnail activates the full screen mode. When the user launches the extended interface by holding the mobile phone next to the display border, the phone displays the album list and the extended interface shows an overview of picture tiles (Fig. 4 (left)). Which album is displayed can be selected using the list on the mobile interface. Selecting an item in the overview magnifies the picture to fill the application window on the extended interface (Fig. 4 (middle)). For the transfer of pictures from one mobile phone to another, users dragand-drop items from one extended interface to another (Fig. 4 (right)).

The web browser application provides a history overview and supports tabbed browsing and bookmark management (in both modes). As the user connects the phone to the external display, the phone shows a menu containing options (e.g., History, Open Tabs) and the extended interface shows the corresponding content such as the list of bookmarks (see Fig. 5). For typing in text, the user can use a virtual software keyboard either on the phone or on the external display.

The map application enables users to display addresses of contacts on a map, as well as the selection of points of interests from a list, and searching for places.

Participants were asked to perform a number of tasks via MobIES and the comparative MO option while using a preconfigured mobile phone on which all required data (e.g., pictures or contacts) were available. With the photo album application, participants performed the following tasks: 1) Show the investigator pictures showing people from three different albums; 2) Search for the picture showing the {Eiffel Tower, rocks} in the albums and delete it. With the map application, participants performed the following tasks: 1) Find the Eiffel Tower / Tower Bridge on the map and show it to the investigator; 2) Show the investigator the addresses of two contacts from the address book as a pin on a map. For the third block of tasks, participants used the The investigator introduced MobIES and the MO option and participants practiced using them. Then the participants performed a series of tasks, once using MobIES and once as a comparative approach using mobile phones only (MO). The order of systems was counterbalanced and the task order was randomized. Participants filled in a questionnaire regarding usability, including the computer system usability questionnaire [START_REF] Lewis | IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use[END_REF], after performing the tasks with each system.

We recruited 16 participants (5 females), aged between 20-33 (M=26). All participants were students with diverse fields of studies. All participants used smartphones with a touch screen and 14 reported having experience with multi-touch displays. They received 10 Euro after the study session which lasted an average of 45 minutes.

Evaluation Results

On average, each system condition was used for 20 minutes. After each trial, they filled in a questionnaire and rated the system (1=Strongly disagree; 7=Strongly agree). We used the non-parametric Wilcoxon signed-rank test to evaluate differences. Regarding (Q1) "Using the system, I could easily show information to other persons" participants rated the MobIES system significantly higher (Mdn=7.0) than the MO condition (Mdn=3.0) (z=-3.3, p=.001). Similarly, participants rated MobIES (Mdn=7.0) significantly higher than MO (Mdn=5.0) regarding (Q2) "The system supported sharing of information well" (z=-3.3, p=.001). Further, participants rated MobIES higher (Mdn=7.0) than MO (Mdn=3.5) in regards to (Q3) "The system supported jointly viewing of information well" (z=-3.4, .001). Yet both conditions were rated equally concerning (Q4) "Using the system, I often had to change my focus" (z=-.4, p=.72). One likely reason is that the larger screen space provided by MobIES spanned across two devices and thus required users to change their focus, much as using only the mobile phone requires switching between different views. Regarding Q5 participants rated MobIES significantly higher (Mdn=7.0) when compared to MO (Mdn=5.0) (z=-2.9, p=.004).

Participants rated both conditions using the IBM post study system usability questionnaire (1=Strongly disagree; 7=Strongly agree) that allows calculating four scores: OVERALL (the overall satisfaction score), SYSUSE (system usefulness), INFOQUAL (information quality), and INTERQUAL (interface quality) [START_REF] Lewis | IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use[END_REF]. All score results are higher for MobIES: OVERALL (MobIES: 6.37; MO: 5.08), SYSUSE (MobIES: 6.37; MO: 5.25), INFOQUAL (MobIES: 6.30; MO: 5.18), and INTERQUAL (MobIES: 6.34; MO: 4.58). The statements with the largest differences in the ratings cover the issues of system interface and task efficiency (see Fig. 6). S1 and S2 both indicate that participants appreciated the extended interface spanning across two screens as it was perceived as significantly more pleasant to use (z=-3.2, p=.001) and the organization of information was rated to be more clear (z=-2.6, p=.01). S3, S4, and S5 show that participants perceived MobIES as significantly more effective (z=-2.7, p=.007), efficient (z=-2.4, p=.01), and faster to use (z=-2.6, p=.008). Fig. 6. Questionnaire statements with the largest differences in ratings.

Six of the participants emphasized that they liked the level of clarity achieved through the larger screen space. Also, participants pointed out that extending the interface of mobile applications would be helpful to show or share information with others. One user suggested a holder for the mobile phone to leave both hands available for interaction. Four participants pointed out that they liked the ease of use of the system. For instance, P8 stated "It is very easy to switch between using only the mobile phone and using the additional display." Few participants pointed out that they initially had to look for information after the user interface spanned across two displays. Yet all participants learned how to use the system quickly after a short introduction. Other participants highlighted that they liked the extension but expressed doubts whether an external display would be available when needed.

Discussion and Conclusion

MobIES addresses the issue that mobile users temporarily have the need for more screen space in selected situations, for instance, to gain more clarity when viewing large images or maps. The results of our laboratory study strongly indicate that users benefit from using this approach. Parameters that could not be mapped through an experimental setting, such as availability of matching external screens, as well as possible privacy and security concerns need to be considered when deploying such a system. The presented approach is based on a novel application of NFC technology that allows extending existing displays at very low costs. It enables users to take advantage of displays in their environments in order to extend the user interfaces of their mobile applications when needed. However, the presented implementation requires specific software to be available on the mobile and the stationary device, which limits the flexibility of users. To address this, future implementations could include a runtime environment on the stationary display system that executes application logic provided by the mobile client.

In a user study, we compared MobIES with the standard mobile phone option. The results indicate that participants appreciated the degree of information clarity, perceived their task performance to be faster, and highlighted that the system is easy to use. Future investigations will focus on providing a more generalized environment which allows users to take advantage of external displays that are not preconfigured.

Fig. 1 .

 1 Fig. 1. Spanning a mobile user interface across the mobile phone and an external display, here showing a map application.

Fig. 2 .

 2 Fig. 2. (left) The mobile user interface allows for the display of a limited amount of information. (middle) Connecting the mobile and an external display extends the available screen space. (right) Items can be shared with others via drag-and-drop to another connected mobile device.

Fig. 3 .

 3 Fig. 3. Display border with NFC tags (left), covered with tape (right).

Fig. 4 .

 4 Fig. 4. The photo sharing application: (left) extended overview; (middle) focus on a single image; (right) sharing images with another user by dragging an image from one extended interface to another.

Fig. 5 .

 5 Fig. 5. The web browser application: (left) extended web page view; (middle) selecting bookmarks; (right) browser tab overview.

Acknowledgement

This work has been conducted in the Emmy Noether research group Mobile Interaction with Pervasive User Interfaces funded by the German Research Foundation.


Julian Seifert
email: julian.seifert@uni-ulm.de

Dennis Schneider
email: dennis.schneider_l@uni-due.de

Enrico Rukzio
email: enrico.rukzio@uni-ulm.de

MoCoShoP: supporting mobile and collaborative shopping and planning of interiors

Keywords: Mobile phones, interactive surface, collaboration, shopping assistant, collaborative planning

We present MoCoShoP, a system that supports the collaborative process of shopping and planning furniture and interior items. The system consists of a mobile application running on the users' mobile phones and an interactive surface application deployed on shared planning desks in the furniture retail store environment. Users belonging together share a virtual shopping cart. By scanning labels attached to furniture items with their phones that are of interest, users can inspect item details (e.g., dimensions, available colors) with the mobile application and add items to their shopping cart. The shared planning desk allows users to collaboratively review collected items and create possible arrangements of items on a floor plan. Finally, users can store furniture arrangements for later inspection. In this work, we contribute the design and a prototype implementation of MoCoShoP. Results of a first evaluation indicate that users appreciate how they can collect and share data during the process of shopping and how it supports collaborative planning.

Introduction

Online shopping is more popular than ever and recent numbers indicate that this trend is continuing [START_REF] Lipsman | 9 Billion in Q3 2012 U.S. Retail E-Commerce Spending[END_REF]. The list of reasons for this success includes high flexibility for customers who wish to compare prices of products, access to detailed information on products (e.g., availability, possible configurations, dimensions), and social aspects such as easy access to other customers' ratings and reports on experiences with a product. Many types and groups of products are well suited for online shopping. For instance, previews on media files such as music or movies can be provided and thus, customers get a clear idea of what they are going to purchase. However, other artifacts cannot be previewed in an adequate way due to their specific physicality or other inherent aspects that cannot be communicated. Accordingly, many customers prefer visiting retail stores as they allow the touching, testing, and experiencing of a product. This is in particular the case for pieces of furniture that must fit into an existing setting of other previously acquired pieces of furniture. Additionally, they need to meet the customer's personal criteria such as taste or comfort. In retail stores, customers can check these criteria and gain hands-on experience with products. On the downside, retail stores have different drawbacks compared to online shops: detailed product information such as prices, available configurations, etc. are difficult to access. Also, planning how different products would fit into a room with existing pieces of furniture is difficult.

We present MoCoShoP, a system that allows customers to experience the advantages of retail stores (e.g., physical and hands-on experiencing of products) and combines these with the benefits of online shopping (e.g., information access, social shopping). MoCoShoP provides a mobile client application that runs on the customers' mobile phones, which allows for access of product information via network and provides a shared shopping cart (e.g., with family members) if desired. Further, the system provides an interactive planning desk which supports collaborative creating of product arrangements and floor plans containing the collected products. In the following, we illustrate the usage of MoCoShoP with a usage scenario. Scenario: Alice and Bob are planning to buy additional pieces of furniture for their office. In order to look for possible items, they go to a furniture retail store (see Fig. 1a). Both Alice and Bob use the MoCoShoP mobile client on their mobile phones to scan and check out prices and available settings of products (Fig. 1b and1c). When they have collected and added enough items to their cart, they approach the collaborative planning desk and transfer the items to the desk through a touch gesture (Fig. 1d).

On the planning desk, Alice and Bob try different configurations and floor plans with selected products (Fig. 1e). When they agree on a configuration including which items to buy, they save the configuration back to their mobile phones (see Fig. 1f) allowing for further item collection or for the purchase of the selected items.

In this work, we contribute the design and a first implementation of MoCoShoP. Further, we contribute the results of an initial user study.

MoCoShoP Application

The design goals of MoCoShoP are (a) supporting quick information access in retail environments, (b) providing awareness of other users actions to support collaboration, (c) support for collaborative planning and reviewing of potential room plans including purchasable furniture items.

In order to meet these design goals, MoCoShoP includes two components for interaction: a personal mobile client application for each user and a shared interactive planning desk.

Personal Mobile Client

The mobile client runs as an application on the user's mobile phone. It allows users to scan product labels in order to access related detailed information. In order to scan a product ID, the user holds the phone close to the corresponding label which allows the phone to read a Near Field Communication (NFC) tag that is integrated into the label. NFC is based on the Radio-Frequency Identification technology and allows storing of data on a chip that is powered via a capacitive field created by the reading device. This technology is included recently in an increasing number of smartphones (e.g., Nexus 4). As an alternative, printed barcodes could be used to include a larger number of potential smartphones (e.g., the iPhone). When a product label has been scanned, the application retrieves product details and provides an overview (see Fig. 2a). Users can choose to add the product to their shopping cart or simply reject the product. Multiple users can create a joint shopping session which allows them to add products to a shared shopping cart (see Fig. 2b). By selecting an item from the product list in the shopping cart, users can inspect the corresponding product information or delete the item. The mobile client also allows the storage of product lists and floor plan configurations that were created on the shared planning desk (see Fig. 2c).

Collaborative Planning Desk

When users have added potentially interesting products to their shopping cart, they can transition their shopping activity towards a planning activity which is supported by MoCoShoP through the collaborative planning desk. The planning desk is an application that is running on an interactive multi-touch surface, allowing multiple users to work together. First, one user of a group touches the planning desk on the device border with their mobile phone. The mobile phone reads a specific NFC tag which initiates the transfer of collected product IDs to the planning desk application. The planning desk application provides a large canvas which represents a floor plan of the room which the user would like to configure, and thereby plan which pieces of furniture would fit into it (see Fig. 3). The application allows users to quickly rearrange and configure such a floor plan. The interface provides information such as how much money the items cost that are included in the current configuration. In addition, the application provides a number of tools that support the users throughout the planning task. For instance, buttons which rotate items, align, or delete them are provided. Finally, when users are satisfied with their design, the store, the floor plan, and the data are transferred back to their mobile devices.

User Study

We conducted an initial user study in order to gain insights on if and how users would appreciate such a collaborative shopping and planning system such as Mo-CoShoP. In particular, our aim was to gain an understanding of how the system would support collaboration during the shopping and the planning process of furnishing when compared to the current practice of using pen and paper in order to collect information and plan during the shopping process.

Session Organization. Initially, participants were introduced to the aim of the study. Then, participants performed two practical task in counterbalanced order. Once they used the MoCoShoP system and once they used only pen and paper. This pen and paper condition was selected for comparison as it represents an approach most users are familiar with. In order to investigate the collaboration support by MoCoShoP, participants would perform these tasks as pairs of two. After finishing each task, participants were asked to fill out a questionnaire regarding their experiences with the used approach. Practical Tasks. Participants performed one task with each condition (MoCoShoP; pen and paper). The tasks required participants to select, collect, and plan furniture items for a room (a living room and a bedroom). Both tasks were similar in terms of the actions required: first, users were given instructions such as how much money they could spend and what pieces of furniture should be included. Second, the two participants started walking through the experimental shopping environment. We equipped two laboratory rooms with 69 labels attached to the walls representing available furniture items (see Fig. 4a). There, participants looked for items suitable for their planning task. Whenever participants found interesting items they could add them to their shopping lists. When using MoCoShoP, they used smartphones which were provided with the mobile client application installed. In the pen and paper condition, participants were required to take notes manually (see Fig. 4c). Further, participants should plan a room layout including the selected pieces of furniture one time with the MoCoShoP planning desk (see Fig. 4b) and one time using pen and paper (see Fig. 4d). Apparatus Implementation. We implemented a prototype of MoCoShoP for the study. The mobile client application was developed for the Android platform running on a Samsung Nexus S (4" screen, 800×480 px) mobile phone that provides an NFC module for the scanning of product labels. The collaborative planning desk (Dell ST2220T, 22" screen (1920×⨉⨉⨉ 1080 px)) was developed based on the Microsoft Surface 2.0 SDK which provides support for multi-touch interfaces. For the storage and management of product information, a web server provided an interface for the retrieval of corresponding information. Further, a session management server was implemented to store information related to shopping sessions (e.g., list of items in a shared shopping cart).

Participants. We recruited 14 participants who worked in pairs of two. They were aged between 23 and 33 years old and seven of them were female.

Results

All participants expressed that they liked how fast it was to access product information by scanning a label. Several users expressed that a shared shopping cart is helpful in situations when collaborators split up to search for different products by creating a kind of awareness for the other users' activity or location. As expected, most participants appreciated the flexibility provided by the planning desk application which allows users to create many different confections easily. 13 participants stated that shopping and planning furniture items is a collaborative activity they perform together with other people. This reinforces the identified design goal that collaboration support is needed for shopping for furniture items. Participants rated MoCoShoP significantly higher (on a 5-point scale; 5=best; tested using the Wilcoxon Signed Ranks test) compared to the pen and paper condition regarding the support for collaborative shopping (z=-3.13; p=.002), collaborative planning (z=-2.87; p=.004), and perceived creativity stimulation (z=-3.1; p=.002) (see Fig. 5). Further, participants rated MoCoShoP significantly higher in terms of successful task completion (z=-3.22; p=.001), time required to complete the task (z=-3.21; p=.001), support to make the task easy (z=3.21; p=.003), and the perceived system ability to save the user time (z=-3.33; p=.001).

Related Work

The concept and interaction techniques applied for MoCoShoP are grounded in a number of existing and related works. Early work by Rekimoto investigated the pick and drop interaction technique [START_REF] Rekimoto | Pick-and-drop: a direct manipulation technique for multiple computer environments[END_REF]. The touch and interact technique advances the touch-based interaction to mobile phones based on NFC technology [START_REF] Hardy | Touch&Interact: touch-based interaction of mobile phones with displays[END_REF]. PhoneTouch generalizes cross-device (touch-based) interaction [START_REF] Schmidt | A cross-device interaction style for mobiles and surfaces[END_REF] as adopted by MoCoShoP.

Mobile phones have been demonstrated to be suitable devices for mobile recommendation systems to overcome the limitations of traditional retail stores [START_REF] Reischach | A mobile product recommendation system interacting with tagged products[END_REF].

Additionally, mobile phones have been used [START_REF] Broll | Exploring multimodal feedback for an NFC-based mobile shopping assistant[END_REF] for the visualization of customerspecific information on products (e.g., a diabetes shopping assistant). Similar to Mo-CoShoP, the system SoloFind allows users to collect information on products in a retail store for further inspection on a kiosk computer [START_REF] Wiethoff | Solofind: chains of interactions with a mobile retail experience system[END_REF]. In contrast, MoCoShoP incorporates different classes of devices for specific tasks, allows in-formation access via the mobile device, and supports collaboration on the shared planning desk.

Discussion and Conclusion

We presented MoCoShoP, a system that supports customers in retail stores during the process of collecting information on potentially interesting pieces of furniture, and further, during the process of planning how the collected products could fit into their devised layout. While the personal mobile devices are used for information collection, the large interactive surface is used for collaboration and shared discussion.

Our prototype implementation of MoCoShoP demonstrates that the effort for deploying such a system is moderate and existing environments can be easily augmented: product labels with either integrated NFC tags or simply printed barcodes are lowcost factors and interactive surfaces to be used as planning desks will be relatively cheap as technology matures. MoCoShoP combines the benefits of e-commerce and traditional retail stores to improve the user experience.

Fig. 1 .

 1 Fig. 1. Usage scenario for MoCoShoP: Multiple users go shopping together (a). Users pick up information by scanning labels (b) and (c). Users transfer collected items to a planning desk (d) and create plans containing interesting products (e). Finally, they save a planning arrangement and purchase items (f).

Fig. 2 .

 2 Fig. 2. The MoCoShoP mobile application: (a) Product details screen after scanning a product label. (b) Shared shopping cart overview. (c) A floor plan of a configured room including arranged pieces of furniture.

Fig. 3 .

 3 Fig. 3. The collaborative planning desk application provides a touch-based interface.

Fig. 4 .

 4 Fig. 4. Interaction during the evaluation tasks: (a) Using the personal mobile client to collect product information. (b) Collaboration on the planning desk. (c) and (d): Collecting information and planning a room outline using pen and paper.

Fig. 5 .

 5 Fig. 5. Post-hoc questions comparing MoCoShoP and the pen and paper condition (Error bars indicate the standard deviation).

Acknowledgement

This work has been conducted in the Emmy Noether research group Mobile Interaction with Pervasive User Interfaces funded by the German Research Foundation.