“Offline First”

Saw a couple things on Twitter this morning that got me fairly excited. First, the folks at Hoodie published a blog entry outlining just how important it is to design for “offline first.” In other words, assuming that someone has a persistent, robust data connection is an artifact of the desktop-focused web, and we need to refine it.

Now, I haven’t used the Hoodie service. But over the past year, I’ve spent a stupid amount of time thinking about that idea: that “offline” should be the default case we design for, and treat “online” as the enhancement. So yeah, I got a little excited when I saw Offline First’s mission statement:

We live in a disconnected & battery powered world, but our technology and best practices are a leftover from the always connected & steadily powered past.

Emphasis mine, but this is good. This is very good. As Aanand Prasad beautifully states it:

Mobile Internet connectivity is rubbish. I’m a Vodafone user living in London, and seeing the 3G icon in my iPhone’s status bar is as commonplace and pleasurable an event as finding somewhere you can sit down to drink on a Friday. This has profound implications for the assumptions you can make when designing the communication logic of your application, if you value the mobile user experience.

I might go so far as to say “offline” is almost an unhelpfully broad term—just as broad and inexact as “mobile” is, when you think about it. As Aanand said, an “offline” user really means someone whose connection is far from persistent and, well, unreliable. And it covers far, far more folks than we might think. According to some estimates, an overwhelming majority of the world’s mobile-connected users are on sub-3G networks—no 4G, no LTE. (That is, of course, another reason we need to ensure our work is as light as possible for everyone.)

But the other thing I liked about both of these articles—and then I’ll let you go, I swear—is that this isn’t just a technical challenge. In fact, the biggest problems might be design- and UX-related. How do you properly communicate to a user that she’s lost a connection? Or do you need to? What parts of your interface should be available in both states? Given just how much can potentially go wrong between someone requesting a page and downloading it to their client, designing and planning for those points of failure is really, really exciting to me.

(Update: As with most things, it would seem Cennydd Bowles got there ages before I did.)