A study earlier this year found that the US has a 4G coverage rate of 81.3% and an LTE coverage rate of over 90%. These numbers aren’t bad, they’re above the world average, but still leaves 10% out in the cold domestically, and larger uncovered populations worldwide. The numbers get a bit worse when you start looking at maps that show coverage by location instead of population.
Lack of coverage is exacerbated in that often times the best place for a mobile workforce to operate are the most remote. The flexibility of carrying “just a phone” lends itself to mobility in areas where it is impractical to carry a laptop. Moreover, when natural disasters strike, communication infrastructure needed for critical tablet based operations might have been destroyed.
What is therefore needed is an offline capable solution. However, this raises a new problem. What does offline mean? What can a device do without a connection to the cloud or to home base? What does it mean to be truly offline capable? To answer that question, I have outlined a set of requirements that I think you should look for in your mobility platform.
- Data availability – This one is usually the most obvious. There is some sort of data set that exists in the back end and it needs to be available to the mobile user for scheduling, lookup, reference material, or other similar activity. Be sure your solution supports synchronizing this data to the device. Ideally, look for a solution that sends small change sets to the device and syncs in the background.
- Does the app work? – Ok, maybe this is actually the most obvious. Web based solutions are great for the back office, but techniques like local storage, and cached offline apps leave a lot to be desired when pushed to the limit. This is not the browsers’ fault; it is more a case of use the right tool for the right job.
- Look and feel – Some solutions provide a bit of a hybrid approach to offline functionality. They might require you to mark some of your app as offline capable and can sometimes impose limitations on app size (think # of fields or sections in a form) or user experience. These can work, but make sure you measure the tradeoffs if you go down that path.
- App logic – One of the most important aspects of mobile data capture is data quality. This is typically enforced by a set of rules and other logic at the point of capture. Make sure your solution supports disconnected logic. The rules should be handled by the device on the device. There should not be a need to connect to the server to handle field requirements.
- Store and forward – Lastly, the whole concept of being able to store in progress data capture and then send it to the server when you’re back online is critical. Some users might not come back to an office or other connectivity hotspot for days or even weeks. Make sure your device can safely, securely store in progress data capture and then send it back up when reconnected.
I feel that if you can tick those five boxes above, your users will thank you. Even if they are only occasionally disconnected, having a solution that was built to be used while disconnected is important. Do your homework, and make sure you find a mobile application that is truly offline capable.