# Designing for Location: Privacy, trust, frequency, accuracy? Oh my! By Ben Ward http://ben-ward.co.uk This document, and the associated slides, are provided under a Creative Commons Attribution–Share-Alike license: http://creativecommons.org/licenses/by-sa/3.0/ Written for and presented at Chromatic, San Francisco on July 6th, 2009 http://bit.ly/chromatic These are my original, mostly unedited presenters notes, which might help guide you through the slides a little better than just a deck of screengrabs alone. A full write up, with sentences and stuff, will follow on my website. — Ben, July 7th 2009 ## “Location is complex.” * Where is it? * Does your application speak geo? What inputs do you understand? Which inputs _don't_ you understand? * When is from? * A location updated today might be OK. Updated last week? * How accurately was it recorded? * Will go through the methods of obtaining location momentarily. There are lots Accuracy varies * Exactly, approximately? When it's absent? * Is it exact? Approx? What if they provide _no_ location? * How are you going to show this? * Representing location in the page, whilst tolerating variance in all the above. * Users might lie to you. * Was the user intentionally ‘checking in’? Or are they just passing through? In motion? * Are the going to share it with you in the first place? _Why_? Facets. Grey Areas. Edge Cases. ## Traditional Location UI: Mostly: Cities and countries. Postal Codes * Broad localities for length of a session (search, shop), * Standalone Queries, addresses/shipping information, localisation of pricing. * Locality for persistent profile information. Not kept up to date. * Enter city names * Airport codes (Flickr) * Clickable Area Maps * Big, big, big lists ## New Location: No-longer just about city/country level. No-longer about one-time queries * Persistent location, shared with people, attached to dynamically generated content * Used to dynamically filter/change content * Location aware personal-analytics * Massive increase in availability of RAW location to consumers. * Massive increase in location _content_ on the web that can be used as an implied location source, too. (e.g. website showing attendance of this event) * GPS - iPhone, etc. * WiFi - Clarke, Skyhook, Mozilla Geode * IP Addresses * Street Addresses - Google Maps input * Venue names - FourSquare * Synchronisation with events attendance - Upcoming * Coordinates - Published on Twitter, Drag + Drop on Flickr * Location databases - Y! GeoPlanet, provides perma-IDs for locations. Those will general provide quite precise location points. What when you don't need/want a precise point? What about areas? Radii? * Y! Local: Radius selection UI All of these can be used in obtaining a user's location. Some of the examples are publishing locations too, but that's a different context. ## Social * Geotagging * Flickr Map - Precise–location-centric * Flickr Places - Content-centric, broader locations * Brightkite - venue centric. Small map is illustrative. * Twittervision - approx-precise-location (but imprecise data input) * Friends on Fire * I worked on this. With Brickhouse (Tom Coates, Sam Tripodi, Phil Pearson) * Locations are gathered from Fire Eagle (more later, allows user-control, variable disclosure) * Displays precise location updates * Precise message locations * And approximate location updates * Handles zooming/grouping * Fire Eagle * Disambiguation dialog. Entering locations triggers naming conflicts. You have to resolve them. * Sometimes blind, maybe list cities by population * Sometimes you have a starting context (on a map) that you can rank with (e.g. iPhone search for pizza, doesn't show Pizza off the map) * Or you have IP address, can be used a context for the results list * Google Latitude * Mostly from non-GPS sources, so most locations approximate. * Blue area markers represent approximate locations with users at center * Markers in General: Pins vs. Pulse * Pins imply precision, always pointing at an exact place * iPhone GPS uses a ‘pulse’, more approximate, not pointing at anything. ## API-level Availability * Hardware based APIs, e.g. iPhone - Provides precise location or nothing. * W3C Geolocation * Powers Web Browser Location (Geode, Firefox, Chrome, Safari, etc.) * Firefox Geode exposes this with a choice: Exact/Neigh/City * Fire Eagle * Also offers granular control of disclosure Services hooking into any of these have to handle no response, and partial disclosure responses. # _Using_ it: Overcoming the Fundamental Challenges that location poses ## Getting it in the first place * Fire Eagle exists to use location on the web, independent of a connection to any physical location hardware. * e.g. Takes location from iPhone Hardware to web services * e.g. Location from WiFi to FE to Twitter * Web APIs means: OAuth Flow * Web APIs means: Sharing data between services * Explaining what you're going to do with data * Are you storing it? How long? Keeping a history? * Who will see it? How? Where? ## Accuracy is variable * Users may choose to share partial info * Users may lie to you * Users may withdraw their location at any time * GPS is somewhat accurate. Wifi somewhat. Address very. Varies. * What happens when a pool of users provide you with precise data and others with approximate locations? How do you display them together? ## Privacy & Trust * Location is super-sensitive. * Treat it with respect * It's also _new_. User's not used to giving up their location to services * Will be scared of all kinds of irrational scenarios * You have to reassure them, be trustable, be responsible. ## Misc * At what point do you discard data? e.g. Too inaccurate? How do you communicate to a user that they need to provide more detail? How do you ask for that politely? How do you stay trusty when asking? ## What I know so far… * Be upfront, explicit and clear about what location for * How it's stored. * Who sees it. * How long it's going to be stored for. * Offer the ability to clear it out of the system. * Demonstrate functionality up-front. ‘If we knew you were in Florence, we do X, Y, Z’ ### Getting Location * Piggy back on APIs. Fire Eagle provides all manner of sources for Location already built. * Don't duplicate that effort. * Don't raise the barrier to entry for users to provide you their location * they wont want to install a new app. * Conventions are blurry. Pins give impression of precision. Pulsing blobs (iPhone) maybe more approximate, but truthful. Radii and outlines are accurate for both, but complex. ### Your UI: * Be prepared to adjust it. * Make sure you're listening for feedback * Make sure you're logging UI interaction: * Friends on Fire has multiple ways to update (clicking, writing, drag and drop: breakdown of which ones users favour) ### Conclusion * Crashed through the facets of designing for location * Made aware of the variable nature of loc + the plethora of edge cases ### Discussion Questions: * Good location UI you've seen? * Good location copy/language? * Ideas to work around any of the problems/challenges presented here? * Bad experiences with location? * etc.