This Is Nowhere: Why an HTML/JavaScript Single-Page App With GPS Is A Bad Idea
Oct 23, 2018 12:20
The early versions of the This Is Nowhere mobile app were single web pages with HTML and JavaScript. This was a great way to start:
- The libraries built into modern JavaScript are pretty good for handling GPS location and getting JSON data from a server (except for CORS, which was fine after some server adjustments).
- The relatively simple UI was easy to build just using plain HTML/CSS and some JQuery animation effects.
- LocalStorage was plenty for the small amount of key-value information the app needed to track locally.
- The entire development process with this “stack” was fast and flexible, and publishing and installation was nearly instantaneous.
- Last but not least, this was likely to work on almost any mobile device built in the last decade or so, as well as tablets or even many laptops.
A single-page web app looked like the ideal solution for this project. We wouldn’t have to build separate native apps for each platform, wrestling with multiple codebases, or even have to deal with all the arbitrary vagaries of the various App Stores out there.
But then we started field testing.
Installation was a breeze. Late breaking changes were “installed” by simply reloading the web page. Data feeds worked like a charm. The UI was smooth and remarkably consistent across all the different devices we were using.
But permissions for location services and GPS killed us.
The basic idea is sound: if your device’s browser lands on a page that has JavaScript that asks to use GPS and location information, it simply asks you if you’d like to allow that, and if you say yes everything works fine.
BUT:
- People get so many intrusive, nuisance prompts in their day-to-day browsing experience, many folks just instinctively hit “no” before they even read the prompt.
- Once someone has turned off location/GPS access for a specific web site, there isn’t an easy way to turn it back on just for that web site. On iOS, you have to reset all of your permission settings, which means the next few weeks will find you being prompted for crap from all the sites and apps you had already silenced long ago. On Android, there’s different ways to do it for different versions and browsers, making it a support nightmare.
- A perhaps unsurprising number of people simply turn off all location access for their device’s web browsers. This isn’t all that bad an idea: if you need maps, there’s an app for that. Almost all websites that want your location probably have bad reasons for it.
- We “deployed” the web page mostly by just sending testers an email with a link and an access code in it. This generally worked, except for all the people who use Gmail: if you tap on a link in the native Gmail app, it opens the page in an in-app browser - a browser which doesn’t allow access to GPS or Location Services.
So even during our early tests with only four or five people, half or more needed hands-on technical support to get the app working properly on their phones. This clearly wasn’t going to scale to the hundreds of people who were going to be using the app during the show. This needed to be a completely no-fuss experience of installing and starting with all the functionality working immediately.
We were going to need actual native apps.
Native apps still ask for permission to use location services, but people are much more used to saying yes to an app they’ve downloaded than to a website they’re visiting, no matter how app-like that site may be.
So I started working on an iOS version. Android we would figure out down the line.
Doing the first versions in plain HTML and JavaScript wasn’t a loss though. It allowed fast iterations and prototyping, and let us really figure out what was needed and how it would work, while working with a familiar set of tools. It just wasn’t going to be the solution for the final product. At least when it came time to build native apps, I could focus on the “how” since the “what” had already been mostly worked out.
