Design for offline

[Rss Bot 1]

Offline mobile experiences can be frustrating for users. You're on the train attempting to open an article you were reading earlier that morning but didn't get the chance to finish. You've loaded it once before, and you even have two bars of service. However, it just won't open. Your phone thinks it is online, but really it is not. You are offline.

What you're experiencing, day in and day out in a variety of ways, is a problem that we have all accepted as the standard yet haven't seen for what it truly is: a fundamentally flawed experience. 

Regardless of whether you're a maker or a consumer of tech, we don't expect things to work offline, and decades of requiring constant internet connection has set us up to be blind to this issue. 

As such, supporting offline experiences requires attention to be paid to the negative space, which is somewhere we didn't really know to look until Alex Feyerke introduced us to the concept of offline first.

Offline first

With non-digital objects it's easy to differentiate between various on and off buttons

Offline is any scenario in which a user seeks information or functionality while being unable to access a supportive outside network. This may be experienced due to low bandwidth, a lack of internet connection, server outages, or countless other reasons.

At first glance it may seem like designing for offline is as simple as communicating to users that they cannot access the app or that any new data they enter will be lost, but this approach falls far short of what is possible with today's technology. 

Instead, we should look at this as an opportunity to create a 'deployed' application that is as close to fully functional offline as it is online; blending the experiential line between native and web apps.

The offline first methodology aims to be deliberate about these experiences by treating them as more than a patch. It views offline state as an issue of accessibility, and accessibility as the centre of the product. 

It combines what we've learned from the mobile first and responsive design movements, with heavy emphasis placed on designing for the most constrained environments (offline) first and treating connectivity as a progressive enhancement.

With Pokedex you can use advanced search, explore by type, weakness and ability, all offline

We now have an offline-enabled Pokedex, an open source tool for hospitals of the developing world with HospitalRun, Offline Gmail, and even browser games such as 2048 that can function entirely without connectivity. 

Developers have proven the concept of offline design and are now managing to deliver real-life value with it.

The catch

This is awesome, but unfortunately with these types of things there is always a catch. Offline UX patterns maintain ambiguity and often open up more existential questions than we started off with. The question of what we are able to (and should) do with regard to offline state never seems to enjoy a succinct answer, and the huge diversity of internet-based software we're tasked to design certainly doesn't make the work any easier. 

That's not to say that there haven't been some interesting developments in the field, though, and there's a foundation taking form for what offline first apps can be.

With most non-digital products that aim to improve our quality of life, we have an unspoken and true-to-form understanding of the full system state. We can visibly see that the desk lamp is on, or that a desk drawer is open. We can smell the cookies that are being baked or feel the warmth of the oven as it operates. If we didn't sense state with some of these objects, there could be real-world consequences.

With software, such indicators of state that naturally register with our senses don't come with the territory. State is manual and challenging to articulate, and to express it well we must pay proper attention to the environment the product is used in (or the unpredictability therein), and work with design patterns our users comfortably understand (or can easily come to rely on).

Good design is just as much about context and reliability as it is about the ease and pleasure of its use. Achieving the proper design begins with an understanding of the context and motivations of our users. 

Luckily, when thinking about offline experiences, we're already in the right frame of mind. We've started with a complete lack of connectivity as our context and will attempt to provide value under these conditions. To do so, we'll need to see more of the picture, however. Our users could be offline and:

• Recording patient medical data when out in the field
• Reading while riding the train to work
• Trying to upload a photo to social media while on vacation in the desert (and fighting off a hyena)

The next – and often more challenging – steps are to gain an understanding of what the motivations for each use are, then to couple those motivations with the contexts we've outlined. From there we can choose from those couplings the ones that will most benefit from our attention in design. 

Having a grasp on the crossover between motivation and context allows us to understand and serve our customers better, but can also provide answers to broader product questions.

Job stories help us to discover good design, which is essential when it comes to offline use

We can then record the context and motivations in the form of a job story, a form of user story that centres around context and motivation. For a pharmacist whose prescription fulfilment system depends on the internet, we could write either of the following job stories:

• When a customer wants to buy something and I'm offline, I want to be able to collect payment anyway, so that we may be able to continue to serve customers the medicines they need.
• When I'm offline and I've marked a customer's prescription as having been fulfilled, I want to know that the system will perform this function when it has reconnected, so that I don't have to repeat my actions and record fulfilment elsewhere.

These stories are each meant to be a brief detailed objective that frames exploration of design and product teams. They guide our discovery of a proper design, and serve well when designing for offline experiences. 

With an appropriate sense of context and motivation, it should become easier to judge what interactions and UI will be effective for our users.

Next page: Interaction models and offline UX design examples

Use this handy interaction model to help when designing offline experiences

When we're ready to work on our offline UI, whether starting from scratch or improving upon an existing product, it is wise to be mindful of our product's core interaction(s). This interaction (or group of interactions) is what our users do to repeatedly get value out of our software. 

Where possible, we should use this interaction model to help communicate offline state.

For example, Instagram's core interactions might be scrolling through lists of content as well as creating and manipulating it. When we are offline, we're able to interact as we do online, allowing us to go as far as we can without running into roadblocks of functionality. 

When attempting to save, the app places the content in an unobtrusive "waiting" state that is using an existing feedback mechanism to communicate to users that it hasn't yet been uploaded.

Instagram is a great example of an app that clearly communicates its offline state

While it may seem obvious at times, noting our core interactions is a useful practice in helping us maintain continuity in how customers expect to interact with our app. The additional benefit is that we can reuse UI where they're already looking for clues of cause and effect.

While not all breeds of software products can deliver their entire functionality when they're offline, they can provide partial value or clues that it existed to begin with. The bottom line is that they must clearly communicate state. 

Instagram and Slack are great examples of apps delivering as much value as they can up to their reasonable limits while also unobtrusively communicating state.

The need for assurance

Designing for offline requires a new way of thinking

Not all applications are the same, of course, so design patterns for these situations will largely depend on who you're trying to serve, where they are and what they need to do. There are some common clues related to offline experiences, however. They are reach, freshness and reliability (Jesse Beach refers to this as assurance).

Reach is about communicating how far users may explore in our application while offline. To use a videogame analogy, if our users are bound to a single linear path, we don't necessarily want it to appear as though they're operating in an open world. The result of doing so could mean a lot of wasted time on dead-end paths on a quest to unreachable or non-existent areas.

If state isn't well communicated here, it can become difficult to know if that area is purposefully inaccessible or if there is a bug in the system. 

So, we can improve our user experience by establishing clear boundaries when they are in an offline state. Those boundaries should be composed of reachable and unreachable content or actions.

The visual indication of something that is reachable or unreachable will vary by product. For instance, an eCommerce site may fade out products that are not reachable when offline, but in applications comprised of content feeds – such as Twitter – the interaction to load more content has no static visual affordance, so there is a need to find a different solution for communicating reach in this circumstance.

Instagram alerts users to a lack of connectivity so that you're always aware of what's going on

Instagram's approach to this is to use its intercom UI pattern to alert users to their lack of connectivity. The application provides users with a means to attempt to load more content, but is consistent with its feedback for why it was unable to perform the request.

While reach helps users understand what can be done, freshness lets them assess whether or not an action is worth their time. It might be represented as a date on a news article, a timestamp for the last time a currency converter rate was updated, a last-edited date for a collaborative document, or perhaps when a photo was last viewed. 

For example, if the weather forecast was last downloaded just three minutes ago, users may as well spend the next two minutes putting on their rain coats, rather than waiting for a new forecast to download.

Comfortably offline

LinkedIn is another example of an app that provides good context awareness

The combination of these clues helps our users breeze through our application with greater contextual awareness and agility. In the cases where offline state forms an impenetrable barrier for an action (such as saving edits to a collaborative document), the combination of clues of reach and freshness deliver a sense of reliability.

When one attempts to upload a photo to Instagram without connectivity, the photo and work they've done to it isn't destroyed due to an inability to send it to the server. Instead, Instagram saves the photo to their device and retries that upload until the user decides they don't want to anymore. This is an example that treats offline clues of reliability very well.

No data is lost when Instagram loses connection, and the app will keep trying to post until you tell it not to

What we want to achieve in communicating reliability is simple: make it clear whether or not the data that users are concerned with is their responsibility or the app's when they're offline. 

We need to immediately answer their questions of whether or not data syncs automatically when they reconnect, whether further action to sync is required, or whether any progress will be destroyed. A good rule of thumb is to allow users to go as far as possible while reliably preserving data locally until connectivity is restored.

With a process focused on context, motivations and accessibility combined with an awareness of reach, freshness and reliability clues, the designer improves much more than simply the offline experience. It won't be simple, but in the process they'll have created an accessible, fast and easy-to-use product from the start. This is the promise of designing offline first.

This article originally appeared in net magazine issue 293 – buy it here!

Further reading:

You might like Jesse Beach's takeaway from the second Offline Camp in Santa Margarita

Related articles:

• When to ignore 'Mobile-First'
• 5 UX lessons you can learn in the toilet
• 10 really useful responsive web design tutorials

View the full article