Perhaps the most important feature of the This Is Nowhere app was its ability to guide you to the locations you were looking for. The key to that was using the phone’s GPS system.
GPS is one of those modern miracles that seem taken straight from science fiction but which we now often take completely for granted. The fact that it works at all is magical, but of course it doesn’t work perfectly all the time. A lot effort went into handling GPS and location services in the app cleanly and intuitively.
One thing I’ve always admired about GPS and location services is that it’s a massive amount of very sophisticated technology, including space satellites and a global registry of wifi hotspots, dedicated to producing the simple result of a set of two numbers: your current latitude, and your current longitude. If you want to be fancy, maybe two more: your altitude, and an error range for your position. But really that’s it. I find this an inspiration for my work: lots of complexity underneath but producing a very simple result with only one or two things for the end user.
For This Is Nowhere, we wanted to help the user find the location, but we didn’t want to be too explicit. We certainly didn’t want to have a big map with a dot on it saying “GO HERE!” Pretty quickly we realized that an arrow pointing the way was too obvious, as well.
I decided to just work with the distance from the user to their destination. The app would store the distance at the start of the trip and then regularly update it as new GPS information came in, and you could quickly see whether you’re getting closer or further away. Originally, the app actually showed the starting and current distance in meters, but this was one of those cases where precision was very different from correctness: it could figure out the distance to a fraction of a centimetre, but GPS would often be telling you you’re several dozen meters away from your real position.
I tried implementing a progress bar, which would fill in as you got closer - but it still had the problem of GPS bouncing around and possibly showing you’re moving away from the destination even when you’re moving towards it. This seemed to be the worst possible outcome for wayfinding, especially for a non-technical audience.
Finally I decided to divide the distance up into discrete chunks, like a progress bar but with several distinct pieces that would fill in as you got closer. Depending on where you started from, each chunk could be several dozen meters, which let the assumed position bounce around quite a bit without looking like you were moving backwards since it wouldn’t be enough to change the current chunk.
But how should I represent these “chunks” of distance? I tried little rectangles or even just a line, but these didn’t really seem to fit with the “vintage mimeographed typewriter” look we were going with. In one of those “just do something so we can change it later” moments like I described in my previous post, I decided to just use a row of asterisk and dash characters. You start out with just a row of dashes, but as you get closer, they gradually get replaced by asterisks.
And like so many “just do something so we change it later” decisions, this turned out to be the best solution we found. Dashes and asterisks were commonly used as dividers and such when typing up documents on typewriters, so it fit with the look really nicely. The asterisks take up a lot more space than the dashes, so your progress has a sort of physical presence on the screen. I considered not having dashes but just growing the list of stars, but the dashes really help you see how far you have to go, and they provide placeholders to have the stars fill in reliably from left to right across the screen.
At one point I tried using actual hollow and filled star images, but it made the whole thing look like a rating system for an app or a movie or something. We did, however, start referring to the asterisks as “stars” - and that ended up bleeding into the language of the show itself: “look to the stars to find your destination”.
It took a while to figure out how many stars to use. I wanted enough of them so that they would switch on frequently enough to give you a sense of progress, but I didn’t want so many that GPS glitches would be too obvious. Eventually I settled on ten stars. I added some cheats though: your first star has a slightly shorter distance before turning on, so people could feel progress early. The last star never turns on until you actually get to the location - a full set of stars should never mean that you’re merely close but should mean that you are actually there.
Many video games are about wayfinding, and I spent a lot of time thinking about this app in video game terms: how would people understand it without lots of training? How would we give people a challenge without frustrating them? I was especially inspired by Jennifer Scheurle’s investigation into how games cheat to make the user experience better - certainly this wasn’t anywhere near the sophistication of an Assassin’s Creed or Mass Effect game, but the distance ‘cheats’ I used were certainly in the spirit of secretly helping users by being less-than-accurate.
One thing that took extra work was what to do when people were going the wrong way. Originally I had it check on every update to see if you were further away than the last recorded position and if so it would throw up a big red message “TURN AROUND YOU’RE GOING THE WRONG WAY!” This was a bad idea for many reasons:
After lots of experiments I settled on only warning people if they were getting further away than the starting distance - and even then only if they were more than 10% off. That way it would catch people who were definitely going the wrong way, but without annoying everybody else. If you’re on the way to your destination and do have to take a detour, you might lose a star but you don’t get a big warning message. Even for those who do end up getting flagged as going the wrong way, instead of a big red warning, the stars and dashes were simply replaced with a row of “!”s. I still found that a bit jarring and tried to find less intrusive options, but it seemed to get the message across better than other options I tried.
Finally, it took several tries to figure out when the user was “close” to their destination. Originally, it was whenever they were within the last 10% of their starting distance. That didn’t end up working very well, since people could be coming from over a kilometre away, which could end up triggering the “close” event from still 100 metres away - and other people could start from very close, such as 50 metres away, which would require them to be 5 metres from their destination, which sometimes would never trigger since GPS isn’t often that accurate.
We ended up storing a “radius” for each location, and the “close” event would only get triggered once you passed that radius. If a radius wasn’t specified, the default was 20 metres. This let us have a large radius for places like the Public Library, or for awkward locations that were tucked away and often turned out to be hard to find.
Ever since I worked on this project, I’ve noticed how other GPS-based apps “cheat” to improve the user experience as well. I’ve found that my phone’s driving directions maps will show me still going along a main road even after I’ve turned off on a detour - because it’s just pretending to be getting continuous sensible GPS signals and most of the time you are in fact just continuing down the road. Once you get to know the quirks of a system, you’ll start noticing those quirks everywhere.