Citizen engagement with iFLUX

The goal of iFLUX is to enable the rapid development of applications that integrate heterogenous sources of information. While we are doing a lot of work on the IoT/WoT front, by integrating all sorts of physical sensors and actuators, we are also interested in software-generated event streams (i.e. sensors that capture activity in a software system) and human-generated event streams.

In this article, we look at the use case of applications that foster citizen engagement, by making it possible and easy for people to raise issues and give feedback to local authorities. To illustrate the point, think of a mobile app that city inhabitants could use to report a broken streetlight, a dangerous crossroad or a critical situation. In iFLUX terms, citizen become event sources (the mobile app is a user agent that provides an interface to the system). Every issue raised by a citizen becomes an event, that can trigger actions based on configured rules.

As a matter of fact, there are quite a few initiatives for deploying this type of service. The Open 311 standard as even been specified to address the requirements of location-based collaborative issue tracking. Various software platforms, such as FixMyStreet and Shareabouts have been implemented and deployed in a number of cities across the world (see the two screenshots below).

Many things could be done to illustrate the relationship between iFLUX and citizen engagement platforms. One idea would be to modify one of the existing platforms (there are GitHub repos both for the FixMyStreet and the Shareabouts platforms) and to send iFLUX events whenever an issue is reported or updated. It would then be possible to define an iFLUX rule to trigger various actions, such as sending a notification in a Slack channel or updating some kind of metric. Another idea would be to consider the platform as an iFLUX action target. In this model, the idea would be to combine human-generated issues with machine-generated issues (sensors could report issues in the system).

What we have decided to do as a first step is to design and implement a very basic collaborative location-based issue tracking system, which we then use primarily as an event source. One reason for making this choice was to create a bridge between the iFLUX project and two courses that we are teaching at the University of Applied Sciences Western Switzerland.

BUILDING A PROTOTYPE WITH STUDENTS

CONTEXT: MOBILE WEB SERVICES COURSE

Since a few years, we teach a bachelor level course entitled Mobile Web Services. It consists of two different parts:

In the first part, we introduce the concepts of RESTful architectures and look at the design of REST APIs. We then focus on the implementation of the specified REST API, until now on top of the Java EE platform. Students get exposure to standard APIs, including JAX-RS, EJBs and JPA.
In the second part, we study how mobile apps can use the REST API. The course starts with a practical introduction to mobile development. In the past, we have mostly used android for that purpose. We show students how to use platform APIs to access device features (location, camera, etc.).

Until last year, the course was taught as a two-weeks block course. This gave enough time for the students to define and implement a small project, which was providing a connection between the back-end and front-end components. We like for students to come up with their own ideas and to define the functional specs of their projects. So, in general, we provide them with a common theme and ask them to make a proposal that fits within this context:

one year, we have worked on gamification. Students first had to design and implement a REST API for a generic gamification engine, then to implement a mobile app that would use this API in the domain of their choice (education, health and fitness, etc.).
Another year, the theme was photo sharing. Students first had to implement a REST API that would allow the upload, browsing and rating of photographs. They then had to implement a mobile app that would either focus on the content creation process or the content exploration process.
Last year, we have worked on IoT and WoT. Students had to build a platform that would collect streams of observations (from sensors), apply simple processing and compute higher-level facts. For instance, by processing a stream of temperature observations, the platform would compute facts such as the coldest room in the building is room A3 or the average temperature in the kitchen over the last 10 days is 21.3 degrees. From this idea, one group had the idea to build a service that would process various data streams to compute the cost of owning and driving a car. The students then developed a car sharing mobile app that would let users know how they should spit travel costs.