ContextCapture: Exploring the Usage of Context-basedAwareness Cues in Informal Information Sharing

Ville Antila*, Jussi Polet*, Ari-Heikki Sarjanoja**, Petri Saarinen***, Minna Isomursu*

*VTT Technical Research Centre ofFinland

Kaitoväylä 190570, Oulu, Finland

firstname.lastname@vtt.fi

**Nokia Research CentreYrttipellontie 1

90230, Oulu, Finlandari-heikki.sarjanoja@nokia.com

***Nokia Research CentreVisiokatu 1

33720, Tampere, Finlandpetri.1.saarinen@nokia.com

ABSTRACTIn this paper, we investigate the usage of context-based awarenesscues in informal information sharing, especially in socialnetworking services. We present an experimental mobileapplication, which allows users to add different descriptions ofcontext information to their Facebook status updates. Themeaningfulness and the usage of different context descriptionswere evaluated in a two-week user trial. The results show that themost frequently used awareness cues in the test setting werelocation, surroundings, friends and activity. The results alsoindicate that user-defined semantic abstractions of context items(e.g. “home”, “work”) were often more informative and usefulthan more accurate indicators (e.g. the address or the name of theplace). We also found out that using shared context from friendsin vicinity (e.g. identifying the people around) needs carefuldesign to overcome the extended privacy implications.

Categories and Subject DescriptorsH.5.2 [Information Interfaces and Presentation]:Miscellaneous.

General TermsDesign, Experimentation, Human Factors.

KeywordsContext-awareness, computer-mediated communication, mobileapplications, sensing, social media.

1. INTRODUCTIONContemporary mobile devices are equipped with hardware andsoftware, which can provide a wide range of awareness andpresence information about the user and the surroundings.Nevertheless, if not filtered or abstracted this information containsa lot of noise and has little meaning for the end user. One way toapproach this challenge is to build algorithms to mine thedifferent sensory data available from the devices [11, 12]. In

addition, to ensure the privacy and user control there should bemeans for adding semantic information by abstracting thisinformation regarding the specific needs and desires of the user.To give some examples, mobile devices can be used as sensors foradding contextual information to content or applications. Photoscan be tagged with GPS coordinates, or presence information canbe shared by an instant messaging application. Furthermore,location check-ins, adding sports activities and giving informalawareness cues in status updates are increasingly usedfunctionalities in SNSs (Social Networking Services), such as theFacebook.In this paper, we investigate the meaningfulness of different typesof contextual information and the practices of abstracting thosefor public (or semi-public) sharing. To facilitate this, we havedeveloped an experimental mobile application, which allows usersto add different types of contextual information to their Facebookstatus updates in a format of a story. The types of contextualinformation explored in this study include the current physicalactivity of the user, the currently active applications in the mobiledevice, information about the current device, information aboutthe friends around, the current location as well as informationabout the surroundings. Through a two-week user trial weexplored the meaningfulness of these context types and the usageof different abstraction levels when publicly sharing thisinformation. The goal was to shed light into the practical use ofcontext information in informal information sharing and thegeneralization of these practices in designing context-awareapplications.

2. RELATED WORKThere has been a body of research on exploring differentapplications for exploiting context information with mobiledevices. Eagle and Pentland demonstrate the ability to use mobiledevices to recognize social patterns, infer relationships, identifysocially significant locations, and model organizational rhythms[5]. These life patterns can be used as input for creating narrativeevents [15]. Campbell et al. discuss the rising possibilities ofpeople-centric sensing where social ties are used to both enhancethe system learning capabilities and to motivate the user to labelactivities [4]. In the work of Miluzzo et al. they propose a system,which is capable of sensing various activities (location, physicalactivity, social and physical surroundings) and share thisinformation on various social networking platforms [11, 12]. Wepropose a similar approach, but give even more freedom for theuser to select the message to convey (including differentabstractions), thus giving the system possibility to gather morenuanced data from the activities and learn more abstractassociations, which can be used for labeling the contexts.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.

MindTrek’11, September 28–30, 2011, Tampere, Finland.

Copyright 2011 ACM 978-1-4503-0816-8/11/09....$10.00.

Oulasvirta et al. have studied how sharing context informationcould create awareness about the user’s situation and thusenhance communication and collaboration [13]. They also discussthe different design requirements for representing the context-based awareness cues [14]. We have used and adapted some ofthese design requirements as the basis of the application concept,to explore the relevance, meaningfulness and user control in usingcontext-based awareness cues.The perceived privacy implications of shared presenceinformation are largely related to the information type as well asthe intended audience, but people are also willing to stretch theboundaries of privacy in exchange for useful services [8]. Thedownside of added richness of information is always vulnerabilityto misuse. For example, Brown et al. [3] discuss the possibilitiesof extracting information from social networks to create context-aware spam. We have adopted a basic setup of privacy rules andsecurity measures. Nevertheless, adding security mechanismsbeyond the basic cryptography tools is outside the scope of thiswork and is extensively researched in other works. For example,Beach et al. has explored the implications of sharing socialnetworking IDs locally and they also discuss the privacyimplications of such sharing mechanisms [1]. In addition, Lee andChandra propose a phone-to-phone based context sharing to allowdynamic privacy control [9]. These mechanisms could be relevantwhen developing the proposed approach further.The use of mobile devices to create context-aware content tosocial networking services has grown recently. Services such asFoursquare1, Gowalla2 and Facebook Places3 can be used tocheck-in to venues using mobile devices equipped with GPS-chips. Furthermore, location-based formation of social networkshas been researched recently [10]. As the social computing isgetting more mobile and pervasive there has been an increase ininterest of exploring the social-side of context-awareness [6]. Inaddition to mere location or physical activity of the user, thesystems could benefit from the knowledge of the socialsurroundings. For example, there has been research to explore thesocial use of ubiquitous computing in urban areas [7]. In thispaper, we suggest mechanisms to gather context from thesurroundings to enhance both availability and relevance of contextinformation (e.g. querying the devices around). In addition, weinvestigate the extended privacy implications of such sharingmechanisms from the user’s point-of-view and point out designchallenges based on the findings.

3. APPLICATIONThere are two main goals we addressed with the developedapplication. First, we wanted to study the technical aspects ofcollaborative context, for example, how the contextualinformation can be exchanged between different devices.Secondly, we were able to gain new information about the userexperience of context-aware systems, e.g. about the privacyconcerns related to the context sharing, understandability of thecontextually adaptive applications and the meaningfulness ofdifferent abstractions. Furthermore, the shared and storedinformation can also be used for future purposes, such as the basis

1 http://foursquare.com/2 http://gowalla.com/3 http://www.facebook.com/places/

for situation-aware recommendations. The application concept isbuild around three main design goals (adapted from [14]):

Relevance – We wanted to explore the relevance of differentcontext types in informal information sharing.

Meaningfulness – Another goal was to explore themeaningfulness of the different abstraction levels of contextinformation (i.e. labeling).

Control – The application was designed to give full controlto the user, thus providing mechanisms to control thedisclosure of the overall information or message.

The developed application allows people to include contextualinformation to their status updates they send to Facebook. Inaddition to the selection of different context types, the user canalso decide the desired abstraction level (e.g. coordinates, addressor semantic label such as “office”). Our hypothesis is that inmany cases, rather than using exact parameters provided bycontext recognition modules for describing the situation, peoplewould like to add semantic meaning by using more abstractnotions. As Benford et al. argue: “[in this context,] declaringone’s position is perhaps as much about deixis (pointing at andreferencing features of the environment) as it is about tellingsomeone exactly where you are” [2].In this work, we explore not only the different abstractions oflocation information, but also other commonly available and usedcontext information types. We selected six basic information typesthat the users could use to describe their context. The selectedcontext types are activity, applications, device, friends, locationand surroundings. These context types are described more in thenext sections.

3.1 Software Design and ImplementationThe prototype consists of a mobile application and a server-sideapplication, which is integrated with Facebook. The overallprototype architecture is depicted in the Figure 1 below.The mobile application gathers context data from the device itself,available sensors and by using Bluetooth to collect data fromnearby devices. The application presents the sensed contextinformation to the user along with proposals for other semanticabstractions which have been used to describe similar contextsearlier. After selecting the context items and their abstractions, thestatus update is sent over HTTP to the server. The serverapplication stores the received context data into a semantic model(including the raw data from the sensors and the associatedabstraction) and creates a story-like status update, which is used tocreate a new status update in Facebook.

Figure 1. ContextCapture general architecture - maincomponents of the client and server-side applications.

3.1.1 Context RecognitionThe context recognition is based on different “sensors” of activity,such as the accelerometer, ambient light detector and GPS data,the open applications on the mobile device, the device systeminformation, the nearby Bluetooth devices and the WLAN accesspoints. Based on this data, context descriptions are shown to theuser. For example, based on the ambient light detector data,information about the current lighting is shown to user, such as“Dark lighting” or based on the GPS data, the current streetaddress, GPS coordinates and current temperature and weatherdescriptions are shown. In the list below we describe all thecontext information items supported by the application:

Activity – Based on the accelerometer data, a decision is madewhether the user is running, walking or still by usingmovement detection algorithms. This is then shown to theuser as a description of the current physical activityabstraction.

Applications – Based on the data gathered from the mobiledevice, the currently open applications are shown to the useras a description of the current virtual activity abstraction.

Device – Some of the data gathered about the mobile deviceitself, such as the device type, is shown to the user.

Friends – Based on the Bluetooth device and service scandata, the current nearby Bluetooth devices andContextCapture friends are shown to the user as the currentsocial context. The current ContextCapture friends’ detectionis based on the Facebook friends and ContextCapture use, i.e.if the users are friends in the Facebook and both are usingContextCapture and are nearby, they are shown in the currentsocial context abstractions.

Location – Based on the GPS, network and WLAN scan data,the current street address, GPS coordinates, network cell IDand nearby WLAN access points are shown as the possiblecurrent location abstractions.

Surroundings – Based on the ambient light detector and GPSdata, the current ambient lighting and the temperature andweather (which are downloaded based on the GPScoordinates) are shown as the current physical surroundingsabstractions.

3.1.2 Mobile ApplicationThe main functionality of the mobile application is to gatherinformation about the current context and show it to the user. Theuser can then use these context items to create context-awarestatus updates. In addition to the sensed context abstractions, theapplication also lists other commonly used abstractions to give theuser control over the selection of items and abstractions to includein the message. This gives the user the opportunity to reflect anyhigher-level semantics, which cannot be inferred by the system,but also gives the system the possibility to learn these newsemantics given in specific contexts making the recommendationssmarter over time. When the user sends the status update, themobile application sends the selected abstractions as well as thesensed raw sensory data to create the association link to enablemachine learning. This will create a database of collectivelycreated database of context semantics that can be shared betweenusers.

Figure 2. An example use sequence of the ContextCapturemobile application.

In the Figure 2 we present an example use sequence of the mobileapplication, where the user first selects the physical activitycontext to be added to the status update and then selects thewanted abstraction for the activity. In the Figure 2, the user selectsthe “Sitting” abstraction out of the five suggested abstractionsinstead of the actual physical activity (which is “Still”) or writingan own abstraction.

3.1.3 Protocol for Exchanging Collective ContextThe client-to-client communication is done over a Bluetoothconnection, using a specified communication protocol. Themobile client sets up a RFCOMM service when the applicationstarts and notices whether there are other devices nearby offeringthe specified service. If so, the devices exchange MD5-hashedIMSI strings, which are coupled with the Facebook accounts.Thus, the mobile client will recognize the nearby ContextCaptureFacebook friends. If the mobile client is lacking some contextinformation, for example the GPS coordinates, it will request thatinformation from the nearby ContextCapture friends, which will

reply with the data, should they possess it. The syntax for theexchange protocol is as follows:CCRAControlProtocol:<role_name>:<BT_name>:<command>:<parameters>

For example, the mobile client requesting for weather data froma nearby ContextCapture friend takes the client role and sends arequest as follows:CCRAControlProtocol:Client:ClientBluetoothName:WTHR:Request

And the service running on the specified device replies:CCRAControlProtocol:Server:ServerBluetoothName:WTHR:-3 degrees Celsius,Sunny

If the other device does not have the context data asked for, itwill simply reply:CCRAControlProcotol:Server:ServerBluetoothName:NACK:WTHR

The client-to-server communication enables the mobile client tosend status updates to Facebook. The ContextCapture Facebookapplication is located at the server and relays the incoming statusupdate messages from the mobile client to the Facebook. Theclient-to-server communication is based on normal HTTP GETand POST operations, where the data sent is JSON formatted. Thetwo main communication sequences between the mobile clientand the server are the login and status update.In the login sequence, the mobile client sends the login key,which the user has got from the ContextCapture Facebookapplication and the MD5-hashed IMSI string. This way, the user’sFacebook account and the user’s mobile device are coupledtogether at the server by using the Facebook user ID,ContextCapture login key and the MD5-hashed IMSI string.Depending on the login success, the server sends back a reply,which also contains the user’s Facebook friends. This way, themobile client is able to recognize the nearby Facebook friends byexchanging the MD5-hashed IMSI strings acting as identifiers.In the status update sequence, the mobile client sends a JSONformatted data package containing all the context data and theuser-given abstractions to server. The server then parses themessage and creates a story-like status update string, which is sentas a wall post to Facebook. Depending on the success, the serversends back a reply, which also contains the currentContextCapture friends, so that the mobile client can update thefriends list if there have been changes.

3.1.4 Server-side Application and FacebookIntegrationThe key functionality of ContextCapture application is theintegration to Facebook. This integration was done byimplementing a Facebook application, which handles the firstphase of registration. To install the application, the user simplyaccesses the application URL(http://apps.facebook.com/contextcapture). Afterallowing the permissions, the user is redirected back to theContextCapture application with access credentials (Facebookwill give the ContextCapture application an OAuth token foraccessing the Facebook API). This access token is used to querythe basic user information, such as the name and the profilepicture. Then the user is given a unique login key, depicted in theFigure 3, which can be used to sign in with the mobileapplication. This creates the link between the mobile applicationand the Facebook user account.

Figure 3. ContextCapture application on Facebook.After a successful installation and registration of both theFacebook application and the mobile application, the user cansend context-enhanced status updates from the mobile devicedirectly to the Facebook wall (an example is presented below inthe Figure 4).

Figure 4. A context-enhanced status update shown in theFacebook profile.

3.2 Used TechnologiesThe mobile application was implemented for Symbian devices. Qtfor Symbian with additional third-party libraries (such asQBluetooth and QJson) was used. The persistent storage forcontext data was implemented with the Qt APIs for SQLite4. Themobile application is also developed for Android devices, but theywere not used in the trial. The server-side implementation wasdeveloped using J2EE web framework. The contextual data issaved using RDF5 format with Jena Semantic Web Toolkit6 andpersisted in a PostgreSQL7 database. The SNS integration wasimplemented using the Facebook APIs, which enablesfunctionalities such as the user authentication and status updating.

4. EVALUATIONTo evaluate the ContextCapture application and to find answers toour research questions, we arranged a trial where 12 participantsused ContextCapture for two weeks with their own mobile phones

4 http://www.sqlite.org/5 http://www.w3.org/RDF/6 http://jena.sourceforge.net/7 http://www.postgresql.org/

in their everyday lives. This section introduces the user study andthe results from the trial.

4.1 MethodologyThe aim of the evaluation was to study how people would usecontext information in their status updates, what kind of feelingsand user experience automatic context recognition would invokeand what kind of abstraction levels would be suitable forpresenting the context information. To discover these matters,three research questions were set (Table 1).

Table 1. Research questionsRQ1 Do users perceive the context data as useful in manual

status updates?

RQ2 Do users perceive an application supporting manualstatus update through automatic context recognitionand collective context as useful or valuable?

RQ3 What kind of abstraction levels (regarding thesemantics) is understandable for the user?

As we wanted to ensure that all significant data would becollected, various data collection methods were used. In thebeginning of the trial we had an initial web questionnaire whichincluded questions about the Facebook usage and expectationstowards the ContextCapture application. During the trialparticipants could report about their experiences with theapplication through a web-based diary questionnaire. The diaryinquired, which of the context types had been most useful to theparticipants lately and whether they had got any comments andfeedback from their Facebook friends related to the contextualstatus updates. It also included questions about the experiencesrelated to privacy. The participants could also give general free-formatted feedback about the study and tell the possible problemswith the application through the diary questionnaire. At the end ofthe trial all participants were interviewed for getting more in-depth information about the user experience. Interviews alsoincluded a background information sheet, which was given onpaper. It contained demographical and closed scale questions,which were easier to ask in written form.

4.2 ParticipantsAs ContextCapture is currently designed to work with Facebookonly, the first criterion for the trial participants was the fact thatthey had to be active Facebook users. Some of the participantshad to be connected through Facebook, as we wanted to havegroups of people, who could see each other’s status updates andbe able to use friends related context information via “Facebookfriends nearby” –functionality. In addition, the participants had tohave suitable mobile phones supported by the application. Due tothis, we decided to invite only Nokia and VTT employees.Total of 12 users participated in the trial, six male and six female.The age of the participants was between 30-46 years, 37.25 yearson average. Participants used ContextCapture with their ownmobile devices and personal Facebook accounts during the trial.All participants were experienced Facebook users as 25% of themhad used the service 1-2 years and the rest for over two years.Figure 5 shows how often the participants were used to sendstatus updates before the study.

Figure 5. Frequency of sending status updates (generally andvia mobile phone).

4.3 Trial SetupFirst we sent email instructions to the participants on how todownload and install the application. The email included a shortdescription of the study and its purpose, a short manual, the linkand instructions on how to install the application and a link to theinitial web questionnaire. The users were requested to fill in theinitial questionnaire after they had successfully completed theinstallation of the application. This indicated that they had startedthe trial.The participants used the application for approximately twoweeks. During that time, they could tell their experiences throughthe web diary. We asked them to fill in the diary at least five timesand preferably in separate days. Total of 26 diary entries weremade during the trial. At the end of the trial, we interviewed allthe participants; nine of them with face-to-face interviews andthree of them via telephone interviews. Interviews were semi-structured, including questions dealing with users’ expectationsand meeting them, attitudes, privacy and the most pleasing andunpleasing experiences related to usage. Furthermore, participantswere asked about their ideas for further development of theapplication. Interviews lasted approximately 30 minutes each.

4.4 FindingsAt the beginning of the trial participants did not have muchexpectations, which is understandable since these kinds ofapplications are novel to many people. It seemed that participantsthought they understood well how ContextCapture application canbe used, as Figure 6 describes. In addition, privacy was notviewed as an issue at the beginning of the trial and context-awareness and context-aware applications were known to most ofthe participants. Also, under half of the trial participants felt thatthe application was going to be useful for them before the trial,but argued afterwards that the application does provide some extravalue for the status updates and overall was fun to use.As Figure 7 shows, participants viewed Location as the mostvaluable context field. Many participants seemed to think thatadded context information enlivens the status updates in apleasant way. Status updates with location information are alsomore informative as people can use them to reference theiractivities with the relevant location or point out features from theenvironment. Weather information, which was related toSurroundings field, was also seen highly interesting. Applicationand Device were considered as the least useful fields. It seemedthat many participants did not want to advertise the device theywere using, so they considered the device field as unnecessary.

Some of them also thought that the device information is notrelevant context information since it rarely changes.

Figure 6. Statements about the application.

Figure 7. The usefulness of different context fields.Privacy matters did not raise major issues during the trial, thoughparticipants were clearly aware of their privacy and had thought itwhile using the application. For example, the participants did notuse the addresses of their homes or kindergarten their childrenwere, although the audience consisted of Facebook friends knownby the participants. It seemed that the accurate location of theseplaces was too sensitive to be shared. In addition, many of theparticipants stated that the semantic meaning of the place isenough. For example, saying that “I’m at home” is adequateenough for the people the message is meant for, i.e. my friendsknow where I live.Sharing friend’s location was also one thing, which invokedthoughts. In many participants’ opinion sharing this kind ofinformation without permission is not acceptable. So there shouldbe some way for asking a permission to share context dataincluding other users. Friends’ names were also often viewed asprivate information and participants preferred to use more abstractwords, like “group of friends”, instead of giving the exact names.One of the key findings was the fact that participants were clearlyinterested in context data and in using context-aware application.Context information was seen as highly interesting, but theparticipants hoped that they could have had even more control inthe level of abstraction. In addition, more abstract names like“home”, “work”, “kindergarten” were seen as more useful andsecure in many situations than the exact street addresses. Therewere interest towards getting more specific location information,bare street addresses were seen as not useful, but the applicationshould recognize the place, which is located in the address, like amovie theater or a shop.Participants gave some ideas for further development. Forexample, many were interested in using also photos with the

status updates as additional context information. Weatherinformation was seen as valuable, but a more informative way toshow weather conditions could be by using more visualinformation, like a specific icon. Most participants thought that itis critical to integrate the application to Facebook, when a stand-alone application would not be needed anymore and the featurescould be used straight from the Facebook UI.

5. DISCUSSION AND CONCLUSIONSThe motivation for the research described in this paper was toexplore the usage of different types and abstractions of contextinformation in informal information sharing. We approached thischallenge by developing an experimental application that allowsusers to add different context information types and abstractionsto their Facebook status updates. Our hypothesis was that in manycases, rather than using exact terms for describing the situation,people would like to use more abstract notions. The findingssupport this hypothesis. In many cases, the participants reportedthat the usage of semantic labels rather than exact terms todescribe the situation seemed more appropriate and meaningful.In addition, the participants brought up privacy concernsregarding the use of collective context, such as identifying friendsaround. We conclude that introduction of such functionalitiesneeds careful design for mechanisms to give permissions forpublication.Even though the participants felt that the service as such was notso much useful as it was fun, they argued that if developed furtherand integrated better with the mobile devices and the SNSs, theservice could prove to be useful when one wants to share thecurrent situation without having to spend too much timeillustrating the surrounding context.Based on the findings from the user study we analyzed therelevance and meaningfulness of the different context types aswell as the control of the information disclosure.The participants felt that the current location, activity andsurroundings were the most relevant context types, as bydisclosing them the current situation could be described quiteextensively. The more virtual context types, that are theapplications and the device, were seen as less relevant, as theusers did not want to advertise the make or the model of theirmobile device and the applications running were mostly seen asquite boring information to be included. Disclosing the nearbyfriends or colleagues in the status updates was seen as relevant butproblematic due to privacy issues.The context types were seen as most meaningful when the usedabstraction level was high, i.e. the participants felt that the exactlow-level information, such as the street address or the GPScoordinates, conveyed a too matter-of-fact type descriptionwhereas more abstract descriptions, such as “at the movietheatre” or “at the botanical garden” were seen as moreillustrative, interesting and meaningful. Also using the name ofthe building or other abstract place names were preferred, as thisway the users can protect their privacy but in the same time it canbe more expressive for the people who know the area. This type ofinformation abstraction can be thought in some way as “privacythrough obscurity”.The trial participants reported that the application controlsregarding the information disclosure were good. In fact, most ofthe participants wished that most of the context fields should beincluded automatically in order to avoid too much selecting, i.e.

the application interaction should follow the idea of “type thestatus update, choose the context abstractions and deselect whatyou do not want to include” instead of the current idea of “typethe status update, choose the context abstractions and selectwhich ones you want to include”. The participants agreed thatwhen designing and implementing these kind of applications, theinformation disclosure and privacy should be able to be fullycontrolled by the user.We argue that the proposed approach was meaningful andmotivating for the users and in the same time allows the system togather an extensive set of user-defined context labels. Thisextensive set of labels can be used as inputs for machine learningmechanisms to allow smarter recommendations and evenpredictions based on higher level context abstractions, whichcould otherwise be impossible to infer from the data only.

6. ACKNOWLEDGMENTSThis work has been supported by the SMARCOS Artemis project.

7. REFERENCES[1] Beach, A., Gartrell, M., Akkala, S., Elston, J., Kelley, J.,

Nishimoto, K., Ray, B., Razgulin, S., Sundaresan, K. &Surendar, B. Whozthat? Evolving an Ecosystem for Context-aware Mobile Social Networks, Vol. 22, No. 4, pp. 50-55,Network, IEEE, 2008.

[2] Benford, S., Seager, W., Flintham, M., Anastasi, R.,Rowland, D., Humble, J., Stanton, D., Bowers, J.,Tandavanitj, N. & Adams, M. The Error of Our Ways: TheExperience of Self-reported Position in a Location-basedGame, pp. 70-87, UbiComp 2004: Ubiquitous Computing,2004.

[3] Brown, G., Howe, T., Ihbe, M., Prakash, A. & Borders, K.Social Networks and Context-aware Spam. Proceedings ofthe 2008 ACM Conference on Computer SupportedCooperative Work, pp. 403, ACM, 2008.

[4] Campbell, A.T., Eisenman, S.B., Lane, N.D., Miluzzo, E.,Peterson, R.A., Lu, H., Zheng, X., Musolesi, M., Fodor, K.& Ahn, G.S. The Rise of People-centric Sensing, pp. 12-21,IEEE Internet Computing, IEEE, 2008.

[5] Eagle, N. & Pentland, A. Reality Mining: Sensing ComplexSocial Systems, Vol. 10, No. 4, pp. 255-268, Personal andUbiquitous Computing, 2006.

[6] Endler, M., Skyrme, A., Schuster, D. & Springer, T.Defining Situated Social Context for Pervasive SocialComputing. Second IEEE Workshop on PervasiveCollaboration and Social Networking, in Proceedings ofPerCom, Vol. 1. 2011. pp. 3, 2011.

[7] Hosio, S., Kukka, H. & Riekki, J. Social Surroundings:Bridging the Virtual and Physical Divide. IEEE MultiMediaMagazine, Vol. 17, No. 2, pp. 26-33, 2010.

[8] Khalil, A. & Connelly, K. Context-aware Telephony: PrivacyPreferences and Sharing Patterns. Proceedings of the 200620th Anniversary Conference on Computer SupportedCooperative Work, pp. 469, ACM, 2006.

[9] Lee, J.S. & Chandra, U. Mobile Phone-to-phone PersonalContext Sharing. 9th International Symposium onCommunications and Information Technology (ISCIT),2009, pp. 1034, IEEE, 2009.

[10] Lübke, R., Schuster, D. & Schill, A. MobilisGroups:Location-based Group Formation in Mobile SocialNetworks. Second IEEE Workshop on PervasiveCollaboration and Social Networking, in Proceedings ofPerCom, 2011.

[11] Miluzzo, E., Lane, N., Eisenman, S. & Campbell, A.CenceMe – Injecting Sensing Presence Into SocialNetworking Applications. Smart Sensing and Context, pp. 1-28, 2007.

[12] Miluzzo, E., Lane, N.D., Fodor, K., Peterson, R., Lu, H.,Musolesi, M., Eisenman, S.B., Zheng, X. & Campbell, A.T.Sensing Meets Mobile Social Networks: The Design,Implementation and Evaluation of the CenceMe Application.Proceedings of the 6th ACM Conference on EmbeddedNetwork Sensor Systems, pp. 337, ACM, 2008.

[13] Oulasvirta, A. Designing Mobile Awareness Cues.Proceedings of the 10th International Conference on HumanComputer Interaction with Mobile Devices and Services, pp.43, ACM, 2008.

[14] Oulasvirta, A., Raento, M. & Tiitta, S. ContextContacts: Re-designing SmartPhone's Contact Book to Support MobileAwareness and Collaboration. Proceedings of the 7thInternational Conference on Human Computer Interactionwith Mobile Devices & Services, pp. 167, ACM, 2005.

[15] Reddington, J. & Tintarev, N. Automatically GeneratingStories from Sensor Data. Proceedings of the 15thInternational Conference on Intelligent User Interfaces, pp.407, ACM, 2011.