A common practice is to design for the happy path, a scenario where everything works correctly and according to plan. These scenarios tend to paint an overly optimistic picture of the real world. When the happy path meets real-world problems, the charade is over and the app must undergo serious revision or a rewrite.

This is bad for a number of reasons. Obviously, rewriting an app is costly. One of the tenets of good software development is to fail quickly and rapidly. If you finish your app, only to find that it doesn't work as advertised, you've failed far too late. Even if you don't have to rewrite the app, bolting on fixes to address fundamental problems with the underlying architecture can cause bugs that tend to linger until the inevitable rewrite.

The alternative is to start by designing for a worst-case scenario. Worst-case scenarios are more representative of the real world so apps are more likely to behave as you expect. These scenarios tend to be harder to solve but result in a robust solution that covers more edge cases. As a worst-case scenario is a superset of the happy path, you get two solutions for the price of one.

This strategy can be employed in many other areas, such as security, responsive web design, accessibility, and performance. The approach is simple. Pick one or more worst-case scenarios that impact your app the most and build with these scenarios in mind. A worst-case scenario is an excellent constraint. The more constraints you add, the easier it is to design a great solution.

So, what is an offline user experience? We can boil down the principles from Susan's list in the previous section to form a concise definition:

An offline user experience bridges the gap between online and offline contexts by providing equivalent functionality and content to the extent that technology and the laws of physics will allow.

To design this experience, it's vital to understand the pain and frustration that people encounter every day. There are a million ways to build an offline-first experience, but the correct solution is formed by the needs of your audience. The story in the previous section was one example but you can find an infinite number of scenarios. Once you know who you're developing for and their pain points, devising a solution is much simpler.

Let's go through a few more offline scenarios to get you going. Once you start thinking about who your audience is, write scenarios such as these to describe how the offline experience impacts them. Talk to people. Observe them in the real world. Do research to see what others have found. These are all the things that can help you build a more accurate picture of your target audience.

Once you've compiled a few scenarios such as these, identify some common principles to build your app around. Here are the principles that Susan identified at the beginning of the chapter, with a more detailed explanation for each one.

Give me uninterrupted access to the content I care about.

When offline, you don't want to open your app and have no content to consume or interact with. You want to have lots of content available. As an extreme example, a web browser that allows you to surf the entire Internet, as it appeared when you were last online, would be a fantastic experience. This doesn't exist because the laws of physics prevent such an experience.

Naturally, you can't provide an infinite amount of content for people. Instead, provide as much content as possible without hurting the user experience in other ways (that is, don't steal all their bandwidth, don't fill up all the space on their device, don't let the performance suffer, and so on).

Content is mutable. Don't let my online/offline status change that.

One common practice is to make content read-only while offline. When online, you can edit, delete, or manipulate the content, but offline, the only thing that you can do is view it. People want to work with their data regardless, but you're telling them that they can't, usually for no good reason.

Instead, as much as possible, make online behavior match offline behavior. Once you've decided what people can do with their data, try to apply these decisions to all situations. You'll make their lives easier, and yours, as you only have to design and build a single interaction paradigm.

Error messages should not leave me guessing or unnecessarily worried.

A cryptic error message is a bad error message. Well-designed applications should be clear, using human language and a consistent vocabulary. Error messages should be no different. Unfortunately, error messages are often overlooked in the design process. When this happens, the application assumes two faces: a friendly face when everything is fine and a distressing face when things go wrong.

The effect can be jarring and incomprehensible to some people. When their world is falling apart, they need more reassurance and help from their tools, not less. Make sure that you think about the wording in the error messages and how errors present themselves visually.

Don't let me start something I can't finish.

While performing a task, the further I get, the more vested I become in the outcome. For example, let's say I start a task consisting of eight steps. On step seven, if you tell me that I can't finish because I'm offline, I'll be frustrated. If you tell me that I can't save my progress and will have to try again later, I'll be furious.

Don't do that. Be up front about what I can or cannot do. Don't let me proceed down a path with a known dead end.

An app should never contradict itself. If a conflict exists, be honest about it.

In Chapter 6, Be Eventually Consistent we'll discuss split-brain scenarios. A split-brain scenario occurs when two people change the same data at the same time, on different devices. When the devices try to reconcile their data automatically, they can't. It's up to people to decide what change to keep and what to throw away.

In a poorly designed application, several things can happen. The app can clobber one of the changes without asking, resulting in confusion. It can show both of the changes side by side without explanation, which is also confusing. It might also enter a cryptic failure state, which leaves people even more confused and powerless.

Always get input from people when a conflict cannot be automatically resolved. If you must show inconsistent data, always provide an explanation.

When the laws of physics prevail, choose breadth over depth when caching.

As mentioned in the first principle, infinite caching violates the laws of physics. There will often be more data than you can reasonably cache. You have to make a prioritization decision. What data is most valuable to people? Cache that data first.

In most applications, there are different types of data that can be cached. As older data is usually less valuable than newer data, the more you cache, the value of caching in a particular category goes down. At some point, continuing to cache a particular data type is less valuable than switching to a different data type.

First, cache a small set of data across all the types. Then, go progressively deeper across all the data types simultaneously, with the more valuable types prioritized. As a result, no empty screens will appear when people skim the app. The UI will feel data rich on the surface and deep in all the right parts, which is what they want.

Empty states should tell me what to do next in a delightful way.

If there is nothing in the cache, you will have to show an empty state. There is very little that people can do with these states, which is a bad experience.

However, these states can be more than blank screens. They can tell people what to do next. They can be delightful: providing a clever message, image, animation, or video that people wouldn't ordinarily see. They can contain sample data, which people can interact with to see how the screen would ordinarily work. They can even keep people entertained with a game, puzzle, or other distractions.

Empty states are very easy to ignore. When engineering resources are tight, they are among the first things to be cut. Figure out how often people will see these relative to the other screens and then apply resources appropriately. During offline usage, empty states are more likely to occur.

Don't make me remember what I was doing last. Remember for me.

Context is king. If I close my app, preserve my current state. When I reopen the app, I want to see what I was doing last or find it simple to get there. The more complicated the app, the more important this is.

Many apps forget the context when switching from online to offline. They give themselves permission to reset certain parts of the UI, which is jarring and easily avoidable. As with most of these other principles, don't compromise on the attributes of a good experience just because an app happens to be offline.

Degrade gracefully as the network degrades. Don't be jarring.

Networks are not binary. There is a lot of gray area between not working at all and working very well. One of the goals of an invisible design is to avoid speed bumps in the user experience. An interface may switch abruptly from an online mode to an offline one, or worse, toggle rapidly between the two states. If implemented poorly, this will interrupt the flow and make it more difficult for people to get their work done.

Help the application see or anticipate an impending loss of connectivity. When appropriate, it should scale back its bandwidth usage, avoid massive changes to the interface, and gently nudge people if they are encountering any problems. The goal is a smooth transition from online to offline that informs the user in an unobtrusive way.

Never purge the cache unless I demand it.

Cache is the most valuable aspect of an offline experience. If the cache goes away while offline, people won't have any content. This is a bad experience. Protect the cache at all costs. Don't clear it unless people ask for it explicitly (usually for security reasons).

The latter implies an affordance to clear the cache. Web browsers have one but a lot of apps don't. This is extremely important, particularly when login credentials are involved. People may want to purge their data for a good many reasons. They may even need to do it remotely from another device.

Unreliable and nonexistent Internet connectivity is a widespread problem, both in highly developed nations and nations that are less developed. Consider a few statistics from ITU, the United Nations specialized agency for information and communication technologies (http://www.itu.int/en/ITU-D/Statistics/Documents/facts/ICTFactsFigures2015.pdf):

If you optimize for a fast Internet connection, you are making an implicit decision about who you're designing for. If you don't want Internet connectivity to dictate who can use your app, design the offline experience first. Even if you're building an application that only Americans will use, consider that potentially 3 out of every 100 people are eking out a mere 56 kbps. Every megabyte has a large impact on their user experience and ISP bills.

This doesn't mean that you have to build an app that looks like Craigslist. There are intelligent ways to make an app scale its behavior based on the Internet connection available. You can even use location services to become aware about the potential dead zones in time to take preventative measures. We'll cover these strategies in Chapter 8, Networking While Offline.

Are you convinced that building with an offline-first mindset is a good idea? Great! Now, how do you sell this vision to the decision makers around you? Many activities have a negative impact on productivity in the short-term but a positive impact in the long-term: writing tests, conducting user research, including good comments in the source code, and so on. In the same way, switching to an offline-first paradigm can be perceived as an unnecessary distraction, even though the long-term benefits are clear. Let's address this now.

If offline usage is so important, why don't we optimize for it? One reason is internal: it's hard to change our innate behaviors and habits. Developers are on the cutting edge and have difficulty imagining a world where computers are slow and Internet connections are flaky. Fortunately, there are tools to help us simulate that other world.

Even if we overcome this obstacle, there are still external hurdles to change:

These are harder conversations to have but worthwhile. One of the goals of this book is to provide the evidence that you need to convince the developers, designers, and management in your organization. Offline-first development can improve your ability to deliver in all of these areas.

In this chapter, we established a case for why you want to approach application development with an offline-first mindset. In the next chapter, you will build a basic offline to-do app. Each subsequent chapter will build on this base. By the end of the book, you will have transformed this base into a fully capable online app that translates seamlessly between the online and offline worlds.

Open your development environment and let's get started.