Voice of InterConnect: An Offline First Mobile Web App

A case study in creating an offline-capable mobile web app using Hoodie, IBM Cloudant, and IBM Watson Services

Making web apps work under adverse network conditions is essential to keeping customers happy who rely on their applications’ data at all times. No matter if they’re in rural parts of the country, traveling on a plane, riding the subway, or working in parts of the world with slow or intermittent connectivity, your customers expect your application to simply work.

The Challenge

Connectivity and access to online resources such as APIs or centralized storage have traditionally been treated as fundamental requirements for most web applications. You’ve needed to have both for anything to work, and almost all of the software we interact with today was built on this assumption. So what happens when your users’ devices and your servers can no longer communicate? Will you show an error message and ask them to “please try again later,” or would you rather ship an app that will smoothly deal with these kinds of problems and provide a frustration-free experience?


The goalposts have moved, and not only can software now be designed to work with fluctuating connectivity, but it can also now survive prolonged loss of connection to any online resource. The result of this creates an “always on” end-user experience with minimal-to-no application downtime, greatly reducing the risk of lost productivity. Modern software that is capable of thriving in such conditions is created using an approach called “Offline First”.

Offline First is an approach to creating reliable applications that are always fast and responsive, regardless of internet connectivity.

The Business Value of Offline First

The first reaction to the idea that web applications should work offline is usually skepticism. After all, technological progress can’t be stopped, and surely that applies to mobile networks too, right? But consider that:

  • Internet use happens primarily on mobile devices, and in most emerging markets, has never happened anywhere else. Mobile devices will be offline from time to time; it’s just a fact of life.
  • Average 4G speeds have actually dropped by 50% in the US as more subscribers have joined.
  • High-bandwidth mobile networks are large, expensive infrastructure projects, and many areas of the planet will never have this luxury.
  • Geography and architecture are often non-negotiable. (That mountain is going to interfere with your signal, and waiting for someone to build a cell tower on it isn’t a helpful option.)
  • Expecting customers to wait a few years until telcos build more infrastructure doesn’t solve their problems and frustrations today. An Offline First approach, however, does.

Offline First means creating apps that still work in adverse network conditions. While the approach may appear solely focused on conditions of poor network infrastructure, there are significant advantages it gives the app under all conditions:

  • Apps are faster, since all assets and data are primarily stored on the clients’ devices (zero latency, less traffic).
  • Apps are more robust, show fewer errors, and can still work for existing customers when your server or cloud service provider is down.
  • Apps don’t lose data. Since you’re storing data locally first, you can save any time, all the time, on every single keystroke, if you so wish.
  • Apps can implement local encryption, giving your customers the peace of mind that no one can access their data, not even you.
  • Apps can be used before customers need to sign up, creating a wide array of new options for conversion optimization, as customers who have already invested time in using your app may be more likely to register.

For your business, Offline First means: more robust, reliable, and usable apps that are faster and have significant new conversion opportunities.

Voice of InterConnect

To demonstrate how an Offline First application can enable continuous and seamless end user productivity without a reliable connection to the external APIs and storage services it uses, we built Voice of InterConnect.

Bradley Holt and I share our Offline First demo at the IBM InterConnect conference.

Voice of InterConnect, named after the IBM InterConnect conference where it was demoed, is an Open Source web app that records voice messages, transcribes them to text, and analyzes the speaker’s sentiment. Try out the application here to get a sense of the experience (disconnect from the internet if you’re feeling adventurous) and read on to understand how it works.

When a user records a voice message, we store it on the device and then synchronize it to the backend server. Once synchronized, the backend transcribes the message utilizing the Watson Speech to Text API and then runs sentiment analysis using the Watson Natural Language Understanding API. Both the text and sentiment scores are synchronized back to the user’s device and then displayed immediately. All of these parts are loosely joined: if any step can’t be completed because there’s no network connection, it will automatically try again until it can, without negatively affecting the user experience.

Usually, software is built without concern for poor connectivity, and the entire app breaks when bandwidth is even remotely spotty. However, because in this case we store the recordings and the returned analysis locally, we can have our application unobtrusively deal with being disconnected: you can still access your existing recordings and results, and you can add new recordings. They won’t be processed until you’re back online, but you can still be productive and input data under any circumstance.

Designing for Offline

We didn’t want to interrupt the user’s experience of creating data to warn them that they’ve lost connectivity. The reason for this is simply that being offline no longer affects their capacity to create. In the areas that are dependent on connectivity, though, effective communication becomes very important.

In Voice of InterConnect and other applications, this communication is only required in areas where the experience absolutely depends on access to outside services, such as an external API. In our case, it’s only when a user wants to process their audio recordings with Watson’s services that communication of an offline state needs to take place.

Reaching out to services isn’t possible when offline, but all data remains safe and will sync once reconnected.

Once connectivity is restored, all work that was inputted while offline and any queued responses from the backend are synchronized. The app can show that full functionality is now available again, and confirm that any data that would have been lost in other applications with more traditional architecture has indeed been salvaged.


We used Hoodie, an Open Source JavaScript backend for Offline First web applications, to provide data persistence and offline synchronization, as well as user authentication and background tasks on the client and third party integrations on the server.

The journey and transformation of user data throughout the architecture of the Voice of InterConnect app

The application is continuously deployed from the GitHub repository to staging and production environments on IBM Bluemix. You can deploy your own instance of this application on Bluemix with the Deploy to Bluemix button.

IBM Cloudant is a database fully compatible with CouchDB’s replication protocol, making it a perfect technology for offline data synchronization. It can handle conflicts without the possibility of data loss, while also offering extendable analysis features with horizontal and geographical scaling using its built-in cluster feature.

For Voice of InterConnect, IBM Watson Speech to Text and Natural Language Understanding APIs are used to transcribe and then analyze sentiments of recordings. It’s worth noting that there is no limit to what APIs you could use when building an Offline First application with Hoodie.


The entire Voice of InterConnect application was built by two people in the span of a few days of work. Integrations on the client for data storage, sync, and authentication is less than 25 lines of code. The entire server logic for the integration with Watson APIs is less than 500 lines of code. You probably see where we’re going with this.

Offline First is not immediately simple to grasp, but the implementation of solutions is in no way a cost- or time-prohibitive endeavor. If you want to tinker, check out the app’s source code or deploy it to Bluemix. To learn more, check out the Offline Camp Medium publication and reach out to us with any questions you might have about Offline First.


Voice of InterConnect was created by Gregor Martynus (@gr2m, LinkedIn) and Steven Trevathan (@strevat, LinkedIn).

Gregor is an Offline System Architect at Neighbourhoodie Software, based in Berlin and Los Angeles. He has been building offline-capable web apps since 2011 and maintains the Hoodie Open Source project. Gregor was awarded the title of IBM Champion in 2017.

Steven is a product designer at Make&Model Inc, based in Washington, D.C. He has been designing and developing software for 19 years and specializes in web, mobile, and IoT product experience design.