Understanding Location

GNSS

The Global Positioning System (GPS) is a GNSS (Global Navigation Satellite System) that consists of a ground-based control system, a series of satellites, and any number of anonymous receivers. It’s a system of satellites that communicate one way, and the signals that come from them have nothing to do with mobile networks.

It is important to know that—depending on where someone is on earth—there are about four operational GNSS networks. Pretty much every mobile phone uses a chip that works with both GPS and the Russian GLONASS system. Figure 1 shows raw location data on a mobile phone, triangles representing GLONASS satellites, and circles representing GPS satellites. In combination, the information from the two networks increases accuracy even more.

Without any other assistance, the accuracy of GNSS can be as good as ten meters, but other assistive technologies—which are too complex to get into now—can give a mobile phone almost pinpoint accuracy. To test this, go outside and, once you are sure you have a good location set, try zooming way in on a map and walking down the sidewalk. You can now pretty easily tell which side of the street you are on and maybe which side of the sidewalk.

Wi-Fi

For years, mobile OS makers and other providers of location services have been using multilateration to correlate the location and signal strength of other sources to Wi-Fi network signals, forming a map of locations based on Wi-Fi. (Multilateration determines location by measuring the Time Difference of Arrival (TDOA) for broadcast signals at
different ground stations.)This is especially helpful in cities, where overpasses and buildings can form shadows, or radio canyons, in which GNSS signals cannot find a mobile device. Wi-Fi keeps accuracy high and adding it to other signals improves location awareness even more.

However, Wi-Fi is not common in many other parts of the world—or even in rural areas in the West. So, depending on how widespread your product audience is, Wi-Fi may not be reliable because not everyone can use it.

Asking the User

People often know where they are. So, if you cannot get any location data or your users want to override it for some reason—even just because the data is bad—let users enter their location. Avoid overriding user-entered location data—or, at least, provide a warning if you do.

If you do ask for the user’s location, allow lots of methods of specifying location. Think about what the user knows and is comfortable with. Do not require a street address unless it is really necessary. Do not require ZIP or postal codes if users are unlikely to know them—for example, when they are traveling.

Precision and Accuracy

All location values are communicated to your app or Web site as a mathematical point of infinitely small size. As I’ve already mentioned, we know location services are not perfect, so they’re clearly missing something.

The something that’s missing is the knowledge that people often confuse precision and accuracy. Here’s a quick primer: Precision is the number of decimal places to which you can measure something. Accuracy is how correct a measurement is. The less accurate a measurement is, the less precisely you should report it.

A location service provides a horizontal accuracy value, which is usually an R68 radius. Meaning there is a 68% chance the user is are located within the circle. If a device has poor location accuracy or a user zooms in a lot, as shown in Figure 2, the user may not be at the blue dot, but is probably somewhere inside the big, light blue circle.

Now, let’s consider briefly how we communicate location. Most digital systems use a not very human readable decimal lat/long, or latitude/longitude, system. For example, right now I am at 39.027555, -94.659761. These are not so-called “GPS coordinates,” but just one of many coordinate systems in general use.

While there are coordinate systems that intrinsically handle reduced precision, decimal lat/long is not one of them—at least, not as computers use it. Truncating my location down to 39.02, -94.65 would not indicate a less accurate location—similar to how the circle shows imprecision in location—but an entirely different location that is some distance away. The computer assumes perfect accuracy, so reads it as 39.020000, -94.650000, which is about 2,000 feet away from where I am sitting in my house, as shown in Figure 3.

While the technology often makes all of this a bit confusing, make sure you understand it well enough to ensure your designs use everything available, including a horizontal accuracy value, to communicate precision and accuracy properly in a user interface.

How Much Precision Do You Need?

You now understand the basics about location technologies, but you’ll rarely need to pick just one of these. Instead, your mobile applications—and, with some caveats, Web sites—can simply use the existing services that are built into a mobile device’s operating system.

You can request either coarse or fine location. At the highest level, coarse means the cell, sector, or multilateration. Fine means GNSS and Wi-Fi. Fine location—and sometimes coarse—also offers a measure of precision. For example, asking Android to getAccuracy will give you the radius in meters of the blue circle that is shown in Figure 2.

Now, why would you ever want coarse location? More precision is always better, right? Well, is it? Or do we need to find the proper solution instead? For example, if you are showing the weather for an area, how much precision do you need? Knowing the user’s location to within a few blocks or even a few miles is just fine. If it’s just a weather report, we don’t care whether the position is a little inaccurate, so we don’t need to process the data to that level of precision.

Everything has tradeoffs. Fine location has the following downsides:

• It uses more power, so drains the user’s battery faster.
• There are more privacy concerns—for both the user and your organization.
• Getting the location data can take some time so may slow down the application.

Plus, getting the desired level of service depends on what features the user currently has enabled. If the user has turned off the GNSS service and isn’t near Wi-Fi, your app or Web site can ask for fine location all day long, but won’t get it. The operating system may display a notification that your app or Web site wants more precision, so be sure not to annoy the user by adding your own error messaging.

If your app doesn’t really need fine location, you can avoid many heartaches and possibly make your app or Web site perform better by not asking for it.

Geofencing

There are a lot of neat things you can do with location, but let’s talk briefly about one other enabling technology that people often misuse or misunderstand: geofencing.

Geofencing means setting up areas and correlating the position of user handsets to the fenced off area. If a user crosses a fence, this can fire off relevant actions. Some common use cases are:

• advertising—When walking down the street, the user can be notified of a deal at the restaurant they are passing this moment
• safety—The user can receive an alert when her children are about to leave an amusement park.
• service—Don’t send the user alerts about their connected car needing service when the car is already at the dealership.

Many define a geofence as a radius around a point, but this is wrong. A geofence is any perimeter on a map, usually a polygon. So I guess a radius around a point is not entirely wrong, but it is horribly limiting. If your geofencing provider does only circles, I’d get a different one.

If you could set only circles, the examples I’ve provided would be much less useful. If the circle were too small, people would walk by before getting the restaurant’s ads; if too large, people in the next block might also get them. Parks and parking lots are not circles, so people might miss alerts, or alerts might be misdirected to people when they’re not applicable.

Geofencing can be very useful for all sorts of purposes, but make sure you understand it well and set it up properly.

Location APIs

I often advise teams not to build anything they can borrow. Location services abound and provide all sorts of useful data that you can leverage.

Reverse geocoding is the practice of turning coordinates into a street address. Google and many others offer APIs that do this very reliably, so you won’t have to build your own by any means. You can even try them out for free with limited searches to see how well they work.

There are additional APIs that can provide all sorts of data on roads, traffic, businesses, and more. Since we’ve just talked about geocoding, one of my favorite things is location API’s increasing awareness that things on the ground are not just pinpoints, so buildings have shapes on a map—as do administrative regions such as cities. Figure 4 shows both of these examples.

Designing for Location

Creating products that use location effectively is an exercise in restraint. While there are best practices for address gathering and map formatting, as is so often the case, the user interface is much less important than optimizing the overall architecture and process to best satisfy the user’s needs.

Location Is For Users

Many apps get permissions for all sorts of irrelevant sensors and data on phones. Don’t do that. Use location only when it benefits the user—never because more data is good just for your own internal purposes or to sell users’ information.

Gain Trust Through Transparency

Don’t be creepy. While users understand that their devices are connected and intelligent, they expect them to be benign or helpful. Don’t use sensor data too proactively without providing the appropriate warnings or context. Otherwise, users may mistrust what your system knows or might do.

When the user performs an action that requires location, make it clear beforehand that this will happen. The user can then tacitly opt out of sharing that data. Get the most relevant location information automatically, without making the user enter, select, or confirm the location.

When a device performs actions based on the user’s location, display that location so the user knows why an action is taking place. Never show anything like lat/long, but instead use reverse geocoding or a place name API to provide more natural names to labels.

Give Users Control

Providing users a method of changing their location is good not only for transparency and trust, but also lets users change their location as necessary.

Make sure manual location input methods are natural. A lot of services that I’ve encountered ask for the ZIP code. This seems mobile friendly because it’s a nice, short number. But who knows the ZIP code for anywhere but their home? Provide human-centric methods of specifying location instead. Good examples include a map that lets people scoot it around to recenter or typing a value while connected to a location API, as I described earlier. The system can then autosuggest answers or autocomplete poorly formatted addresses.

Never require users to provide addresses by typing in a number of specific fields for street, city, state, and so on. Allow free data entry. All of the location APIs can handle this data. Providing multiple input fields is not best practice. It is an old, familiar practice, but check out how all big map providers now accept complete addresses. Best practice is not common practice.

Design for the Platform

Compare Weather.com on your PC and your mobile device. The home page is entirely different on these two devices. Because they know how people use different devices, they leverage the individual platforms’ capabilities.

Desktop operating systems do not have good location services, so while they offer this capability, it’s not reliable. More importantly, it may not be relevant. For example, from home, users may want to check tomorrow’s commute or their trip this weekend. However, on mobile, people tend to be looking at information about their current environment. Even if they then wish to change contexts and look for a friend, they’ll understand that a mobile device is a connected, sensor-laden companion. Their first expectation is current, accurate, up-to-date information.

Create custom experiences, not just flexible user interfaces, to leverage the capabilities of and expectations for each platform. Yes, this means plain-vanilla responsive won’t do for Web sites. You’ll need to start using adaptive methods.

Don’t Assume Everything Is Perfect

Signals can fade in dense cities, so your maps or geofences may be wrong. Who hasn’t been annoyed by having turn-by-turn directions tell them to make a turn when it’s too late to do so?

As always, design with resilience in mind so the system reacts smoothly when the unexpected occurs, recovers from errors, and doesn’t trap the user in some hole because your app assumes it is right. Build your product for humans.

Location Privacy

Don’t think designing the user interface and interactions is the end of dealing with location. Location privacy is a big deal—both for user trust and from a legal point of view. In the US, COPPA (The Children’s Online Privacy Protection Act) is the most often cited law. It requires that your app, Web site, or service does not gather or track location data for anyone under the age of 13.

But even for adults, exploitation of location awareness is becoming all too common. It can reveal information that puts people and organizations in legitimate danger. The recent use of Strava heatmap data to find secret Western military installations is just the latest example of how people can misuse even anonymized information.

Strava didn’t intend to share secret information, but their poor attention to privacy is an almost perfect example of what not to do when you intend to build a product that respects users’ privacy and engenders trust. Strava made the following mistakes:

• It was not clear to users that Strava would save their tracking data forever and share it with others.
• Saving and sharing were selected by default.
• Settings to change sharing were available only on the Web site and not even mentioned in the mobile app.
• Jargon made it hard for users to understand what exactly the consequences of sharing location data were, even if they found the information and controls.

I have previously written about simple ways to ensure that location data is saved in ways that avoid dangerous user exploitation, but increasingly, I cannot suggest even those approaches. Instead you should do the following:

• Avoid saving users’ location data at all. Use the data at runtime to provide the service, but don’t store it.
• If you have to store this data for a session, build a reliable, auditable method of purging it.
• If your business model requires storing and aggregating data for analysis or customer service, do not attach personal data to each data file. Be sure that no one can ever get this data out of your internal systems.
• If your business model requires sharing location data, think very hard about what that means, red team the worst cases, and do a lot of usability testing before you find yourself having to explain a problem on the front page of a newspaper.

Always make users aware of what data you are gathering, as well as the possible consequences. Require them to opt into sharing explicitly, and allow them to change their settings easily, at any time they’re using your service.

Waiting for Perfection

Back in 2001, when we were starting to see prototypes of mobile phones with an antenna and chipset for GPS, the phone company I worked for wanted to prepare for the future. So we met, pondered, tested, and came up with a bunch of design principles.

But we then simply disbanded, having done nothing operational with them. Much of the team decided that we needed to wait until a GPS-enabled phone was available. But I and some others argued that the perfect is the enemy of the good. Most of our use cases would work great with cell, sector, or multilateral levels of precision.

Neither we nor anyone else launched this service, and when the first phones emerged, the first GPS apps simply had a decimal display of latitude and longitude, so were not helpful at all. For years, we failed to start building good, useful location services because we were waiting for some ultimate, perfect technology solution.

If you could improve your product by adding sensor data such as location services, do it now. Start thinking about the right ways to use the many turnkey technologies that are now available. But don’t get caught up in using improper jargon or think that location awareness is a stretch goal, so users can just keep putting up with that bit of unexpected friction. Leverage what makes mobile great so you can make really useful experiences.