Mobile App Design Flashback
Facts from a (not so) near past
Back in 2002-2004 when the mobile ecosystem was in its early days application developers were facing challenging constraints from every fronts. The cellular network bandwidth provided by GSM, CDMA and GPRS (for a few lucky ones in Europe) was only offering a few KB per second, coverage was extremely spotty and latency really high.
The smartphone device’s resources were also scarce: slow CPU, few hundreds of KB of RAM, limited application’s stack size, strict application size limits and mobile software platform with limited APIs (Series 60, J2ME, Brew, Openwave). On top of that the hardware was cumbersome: small screens, no touch capabilities, 12 keys, no wifi,...
For connected applications, the cellular network limitations was by far the hardest problem to solve. Users were more than often left staring at a spinner of death for seconds or even minutes with non network fault tolerant applications.
One thing hasn’t changed since them: a frustrated user is a user that runs away from wrongly designed applications.
5 fundamental mobile design principles
When I was CTO at MotionBridge in 2004 we were developing an embedded application interacting with our search backend with the promise of offering mobile search capabilities even under limited cellular connection and having a responsive UI under any conditions. We relied on 5 fundamental principles:
store and sync design pattern
sync with remote servers whenever the network is available
all non UI specific tasks must run asynchronously
preempt network data as much as possible by guessing user’s most likely future action
provide visual feedback whenever data is not synchronized or results are partial (i.e. local only)
The first principle is the most difficult to achieve because of the engineering effort involved but it’s also by far the one with the highest reward in terms of responsiveness.
Store and sync
The basic idea behind it being that any information provided by the user that must be sent to servers is first stored locally in a database and is eventually synchronized asynchronously when the network is available. It implies that you have some sort of distributed database and that the synchronization engine is able to reconcile local and remote identifiers and to deal with data conflicts.
Think of Git, you always work with your local copy of the repository and push/pull/sync at some point.
It might seems counter intuitive to imagine a disconnected search engine but thanks to 2. and 4. the application always had a subset of the search index locally allowing users to perform searches and getting some results under most conditions...
The false hope of 2.5G, 3G, UMTS, 4G, LTE
The cellular infrastructures and powerful smartphones were supposed to deliver always on connectivity, low latency, high bandwidth and make the development of connected mobile apps easier and the user experience seamless, right? Wrong! The network infrastructures have greatly improved, but at the same time the mobile application’s bandwidth consumption doubled every 2 years (or ~30 times over the last 10 years) thanks to larger media files, streaming,... The smartphone penetration in US went from 2.5% to 80% since 2005.
What about sharing a photo on your favorite social app at the stadium during a NFL game? No bar, the network downgrades to Edge, apps become unresponsive and slow. Following our 5 principles, one would simply take the photo and store it locally alongside with other metadata and let the background synchronization engine handling the network congestion.
Overall the user’s experience has improved but unresponsive applications are still legion because of bad design practises.
Don't reinvent the wheel
10 years ago early mobile users were more forgiving but with the power packed in today’s smartphones and the promise of always on connectivity mobile application must operate at all time, connected or disconnected, must be responsive and never blocking. That’s the expectation of every users and applications not fulfilling this hope are bound to failure.
Implementing principle 1., 2. and 4. from scratch is as difficult as 10 years ago but there are now mature platforms and SDKs that greatly simplify the life of developers by providing a robust foundation so you can focus on your core business. Couchbase Mobile and Firebase offer real-time data synchronization out of the box for developers managing their own infrastructure and the ones who don't want to.
Couchbase Mobile is a full-featured NOSQL data platform that brings ‘always available and always responsive’ capabilities to any applications at a much lower development effort.
The stack comprises Couchbase server, Couchbase Lite and Couchbase Sync Gateway. It’s a cross-platform solution that gives full control of which and how data is synchronized while writing few lines of code. It provides a strong base to implement mobile syncing and improving responsiveness.
You can learn more about Couchbase mobile here: https://www.couchbase.com/nosql-databases/couchbase-mobile
Firebase is a full stack mobile platform that helps quickly develop apps without having to manage the infrastructure. It is available on all major mobile platforms including iOS & Android and also for Unity, C++ and Web. The NOSQL/JSON database combined with the mobile SDKs allow for real time data synchronization in your mobile apps and handle the complexity of data synchronization and conflict resolution. Firebase ensures that mobile applications remain responsive regardless of network latency and connectivity.
You can learn more about Firebase here: https://firebase.google.com/
Implementing the store and sync design pattern has a significant impact on your application architecture and must be considered early in the design stage. A first release must delight users as the competition across the App Stores is simply too stiff to take a risk!