Why do most app developers run a mile from offline app development?
Here’s a hint: it’s hard.
Two of our recent projects for Enquos and Yachting Pages have been ‘offline-first’ apps, developed to work equally well offline as online.
Yachting Pages had a 23,000 strong inventory of products. They wanted that translated into an app that could be used by yacht crew in the middle of the ocean. 4G in the Atlantic is, putting it mildly, not great – so the app needed to function offline with the same efficiency as the Yachting Pages website online. The app we developed is fast, simple and easy to use, and doesn’t require cellular or WiFi connection.
Enquos wanted their users to access their richly populated food database so they could quickly and easily log their nutrition intake while on the move, even in areas with poor connectivity. In just two days, we showed this would be technically feasible, and the project was a go.
To get these projects working we had to overcome two major barriers: syncing and search.
Syncing
Apps need the correct and current version of your data to function properly. For an online app, the only source of correct content is the server, whose records are updated whenever the business’ stock, date or content is updated. Each time an offline-first app goes online, it pulls this new data. When the phone stays offline, it uses a local copy of the database.
If a business’ inventory contains thousands of items, an app shouldn’t be expected to download the whole database each time it goes online as this would eat up the user’s data allowance. Instead, it should be smart about the data it downloads.
This issue is made trickier by the fact that when a user makes a change with their app, a record of this change should also be sent back to the server.
To compound complications further, the offline version of an app must contain all the records on the device itself to be fully usable. Developed incorrectly, this can mean that the app hogs the memory on the phone, slowing it down.
But not necessarily. Calvium’s development team has built large directories and databases on a phone that don’t take up much space – megabytes rather than gigabytes. As handsets now come with ever-increasing amounts of storage, a few extra tens of MBs is now not so much to ask, relatively speaking.
A knowledgeable developer will work with you to find that balance. Storing gigabytes of video for a marginal gain in user experience simply isn’t worth it, but storing tens of megabytes is worth it if this makes the app relevant for 25% more users, reduces the ‘round trip time’ from 10 secs to 0.5 sec or boosts user attention significantly. Compromising on imagery can also save storage. An online app might feature 10 hi-res images per product, where the offline version features only 3 medium-res ones. Skilled app designers and developers will seek to understand their customer’s needs to make these compromises.
It’s not just syncing that presents a challenge for developers, though: search functionality does too.
Search
Getting search right for offline apps can be split into two challenges: quality and speed. The end user demands both.
Search, in general, is incredibly complex.
Each body of content features its own ambiguities and details. Does an app display the result that most closely matches the word typed, or the one most people want? What if there is a result closer to their location, or one that is more highly rated? If someone types ‘app’, are they seeking ‘apps’ or starting to type ‘apple’? The likes of Google have whole teams of PhD graduates answering these questions.
The benefit of searching online is that the app can study all the other search queries for that word, your previous search history and the context around your current search. This improves search quality by second-guessing what you’re after and providing more relevant results. Take the app offline, and you remove a lot of the helpful context that makes great search so effective – most significantly, information from searches made by other users.
This quality issue can be solved in several ways, including using pre-computed searches; storing more data on the device; redesigning the app UX so that faster results matter more than accurate ones; giving users more options for filtering their results, and using the device’s other functions – like GPS – to enhance the search parameters.
As for speed: it takes a lot of maths to do search well, and a huge server has a lot more computing power than a phone. In theory, online apps will therefore offer faster searches.
Again, there are several possible tricks for improving offline search speed. The app could harness the brains of the server and work out popular searches and store these on the phone beforehand. It could also use an optimised database search engine, search software that is designed for speed, or be UX-designed so that slow searches are less obvious or annoying for the user.
Optimising for search speed and quality typically involves more one-off development work at the start of a project. Databases that offer fast on-phone searches typically require more technical effort to synchronise. To achieve an effective mix of smart and efficient search performance, servers have to be more helpful towards the app itself.
Reap the rewards
Put all this together and you can see why a lot of app developers and agencies run for the hills when confronted with an offline app project. Some businesses may even be put off commissioning an app altogether, because they assume they need great signal or WiFi for it to work properly. The good news? It can be done, and the user experience can be seamless: you simply need an experienced and talented team to tackle it.
We might know one.
To find out more about how we can help you, read our Yachting Pages case study or simply drop us a line – we relish the technical challenge.
