Designing the offline experience

In the last section, you configured the tools necessary to make your app real. Now, let's step back and design the app in the context of some of the offline scenarios that we discussed in Chapter 1, The Pain of Being Offline.

What do users need from this app and why?

Designers often employ user stories to break a scenario into chunks. Each user story takes a person, describes a specific need that they have, and reveals the context behind the need. The format that we will use in this book is as follows:

• As [a person]
• I want [to accomplish a goal]
• So that [context about the goal]

Let's talk briefly about each clause. How do user stories help us understand what we need to design and build?

• As [a user]: This helps us understand who we're building for. If this person works with other people, we can (and should) consider how they will work together as a team. This is extremely important in communication-oriented products. Our simple to-do app considers a single user, Susan, but you could easily write additional stories that reference her friends, acquaintances, and coworkers.
• I want [to accomplish a goal]: This helps us understand what the person is trying to get done. It should focus on actions and goals with a concrete outcome. By itself, this isn't enough to tell us what to build. We still lack the context around the need. That's what the next clause informs us about.
• So that [context about the goal]: Unlike the As and I want clauses, there may be multiple So that clauses in a single story. The context behind a need may be complex so we should capture it fully. These help us understand the motivation behind the need. Motivation is important because the same need with different motivations can manifest itself in very different solutions. For example, so that I don't lose my job will result in a very cautious, accident-averse solution as compared with so that I learn to fail quickly.

Once you've written one user story, write another. Depending on the complexity of the scenarios and granularity of each story, an app may have as few as five user stories or as many as fifty. However, it is unlikely that you will build all of them at once. This is an exploratory phase to discover needs that are both primary and ancillary to the app that you're building.

User stories do not live in isolation. If your app is at all complex, you should map the stories relative to each other. This will help you spot patterns that may influence the way you choose to implement them. Give each user story a brief title in order to make it stand out at a glance, then group the stories by user, function, or complexity. We won't map our to-do app stories as there are so few of them, but definitely read about story mapping online if you want to learn more.

Here are five user stories associated with Susan's scenario from Chapter 1, The Pain of Being Offline:

• Items should display while offline: As Susan, I want my to-do items to always appear once they are downloaded so that I can remain productive while offline, I don't have to worry about data loss, and I can learn to trust my to-do app to Do The Right Thing?.
• Keep all my devices in sync: As Susan, I want the to-do items on all my devices to remain in sync so that I don't have to wonder whether a device has a particular to-do item, I can just grab the nearest device and start typing, and my source of truth is the list itself, not one of several devices.
• Don't keep me waiting: As Susan, I want my to-do app to feel fast and ready to go at all times so that editing my to-do list is as frictionless as pen on paper, I never feel like I'm waiting, and I don't give up and neglect to write something down.
• Sharing with friends should be bulletproof: As Susan, I want to share items easily with friends regardless of where we are so that we can coordinate ourselves, sharing with friends who are close by feels visceral and physical, and I don't have to rely on third-party solutions, hacks, or intermediaries.
• Safeguard my data: As Susan, I want everything that I type in the app to be preserved so that I don't lose anything accidentally, the app earns my trust, and I can always go back, revert, undo, and so on and so forth.

How will people accomplish their goals using the app?

User stories do two things: they point us in the direction of the final solution and give us constraints that eliminate options. Both of these functions are valuable but still very abstract. How do we flesh out the design in more detail?

One excellent approach is through workflows. Workflows describe a path, or paths, through an application by which people can accomplish their goals (as illustrated in the user stories). They are most often visualized as flowcharts.

The following flowchart describes the offline workflows through our to-do app. The chart consists of two types of components: rectangles and circles. Rectangles represent specific views in the application by which people can observe the state of the UI and orient themselves to it. Circles represent specific actions that people may perform on a view:

Workflow

With this basic workflow in place, let's look at each user story and see how the workflow maps to it. Some of the user stories imply an online experience and thus won't be solved in the first offline version of the app. We'll note this where appropriate.

Items should display while offline

As the entire app is offline, this is a trivial problem to solve. Items created in the to-do app are always stored locally and thus always available for display. We will solve this more rigorously in Chapter 4, Getting Online for the online case.

Keep all my devices in sync

As the first version of the app is offline, each instance of the app has its own local database with no syncing required. In Chapter 4, Getting Online, we will introduce multidevice support and add incremental improvements in Chapter 5, Be Honest about What's Happening, Chapter 6, Be Eventually Consistent, and Chapter 8, Networking While Offline.

Don't keep me waiting

Again, this is trivial to solve in an offline context. Loading data from the local storage is extremely fast. When we add online support, we will have to account for network bandwidth and latency with delays of milliseconds (or even seconds). We will address these concerns in Chapter 7, Choosing Intelligent Defaults and Chapter 8, Networking While Offline.

From an interaction perspective, the workflow implies a maximum of three clicks for any path. The worst-case scenario—editing an item—involves the following steps:

• Click an item in the list to view it
• Click to edit the item
• Click to save the item

This is reasonable but could be improved to one or two clicks if we employed inline editing or autosave. For the sake of simplicity, I will leave this as an exercise for the reader.

Sharing with friends should be bulletproof

Technically, sharing does not require an Internet connection. With Wi-Fi and Bluetooth, it is possible to share to-do items without an Internet connection. We will solve basic sharing over the Internet in Chapter 4, Getting Online with an exploration of Wi-Fi and Bluetooth in Chapter 8, Networking While Offline.

Safeguard my data

While offline, the phone is the source of truth for the data. As long as the phone has regular backups, data is relatively safe. However, with an active Internet connection, we can back up the data to the cloud at more frequent intervals. We will implement a basic Internet backup solution in Chapter 4, Getting Online with improvements in Chapter 5, Be Honest about What's Happening and Chapter 6, Be Eventually Consistent.

What does the app look like, roughly?

In the workflow, we can see that there are three primary views in the app: a list of to-dos, a form to create a new item, and a form to edit an existing item. Let's build these with some basic wireframes.

It's often the case that you don't end up with a carbon copy of your initial design. As you iterate on the design and turn it into code, you will discover obstacles, easier ways to do something, or a better approach. As long as the finished solution works and complies with your requirements in a well-designed way, it's actually better to adjust your design to these realities as you go along.

As we build our to-do app, you'll notice some of this behavior. In this chapter, compare our wireframes with the finished product. While we won't go into the reasons behind the discrepancies, think about why these differences exist. Would it have been better to stick with the original design or is the final app actually simpler and better than it otherwise would have been?

A list of to-dos

This screen displays a list of outstanding to-do items. It allows you to create new items, view the existing items, and restore the Deleted items. Here is one possible solution:

To-do list wireframe

There are two lists. The top list contains all the active items and the bottom list contains all the inactive items. To create a new item, click add todo item. To view an existing item, click it. To restore a Deleted items (or delete an active item), drag it from the bottom list to the top list (or from the top list to the bottom list).

Creating a new item

This screen is used to add a new item to your to-do list. As the workflow doesn't provide any insight into what a to-do item consists of, what are Susan's use cases? She wants her to-do app to be quick and easy to interact with, so we'll add as few fields as possible:

• Text description. This is how Susan refers to her to-do items. The description should be short and concise so a simple input field will suffice.
• Image: Susan is a visually-oriented person. She takes pictures of things to get done on her iPhone and then tags her to-do items with the images.
• Location: She doesn't want to have to check her to-do list all the time. Instead, she wants her phone to notify her when she's in the same location as a task that needs to be done.

With these criteria in hand, here's one possible solution for this screen:

New item wireframe

Click the Description field to set a description. Click on Select… to attach an Image or video to the item. Choose a radio button to set a Location for reminders. Click on Save to commit your changes or click Add a todo item to go back without saving.

Editing an existing item

This screen is very similar to the new item screen. It is used to make changes to an existing to-do item, which means that the design is identical, except that the fields are prepopulated by whatever is assigned to the to-do item:

Edit item wireframe