Creating Technology for Social Change

Thinking about Design with Geo-fences

Here at the Center for Civic Media, we’re exploring the use of smartphone apps for civic engagement. I’m really excited about using geo-fences for civic engagement; my project Action Path uses them to trigger push notifications about opportunities to participate as you walk down the street. But it’s still an open question: What constitutes good uses and good design for geo-fences?

Nathan Matias and I ran a workshop on March 14, 2014 at MIT exploring this question with other students interested in using geo-fences in mobile design. The following are our notes and takeaways.

The What and Why of Geo-fences
First off, it’s important to differentiate geo-fencing from geo-location and geo-awareness. Here are some definitions:

  • Geo-location: identifying the real-world location of a user with GPS, Wi-Fi, and other sensors
  • Geo-fencing: taking an action when a user enters or exits a geographic area
  • Geo-awareness: customizing and localizing the user experience based on rough approximation of user location, often used in browsers

Since geofencing is focused on action, not all location-based mobile experiences require it. Many designs can and should avoid the messiness of using geo-fencing by relying on basic geolocation services.

Geofence Example

Entering and exiting a geo-fence

Good, or common, uses of geo-fencing include: location tracking of objects and users, lifehacking, games (in the form of run-arounds, check-ins), and hyper-local ads and offers. Apps that are obvious employers of geo-fences include: foursquare (check-in reminders), ChildrenTracker (alerts for parents when kids are home or at school), and Field Trip (notifications about places to see around a community). However, there are some clever, non-obvious uses of geo-fences like Google Keep, which allows you to set location-based reminders for notes to self (lifehacking) and Pandora’s radio app, which sends hyper-local ads to you as you walk-about, most notably McDonald’s.

General Design Considerations 
During the workshop, we discussed more general design considerations inspired by these examples and known limitations of smartphones and their use. One key concern is accuracy. Users can set their location mode on their phone to be anywhere from high accuracy, which uses both GPS and Wi-Fi Position System, or they could have it on low accuracy (only GPS) or completely off. This affects how well your app can detect geo-fences, especially in cases where you attempting to create small radii around them. The user’s mode of transportation and movement speed can also affect accuracy. Phones sometimes struggle to update their location information while on a car or bike versus walking—some apps actually allow you to toggle modes. Device variability can also affect the accuracy of geofence detection, which is dependent on hardware details and network connectivity.

When designing a user experience, you need to be thinking about notifications and what users’ tolerance levels are for frequent or repetitive notifications. Avoid notification fatigue by throttling the number of geo-fences and triggered actions. Good designs account for overlapping geofences and boundary areas where walking a straight line can trigger an overwhelming number of enter and exit geo-fence events.

Geo-fences also take a toll on device performance. Location services draw a lot of battery power for frequent checks against GPS, Wi-Fi, and maps that talk to background services that use CPU resources while listening for notifications. The data download issue also brings data usage into the picture—some users might have limited accounts and if you have designed your system to exchange a lot of data between a server and the device, your system could cause users to overcharge their data plan. Good designs will balance local data processing with processing on a remote server, perhaps caching some data locally for upload at later times, perhaps over Wi-Fi.

Lastly, designers needs to think about adoption, permissions, and privacy. Geo-fence applications are standalone apps with background services, downloaded from the Play Store. You lose a large audience by requiring an app download rather than publishing a web page. Many geo-location applications work fine with basic location data available to the browser. You can also expect to scare and possibly lose another set of users through the broad permission agreements required to run your geo-fencing app and service. This brings us back to privacy: geo-fence applications need to know your location, and many geo-fence apps collect that data in a central location. If you are building software in an academic setting, you will need to take seriously the risk to users. For commercial app makers, it’s also an important consumer rights issue.

Developing Geo-fence Applications with Google Play Location Services
On Android, geofences are created using Google Play Services, a clever set of libraries that are compatible across many versions of Android and can be updated via the Google Play Store. Play services is used to connect Android phones with maps, Google+, game libraries, Google Drive, and more. The geo-fence libraries enable developers to create geo-fences with a specific location and radius. As the phone’s location data updates across multiple sensors, the libraries check to see if the phone is likely to have entered or exited one of those circles.

Geo-fence transitions are triggered as Android Intents. In the workshop, we showed participants how to create an Android IntentService that listened for transitions and fired new intents that triggered further actions, including a diagnostic logger and rich notifications. We also showed participants how to associated geo-fences with persistent objects that could store names, images, tasks, and other metadata about a location.

Triggering Catbread Meme with Geo-fences

After fiddling with Eclipse and ADT, we were able to support every participant to successfully add a new geo-fence to the software, build our sample code, and deploy it on their phones.

Testing Geo-fence Applications
When we advertised our workshop, Richard Stallman strongly urged us to include information about location spoofing and privacy. It was great advice, especially since location spoofing is a basic debugging technique. After enabling developer options on our phones and selecting “enable location spoofing,” we installed location spoofing apps on our phones and played with pretending our phones were in a variety of locations. Note that many of these location spoofing apps are ad-supported, which means that using them may actually include a net loss of privacy. For that reason, we see a clear need for an open source, non-commercial location spoofer for Android that’s designed to support testing and debugging.

With location spoofing capabilities in hand, we headed outside to do a little bodystorming-style testing of geo-fences—everyone with their own device in hand. We’ve found that embodied experiences with data offer powerful learning experiences for workshop participants.

We set up test geo-fences in the courtyard next to the MIT Media Lab. We placed an orange cone at each geo-fence center. Participants tried walking up to, away from, and past the various points. This gave our workshop participants a chance to experience what it was like to enter and exit geo-fences. It also gave them first-hand experience at the accuracy issues faced by geo-location apps.

The map below shows the Google Maps zoomed-in view of the courtyard. The blue markers all represent the center of geo-fences, which we gave a five meter radius. We used iTouchMap.com to get the GPS coordinates.

For the first five minutes, no one was able to trigger a geo-fence. After some fancy use of Google Maps, I realized that my phone placed me around ten meters away from my actual location. The orange dot represents where I was able to finally get a reading on the geo-fence around the rightmost blue marker.

MIT Courtyard Geo-fence Positions

The GPS coordinates we had painstakingly grabbed from specific points on the zoomed-in map were all off-center by at least ten meters. This could arise from inaccuracies in the software we used to define the geo-fences, skew arising from the isometric maps view we used to identify our location, or inaccuracies in the devices themselves.

We anticipated a mishap like the orange dot; we wanted to give our workshop participants practical experience with the strengths and limitations of geo-fence systems. Although location spoofing software is a helpful time-saver, it can give designers a false sense of confidence. Good geo-fence designers will test the experience in-person to get the location and radius right for their applications.

Geo-fence Literacy and Civic Participation
For geo-fences and other location-based activity to become a basic part of civic engagement strategies and civic technology design, organizers and designers will need to become familiar with best practices for creating good geo-location services, just like they have learned to use Facebook, Twitter, web publishing, and online donations. Our workshop was a first step towards developing trainings and perhaps co-design events that can make geo-location an effective tool for civic life. Even as I develop and test the Action Path system, we’re excited to do further work to help others imagine and create effective geo-located activities.