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:
We have to convince other developers that this will help us build better products, more efficiently
We have to convince other designers that this will improve the user experience
We have to convince our boss or others in upper-level management that this will increase our revenue
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.
Developers care about efficiency and don't want to write more code than necessary. The extra care that goes into an offline-first application can, at a glance, seem to necessitate more code. You might get pushback that the team wants to build the easiest thing first and leave the offline functionality for later. This is a mistake. Instead, have a discussion about the architecture and tools that can ease the development effort.
In Chapter 4, Getting Online, we'll show how tools such as PouchDB, remotestorage.io, and Hoodie, custom built for offline use, can greatly reduce the amount of code that your team will need to write. These tools allow you to write good offline code, once. As applications are built, they gain complexity. This complexity makes them more difficult to change in the future. Using the right tools up front can save days or weeks of development time over the long run.
To make the case, show all the ways that an online app that is not optimized for offline usage can fail. The following chapters will talk about these situations in detail. Describe the pain that users experience while encountering these scenarios. If possible, take an existing app and write a task-based script that exercises these scenarios.
If your team is still skeptical, find people willing to try offline tasks on the app that you've built or a simple prototype. Invite your coworkers to attend. There's nothing like a firsthand observation of people struggling with a key part of your app to convert team members to your side.
Functional designers care about how people solve problems using the app. The trick is that there are many problems to be solved and you can't expect others to give offline problems the priority that they deserve. One way to measure priority is by the number of people affected by the problem. As offline problems are so widespread, you can make a strong case that every person using your app will benefit to some extent.
To start the discussion, build a task flow diagram for your application. This will help you see the scope of the app from a workflow perspective. In the diagram, point out the offline error cases and how these will affect the experience that people have. When functional designers see all the dead ends that their target audience might experience, they will be motivated to join you.
Visual designers may be a bit harder to convince. They too care about the experience of an app but care more about the clarity of the presentation rather than the functionality. Take the task flow diagram that you built earlier and mock rough screens that correlate to each step in the flow, including the error cases. Make sure that everyone is aware of the total surface area to be designed, not just the happy path. Often, designers don't see the whole picture up front because they're working from a theoretical model of how things might work, not a model that has been battle-tested in the real world. By building an accurate map of the world, your designers become better equipped to design a clear and delightful interface.
The business cares about generating revenue. This goal is often in opposition to spending time on quality software that works well in a variety of adverse conditions. Correspondingly, these are some of the hardest people to convince. You must show that changing the way you do design and development will positively impact the bottom line.
People have a very low tolerance for apps that don't function. Only 16% of those who fail to use an app the first time will return (http://techcrunch.com/2013/03/12/users-have-low-tolerance-for-buggy-apps-only-16-will-try-a-failing-app-more-than-twice/). If one of the 4 billion people that are without a regular Internet connection tries to use your app and can't because they're offline, how long will they stay with yours before uninstalling and switching to a competitor's app?
On the other hand, if you're the only app among your competitors to provide an exceptional offline experience, you're more likely to gain market share and positive reviews from the billions of people impacted by poor offline experiences.
Revenue aside, if there are people in the management chain who care about design, your job is easier. The higher they are in the chain, the easier still. You can argue with them about design on even terms as they're already convinced of its value. If the CEO wants well-designed products, your job as a design emissary is done.