Presentation of my research on “Uncertainty in Location-Aware Systems” (40MB) at today’s internal mini-workshop.

Relation to my thesis: I am now considering selecting my first sub-question “how certain (cf. taxonomy) do positional and tracking systems have to be in order to be useful and acceptable?” as my main research question. It really fits with my past experiences and with my current interest in the granularity of user experiences in ubicomp (as well as in the accuracy of geotagged images in Flickr).

I blanked on a basic question about the potential applications of my research and started talking about how garbage collectors could profit from it (referring to the Liaison project and my very own thoughts in urban computing) . I am afraid it did not match the audience on that one, but it feels good to get off the beaten tracks (e.g the usual emergency management, fleet and assets tracking) when it comes to location-aware systems.

In the workshop, a talk on the quality of service in networks, made me recall the paper User-perceived Quality of Service in Wireless Data Networks and how I could actually apply the same approach of user-perceived quality in my research.

There is a philosophical level to my research that highlights the mismatches between our needs, expectations and behaviors towards technologies. It relates to Jose Rojas‘ (University of Glasgow) questioning the techno-push in ubicomp and how cultures have a different set of beliefs, goals, aims towards technology.

Girardin, F., Nova, N., Blat, J. (2006): Towards Design Strategies to Deal with Spatial Uncertainty in Location-Aware Systems, Poster at Ubicomp 2006, Orange County, CA.

Abstract:
Building ubiquitous applications that exploit location requires integrating underlying infrastructure for linking sensors with high-level representation of the measured space to produce a pleasant user experience. However, the real-world constraints limit the efficiency of location technologies. An inherent spatial uncertainty embedded in mobile and location systems constantly challenges the coexistence of digital and physical spaces. This paper reports on a qualitative study of spatial uncertainty in the context of a pervasive game named CatchBob! It is part of ongoing work that aims at capturing information on users’ perceptions of uncertain spatial information in uncontrolled, real-world settings as well as a key element for defining better design strategies to manage spatial uncertainty in location-aware applications.

Related to Posters for UbiComp 2006 Accepted.

Yesterday, I had a meeting with Narcis Pares, from the Interactive Communication Experimentation Group at the UPF. I know him from Anna Carreras, a PhD student at the UPF interested in educational uses of virtual reality and who worked on MEDIATE.

MEDIATE, a work by Narcis’ group, tries to tend a multi-sensorial bridge to the interaction of autistic children and the world surrounding them.

I presented CatchBob! and my research scope on spatial uncertainty in ubiquitous computing.

I had to define clearly what aspect of uncertainty I focus on. I made the difference between uncertainty due to miscommunications and technological limitations. Then defined the different sources of the spatial uncertainty in location-aware environments.

Narcis went on questioning the potential bias in my data. How much of the uncertainty is coming from the system and how much from the game. According to him, the game lacks of some basic rules. The boundaries of the game are not define in some cases, and the player does not know what to expect. Reactions should be matched with certain rules. That is if there are fuzzy zone, then the player should know about the fuzziness (get an impression of the cold spots). Catchbob! players are like footballers playing on a field without lines. I argumented that the real world is like that (mentioning example of taxi drivers and GPS). One way for him to get better data, would be to setup and experiment in which the uncertainty is controlled.

He told me to think about what is under the control of the system, the user and neither. Giving me the example of one of his experiment in which the system had to support both 3rd person and 1st person interaction. In the third person interaction, the sensors tracked the shadow of user without the user noticing. So the shadow is neither under the control of the system neither the user.

Finally, does CatchBob! provide physical support for a virtual game? (related to the questions on the potential bias)

The streaming video of last year’s Catchbob! experiments:

CatchBob! is an experimental platform in the form of a mobile game for running psychological experiments. It is designed to elicit collaborative behavior of people working together on a mobile activity.

Running on a mobile device (iPAQ, TabletPc), it’s a collaborative hunt in which groups of three persons have to find and circle a virtual object on our campus.

My article Pervasive Game Development Today has been published in Mobile Game Developer:

Fabien Girardin from EPFL provides an overview of the pervasive gaming world, introducing positioning techniques and gives examples from the development of CatchBob!, a multi-user locative mobile game.

I wrote a postmortem on CatchBob! a treasure-hunt type, Wi-Fi based locative and collaborative mobile game I developed at the Swiss Federal Institute of Technology Lausanne, Switzerland. The document describes the whole development process, from the technical architecture to the user perception of the game. I talk about the positioning system, the data, the communication tool as well as the the user interface. I finish by introducing a few topics I find interesting in the field of locative media. This document addresses a large audience. Non-tech-savvy people should not be afraid to have a glance at it.

“Building a mobile, locative, and collaborative application“, by Fabien Girardin.

There is a lot to learn to hear the CatchBob! participants talking about the application and the interface. There is a gap between the user’s expectations and what the tool really does. This can lead to the lost of trust on the tool (it did not act like I thought it would have) and frustration (sometimes it refused to work).

• The unreliable network is sometimes not perceived as a disturbance but as a failure. A couple of users blamed the tool for the lost of connectivity.
• The positioning accuracy was not always understood and disturbed some players (i did not move physically, but I moved on the map. The proximity to Bob changed eventhough I did not move).
• Users where not used to write on a TabletPC. Some had a hard time adapting their writing, or they like to challenge the tool (writing as fast and small as possible).

Based on that, I prepared several improvements

• Demo tabletPC that could be used prior to the experiment for the players to get a feeling of the tool
• improved the refresh button feedback, to enhance the feeling of connectivity
• improved the look of the interface. Can trust on a system can be fostered via eye-candyness?

The polished CatchBob! interface

The version of CatchBob! with awarness was run this week. In this version, the strokes are synchronized on each TabletPC every 15 seconds. Screenshots of each player’s screen is taking every 30 seconds. The refresh button needs to be pressed to got the other’s players position. The whole system is stable. However, the current version of PlaceLab is still based on the nasty Wireless Zero Config. I will apply the new WZC-less Place Lab XP spotter of Jeffrey Hightower. It might solve the problem of connection/disconnection that happened a few times during the pre-tests.

We ran a CatchBob! experiment with the awarness tool disabled. Nicolas reports on it in A catchbob test.
Animation made of the red player’s screenshots taken at each refresh action.

The problem of stroke synchronization on CatchBob! is tackled. The player now get a visual feedback (change of color from black to the player’s color) when their writing is synchronize. Immediatly after a stroke is done attemps to synchronize it with the server are done.

2MB .mov video