ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Yuki Matsuda, Shogo Kawanaka, Hirohiko Suwa, Yutaka Arakawa, Keiichi Yasumoto
aa r X i v : . [ c s . S I] F e b ParmoSense:A Scenario-based Participatory Mobile Urban Sensing Platformwith User Motivation Engine
A P
REPRINT
Yuki Matsuda † , ∗ , Shogo Kawanaka , Hirohiko Suwa , Yutaka Arakawa , Keiichi Yasumoto Graduate School of Science and Technology, Nara Institute of Science and Technology, Ikoma, Nara, Japan Center for Advanced Intelligence Project AIP, RIKEN, Chuo, Tokyo, Japan PRESTO, JST, Chiyoda, Tokyo, Japan Research Fellowship for Young Scientists, JSPS, Chiyoda, Tokyo, Japan Graduate School and Faculty of Information Science and Electrical Engineering,Kyushu University, Fukuoka, Fukuoka, Japan † [email protected] A BSTRACT
Rapid proliferation of mobile devices with various sensors have enabled
Participatory Mobile Sens-ing (PMS) . Several PMS platforms provide multiple functions for various sensing purposes, butthey are suffering from the open issues: limited use of their functions for a specific scenario/caseand requiring technical knowledge for organizers. In this paper, we propose a novel PMS platformnamed
ParmoSense for easily and flexibly collecting urban environmental information. To reducethe burden on both organizers and participants, in ParmoSense, we employ two novel features: modu-larization of functions and scenario-based PMS system description.
For modularization, we providethe essential PMS functions as modules which can be easily chosen and combined for sensing indifferent scenarios. The scenario-based description feature allows organizers to easily and quicklyset up a new participatory sensing instance and participants to easily install the corresponding sce-nario and participate in the sensing. Moreover, ParmoSense provides GUI tools as well for creatingand distributing PMS system easily, editing and visualizing collected data quickly. It also providesmultiple functions for encouraging participants’ motivation for sustainable operation of the system.Through performance comparison with existing PMS platforms, we confirmed ParmoSense showsthe best cost-performance in the perspective of the workload for preparing PMS system and varietiesof functions. In addition, to evaluate the availability and usability of ParmoSense, we conducted 19case studies, which have different locations, scales, and purposes, over 4 years with cooperationfrom ordinary citizens. Through the case studies and the questionnaire survey for participants andorganizers, we confirmed that ParmoSense can be easily operated and participated by ordinary citi-zens including non-technical persons. K eywords Civic computing · Ubiquitous computing · Mobile computing · Participatory sensing · Smart city · Urbansensing · Gamification · Incentive mechanism
Mobile devices come equipped with various sensors including GPS, inertial sensors, environment sensors, camera,microphone and so on. The rapid widespread of such mobile devices have enabled Participatory Mobile Sensing(PMS) [1, 2, 3]. PMS systems are based on crowdsourcing technology, where data in a wide geographical area canbe collected efficiently and at low cost by leveraging sensors on mobile devices carried by ordinary citizens. Many ∗ http://yukimat.jp/ atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine applications can utilize collected urban data to bring various benefits to our daily lives. For instance, because PMSsystems use common devices, they can be easily used to collect data for urban analysis [4], office management [5],healthcare [6], and education [7, 8]. In addition, since PMS systems can be applied to any region in which people stayor pass, they are very effective for collecting geospatial data over a wide area. In urban environment for example, datasuch as illuminance of the road at night [9], noise levels in the city [10, 11], and air pollution degrees [12, 13] can becollected.PMS is a sensing mechanism based on the voluntarism of general people. In other words, the sustainability of thesystem is a critical challenge in real-world operations. As an idea to enhance this sustainability, the mutual linkagewith the local community where ecosystems are already formed can be considered. For example, the civic cooper-ation that people work with government, universities, companies, etc. to promote community development spreadsglobally. Especially in recent years, CivicTech which combines ICT and civic cooperation is gathering attention, e.g.,FixMyStreet [14]. In our study, we focus on PMS systems which can be used in CivicTech communities.To realize PMS systems in the real world for broad urban environment analysis, we believe that a platform that can beeasily and quickly customized by organizers to perform a variety of sensing tasks, and that is easy to set-up and runon the participants’ smartphones, is essential. However, when we investigated the functions implemented in existingPMS platforms [15, 16, 17, 18, 19, 20, 21, 22, 23], we found two main challenges in using these platforms for broadurban environment analysis: C1: Limited support of essential functions and
C2: Difficulty of system construction andoperation .Regarding C1 , existing platforms tend to focus on specific sensing purposes, e.g., urban transport data sensing, andtherefore support limited functions. Because the purpose of sensing differs among organizers of urban sensing, thenecessary functions, i.e., sensing function, incentive mechanism, task request control, and data processing method,will also differ depending on the purposes. Thus, in the ideal PMS platform, flexibility to adapt the platform toperform sensing for various purposes is mandatory. Moreover, motivating participants is an important aspect of PMSsince participatory sensing relies on voluntary participation of ordinary citizens [24], but we found that these platformsdo not implement it enough. And regarding C2 , The platforms require a high level of technical skill for users. Forexample, some platforms require programming skills for organizers and data processing skills for participants. Inorder to open the door of participatory sensing to non-technical users, it is necessary to ensure that PMS systems canbe easily constructed and operated by both organizers and participants.In this study, we designed and built a novel PMS platform called ParmoSense , for easily and flexibly collectingurban environmental information for various purposes by overcoming the challenges mentioned above. To achievethis, we employ two features: modularization of functions and scenario-based PMS system description.
We providevarious functions essential for PMS systems such as sensing functions, motivating functions for participants, andprocessing functions for collected data, and allow organizers to combine these modularized functions freely througha GUI web application. We call a combination of these modularized functions a scenario . Once a scenario has beencreated, participants can download it onto the ParmoSense Client application and run it without doing any furthersetup or processing tasks. Thus, participants can contribute to many different sensing tasks without installing multiple-applications or performing complicated tasks which require technical skills.To evaluate the superiority of ParmoSense, we compared a performance with existing PMS platforms. First, weconfirmed that ParmoSense provides a higher variety of functions than the existing PMS platforms, which solveschallenge C1 . We also found that ParmoSense eases organizers to prepare PMS systems. It belongs to the lowestpreparation workload group among those platforms, which solves challenge C2 . From both perspectives, therefore,ParmoSense shows the best cost-performance. In addition, to evaluate the availability and usability of ParmoSense inthe real-world, we conducted the 19 practical case studies with ordinary citizens including non-technical people. Weconfirmed that ParmoSense can deal with various sensing targets, organizers, and participants, in real environments.Our contributions in this paper are as follows:i. We designed a PMS platform, named ParmoSense, which allows general people to easily operate PMS sys-tems with scenario-based system construction regardless technical skills.ii. We organized functionality requirements through the survey of existing PMS platforms, and implemented allfunctions as combinable modules.iii. We confirmed that ParmoSense shows the best cost-performance in the perspective of varieties of functionsand preparation workload through the evaluation on comparison with nine existing platforms.iv. We confirmed the availability and usability of ParmoSense through the 19 practical case studies in the realworld, and interviews with participants and organizers of sensing tasks.2 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Table 1:
Overview of supported functions.
Platforms FunctionsSensing functions Motivating functions Processing functionsF1 F2 F3 F4 F5 F6 F7 F8
Implicit-sensing Explicit-sensing Request Reward Feedback Editing Browsing Export
AWARE [15] X △ *b △ *e △ *g X X
Sensus [16] X △ *c X △ *h Medusa [17] X △ *d △ *e △ *f X Funf [18] X △ *d X X X
MinaQn [19] △ *a △ *b △ *e X X
KOKOPIN app [20] △ *a △ *c X X X
Ohmage [21] △ *c X △ *g X X X
OpenDataKit [22] △ *a X X X X
GP-Selector [23]
X X X △ *f ParmoSense
X X X X X X X X *a Location (GPS) only supported. *b Media upload (photo, sound, etc.) limited. *c Raw data collection unsupported. *d Questionnaire unsupported. *e Static request only supported. *f Monetary incentives only supported. *g Feedback of data collected by oneself only supported. *h command-line tool is required. The rest of this paper is organized as follows: In Section 2, we survey the existing PMS platforms and systems, andorganize required functions for PMS systems and skill requirement for participants and organizers. In Section 3,we describe the concept and the architecture of ParmoSense and provided functions on ParmoSense. To evaluateParmoSense, we compare the functionality and performance with existing PMS platforms in Section 4, and conductthe 19 practical case studies with general people including non-technical persons in Section 5. Section 6 concludesthis paper, and we will discuss limitation and future challenges of ParmoSense.
This section is devoted to clarifying what kind of functions are necessary for PMS systems and what kind of skills arerequired for users (organizers and participants) of PMS systems. We first organized the necessary functions into threecategories: sensing functions, motivating functions and processing functions. Then, we investigated the functionsimplemented in existing PMS platforms [15, 16, 17, 18, 19, 20, 21, 22]. The results are summarized in Table 1. Theskills required by organizers and participants in existing PMS platforms are shown in Table 2.
Sensing is an essential part of PMS systems. We define sensing functions as those that allow the organizer to specifywhat kind of sensors to use, and how to collect sensing data from the urban environment. There are two different waysof sensing: implicit (F1) and explicit (F2) sensing.
Implicit-sensing (F1):
Uses sensors embedded in mobile devices. It is mainly used for collecting urban environmen-tal data without actively involving the participant, i.e., implicit sensing.
Explicit-sensing (F2):
Used for collecting data generated by human behavior, e.g., photos, voice, and questionnaires.It is used for collecting urban environmental data through directly involving participants, i.e., explicitly, andlocally.AWARE [15] provides a platform for both implicit and explicit sensing. For implicit-sensing, the organizer can choosewhich smartphone sensors to use from a web UI. They can also configure the detailed settings such as sensing interval.For explicit-sensing, AWARE allows the organizer to distribute questionnaires manually.Ohmage [21] supports explicit-sensing, by allowing participants to post reports by themselves. Several report formatsare accepted such as single/multiple selections, free text, multimedia (e.g., photo, sound) and so on. Ohmage also3 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine supplements collected data through implicit-sensing. Specifically, it can be used to record the transportation status(e.g., still, walk, run) of a participant.The other conventional platforms however, tend to focus more on either implicit- or explicit-sensing (as shown inTable 1), and provide limited functionality for the other form of sensing. As mentioned before, the two sensingmethods have many differences such as data type that can be collected, and the data’s features. Thus, with theseplatforms, it is difficult to supplement the collected data due to severe restrictions in sensing functions.In this paper, in order to realize a flexible sensing platform, we aim to provide functions for both sensing methodscomprehensively and support the organizers’ ability to easily choose and combine functions.
Since PMS relies on voluntary participation of ordinary citizens, it is essential to not only focus on acquiring users, butalso on motivating them to continue participating in the sensing tasks, i.e., to support user retention and activation [25].Motivating functions allow the organizer to define the methods for motivating participants. Some of the conventionalplatforms use outside stimuli to support participant motivation and engagement. We classify these outside stimuli asfollows:
Request (F3):
This is urging behavior by explicitly requesting participation. There are many methods of sendingrequests. The most common method is the static/dynamic request, which includes providing a task list,issuing notifications and so on. Other methods such as Audition [17], and Reverse-auction [26, 27] whichpurposely restrict the rights of contribution and make participants scramble to contribute, have also been used.In addition, the willingness-based participant selection [23], which selects the participant for requesting basedon an estimation of the participant’s willingness for sensing task, has been used.
Reward (F4):
In this method, participants are compensated for their contribution through monetary and non-monetaryincentives [28, 29]. The monetary incentive encourages participants to contribute to the system by givingmoney-related value such as in-app currency/points, discount coupons, and gifts. Participants can directlyget explicit value as a consideration for their contribution. It often marks high effectiveness, however, thereare problems related to sustainability of system management [24]. To reduce costs for rewards, the Auctionmechanism [30], and the following non-monetary incentive mechanism can be used. The non-monetaryincentive gives experience (a kind of fun) as compensation for participant’s contribution [31, 32, 33]. Thereare several kinds of experiences such as interaction with other participants, and gamification. The interactionwith other participants induces social facilitation effects that stimulate the participant to contribute moreactively [34] for getting praise from others, e.g., getting more like , more comments . Gamification is themechanism which introduces game elements into a conventional system, and it has been shown to contributeto motivation of participants, and reduction of monetary rewards [35].
Feedback (F5):
This method urges behavior by providing feedback such as a visualization of participants’ contribu-tion on a map, graph or timeline. Sometimes the contributions of other participants are also included in thevisualizations, and sometimes they are excluded.MinaQn [19] uses a recruitment mechanism to grant participants the right to participate in urban planning (contribu-tion to society) as non-monetary incentive. In addition, the platform also visualizes a summary of the participant’scontribution to increase their willingness to continue contributing.Medusa [17] is a platform which utilizes monetary incentives effectively. Medusa can acquire participants by using re-cruitment, which provides money as compensation, and through audition. Furthermore, to retain participants, Medusaadopts the concept of reverse incentive (obligation/responsibility of executing tasks), where workers pay to organizersfor the privilege of performing the task. This can help prevent participants from quitting the system in the middle ofsensing tasks.GP-Selector [23] is a platform that employs a participant selection algorithm by various conditions suitable for sensingtasks. It includes location-based constraints (e.g., geofences), capability-based constraints (e.g., available sensor), andwillingness prediction.In these conventional platforms, functions to motivate participants have a number of shortcomings. For example,with Request functions (F3), in order to increase the number of successful requests, it is necessary to consider thenotification timing and the target participants, but this is not supported. Similarly, with Reward functions (F4), weneed to consider not only monetary incentives, but also
Gamification . In this paper, we consider how to designmotivating functions which incorporate the concepts of interruption through notification and gamification.4 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Table 2:
Overview of platform skill requirements.
Platforms Skill requirementsOrganizer skills Participant skillsR1 R2 R3 R4
Development App distribution App/Func. management Data processing
AWARE [15] As needed *a - Required -Sensus [16] As needed *b - - -Medusa [17] Required Required - -Funf [18] - - Required RequiredMinaQn *c [19] - - - -KOKOPIN app *c [20] - - - -Ohmage [21] - - Required -OpenDataKit [22] As needed *a Required Required RequiredGP-Selector [23] As needed *d - - -ParmoSense - - - - *a Development by programming is needed for extending functions. *b Database server is required for data collection. *c These platforms assume the use of ordinary citizens or administrative officers, hence, technical skills are not required. *d XML-based script coding is needed for making complex participant selection constraints.
In general, organizers intend to analyze or visualize urban environmental data collected with PMS. Hence, PMSplatforms must support easy and quick access to this data. In the processing functions, the organizer defines methodsof data processing to be used. The following functions are implemented in conventional platforms:
Data editing (F6):
This involves data cleansing and labeling, as pre-processing for detail data analysis.
Data browsing (F7):
This involves monitoring the status of data collection and visualizing the collected data.
Data export (F8):
This involves exporting of collected data for more detail analysis and/or visualization with third-party tools. Various exporting format types are supported depending on the purpose such as CSV, JSON,XML and RDB.Funf [18, 36] and OpenDataKit [22] are designed as platforms that mainly focus on data cleansing and visualizing, aswell as exporting. Additionally, these platforms support data processing in a variety of environments such as in thecloud and on the smartphones used for data collection (endpoint devices). Thanks to the various processing functionsin the platforms, many research projects in the world utilize them. Although most of them also support basic functions,there are differences in functions supported by other conventional platforms [15, 19, 21].In this paper, we implement all functions (F6–F8) as in Funf [18, 36] and OpenDataKit [22]. During implementation,we considered how to make the required technical skills for organizers and participants lower. Specific skills neededto operate existing platforms are described in the section below.
In PMS, it is assumed that the organizer may be from a non-technical profession/background, e.g., they may be anadministrative officer or urban planner, and ordinary citizens participate in the data collection. Thus, it is necessary tore-consider the skills required by the PMS platforms for the organizers and participants.Table 2 shows skill requirements for each conventional platform. Development skills (R1) and App distribution skills(R2) are required for organizers, where:
Development skills (R1):
Skills to develop the urban sensing system for the specific purpose.
App distribution skills (R2):
Skills to distribute client applications to participants’ smartphone.AWARE [15], Medusa [17], and OpenDataKit [22] have high extendability like a framework, but a high-level ofprogramming skill is required for system construction (R1). In addition, most of the systems that require system5 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine development also require organizers to have the skills necessary to release applications on official stores such asGoogle Play and AppStore (R2). With web-based platforms such as MinaQn [19] on the other hand, deploying theapplications is quite easy. However, continuously attracting users to the web application is required (R2).App/Function management skills (R3) and Data processing skills (R4) are other skills that are required from partici-pants, where:
App/Func. management skills (R3):
Managing applications and functions such as installation of applications andsetting of functions to accomplish sensing tasks.
Data processing skills (R4):
Processing data collected using the participant’s device before uploading.Since AWARE [15] and Ohmage [21], OpenDataKit [22] have many functions as a platform, the functions are dividedinto multiple applications and provided to participants. Also, Funf [18] requires participants themselves to set up thesensors (e.g., sensing interval) for each smartphone. Therefore, to construct the sensing environment that the organizerintended, knowledge and skills related to applications and functions are required for participants (R3).Funf [18] and OpenDataKit [22] adopt a mechanism where they ask participants to perform data processing andcleansing. Such processing requires knowledge and skill to judge whether data is good or bad, so the burden onparticipants is substantial (R4).Overall, conventional platforms require various skills for both organizers and participants to construct and operate thesystem. To realize PMS systems that can be used by non-technical people, these problems must be addressed. In thisstudy, we propose a new platform to resolve these problems.
We design and implement a novel participatory urban sensing platform,
ParmoSense , to solve the problems mentionedin
Related work section. ParmoSense aims to solve the following key challenges:C1: Limited support of essential functions needed for PMS systems (listed in Table 1)C2: Difficulty of system construction and operationParmoSense allows organizers and participants to operate or contribute to PMS systems without complex proceduresor technical skills.
ParmoSense is based on the following three basic principles.
Principle
ParmoSense must achieve two contradictory requirements, easiness of system construction and diversityof available functions. Therefore, we employ the idea of modularizing functions inspired by existing re-search [15, 21]. ParmoSense provides the sensing, motivating and processing functions in Table 1), and thesecan be combined to form a PMS system.
Principle
Conventional platforms require a high level of technical skills, e.g., programming skills for organizers to cus-tomize the platform for a specific sensing task. In order to deal with multiple purposes flexibly, ParmoSenseis composed as a combination of modularized functions as well as the detailed settings of each function. Weunify the combination and settings as a scenario . A
Scenario contains such information as the scenario name,description, sensing targets, sensing area, period, motivation method, etc. Through GUI-tool in ParmoSense,the organizer can generate the scenario easily. Based on the created scenario, ParmoSense automatically con-figures both a server system and a client application by distributing necessary information. Since scenarioscan be created using any combination of functions and settings, logically, any kinds of PMS system can bebuilt with ParmoSense. Another important advantage of the scenario-based system is that users can partici-pate in various PMS projects through one client application, whereas in the past, each PMS project requireda dedicated application.
Principle
The most effective way of motivating participants depends on the purpose of sensing. To realize sustainableurban environmental sensing, ParmoSense has a
Motivation Engine with a variety of motivation algorithms.The Motivation Engine provides the following functions for motivating participants:6 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Figure 1:
Design concept of ParmoSense. • Motivation based on the behavior of an individual:
Granting incentives according to contribution, Visualization of contribution•
Motivation for all participants, regardless of contribution:
Providing competition mechanisms such as rankings, Sharing of experiences among participantsAdditionally, by considering temporal/spatial information, e.g., the current time and the current position ofthe participant, it is possible to control the actuation timings of these functions. The optimal motivatingalgorithm according to the purpose of the organizer can be incorporated into the PMS system by combiningand customizing these functions.
The architectural design of ParmoSense is shown in Fig 1. ParmoSense consists of three parts that have the followingroles:
ParmoSense Dashboard:
A web application for organizers that can be used to create and distribute scenarios of PMS systems, and toprocess collected data.
ParmoSense Client:
A client application for participants that can run various scenarios. By downloading and installing a scenario,it behaves as the corresponding sensing application.
ParmoSense Server:
A central system for integrated management of the scenarios created by organizers and automatically con-structing a virtual server system for each scenario. It can collect sensing data from ParmoSense Client andgenerate feedback based on the analysis of the collected data.7 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Figure 2:
System architecture of ParmoSense. (a) ParmoSense consists of three components: Dashboard, Server,and Client; (b) Scenario instances are built for each PMS scenario.Arrows in Fig 1 show contents transfered between organizer/participant and ParmoSense Server for each operationphase of PMS. Each phase is defined as follows:i.
Distributing Phase:
The phase for distributing the scenario created by the organizer to the participants viaParmoSense Server.ii.
Sensing Phase:
The phase for giving feedback (e.g., reward) to the contribution of the participant suchas uploading sensing data by participants.iii.
Processing Phase:
The phase for editing, cleansing and visualizing the collected data.Since ParmoSense is based on
Principles mentioned above,organizers can distribute sensing applications bysimply exchanging scenarios with participants in Distributing Phase. It is therefore not necessary for each participantto manage the applications by himself. Furthermore, thanks to
Principle , in Sensing Phase, the feedback formotivating participants is created by the Motivation Engine using the collected data, and automatically provided toparticipants.
The concrete system configuration of ParmoSense is shown in Fig 2. In the following subsections, we will describe theParmoSense Dashboard used by organizer, the ParmoSense Client used by participants, and the ParmoSense Server inmore detail.
An organizer carries out every operation, e.g., management of a PMS scenario, processing of collected data on theParmoSense Dashboard, a web application. It consists of
Scenario tools and
Data tools shown in Fig 2 (a) (cid:13) and (cid:13) respectively.Scenario tools (Fig 2 (a) (cid:13) ) provide many operations such as creating, editing and deleting PMS scenarios, andbrowsing, activating and stopping scenarios. Fig 3 (a) shows the user interface for editing scenarios. The organizercan describe a scenario using the three kinds of functions, sensing, motivating and processing functions, mentioned in8 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Figure 3:
User interface of ParmoSense Dashboard. (a), (b) Scenario tools interface as shown in Fig 2 (a) (cid:13) ;(c), (d) Data tools interface as shown in Fig 2 (a) (cid:13) . Related work section, without programming, through the GUI (
Principles ). The scenario defined in Scenariotools is automatically converted to JSON format, and transferred between each part of ParmoSense.When the scenario editing is completed, the virtual server system is automatically built depending on the scenario,and deployed by
Scenario manager (Fig 2 (a) (cid:13) ). At the same time, the QR code for downloading the scenario toParmoSense Client is automatically generated. Fig 3 (b) shows the user interface for browsing/managing the scenariocreated by organizers. Scenarios currently in progress/stopped are indicated by blue/gray respectively, and thesestatuses and the scenario settings can be changed by using the GUI.Data tools (Fig 2 (a) (cid:13) ) provide the functions for processing and visualizing data aggregated into Data manager (Fig 2(a) (cid:13) ). The user interface for editing the collected data is shown in Fig 3 (c). The organizer can improve the qualityof the data by editing/excluding inappropriate data from the collected data. The organizer can also add labels to thedata. The processed data can be exported in the form of JSON, CSV, RDB etc. The user interface for visualizing thecollected data is shown in Fig 3 (d). The organizer can check the data in two ways: overlaying them on a geographicalmap, or sorting them in a time-series order. The participant performs all sensing tasks of ParmoSense through the ParmoSense Client smartphone application.ParmoSense Client runs on smartphones with Android OS or iOS, and it can be installed from general applicationstores (Google Play, AppStore). Since the behavior of PMS system on ParmoSense is defined by a scenario (
Principle ), it can behave as various sensing applications by installing scenarios to ParmoSense Client.9 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Figure 4:
User interface of ParmoSense Client. (a) Participants can install a PMS scenario via scanning the QRcode; (b) Installed scenarios are listed up for switching scenarios; (c) PMS tasks and participants’ contributions areshown on a map view.Fig 4 (a) and (b) shows the user interface for the scenario installation. The participant performs the following steps inorder to install the application:i. Log in on ParmoSense Client via Google Authentication.ii. Scan the scenario QR code by using their smartphone camera (Fig 4 (a)). An organizer can get QR codes ofscenarios from ParmoSense Dashboard, and print it out for participants.iii. The participant confirms participation in sensing.This procedure makes it easy to install scenarios. All these are done via the
Web API shown in Fig 2 (a) A (cid:13) . Participantscan participate in multiple scenarios. The scenarios that have been installed and performed in the past are listed, asshown in Fig 4 (b). This makes it easy for a participant to join the same scenario again.Fig 4 (c) shows an example of the ParmoSense Client interface after installing the scenario and participating in sensingtasks. Requests of static sensing tasks are shown as pins on the map, and the participants can carry out the task at thisplace and acquire the reward accordingly. The user score is displayed in the upper right area. It is a means of providingfeedback to the participant through gamification and visualization of contributions. The feedback and the executionstatus of tasks are reflected in real time according to the participant’s and other participants’ actions via MQTT Broker shown in Fig 2 (a) B (cid:13) . ParmoSense realizes many-to-many and real-time communication by adopting MQTT (MQTelemetry Transport) [37] as a communication protocol. ParmoSense Server consists of three parts:
Scenario manager , Data manager and
Scenario instances shown in Fig 2(a) (cid:13) , (cid:13) and (cid:13) respectively.Scenario manager plays the role of storing the scenario created on ParmoSense Dashboard, and constructing andmanaging Scenario instance in accordance with the scenario. The Scenario instance is an instance executed on a serverwhich communicates with a ParmoSense Client. By automatically constructing this Scenario instance for each scenarioand forming Scenario instances, various scenarios in ParmoSense can be created without programming. Scenariomanager monitors the operation status of the Scenario instance, and the organizer can start or stop the operation. It alsodetects unexpected troubles in the Scenario instance, and it stops or restarts them. The data collected by participantsis aggregated in Data manager, and this data is used for calculating the participants’ score, visualizing on the map andso on. 10 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Figure 5:
Examples of motivating functions. (a) ParmoSense Client can send a notification to participants for re-questing a PMS task; (b) ParmoSense can provide coupon as monetary incentive; (c) Other participants’ contributionsare shared as a timeline.Fig 2 (b) shows the mechanism of the Scenario instance. Scenario manager builds the Scenario instance by incorporat-ing the module program of corresponding functions (Sensing Functions, Motivating Functions, Processing Functions)based on the scenario that an organizer created. Scenario instance communicates with ParmoSense Client via MQTTas described above. If a participant sends (publish) the sensing data, the corresponding Scenario instance receives(subscribe) the data collected by participant’s smartphone sensors, and processes using modularized functions (e.g.,analysis of data, calculation of ranking) which are described in the scenario. According to these results, response datais generated and published to all participants who should be informed.
ParmoSense comprehensively supports functions investigated in Table 1. In this section, we outline the support statusof each function.
Implicit-sensing (F1):
ParmoSense supports data collection from sensors embedded in smartphones. The types ofsupported sensors are shown below:• Position sensor (e.g., GPS)• Environmental sensors (e.g., light sensor, barometer)• Inertial sensor (e.g., accelerometer, gyroscope)• External sensor device (heart-rate sensor)It also supports data collection of BLE scan logs of peripheral devices (e.g., iBeacon, other smartphones). For all thesesensors, detailed configuration such as measurement interval and enabling/disabling of background measurement canbe set on Scenario editor of ParmoSense Dashboard by the organizer.
Explicit-sensing (F2):
ParmoSense supports various kinds of data collection methods that cannot be collected bysensors embedded in a smartphone. One of them is photo uploading. When taking photos and uploading them, partic-ipants can provide additional data such as explanatory texts of the photo taken, GPS position, and other data obtainedby Implicit-sensing. Questionnaires are also provided. Different question types such as binary questions (YES/NO11 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Table 3:
Preparation Workload for Each Task.
Contents of work Preparation Workload Done by w development (programming) 0, 8 *a organizer w development (GUI editing) 0, 4 *e w publishing to app store 0, 8 *b w installing application 0, 1 *c , 2 *d participant w configuring functions 0, 2 *e *a calculated with LOC of source code. *b calculated based on time for becoming available in general stores. *c installation of single application (reference time). *d installation of multiple application. *e calculated by comparing with w , w and w relatively. question), multiple-choice questions (up to 4 options), and questions that require photo uploads and explanatory text,are supported. These questions can be chained together to support a step-by-step questionnaire. Static/Dynamic request (F3):
ParmoSense supports both static and dynamic requests for soliciting contributions onsensing tasks. In PMS for urban environments, there are many requests based on geographical information. Staticrequests place each task as a checkpoint on a map as shown in Fig 4 (c), which allows participants to easily find thetasks to be performed. For dynamic requests, we support informing participants of task requests through notificationsas shown in Fig 5 (a). Organizers can generate and request tasks from specific participants, for example, by settingthat any person who is detected entering a certain area is notified. Location information can be obtained using regionmonitoring technology such as Geofence and iBeacon.
Monetary/Non-monetary reward (F4):
ParmoSense supports both monetary and non-monetary rewards to compen-sate participants for their contributions. The monetary rewards supported are discount coupons that can be used atrestaurants, cafe and so on, as shown in Fig 5 (b). Since the discount coupon is linked with purchasing behavior,it is effective for motivating participation in scenarios such as sightseeing. For non-monetary rewards, ParmoSensesupports the gamification mechanism. This includes awarding points for a contribution, competition mechanisms suchas comparing a participant’s degree of contribution to that of other participants, and virtual level-up elements by re-peating the contribution. Also, depending on the demand for data collection, monetary/non-monetary rewards can bebiased. For example, the expensive reward can be set for a low upload rate task or high priority task.
Feedbacks by visualization (F5):
ParmoSense also supports feedback not included in game features, for example,visualization of own contributions, and data/experience sharing. Visualization of own contributions is of two types:(i) plotting the pins of contributions on the map and (ii) scoring contributions with the non-monetary rewards detailedabove. In addition, a data sharing function to share/visualize data such as participants’ experiences and what differentparticipants viewed, heard, or sensed (environmental conditions) is provided. For example, ParmoSense can plotsensing data uploaded by other participants on the map and share them on a timeline as shown in Fig 5 (c).
Editing of collected data (F6):
ParmoSense helps organizers to pre-process collected data before detailed analysis.For example, it provides functions such as cleansing unnecessary data, selecting data to be used, and labeling the data.Also, since these data processing functions are designed to protect the original data, it can be restored at any time.
Browsing of collected data (F7):
ParmoSense provides visualization tools for instant and easy confirmation of thecollected data. There are many types of tools such as a tool for plotting data collected by all or each participant on themap, and a tool for displaying all data as a list. These tools can be used at any time even while sensing tasks are inprogress.
Export of collected data (F8):
ParmoSense supports various data output formats. Data analysis data can be output inCSV, JSON, XML, RDB (SQLite), etc., so that analysis can be started immediately. Moreover, when exporting to athird-party visualization tools (e.g., Open Street Map [38], Google Earth [39], Cesium [40]), it is possible to output inKML ( https://developers.google.com/kml/ ) or GPX ( ). ParmoSense has tackled two challenges to be solved: “limited support of essential functions in existing PMS platforms(C1),” and “difficulty of system construction and operation (C2).” In this section, we use the easiness of systemconstruction and operation and the number of functions provided as the metrics, and we evaluate the performance ofParmoSense compared with conventional platforms. 12 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
We evaluated the difference in the development cost and the operation cost of ParmoSense compared to conventionalplatforms [15, 16, 17, 18, 19, 20, 21, 22, 23]. We used the workload cost for starting operation of the system (Prepara-tion Workload) as the metric of comparison. The definition of Preparation Workload is as follows:Preparation Workload ( W ) ✓ ✏ Preparation Workload ( W ) is the total time required from the start of developing the PMS system to the start ofsensing tasks, which is calculated by the sum of sub tasks (Eq. 1). T = X i =1 w i (0 ≤ W ) (1)Where w ∼ w is the relative estimated time required for each task, as shown in Table 3. As reference, wedefined the time required to install one application from a general application store, e.g., Google Play or AppStoreas w x = 1 . ✒ ✑ The estimated Preparation Workload on each platform is shown in Table 4 and the x-axis of Fig 6. The filled circle( • ) represents the case where the simplest system on each platform was constructed. AWARE [15], Medusa [17],OpenDataKit [22] and GP-Selector [23] can be extended by programming as necessary. However, w will increaselinearly with the development of functionality.Therefore, ParmoSense belongs to the group which needs low Preparation Workload, and can be operated as easilyas other platforms in the same group. Also, conventional platforms [15, 17, 22, 23] suffer from the problem wherethe time required for expansion tends to be long when trying to extend the systems’ functionalities. In contrast,ParmoSense is designed to cover the necessary functions in advance, and thus, although Preparation Workload requiredis equivalent to other platforms, it achieves higher functionality. We evaluated the diversity of functions that ParmoSense provides, compared to conventional platforms [15, 16, 17, 18,19, 20, 21, 22, 23]. As a metric for comparison, we use the following fulfillment status of functions (Function Score):Function Score ( S ) ✓ ✏ Table 1 shows all the functions supported by each of the existing PMS platforms. The score of each function s ∼ s is determined by the implementation status of each function (F1 ∼ F8) of Table 1, and Function Score( S ) is calculated by the sum of them (Eq. 2). S = X i =1 s i (0 ≤ S ≤ (2) s i = if F [ i ] = X . if F [ i ] = △ otherwise ✒ ✑ The estimated Function Score on each platform is shown in Table 4 and the y-axis of Fig 6. While conventionalplatforms have moderate scores ( S = 4 ± ), ParmoSense has a higher score ( S = 8 ) due to comprehensivelysupporting all the functions provided in existing platforms, and incorporating motivating functions, which are missingon all existing platforms. Furthermore, the advantage of ParmoSense will be even higher if we consider the effectbrought by the combination of these functions. For example, ParmoSense can provide combinations of multiplemotivating functions, such as gamification, rewards, and interruptions, which can not be provided on other existingplatforms, and which may be more effective than using a single motivating strategy/function, since they cater for moreparticipant preferences. 13 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Table 4:
Breakdown of Preparation Workload ( W ) and Function Score ( S ). Platforms Preparation Workload Function Score w w w w w W S
AWARE [15] - *a *a - 8 1 - 17 3.5Funf [18] - - - 1 2 3 4.5MinaQn [19] - 4 - - - 4 3.5KOKOPIN app [20] - 4 - 1 - 5 4Ohmage [21] - - - 2 2 4 5OpenDataKit [22] - *a *a *a Additional time is required for developing the new functionalities.
Figure 6:
Comparison graph.
We conducted 19 case studies with ParmoSense over four years. Prior to the evaluation, we released ParmoSense togeneral application stores (Google Play, AppStore). We collaborated with various organizers to design and build 19scenarios, and then deployed them via the client application. Members of the general public who had downloaded theapplication acted as participants.Our aim in doing these case studies was two-fold. First, we wanted to validate that our implementations of the sensing,processing and motivating functions on ParmoSense would work well in real world PMS tasks. Second, we wantedto determine how effective the functions were in motivating participation and in supporting organizers to collect14 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine required data and to extract the required information. Such knowledge would allow us to improve the functions, orto recommend additional functions to be included in PMS systems. Table 5 shows the details of each scenario (startdate, period, number of participants, and embedded functions). In following subsections, we discuss the sufficiency ofParmoSense functions in each scenario.
We categorize case studies into four groups according to the type of sensing tasks involved and provide an overviewof each group in this section. We then describe how well the ParmoSense functions performed for each scenario.
Urban-data collection during workshops (S1–S6):
S1–S6 are scenarios for workshop-style events, such as aMapping-party [44, 45, 46], which is widely used in organizations such as OpenStreetMap. The overview of eachscenario is as follows:
Scenario S1–S2 (Mapping-party)
These scenarios were aimed at collecting unmapped geographical data. In this event, we collected informationon trees (names and positions) in our university campus.
Scenario S3 (FixMyStreet)
This scenario was for collecting dynamic geographical data such as road breakages, graffiti, and street lampfailures by imitating the mechanism on FixMyStreet [14].
Scenario S4–S6 (Urban-planning)
These scenarios involved surveying existing POIs such as local buildings, public facilities, and nature, forurban planning.Through the deployment of these scenarios, we obtained the following knowledge:• Because participants were willing to attend the event by themselves, we confirmed that the set of motivatingfunctions on ParmoSense are enough for getting sufficient contributions from the general public.• The following functions of processing functions worked effectively: – Data labeling function – Cleansing function for unnecessary data – Automatic mosaic function by face recognition – Data export function
Urban-data collection during sightseeing (S7–S11):
S7–S9 are scenarios for sightseeing PMS, e.g., with an informa-tion sharing tool for tourists, or an urban sensing system mimicking a tourist guide. The overview of each scenario isas follows:
Scenario S7 (Experience-sharing)
This scenario involved sharing discovered sightseeing spots among a group of tourists. To encourage positiveposting among participants, we used points as the motivating function (F4).
Scenario S8 (Tourist-guidance)
This scenario involved collecting data such as photos and behavior logs from tourists, while providing sight-seeing information through a virtual tour guide [41]. We provided a data editing function (F6) for organizersto edit collected data after the event.
Scenario S9–S11 (Multi-type-requests)
The scenario was for comprehensively collecting environmental data of sightseeing spots, by requesting it invarious ways from tourists. To encourage active contribution of participants, we provided all the availablemotivating functions such as static/dynamic request (F3), points and coupons (F4). Fig 7 shows Screenshotsof ParmoSense Client which are providing motivating functions including the dynamic points controls basedon the demand for sensing tasks. Fig 8 visualizes participants’ trajectories when they use ParmoSense whichhas/does not have motivating functions (F4). The area marked with dashed lines shows motivating functions(weighted points) effectively work to change user’s behaviors by dynamically weighting points which canbe earned. It suggests motivating functions in ParmoSense could contribute to solving the spatio-temporalcoverage issue of general PMS systems. The detail analysis of these case studies (S9 and S10) are providedin our other papers [42, 43]. 15 a t s ud ae t a l . P a r m o S e n s e : A S ce n a r i o - b a s e d P a r ti c i p a t o r y M ob il e U r b a n S e n s i ng P l a t f o r m w it h U s e r M o ti v a ti on E ng i n e Table 5:
Overview of Case Studies.
ScenarioNo. Functions Start date Period Number ofparticipantssensing functions motivating functions processing functionsF1 F2 F3 F4 F5 F6 F7 F8
Implicit Explicit Request Reward Feedback Editing Browsing Export S1 X X X X X
Feb. 9th, 2016 0.5 hours 15S2
X X X X X X
Feb. 17th, 2018 1 day 9S3
X X X X X
June 1st, 2016 0.5 hours 17S4
X X X X X X
Dec. 17th, 2016 2 days 14S5
X X X X X X
June 8th, 2017 1 day 6S6
X X X X X X
June 10th, 2017 1 day 20S7
X X X X X X
June 5th, 2016 2 days 19S8 [41]
X X X X X X X
Nov. 22nd, 2016 3 days 14S9 [42]
X X X X X
Nov. 26th, 2017 1 day 30S10 [43]
X X X X X
Jul. 29th, 2020 1 day 10S11
X X X X X
Oct. 5th – Nov. 4th, 2020 1 day/person 108S12
X X X X X
Jan. 21st, 2016 10 days 12S13
X X X X
Apr. 20th, 2017 14 days 83S14
X X X X X X X
Mar. 12th, 2016 1 day 10S15
X X X X X X
Nov. 13th, 2016 1 day 48S16
X X X X X X X
Feb. 25th, 2017 1 day 25S17
X X
June 11th, 2017 2 days 18S18
X X
July 24th, 2017 4 hours 100S19
X X
Sept. 24th, 2017 6 hours 200 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Figure 7:
A photo of participant and screenshots of ParmoSense Client in Scenario S9.
Figure 8:
User’s trajectories with/without motivating functions in Scenario S9.
Through these case studies, we observed the following on the effectiveness of the implemented functions for scenariosbelonging to this category:• In the case of sightseeing, motivating functions were essential because tourists participated in the scenarioopportunistically.• Collecting factors, e.g., points and sharing information with each other, were more effective than the competi-tive factors, e.g., score and ranking, at motivating participant’s continuous participation because “sightseeing”was their primary purpose and collecting factors were more relevant.17 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Figure 9:
Result of human-behavior investigation in Scenario S15.
Urban-data collection in daily life (S12–S13):
The data suitable for collecting by PMS are often “continuous” and“long-term” data, because PMS is a sustainable sensing mechanism to realize comprehensive spatio-temporal datacollection without any infrastructure due to the use of the many mobile devices dispersed in the city. S12 and S13were scenarios for collecting such long-term and continuous data. The overview of each scenario is as follows:
Scenario S12 (Static-request)
This scenario was for periodically collecting information that changes day by day, e.g., bulletin board infor-mation at a facility, and temperature of a place. To encourage participation, we set a limit on the number ofparticipant contributions resulting from static requests (F3) that would be accepted, which is similar to theAudition mechanism [17].
Scenario S13 (Dynamic-request)
This scenario was for conducting questionnaires linked to location information by interrupting participants.Push notifications were used, and participants’ location and behavior were taken into consideration, to providedynamic requests (F3). No maps, rewards, or visualizations were included.Through the case studies involving these scenarios, we concluded the following regarding the effectiveness of Par-moSense functions intended for urban-data collection in daily life:• In the case of S12, due to the use of static requests through placing pins on a map, the achievement of sensingdepended on the active and continuous contribution of participants themselves. The following functionsworked efficiently when motivating contribution: – Virtual rewards (e.g., point, ranking, level) – Monetary incentives – Visualization of contributions of the participant and of other participants• Restricting the number of contributions on static requests was effective for encouraging continuous participa-tion because it prevented point inflation, but it also caused the leaving of some participants.• In the case of S13, we found that contribution of participants improved when the timing of requests was basedon participant’s location and behavior, e.g., participants were more likely to respond to requests if the locationof the sensing task was near to their present location.
Human-behavior investigation on events (S14–S19):
ParmoSense can not only collect urban environmental data, butalso data of “people” existing in the city. S14–S19 were scenarios created for investigating human behavior duringvarious situations: events, daily life, sightseeing and so on. The overview of each scenario is as follows:
Scenario S14–S16 (Stamp-rally)
These scenarios was for investigating the behavior of people who participate in the electronic “stamp rally”which is a process where visitors are instructed to go around to certain places, events etc. location [47]. A18 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine physical (electronic) stamp is put in a predetermined place, and when a visitor arrives, a stamp is stuck ona sheet (application). Reward is given based on the number of stamps accumulated. The rewards includecoupons, prizes, points and ranking as non-monetary/monetary rewards (F4). We provided a data browsingfunction for visualizing participants’ behavior (F7). Fig 9 shows examples of visualization of participants’behavior.
Scenario S17 (Sightseeing)
This scenario was for collecting participants’ movement data linked with the location information, to inves-tigate the participants’ behavior tendencies during sightseeing. To continuously sense tourists’ behavior, weused an implicit sensing function that ran in the background (F1).
Scenario S18–S19 (w/external-sensor)
These scenarios was used to collect participants’ movement and heart rate data linked to location information,to be used to construct a database for human behavior analysis. We added a function to connect a wearablesensor to external sensors (F1) via BLE, for collecting data.Through these case studies, we learned the following about PMS for human-behavior investigation:• To analyze the behavior of a person, there is a need to visualize behavior logs in various ways. We found thatthe functions provided by ParmoSense such as GPS trace, and Chord diagram listings worked effectively.• Since these scenarios were aimed at sensing of human behavior affected by the specific function, it wasnecessary to suppress interference of elements, which is except for the function to be evaluated, to people.We confirmed that ParmoSense can minimize the number of unnecessary functions because of module-baseddesign.• It is sometimes necessary to collect data with high frequency over a long term (S18 and S19 were scenariosthat required acquiring the 9-axis sensor data at 100 Hz over several hours). In this case, we found thatfunctions such as continuous data acquisition in the background worked efficiently.
In the following sections, we summarize and discuss the results of the subjective surveys held in each case study. Weasked each participant and organizer questions about the usability and performance of ParmoSense.
Participants in nine scenarios (S2, S4–S6, S9, S13–S16) were given the questionnaire. These scenarios had manyordinary citizens participating, and include at least one motivating function. The total number of participants whoanswered the questionnaire was 201. About 70% of participants were in their 20s, however, various age groupsranging 10s to 80s were targeted. Attributes of participants are listed below:• Citizens living in the local area, men and women of all ages (S2, S4, S15–S16)• Undergraduate students majoring in architectural engineering in their 20s (unfamiliar with the informationscience) (S5, S6)• Graduate students majoring in information science (S9, S13)We also distributed questionnaires to the organizers of five scenarios (S2, S4–S6, S9). The skills of the organizersvaried from those with high IT skills like IT engineer to those with low IT skills like students majoring in fields otherthan IT. The attributes of the organizers are listed below:• Employee of regional public facility (S2)• IT engineer (S4)• Undergraduate students majoring in architectural engineering (S5, S6)• Graduate students majoring in information science (S9)
To evaluate the usability of ParmoSense Client, we asked participants the questions which are listed in Table 6. weasked Q1 ( “Was ParmoSense Client easy to use?” ) with a 5-point Likert scale (5: very easy to use – 1: very hard to19 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine Table 6:
Questionnaire items for participants and non-participants (S2, S4–S6, S9, S13–S16).
ItemNo. Questionnaire Detail Answer1 2 3 4 5 Average (disagree) (agree) Q1 Was ParmoSense Client easy to use? (S2, S4–S6, S9, S13–S16) (5.0%) (11.9%) (45.6%) (21.9%) (15.6%) Q2 Why did you think so about the answer to Q1 ? (S2, S4–S6, S9, S13–S16) (Open-ended question) - Q3 Was the event using ParmoSense fun? (except S13) - 4 14 42 43 4.2 (0.0%) (3.9%) (13.6%) (40.8%) (41.7%) Q4 Why did you think so about the answer to Q3 ? (except S13) (Open-ended question) - Q5 What factors will encourage you toparticipate in experiments? (Non-participants ofS13) (Open-ended question) -use), and then asked for the reason in Q2 . The total number of answers was 196. The breakdown of answers is shownin Table 6. The average score was 3.4 and about 40% of participants answered “easy to use.” Participants who answered “easy to use” had the following to say:• “We could operate intuitively because of simple application design.” (S4, S6, S16)• “Map visualization function is helpful for understanding the collected data having position information.” (S4,S5, S6)Those who answered “hard to use” gave the following comments:• “It was difficult to use ParmoSense application because I was not used to smartphones.” (S4, S15)• “ParmoSense application was not suitable for long-term use because this application consumes battery morethan expected.” (S4, S5, S6)• “Unused functions should be invisible.” (S13)Overall, we found that using ParmoSense was easy for participants who use smartphones on a daily basis regardlessof age. In the case of local events where elderly persons also attended, some seniors felt that it was difficult to usea smartphone. However, this is not a particular problem of ParmoSense. As the use case diversifies, the informationdisplayed on the screen also diversifies. Thus, to solve this issue without programming skills, it is necessary to modu-larize the screen configuration of the application and also to enable screen layout design in Scenario tools accordingto the use case.Next, we asked Q3 ( “Was the event using ParmoSense fun?” ) with a 5-point Likert scale (5: very fun – 1: not funat all) in target scenarios except for S13. Additionally, we also asked Q4 to solicit free responses from participantson how motivating functions such as Reward and Visualization affected their sensing behavior. The total number ofanswers was 103. The breakdown of answers is shown in Table 6. The average score from the responses was 4.2 andabout 80% of participants answered “fun.” In Q4 , we obtained the following comments:• “It is pleasant to see the behavior of other people and other groups by checking the pins on the map andtimeline in real time.” (S4, S12)• “Ranking function and leveling function makes it fun and encouraging.” (S4, S5, S9)• “This application increased the fun of the stamp rally.” (S15, S16) We also provided questionnaires to non-participants in the free participation scenario (S13) in order to explore thereasons why they did not participate in the sensing tasks. 20 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine
Table 7:
Questionnaire items for organizers (S2, S4–S6, S9).
ItemNo. Questionnaire Detail Answer1 2 3 4 Average (disagree) (agree) Q6 Was ParmoSense easy to introduce to the event? - - 3 2 3.4 Q7 Could you collect the desired data? - - 1 4 3.8 Q8 Were participants’ motivation for attending to events im-proved by using ParmoSense? (e.g., ranking, coupons) - - 3 2 3.4 Q9 Was Data tools easy to use? - 1 2 2 3.2
Q10
Were the data outputted by the data output function easyto use secondary diversion and data processing? - 1 3 1 3.0
Q11
Do you want to use ParmoSense again in future similarevents? - - 2 3 3.6
Q12
Why did you think so about the answer to
Q11 ? (Open-ended question) -In scenario S13, 35 of 118 candidates did not respond to the request to attend our experiment. We asked these 35non-participants the open-ended question Q5 ( “What factors will encourage you to participate in experiments?” ). Thefactors that promoted participation were related to ease of participation (17 people), battery consumption concerns(10 people), rewards (13 people), and benefit or convenience (12 people) respectively. Furthermore, four people wereconcerned about privacy, such as “requiring personal information (e.g., e-mail address)” and “cannot be anonymous.” Almost half of the non-participants pointed out that the number of steps they needed to take in order to participatewas inconvenient. To minimize the steps to participate in multiple scenarios, we first required participants to installParmoSense Client. After installing the application, participants read a QR code of each scenario in order to participatein that particular scenario. However, people who participated in only one scenario felt that this is complicated and thathaving a single, pre-configured application for a specific scenario might be easier.Also, to make the registration and login process easier, we adopted Google Authentication (using Gmail address) andsupported auto-login. This is a standard method used in many applications. However, some participants felt that ourapplication could collect private data such as the e-mail address. In the future, we aim to address this by introducingan anonymous participation mode that does not require participant registration.
To evaluate the effect of ParmoSense from the view of organizers and the usability of processing functions, we con-ducted a questionnaire with organizers. The questions for organizers are listed in Table 7. Q6 – Q11 were answered with4-point Likert scales (4: strongly agree – 1: strongly disagree),
Q12 was a free-response question.To evaluate the organizer’s burden indicated in Fig 1 – Distributing-phase, we asked about Q6 (Ease of creating anddistributing scenarios) to organizers. Two people answered “4” and the other three answered “3,” giving an averagescore of 3.4. Although the IT skills of the organizers were quite different, all of them felt that ParmoSense was easyto use for PMS.Next, we asked Q7 (Whether they were able to collect desired data) and Q8 (Performance of motivating function),to get feedback from organizers about Fig 1 – Sensing-phase. Four organizers answered “4” and one answered “3”in Q7 , while two answered “4” and the other three answered “3” in Q8 . Consequently, we can say that ParmoSenseallows organizers to collect desired data and to motivate participants to contribute the sensing continuously, from aorganizer’s objective perspective.To evaluate Fig 1 – Processing-phase, we asked the organizers about the Q9 (Usability of Data tools) and Q10 (Avail-ability of output data). Two organizers answered “4” and two answered “3” and another organizer answered “2” for Q9 , while one organizer answered “4” and three answered “3” and other one answered “2” for Q10 . The averagescores were 3.2 and 3.0 for Q9 and Q10 , respectively. According to these results, we can confirm that the Data tools ofParmoSense work substantially fine.Additionally, we interviewed the organizers who answered “2” in Q9 and Q10 , respectively. The organizer whoseanswer for Q9 is “2” said “Unexpected data was downloaded when exporting data for each tag after tagging data.” Therefore, as an additional question, we asked “Is it easy to use if data could be successfully downloaded?,” and we21 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine got the answer “I think so.”
This shows that although it is necessary to improve the flexibility in the export function,it seems that the usability of Web editor meets specific service standards. Next, the organizer whose answer for
Q10 is “2” said “When doing Web visualization, the operation became heavy and the PC froze many times.”
About 700photos were collected in this organizer’s event. This data amount was too large to display all photos at once. In thefuture, it is necessary to set an upper limit on the number of photos that can be displayed, or reduce the image sizeaccording to the number of images before uploading.Finally, three organizers answered “4”, two answered “3” in
Q11 (Whether to use ParmoSense again). When we askedthe reason in
Q12 , the following answers were obtained:• “It can find places where the participants are interested in.” • “It can easily collect data with location information and can edit detailed information later. In addition, byvisualizing the data, participants can understand how the data is used intuitively.” From these results, we found that ParmoSense is useful for human-behavior analysis and feedback of results to partic-ipants and it is easy to edit data.
Demands for the assessment of the urban environments through PMS systems are spread not only in the informationscience field, but also in a wide range of areas, such as urban planning and public services. In such areas, organizersare not always familiar with information technology. Therefore, ParmoSense was designed to serve as a useful tool tocollect the urban environmental information easily and flexible regardless of organizers’ IT skills. ParmoSense allowsorganizers to construct, distribute, and introduce various types of PMS system for various purposes by modularizingfunctions and describing combinations and settings as “scenario.” In PMS systems that involve ordinary citizensfor collecting data, motivating participants is also important for continuous system operation. Thus, ParmoSensesupported several motivating functions as an incorporated feature, which was not supported on conventional platforms.Through performance comparison in the perspective of varieties of functions and preparation workload with existingPMS platforms, we confirmed ParmoSense shows the best cost-performance. In addition, through 19 case studies overfour years, we confirmed that ParmoSense could be compatible flexibly with various sensing tasks, motivate methods,and data processing. Moreover, ParmoSense can suppress the burden of organizers and participants in system opera-tion, and we found that it has higher cost performance than any conventional platforms. On the other hand, we alsofound ParmoSense has not been a “magic bullet” solution that can be used in every situation. ParmoSense shouldimprove privacy and security by allowing organizers to control them based on the sensing purpose. In addition, to op-erate scenarios that involve a more significant number of participants, robustness and scalability should be guaranteedbased on distributed processing and prediction of score update and so on.
This research was funded by JST PRESTO (JPMJPR2039) and JSPS KAKENHI (JP19K24345 and JP19H01139).
References [1] J. A Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, and M. B Srivastava. Participatorysensing.
Center for Embedded Network Sensing , 2006.[2] Andrew T Campbell, Shane B Eisenman, Nicholas D Lane, Emiliano Miluzzo, and Ronald A Peterson. People-centric urban sensing. In
Proceedings of the 2nd annual international workshop on Wireless internet , page 18.ACM, 2006.[3] Eric Paulos, R Honicky, and Ben Hooker. Citizen science: Enabling participatory urbanism.
Urban Informatics:Community Integration and Implementation , 2008.[4] Shigeya Morishita, Shogo Maenaka, Nagata Daichi, Morihiko Tamai, Keiichi Yasumoto, Toshinobu Fukukura,and Keita Sato. Sakurasensor: Quasi-realtime cherry-lined roads detection through participatory video sensingby cars.
Proc. UBICOMP ’15 , pages 695–705, 2015.[5] K Konis and M Annavaram. The occupant mobile gateway: a participatory sensing and machine-learning ap-proach for occupant-aware energy management.
Building and Environment , 118:1–13, 2017.22 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine [6] C. R. De Rolt, R. Montanari, M. L. Brocardo, L. Foschini, and J. da Silva Dias. Collega middleware for themanagement of participatory mobile health communities. In , pages 999–1005, June 2016.[7] Scott Heggen. Integrating participatory sensing and informal science education. In
Proceedings of the 2012 ACMConference on Ubiquitous Computing , UbiComp ’12, pages 552–555. ACM, 2012.[8] Kok-Leong Ong, Simone Leao, and Adam Krezel. Participatory sensing and education: Helping the communitymitigate sleep disturbance from traffic noise.
International Journal of Pervasive Computing and Communications ,10(4):419–441, 2014.[9] Yuki Matsuda and Ismail Arai. A safety assessment system for sidewalks at night utilizing smartphones’ light sen-sors. In
Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing:Adjunct Publication , pages 115–118. ACM, 2014.[10] Eiman Kanjo. Noisespy: a real-time mobile phone platform for urban noise monitoring and mapping.
MobileNetworks and Applications , 15(4):562–574, 2010.[11] Nicolas Maisonneuve, Matthias Stevens, and Bartek Ochab. Participatory noise pollution monitoring usingmobile phones.
Information Polity , 15(1):51, 2010.[12] Diego Mendez, Alfredo J Perez, Miguel Labrador, Juan Jose Marron, et al. P-sense: A participatory sensing sys-tem for air pollution monitoring and control. In
Pervasive Computing and Communications Workshops (PerComWorkshops), 2011 IEEE International Conference on , pages 344–347. IEEE, 2011.[13] Yu Zheng, Furui Liu, and Hsun-Ping Hsieh. U-air: When urban air quality inference meets big data. In
Pro-ceedings of the 19th ACM SIGKDD international conference on Knowledge discovery and data mining , pages1436–1444. ACM, 2013.[14] FixMyStreet.org. FixMyStreet Platform. http://fixmystreet.org/ , 2018.[15] Denzil Ferreira, Vassilis Kostakos, and Anind K Dey. Aware: mobile context instrumentation framework.
Fron-tiers in ICT , 2(6):1–9, 2015.[16] Haoyi Xiong, Yu Huang, Laura E. Barnes, and Matthew S. Gerber. Sensus: A cross-platform, general-purposesystem for mobile crowdsensing in human-subject studies. In
Proceedings of the 2016 ACM International JointConference on Pervasive and Ubiquitous Computing , UbiComp ’16, pages 415–426. ACM, 2016.[17] Moo-Ryong Ra, Bin Liu, Tom F. La Porta, and Ramesh Govindan. Medusa: A programming framework forcrowd-sensing applications. In
Proceedings of the 10th International Conference on Mobile Systems, Applica-tions, and Services , MobiSys ’12, pages 337–350. ACM, 2012.[18] Nadav Aharony, Wei Pan, Cory Ip, Inas Khayal, and Alex Pentland. Social fMRI: Investigating and shapingsocial mechanisms in the real world.
Pervasive and Mobile Computing , 7(6):643–659, 2011.[19] Mina Sakamura, Tomotaka Ito, Hideyuki Tokuda, Takuro Yonezawa, and Jin Nakazawa. Minaqn: Web-basedparticipatory sensing platform for citizen-centric urban development. In
Adjunct Proceedings of the 2015 ACMInternational Joint Conference on Pervasive and Ubiquitous Computing and Proceedings of the 2015 ACM In-ternational Symposium on Wearable Computers , UbiComp/ISWC’15 Adjunct, pages 1607–1614. ACM, 2015.[20] M. Mishima, T. Matsumoto, S. Takano, and O. Matsuda. Kokopin app: A mobile platform for biogeography. In
Proceedings of the 2nd ACM International Workshop on Multimedia Analysis for Ecological Data , MAED ’13,pages 35–40. ACM, 2013.[21] H. Tangmunarunkit, C. K. Hsieh, B. Longstaff, S. Nolen, J. Jenkins, C. Ketcham, J. Selsky, F. Alquaddoomi,D. George, J. Kang, Z. Khalapyan, J. Ooms, N. Ramanathan, and D. Estrin. Ohmage: A general and extensibleend-to-end participatory sensing platform.
ACM Transactions on Intelligent Systems and Technology , 6(3):38:1–38:21, 2015.[22] Waylon Brunette, Mitchell Sundt, Nicola Dell, Rohit Chaudhri, Nathan Breit, and Gaetano Borriello. Opendata kit 2.0: Expanding and refining information services for developing regions. In
Proceedings of the 14thWorkshop on Mobile Computing Systems and Applications , HotMobile ’13, pages 10:1–10:6. ACM, 2013.[23] Jiangtao Wang, Yasha Wang, Leye Wang, and Yuanduo He. Gp-selector: a generic participant selection frame-work for mobile crowdsourcing systems.
World Wide Web , 21:759–782, 2017.[24] Yutaka Arakawa and Yuki Matsuda. Gamification mechanism for enhancing a participatory urban sensing: surveyand practical results.
Journal of Information Processing , 24(1):31–38, 2016.[25] Gamification Co. Gamification pitfalls: Badge fatigue and loyalty backlash. ,2012. 23 atsuda et al. ParmoSense: A Scenario-based Participatory Mobile Urban Sensing Platform with User Motivation Engine [26] Francesco Restuccia, Sajal K Das, and Jamie Payton. Incentive mechanisms for participatory sensing: Surveyand research challenges.
ACM Transactions on Sensor Networks , 2015.[27] L. G. Jaimes, I. Vergara-Laurens, and M. A. Labrador. A location-based incentive mechanism for participatorysensing systems with budget constraints. In , pages 103–108, 2012.[28] Hui Gao, Chi Harold Liu, Wendong Wang, Jianxin Zhao, Zheng Song, Xin Su, Jon Crowcroft, and Kin KLeung. A Survey of Incentive Mechanisms for Participatory Sensing.
IEEE Communications Surveys Tutorials ,17(2):918–943, 2015.[29] R. I. Ogie. Adopting incentive mechanisms for large-scale participation in mobile crowdsensing: from literaturereview to a conceptual framework.
Human-centric Computing and Information Sciences , 6(1):24, 2016.[30] Ioannis Krontiris and Andreas Albers. Monetary incentives in participatory sensing using multi-attributive auc-tions.
International Journal of Parallel, Emergent and Distributed Systems , 27(4):317–336, 2012.[31] Gabe Zichermann and Christopher Cunningham.
Gamification by design: Implementing game mechanics in weband mobile apps . O’Reilly Media, Inc., 2011.[32] Sebastian Deterding, Dan Dixon, Rilla Khaled, and Lennart Nacke. From game design elements to gamefulness:defining gamification. In
Proceedings of the 15th International Academic MindTrek Conference: EnvisioningFuture Media Environments , pages 9–15. ACM, 2011.[33] Fabian Groh. Gamification: State of the art definition and utilization.
Institute of Media Informatics UlmUniversity , 39, 2012.[34] Yufeng Wang, Xueyu Jia, Qun Jin, and Jianhua Ma. Mobile crowdsourcing: framework, challenges, and solu-tions.
Concurrency and Computation: Practice and Experience , 29(3):e3789, 2016. e3789 CPE-15-0470.R1.[35] Yoshitaka Ueyama, Morihiko Tamai, Yutaka Arakawa, and Keiichi Yasumoto. Gamification-based incentivemechanism for participatory sensing. In
Pervasive Computing and Communications Workshops (PerCom Work-shops), 2014 IEEE International Conference on , pages 98–103, 2014.[36] MIT Media Lab. Funf - open sensing framework. http://funf.org/ , 2017.[37] OASIS. MQTT.org. http://mqtt.org/ , 2014.[38] OpenStreetMap Foundation. OpenStreetMap. , 2018.[39] Google LLC. Google Earth. , 2018.[40] Cesium. CesiumJS. https://cesium.com/cesiumjs/ , 2018.[41] Masato Hidaka, Yuki Kanaya, Shogo Kawanaka, Yuki Matsuda, Yugo Nakamura, Hirohiko Suwa, Manato Fuji-moto, Yutaka Arakawa, and Keiichi Yasumoto. On-site trip planning support system based on dynamic informa-tion on tourism spots.
Smart Cities , 3(2):212–231, 2020.[42] Shogo Kawanaka, Yuki Matsuda, Hirohiko Suwa, Manato Fujimoto, Yutaka Arakawa, and Keiichi Yasumoto.Gamified participatory sensing in tourism: An experimental study of the effects on tourist behavior and satisfac-tion.
Smart Cities , 3(3):736–757, 2020.[43] Shogo Kawanaka, Juliana Miehle, Yuki Matsuda, Hirohiko Suwa, Keiichi Yasumoto, and Minker Wolfgang.Design and evaluation on task allocation interfaces in gamified participatory sensing for tourism. In
Proceedingsof the Workshop on Artificial Intelligence for Mobile and Ubiquitous Communication System , MobiQuitous ’20,page 1–6. ACM, 2020.[44] M. Haklay and P. Weber. Openstreetmap: User-generated street maps.
IEEE Pervasive Computing , 7(4):12–18,Oct 2008.[45] Desislava Hristova, Giovanni Quattrone, Afra Mashhadi, and Licia Capra. The life of the party: Impact of socialmapping in openstreetmap. In
International AAAI Conference on Web and Social Media , pages 234–243, 2013.[46] Peter Mooney, Marco Minghini, and Frances Stanley-Jones. Observations on an openstreetmap mapping partyorganised as a social event during an open source GIS conference.
IJSDIR , 10, 2015.[47] FaithCreates Inc. Rally. https://rallyapp.jp/en/https://rallyapp.jp/en/