Offline first Absolutely.

We live in a disconnected & battery powered world.

Build apps which assume that any server they need might not be there. Mobile apps which don’t start being unreliable when you’ve got dodgy connectivity. Save everything locally and then sync it.

The key word here is “sync”. To build a proper modern app, which not only copes with inconsistent connectivity but doesn’t bother the user about it, you have to save your data locally and then sync it up to the backing store, wherever that is (whether it’s a server provided by the app maker, or your Google account, or remoteStorage, or some personal thing like a PogoPlug). This means that the backing store, and your app, has to be able to cope with inconsistent and conflicting data. This is a hard problem to deal with; when I was working on Ubuntu One, we spent a lot of time with it. So… don’t try and roll your own solution. Really. Use something that’s already out there to handle data with syncing. can do this for web apps you build, or use Pouch; Parse or Firebase are similar public commercial services. The Ubuntu SDK has U1DB. Apple stuff has iCloud. Android has the backup API. Building an app for offline first means dealing with inconsistent data, but there’s no reason to not have an existing framework take on some of that load for you.

The offlinefirst people are starting a conversation about the user experience here. After a few years of working on this, the technology is mostly worked out (as you’ll see above), but we’ve hardly brushed the surface of how to present this to the people using your apps. In my heart I believe that there should be no presentation of it: that your app should just look and work exactly the same as it does in a world with infinite always-on bandwidth. That the “user experience” of offline first is that people like your app more not because it’s better, but because it’s not worse: because it never breaks even when you’re in a train tunnel. It’s not something you’d notice, unless you sat down and thought about it, in exactly the same way that no-one gives out credit because your app doesn’t crash much, unless all its competitors crash more. And I fear that exposing this stuff to the user interface is a way of saying “look, we had to do tons of really hard technical work to make things this smooth; we deserve a little bit of the UI which shows that this really hard technical stuff is working away in the background”, which is not a good argument.

But that’s a naïve thought. Ideally that’d be the case but clearly it isn’t. There is a difference between “this is offline” and “this is online”, even if only in the edge cases: if I’m typing my shopping list on my laptop before I pick up my phone and run out the door to the supermarket, I need to know if that shopping list has actually made it to my phone before I turn the laptop off. If the synced status of your data is entirely invisible — that is, we pretend that it’s all synced, all the time — then you get bitten on the one time when it wasn’t synced but you needed it to be. This sort of thing is what I think the conversation will be about, and it’s going to be fascinating to be a part of it.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • (no mentions, yet.)