Getting Started With Offline Design Patterns
The discovery of a proper solution to any given problem will always pay homage to the contexts and motivations wherein it became a problem to begin with. Without understanding them, the problem is — in effect — groundless, with the solution swimming in a sea of assumption.
The tremendous benefit we have with Offline First is that the exploration of a solution always starts within a context. Our digging does not stop there, but at least we’re grounded in a circumstance where our customers’ challenges are easier to identify.
In a session at Offline Camp California focused on UX/UI patterns, we surveyed a lot of ways web applications solved their own offline problems, but eventually returned to discuss the ever important “why” that guides the “how.” So, we began looking into motivations and anxieties.
Motivations & Anxieties
Jesse Beach did a wonderful job outlining the anxieties we used as a contextual basis of understanding for our discussion in her post, which you should read, but I’ll summarize and amend those a bit here.
With each motivation there are different combinations of anxieties that may affect your confidence in the successful outcome of your actions. Those concepts of anxiety, as Jesse cleanly defined, are Freshness, Reach, and Assurance. Let’s get to know them.
Freshness
So, how fresh is this content? When did I last edit it? When did I last view it? Have there been any updates since the last time I viewed it? These questions all refer to my understanding of the freshness of the content in question. The content could be the Financial Times, a draft of a blog post I’ve been writing, or a risk assessment of my doomed reinsurance portfolio.
Generally speaking, communicating Freshness can be a good way to help people better assess whether or not something is worth loading. In exploration, we found several decent ways to communicate Freshness:
- Showing timestamps on content (such as “last edited“ or “published on” dates)
- Showing when you have last viewed that content (helps when deciding if it’s worth the time to view it again)
- Showing if there have been any updates (often a red dot, a number, or other locally understood symbol)
Communicating Freshness is useful in any context, but what about when you’re completely offline? In this context, the clarity delivered could use the extra help of communicating one’s Reach.
Reach
Where can I go from here? How much content am I able to get in my present state? Is there a limit? Am I going to hit a dead end and lose all progress?
To me there is some part of Reach that feels tied closely to Assurance (explored below), but Reach speaks very neatly to the anxiety of not knowing how much you can (or should) do. If you are aware of your offline context, you may choose to act accordingly, however in most cases it’ll be a failed request that informs you of this state.
This makes me a huge fan of Jesse’s proposed states of reachable, unreachable, and unknown to help one understand their capabilities in the moment. It is currently unknown to me how we could communicate unknown, but we did come up with some interesting and not far-fetched concepts for how we can standardize or guide the improvement of reachable and unreachable experiences.
- Reachable: a state in which, without doubt, an action may be performed or content may be retrieved without error
- Unreachable: a state in which, without doubt, an action is unavailable or content will not be retrieved
One could argue that the non-existence of an unreachable state is enough to communicate that content is reachable, but I think that the precedent set by a reachable state is that it may at some point be unreachable. It gives space for recognizing a possible opposite scenario. For example, how do you know that one Cheerio is burnt by looking at it? Because all the other Cheerios are not.
In general, I agree that these could add a lot of cruft to an already crowded web, but I believe we should be careful not to minimize to the point of intangibility in the tools and applications where it can count for something. Our choice to include such states should be guided by our core interactions and product value delivered to the people using them.
Nolan Lawson pointed out, as a form of Reach, the symbol used by Google AMP Caching to communicate that a page will load quickly on mobile. This is really useful to know when you’re in the mode of impatiently gambling seconds of time for successful search results and might want to risk clicking on a vague result.
Assurance
What is my responsibility as a user to secure my own data? Do I have any responsibility at all or does the application take it all upon itself? Do I feel confident in this?
As mentioned above, I think Reach and Assurance have a lot of overlap as concepts. I think we can define Assurance in two ways similar to Reachable and Unreachable:
- Assured: an indicator that represents, without doubt, what is being, and what has been, performed
- Unassured: an indicator that represents, without doubt, that an action has not, or will not be performed, and reveals what actions must be done to correct course
As Jesse communicates, synced and saved are pretty well-known concepts and are good to reuse to communicate the state of your data. They might be seen as:
- Unsaved (or “Save”)
- Saving or Syncing Changes
- Saved or Changes Synced
- Edited (invokes Freshness)
When all anxieties have been addressed according to the shape and function of our application, we can consider it more accessible, friendlier, and hopefully considerably faster. While all of these concepts are aimed at the application itself and it is invaluable to consider what we can do there, it is worth recognizing that our applications are experienced within a device and, in the case of web apps, within a browser. It’s important to consider what these contexts enable us to do, but also what they can do to facilitate a better offline experience themselves.
In closing, I’ll pose three questions. To improve the speed, capabilities, and dependability of our Offline First apps:
- What is the responsibility of the developer?
- What is the responsibility of the browser?
- What is the responsibility of the hardware?
To answer these questions, and to set the standard for Offline First applications, we as a community have a responsibility to work together to explore the diverse use cases for offline technology and its equally diverse users. To achieve that, we need people from all areas of the community and all skillsets (design, development, product, leadership) to engage in making it happen.
I’ll start by continuing to explore these concepts of Freshness, Reach, and Assurance. How will you?
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.
Check out this article from Steven, originally published in Net Magazine, for more on the challenges of UX design for Offline First:
