The Mobile Web App Developer’s Dilemma
I’m currently sitting on an Amtrak train from NY Penn to Exton, PA (the Philly-ish area). The ticket taker was coming by on his nifty device scanning tickets, which would then check a database of purchased tickets to confirm the purchase and the identity of the purchaser. However, when we hit a tunnel (and therefore no data connection), the device stopped working; any scans returned “Ticket not found.” You would think that whoever developed this system for a subway/train company would have considered that at times there might not be a data connection, but that didn’t seem to be the case. This is a bit of a dilemma for anyone developing apps for mobile.
I’ve been thinking about this a lot lately since beginning work on a small pet-project that is based on the mobile web. My friend Dave and I were discussing this same issue: web developers assume an Internet connection because that’s been status-quo for us. People aren’t viewing websites if they aren’t connected.
That is changing though; I assume that a lot of developers like me are seeing the value in mobile. This is a very different medium from a desktop or laptop because you cannot assume there will always be a connection (or at the very least a strong one). If you do, your app or website will not always work and you will have some unhappy users. So what do you do?
A: Use Local Storage
Let’s look back at my ticket-taker friend from Amtrak (which I’m assuming is a native app, not a mobile web app). The solution here should have been a fairly simple one: download the ticket information incase you don’t have a connection. And it doesn’t have to be a download-all-the-data thing either. 2 possible solutions are that the ticket taker chooses the train he’s on and downloads those tickets, or the app does it automatically based on time and geolocation (when he does have a data connection). This does raise its own problems; what about multiple ticket takers or syncing, etc. But this is just a temporary solution for when there is no conenction. Once you get it back, proceed as normal, syncing the offline data and alerting the user of any anomalies.
So what about mobile web developers? Websites have traditionally (and until recently, exclusively) required an Internet connection to be viewed properly. How do we make it work without data? Thankfully the fine folks at W3C have been thinking of this and, starting in HTML5, introduced HTML5 Storage APIs. This allows us to cache pages and store data that we can later sync back to the server, once we have a connection.
As I build out my little project I will be experimenting with this a bit, but assuming an offline state has been at the forefront of my mind from the start as should be the case with anyone developing for mobile. Doing this right will be a big step in the direction of popularizing web apps over native apps on mobile devices.
One of the frustrations I have is that apps have different functions which require different tiers of access, but don’t differentiate between those tiers, and when they can’t get data signal, they shut down entirely. For example- why shouldn’t Words With Friends have a dictionary onboard that lets me make my play (the wireless is used to check possible plays against the database) and then upload it when my commute is over. I have the space for a dictionary download. Or my FitBit, which won’t sync (via Bluetooth) unless there is also a data connection. Why do two things in my pocket need access to the satellite in space to talk to each other?
Exactly Jared! Developers rely too much on a data connection to make their apps work, when it should really be a “work all the time, sync when you can” sort of connection. Instagram’s approach (the optimist’s approach) is a good one. Give positive feedback even without a connection and sync when you have it.
I think this is all a temporary issue. The blanket of data coverage isn’t getting smaller it’s only getting bigger. I believe you’ll have more of an issue trying to lose your data connection than find one in the near future.
Perhaps- at least until then though, we shouldn’t assume the user will always have a connection.