Supporting Offline Users — What Happens When it Breaks?

Some error messages, while accurate, are less than helpful to users.

Last year at Offline Camp California, I had the privilege of participating in a session titled, Supporting Offline Users: What Happens When it Breaks? I will try to provide a long overdue summary of that session as well as some additional thoughts on the topic.

When I attended Offline Camp California, I came with a couple of questions and topics on my mind. One of those topics was the question this session was trying to answer — how do we best support users when things go awry in an offline app?

One of the key tenets of Offline First is that we do not want to treat offline as an error condition, but this does not mean that offline apps are error free. Let’s look at a couple of error scenarios that can happen in an offline app:

Communication Errors

While one of the key advantages Offline First applications provide is the ability to run without a network connection, these type of applications oftentimes need to synchronize data when connectivity is available. In low connectivity situations (such as lie-fi), this synchronization can and will fail. So how do we help our users deal with these failures? Here are some suggestions that were brought up during our discussion:

• Provide your users some indication of synchronization progress. In providing this information, we need to consider how much information we reveal to the user and whether or not synchronization state is important and/or useful to users.
• We can use a reductionist method for sending data. If we can’t synchronize the whole set of changes, can we synchronize the most important parts of the data?
• We could provide a diagnostic tool for our users to diagnose their connectivity. Ideally this tool would guide users through various steps of trying to verify the state of their connection. Where possible, information from the browser such as the Network Information API would be used to provide further diagnosis and recommendations.

Application Errors

Developers make mistakes and those bugs make their way to our users. In an offline app, diagnosing those errors becomes more complicated because everything needed to identify the problem may only exist on a user’s computer or device. In building resilient Offline First apps, we should seek to build apps that are self diagnosing and where possible, self healing. Here are some things to keep in mind:

• It can be helpful to store errors in offline storage so that those failures can be sent to an online source for further investigation when connectivity is available. Keep in mind when storing and sending diagnostic data to only keep as much data as is needed to diagnose the problem. You don’t want to use more storage and bandwidth than is necessary, particularly for folks who are in a location with low connectivity or are on a resource constrained device.
• Offline First application developers should be more intentional about handling of errors. Ideally an Offline First app should never swallow errors — if there is an opportunity for an error in a particular bit of code, ask yourself, how can I best handle and/or recover from this error when the user is offline?

User Errors

Due to the disconnected nature of offline applications, one more error scenario should be considered: What happens when the user doesn’t understand the application and they do not have network connectivity? Here are a couple of suggestions:

• Design for simplicity — complicated UIs require more explanation and have a higher learning curve.
• Provide tutorials — build workflows into your application that show a user how to perform specific tasks.

While some of the ideas proposed above may set a high bar for offline applications, the reality is that improving our offline applications in regards to how we handle communication, application, or user errors even in a small way will provide for a better user experience. Just as offline shouldn’t be treated as an error condition, our users deserve better handling for the common errors offline applications encounter.

Editor’s Note: This article recaps discussions we had at Offline Camp, a unique tech retreat that brings together the Offline First community. Join us at our next event or sign up for updates and cast your vote on where we should host future editions of Offline Camp.