Apps offline

I'm in the process of thinking through an offline state for one of our apps; this app, like others, requires an Internet connection to do pretty much anything. To get started, I did a quick audit of several apps I use regularly to see how they handled the same situation. I excluded apps that work offline.

Here is a sampling of those screen states; click or tap to see larger versions.

What I saw

I noted three primary paradigms.

  1. A system alert
  2. A memory state with an in-app alert banner
  3. A dedicated offline state

Some had a combination of states, e.g., a system alert with memory state. System alerts generally offered the option to open Settings.

Some apps retrieved old content (a memory state), but would present a message — usually in banner form — alerting me that I was offline. Facebook, for example, let me see old posts, and even draft new posts — nice.

Some apps presented a refresh button or other similar action to re-test my connection. Others, like Medium, were vague and offered little help. Some apps, like Yelp, took this as an opportunity to use a little humor.

In reviewing the apps, I asked myself the standard usability questions:

  • Was it obvious what had happened?
  • Was a solution provided?
  • Was it clear what to do next?

Why it matters

Even though it's 2015, there are no guarantees your app will have online access. Designing for this edge case is critical if your app requires it.

Don't kill the modal

Back when computers were coal-powered, showing more information to site visitors meant shuffling them off to a new page. We were sad.

In time, the modal window was introduced, and those of us who built websites considered it our savior: it permitted the presentation of relevant, contextual content or transactions in the same screen. We were happy.

Over time, however, we abused our savior: we began stuffing entire pages of content or multi-step forms into that poor little floating box. (And don't even get me started on ad modals that appear the moment you land on a new screen.) All of this misuse and abuse of the humble modal has left many calling for its demise. 

But the modal still serves its original, invaluable purpose of presenting snippets of content or simple transactions in a focused area without forcing a context shift. On TED, for example, we implemented a modal that lets users do things like save talks to watch later without having to be redirected to a login screen first. 

So instead of getting rid of the modal, let's be smart about its use:

  • Use a modal when a trip to a new screen might be overly disruptive.
  • Include no more than a few lines of content or a very abbreviated form.
  • Avoid spawning a new modal from an existing modal.
  • Allow users to close the modal multiple ways — e.g, the esc key or clicking outside the modal — not just a close button.
  • Fix the modal's position so it can't scroll off-screen.
  • Make sure it works well on mobile, or design an alternative.
  • Make it accessible.
  • Never spawn a modal automatically (unless you'd like a midnight visit from Jakob Nielsen).

If a modal isn't right, but shifting screens is less than ideal, there are alternatives including slides, accordions, expanding panes, and enhanced tooltips. These are all great ways to add depth while keeping people anchored in the current experience, but none is a universal replacement for the humble modal.