Offline First (Web) Apps - Fronteers 2014

Oﬄine-First
BETTER (WEB) APPS
Alex Feyerke / @espylaub
Fronteers 2014, Amsterdam
Good afternoon!
This is „Ofﬂine First Web Apps“, my name is Alex, I‘m a web designer from
Berlin, and I‘m very grateful to Flurin and the fronteers team for inviting me
here. I‘m part of the team that makes Hoodie:

View Slide

an open-source server that lets you quickly build complete, data-driven web
apps from the frontend. It‘s like jquery for data storage. And Hoodie is a bit
special, because these apps are ofﬂine capable by default, meaning they won‘t
break when the connection goes down, and this is basically why we‘re so
interested in this whole topic.
Source: http://hood.ie

View Slide

Offline-First
Concepts
Interfaces
Experiences
Problems
So, first of all, what this isn't: a step by step guide to actually building offline
first apps. I don‘t want to stand here and explain to you how this one thing
works at this moment, I‘d much rather spend time showing you what it means,
and getting you interested in the general idea.
[read slide]
But before we get started, let‘s talk about how we work.

View Slide

How we work
IT‘S BASICALLY
SCIENCE FICTION
We make web apps. Or native apps, for our purposes, it doesn't make a
difference. But we make, and while we make, we imagine those things we
make in their completed, working, usable state. We imagine them in the future,
where all the cool people are using our stuff and making us rich and famous.
Or at least internet famous. Maybe just Kickstarter famous.

View Slide

Maybe you‘ve seen plastc, this „20 credit cards in one“-thing, and like most
pre-order/crowdfunding people, they have a vision, and they have a video. And
it‘s basically a tiny slice of science ﬁction, a year in the future: „here‘s how we
imagine real human beings behaving in the near future“.
And, of course, the technology that goes with it. It‘s small and speciﬁc and
mainly related to how people pay for things.
[plastc.com]

View Slide

But there are other ways of imagining the future. Microsoft, for example, is a
big monolith of a company, and it loves imagining the future in more elaborate
ways. They regularly release a so-called "Productivity Future Vision", like this
one, for 2011. The name sounds as if someone just pulled three human
resources buzzwords from a hat, but let‘s take a look:

View Slide

https://www.youtube.com/watch?v=a6cNdhOKwi0
Microsoft‘s Productivity Future Vision 2011
But it feels… wrong. It's too smooth. It's not normal enough. It‘s a
choreography of wealth and status, and it‘s utterly improbable in its perfection.
And maybe you noiced: the devices still have recognizable pixels, but none of
them have battery or signal strength indicators.
Source: https://www.youtube.com/watch?v=a6cNdhOKwi0

View Slide

Everyone's happy, nothing is broken or
smudged. There is infinite wi-fi with
infinite bandwidth, no batteries run out,
no traffic, no delays.
—Tobias Revell
Critical Design / Design Fiction
You should absolutely read those lecture notes, by the way. It's eye-opening
and very well done, which is why I'm stealing a bit more from it.
[source: http://blog.tobiasrevell.com/2013/12/critical-design-design-fiction-
lecture.html]
Look at this Google Glass promo:

View Slide

https://www.youtube.com/watch?v=v1uyQZNg2vE
Google Glass Promo Video
This is marginally better: there‘s normal stuff like playing with dogs or a flight
being late, but the basic symptoms are the same: the people, the lives, the
circumstances: most of them are outliers, all very privileged people in a kind of
post-scarcity scenario where, as Revell puts it, "it's a classic case of everyone
suddenly being an ice sculptor and flying around in balloons". It's also not
normal. It's a fantasy, and as far as goals and dreams to work towards go, it's
all a bit odd.
But it‘s more nuanceed, too. It has some degree of normality, and it‘s implying
something interesting: people are using glass in places without network
connections, as in, you know, the sky.
Unless that balloon in the beginning was one of googles top-secret internet
balloons providing wifi to the skydivers and the flying club, I think the
implication is they‘re expecting it to work offline. So: still improbable, but has
hints of normality.

View Slide

Let‘s go back a bit
This next one is from 1969, with a vision of the 1990s. So I‘d just like you to
picture that in your mind for a second. The future, seen from the 60‘s. You‘ve
all seen the movies. Ok?
Now consider that this was made by the British Post Ofﬁce…

View Slide

https://www.youtube.com/watch?v=ONESDY9KMes
Post Office in the 1960s - A glance 30 years into the future
from Dollis Hill Research Station
It seems rather normal. Why is that? People aren't wearing futuristic clothing,
doing extraordinary things, or even sitting at transparent desks with flashy
lights everywhere. We see a normal man at a normal desk in an normal office.
Also: the very first thing that happens: it doesn't work properly. The guy at the
other end can‘t understand anything. And the weather's bad. It's London, Bad
weather is normal. Listen: "suppose she makes an error". People don‘t make
mistakes in Microsoft‘s future vision. Nobody asks „uh, Glass? Did you hear
me?“ in the google thing.
And the topics? Leases, bank statements, mortgages… normal normal normal.
It's mundane, it's a bit wonky, but it's everyday life.
Source: https://www.youtube.com/watch?v=ONESDY9KMes
So thinking about the future is obviously a bit hard, because…

View Slide

[…] for every miraculous iPad there are
countless partly broken realities: WiFi
passwords, connectivity, battery life,
privacy and compatibility amongst
others.

View Slide

The real skill of creating a compelling
and engaging view of the future lies not
in designing the gloss, but in seeing
beyond the gloss to the truths behind it.
—Nick Foster
The Future Mundane
Source: http://www.core77.com/blog/columns/the_future_mundane_25678.asp

View Slide

And I just said this when speaking about this product sci-ﬁ:
„here‘s how we imagine real human beings behaving in the near future“
But what I really mean, and what you really want, is
„here‘s how we imagine something utterly normal happening in the near future“

View Slide

We‘re not normal
I'm showing you all this because we, as, and I'm sad to have to say this from
up here, as well-educated, well paid people in the tech industry in a super-
wealthy country, we're also not normal.

View Slide

And the circumstances in which we work aren't normal, they usually bear little
relationship to how and where our products will probably be used. We build
from behind shiny macs with full-sized keyboards in well-equipped ofﬁces with
fast connections, but the target environments are radically diverse and
different.

View Slide

It used to be that if your device could consume the web, it could also make it.
That‘s no longer true.
First, you had to learn that people‘s devices were different than your dev
machine, and now you realize that their circumstances are also very different,
and require a bit of an empathic leap.

View Slide

Our circumstances
deﬁne our mindset
We have the best tools and the best infrastructure available to us, and of
course, that informs our mindset when we build all the new shiny future things.
An extreme example: If you take a google bus to work, you don't get the usual
public transport experience. You've got free corporate wiﬁ. Your commuting
experience is far, far removed from that of basically everyone else. That‘s
probably your baseline now.
But in a way, we‘re all on the google bus. And we frequently forget that we
have to…

View Slide

Build for
a normal world
Normality is where most of life happens.

View Slide

Build for
a mobile world
And the normal world, with all the normal people it, that have average budgets
and average resources, that world, from your perspective as a developer, is
overwhelmingly mobile. Phones are mobile, tablets are mobile, this thing is
mobile. This is a mobile device. There are, right now, hundreds of university
students sitting in cafes with their little laptops with 3G-USB sticks plugged in.
They'll be moving around, switching connections, losing connections, running
into battery trouble just like people with smartphones.
The big grey box is a relic. Mobile is normal.

View Slide

Normality
is imperfect
And you all know this: it's imperfect. Normality is imperfect. The web is very,
very imperfect. The experience you're building? It's going to break for people, I
guarantee it. It's also imperfect, and it's imperfect in ways you can't inﬂuence,
mainly connection speed and reliability.

View Slide

But what you can do, now, is build experiences to accommodate this normality,
experiences that go beyond your apps just breaking, becoming unresponsive,
showing empty views, losing data, making people nervous with panicky error
messages. You can now build your apps in ways that acknowledge the fact that
the web is imperfect, that your connections to it are also imperfect, and you
can provide good experiences regardless.

View Slide

Oﬄine is
not an error
because Ofﬂine is not an error.

View Slide

Oﬄine is
a fact of mobile life
and therefore…

View Slide

Oﬄine is
a fact of normal life
It‘s just a state your app can be in. And a fairly likely one at that. It‘s not exactly
an edge case.
So here‘s the basic idea behind Ofﬂine First:

View Slide

Treat the network as
an enhancement
OFFLINE-FIRST
IN A NUTSHELL
So again, this comparison to something you know already:

View Slide

Mobile First is a design strategy to help cope with the vast, ungraspable
variety of devices and capabilities, like these android screen dimensions here.
In the same way, Offline First is a design strategy to help cope with the
unknowable circumstances and connection states our users may find
themselves in, and provide good experiences regardless.
Offline First is simply an acknowledgement that this lack of certainty extends a
bit further than we previously thought.

View Slide

progressive enhancement
vs.
graceful degradation
Offline first assumes nothing about the users‘ connectivity. It‘s just another
form of progressive enhancement, really. Offline is the default state,
connectivity is a bonus.Treat the network as a potential enhancement. And in
this case, progressive enhancement really is the way to go, because adding
full offline capability after the fact is a bit difficult: the architecture is necessarily
quite different. At least we think it should be.
So, before we continue, a small foray into…

View Slide

Offline-First
Architecture
offline-first architecture. And because I promised this wouldn‘t be overly
technical,

View Slide

Oﬄine-First
Architecture
A SUPER SHORT OVERVIEW
I‘ll keep it short.

View Slide

WHAT NEEDS TO BE OFFLINE?
An App's ofﬂine capability is guaranteed through two separate aspects:

View Slide

• The app and its assets
- the app itself and its assets must be available ofﬂine. This is done through
Appcache or Serviceworker, or through a native wrapper such as phonegap or
node-webkit. In a native app, this is a given.

View Slide

• The app and its assets
• The app‘s data
- the app must handle data in a way that doesn't require a connection. This is
best done by reading and writing through a local data store which syncs, when
possible, to the server. Use Localstorage, IndexedDB, WebSQL, PouchDB or,
on a higher abstraction level, something like Hoodie.
This, to us, is the more interesting bit.
Let‘s see how hoodie handles this.

View Slide

Hoodie Sync
Here‘s how Hoodie does ofﬂine, and, in fact, everything.

View Slide

FRONTEND BACKEND
Hoodie Sync

View Slide

FRONTEND
App
BACKEND
Hoodie Sync

View Slide

FRONTEND
App
hoodie.store
BACKEND
Hoodie Sync
The app only ever talks to the hoodie API, never directly to the server-side
code, the database, or even in-browser storage.

View Slide

FRONTEND
App
hoodie.store
localstorage
BACKEND
Hoodie Sync
[explain slide]
As far as this concept goes, feel free to replace localstorage with any in-
browser storage of your choice.
This, by itself, is enough for an app. You can wrap that in node-webkit and sell
it to people who don‘t trust the cloud. But let‘s assume you want more, you
want user management and syncing.

View Slide

FRONTEND
App
hoodie.store
localstorage
Sync
CouchDB
REST
BACKEND
Hoodie Sync
[explain slide]
We can do syncing because each user has their own little private database
which only they can access. So it‘s very simple to decide what gets synced. It‘s
the user‘s private data. Of course it should be on their machine, and we can
easily keep people‘s data separate on the server.

View Slide

FRONTEND
App
hoodie.store
localstorage
Sync
Plugins
(node.js)
CouchDB
REST
BACKEND
Hoodie Sync
So, how does it work?
[Explain a direct message moving through the system]
So we never have element talk directly to each other. They only leave each
other messages and tasks, like passive aggressive roommates. It‘s all very
loosely coupled and event-based. Which means that it can be interrupted at
any stage without breaking. Messages and tasks will be delivered and acted
upon whenever possible. It‘s designed for eventual consistency.

View Slide

FRONTEND
App
hoodie.store
localstorage
BACKEND
Hoodie Sync
Sync
Anyone home?
Out for lunch,
BRB
The nice thing is: in most cases, the frontend doesn‘t care whether the
backend is actually there or not. It will hang on to your data and sync whenever
it can, and if your UI allows it, users can keep working without interruption.

View Slide

FRONTEND
App
hoodie.store
localstorage
BACKEND
Hoodie Sync
Sync
I don‘t care!
Out for lunch,
BRB
offline first apps are the web's honey badgers: they don't care, they just do their
thing. Bees, tunnels, bad connectivity: the offline badger just keeps on going.
It's how things should be on the internet: robust and fault-tolerant.
Anyway, the point was:

View Slide

FRONTEND
App
hoodie.store
localstorage
Sync
Plugins
(node.js)
CouchDB
REST
BACKEND
Hoodie Sync
If you want true ofﬂine capability, your app shouldn‘t try to talk to the server
directly, only through sync. And you always want to keep a local copy in
browser storage. That‘s really the central point: the user‘s data on the user‘s
device, always.
Sync is pretty hard. Really. You probably don‘t want to be implementing this
yourself, there‘s just so much to get wrong.

View Slide

We trust the CouchDB for this. It‘s a database that replicates, which is exactly
what we want for syncing.

View Slide

But there are others, and we‘re currently working on using PouchDB locally
instead of localstorage, because it‘s fantastic, cross-platform and speaks
couchy. Which is nice when we‘re syncing data back and forth.

View Slide

Remotestorage has a one-backend-per user approach that also works ofﬂine
and syncs.

View Slide

And there‘s even things like JSGit!
Whatever you do, try and find someone who‘s already solved this particular bit.
But remember: sync is the keystone of offline first:

View Slide

Getting into the offline mindset requires only
one key realisation: when you leave the world
of timely, reliable communication, the local
database, not the server’s, must be the
gateway for all persistent changes in
application state.
— Aanand Prasad
Offline Support is Valuable, and You Can’t Add it Later
Source: http://aanandprasad.com/articles/offline/
So then, the big question:

View Slide

How do I make this
oﬄine magic work?
Magiiiiiiic

View Slide

// Store some data
hoodie.store.add('todo', {name: 'fly to amsterdam'})
Using Hoodie
Nah, just a line of code.
This is what using hoodie looks like. You use the api to store stuff, and when
you add stuff, it expects a type (todo) and an object with data in it.

View Slide

// Store some data
// Sign up a new user
hoodie.account.signUp('[email protected]', 'secret');
Using Hoodie
Sign up a new user: use the API

View Slide

// Store some data
// Listen for store events
hoodie.store.on('add', handleNewObject)
Using Hoodie
Want to know when something changed so you can update the UI?
Listen to events from the library

View Slide

// Store some data
Using Hoodie
Wait, so how do I oﬄine? 0_o
So how do you make this work ofﬁne?

View Slide

// Store some data
hoodie.store.add('todo', {name: 'eat stroopwafels'})
Using Hoodie
That‘s it.
All you need to do is embrace the decoupled architecture of offline first. Talk to
the api, let it sync for you, and listen to events from Hoodie to see if new data
has arrived.
And that‘s it. It‘s not a special feature you have to explicitly invoke, it‘s how the
entire architecture works. You get offline for free.
Let‘s just see that in action:

View Slide

Sweet.
Now what?
So, we felt like we'd solved a lot of the technical aspects, and now we were
wondering: what opportunities does this gives us, exactly? Which problems
can we now solve?

View Slide

Let‘s ask
around
We thought we had a pretty good topic here, and we decided to try and see if
other people agreed.

View Slide

Gregor was on the Africa Hack Trip through Kenya, Uganda, Rwanda and
Tanzania anyway, so he met a lot of people with interesting ofﬂine problems

View Slide

I wrote a blog post that got quite a lot of traction…

View Slide

…some great resonses on twitter and a surprisingly friendly hackernews
discussion

View Slide

View Slide

Then I wrote another one…

View Slide

Mozfest
OFFLINE FIRST-
WORKSHOP
We also had an ofﬂine-ﬁrst workshop at Mozfest London, with about 40
participants…

View Slide

…and another in Berlin a bit later. As we started asking developers from all
over the world about these issues, we were surprised at how many people
suddenly opened up about their offline troubles—realizing they’d had similar
problems in the past, but never spoken to others about them. Most battled it
out alone, gave up, or put it off, but all secretly wished they had somewhere to
turn for offline app advice.
People had veeeery interesting and specific problems, ranging from building,
and I quote, „runkeeper for fish“, for anglers in the norwegian wilderness, to
several people trying to build robust point-of-sale systems for places with bad
connectivity.
But we identified some central themes:

View Slide

Trust and
reliability
OFFLINE PROBLEMS
The ﬁrst and most pressing issue people seem to have is that they can‘t trust
their apps to do the right thing when the connection gets dodgy. You can
summarize this with the following user story:

View Slide

As a mobile app user,
I want to be sure
that my data is actually
available when I need it
USER STORY
And this is quite fundamental. It‘s so fundamental it probably gets forgotten
most of the time. Of course users want this. But it used to be a painful
problem, and it was easier to just fail, show errors and let people blame it on
the telekom.
But you can often do a lot better, and offline first is the way to go. But first, let
me illustrate the problem:

View Slide

So here‘s the german railway advertising that you can apparently book tickets
and use their app under any circumstances, even when free soloing in the alps
(remember, in the tech future, everyone is into extreme sports and ice carving)

View Slide

vs.
and then there‘s the normal world with this guy who can‘t access his ticket,
because the app won‘t start up when the connection is bad. It‘ll work in
airplane mode, but on an actual high-speed train, where the phone can
connect to the occasional cell tower but not do much with it, it fails, and it fails
slowly. While the ticket inspector is breathing down your neck.
The solution would be to store personal data and tickets locally, and not make
the initial communication with the server blocking.

View Slide

Another symptom: screenshotting apps, because you can‘t trust them to retain
their state.
Who here does this?
Lots of people do this. I went through the photos on my phone and found quite
a few of these screenshots, where I was afraid that the data I‘d just fetched
would vanish the next time I opened my phone. Because this kind of thing
happens a lot:

View Slide

Those views were full of data just moments before I took these screenshots,
but then I made the mistake of, I don‘t know, switching apps or putting my
phone away for a minute. And what happens? The apps ditch any data they
may have had, then fail at loading new data, and then the user suddenly has
no data at all. That‘s just not cool.
So, we can use ofﬂine ﬁrst to get…

View Slide

More trustworthy
and reliable apps
OFFLINE FIRST OPPORTUNITY

View Slide

Always-online
architecture
OFFLINE PROBLEMS
The second issue is that many apps are designed to only work while
connected, even if there‘s absolutely no intrinsic requirement to do so.
This is a relic from the age of the big grey box, of the terminal and the thin
client, where all the computing power was probably far away from you. Now it‘s
in your pocket, and we can do things differently.

View Slide

As a mobile app user, when I‘m
oﬄine, I want to be able to use
features that don‘t require a
connection
USER STORY

View Slide

If you‘re only viewing your own data, or adding data yourself, why doesn‘t this
just always work, online or ofﬂine? You should be able to add a meeting, mark
a task as done, write a message, check in, post a picture… create stuff. Store
now, sync later, but don‘t get in the way of getting things done if it isn‘t
necessary. And again, this is an opportunity:

View Slide

More useful and
more usable apps
This is directly linked to the next one:

View Slide

My data
isn‘t with me
OFFLINE PROBLEMS
It‘s probably on a server in the US somewhere, if you‘re lucky it‘s on a CDN on
the same continent as you.

View Slide

As a mobile app user, I want
to have my personal data
on my device at all times
USER STORY
It is my personal data, why should it not be on here? I might need it, and you
don‘t know when. Plus, in most syncing scenarios, I‘m the authority over my
data, so just let me keep a local copy. Or rather, your server only gets to back
up my data.
Granted, this gets problematic if your app is highly collaborative, but if you
have a use case where user data is fairly well isolated, you can easily do this.
So, the potential beneﬁt is:

View Slide

Always-accessible
personal data
Super fast, always available and simply reliable.

View Slide

Apps require
advance planning
to be useful
OFFLINE PROBLEMS
One more thing that frequently irked people when we talked to them about their
ofﬂine woes: apps not being smart about what data they store locally. In short:

View Slide

As a mobile app user, I want
apps to pre-empt my needs
in a sensible manner
USER STORY
Because I don‘t know in advance when I‘ll be ofﬂine. If we always knew that, a
lot of this wouldn‘t be a problem.

View Slide

Once out of bed, internet and apps are
used almost constantly, peaking during
the daily commute with 70 percent
usage.
— Ericsson
Traﬃc and Market Report, June 2012
When are connections worst?
Right. While travelling. In the subway.

View Slide

RSS readers should already
have new data in them
when you open them
With non-smart apps, you‘re regularly caught in the subway with day-old
articles, because you explicitly have to fetch them yourself. But what else
would you want in an RSS reader except new articles whenever you open it?
When do people read on the go? While travelling. When are connections
worst? While travelling. So the apps should fetch the data before you need it.
This is one of the experience driven facets of Ofﬂine First. Just making good
ofﬂine experiences in general.

View Slide

Obviously important data
should probably
be stored locally
Dropbox is good in this regard. Fave something on the phone? It‘s now on the
phone, always. And that‘s a good assumption to make on their part.
You could take this further though…

View Slide

Smart, offline maps
WOULDN‘T THAT BE NICE
So sure, you can have offline maps, but you need to know that in advance. Get
an offline maps app, or get google maps to cache your surroundings.
But… maps knows where you live, right? Imagine if it would pre-emptively
download your surroundings as soon as it notices you‘re on wifi in a different
country than usual.

View Slide

Smart, oﬄine maps
ALSO A BIT SPOOKY
And on the other hand, this nicely demonstrates some of the issues with
caching local data: you need new UI elements, plus you need to answer some
pressing questions: how long will the cached map be retained? Does it get
ﬂushed at some point? Can I remove it when I don‘t need it anymore? Can I
cache more than one at a time, and if yes, is there some sort of limit? In short:
how does it work and can I trust it?
Or, for you as a developer: can you make it trustworthy while hiding all the
complexity? Interesting questions, but a cool opportunity:

View Slide

Smart apps that
pre-empt user needs
Which brings us to:

View Slide

Oﬄine-First
Challenges
It‘s becoming obvious that there are a number of new things you could be
doing, and that these new things require new interfaces and in some parts
even a new design language, because you have to communicate stuff to
people you haven‘t had to communicate before

View Slide

save vs. sync
How do we communicate the states data can be in? Stored locally, scheduled
for sync, synced, possibly out of date, conﬂicting…
possibly out of date is a state you‘ll get quite often in ofﬂine-capable apps, and
you‘ll have to decide how crucial the age of data is, and how you communicate
it. Because old data can still be useful while potentially being wrong. Think train
schedules. Could be wrong, but communicate intent. And that‘s valuable.

View Slide

We all know this is usually a lie. It means lots of things, but in the end it only
means:

View Slide

You wouldn‘t
understand…
„I‘m not ready, and it‘s to complicated to explain why“.
But we want to reassure users, remember? We need to ﬁnd a good language,
possibly visual, to do so

View Slide

If your app now behaves differently depending on whether it‘s connected or
not, you‘ll have to make this clear somehow.
Threema does this by displaying an always-visible connectivity stripe at the
top, red for disconnected, yellow for connecting and green for connected, and
teaches you beforehand what the consequences of each are.

View Slide

Save
But you could just as well selectively disable, hide or re-phrase features.
Imagine a save button that knows whether it‘s connected to the server, and
changes accordingly:

View Slide

Save
AND SYNC LATER
Or you could just let users save either way and inform them about the state of
things after the fact:

View Slide

Saved locally
(oﬄine, syncing later)
There are loads of ways to solve this problem: be super-secretive and just
handling everything in the background, or inform the users before, during or
after they‘ve done something. Depends on the use case, who you‘re
developing for, and how crucial the data is to them.

View Slide

Informing users
about sync
outcomes
Lastly, informing users about sync outcomes. Not just whether they succeeded
or not, but how and possibly why data has changed in their browser. This is
probably one of the hardest UI problems related to sync, especially when it
comes to chronologically sorted data, like chats or other streams/threads.

View Slide

Informing users
about sync
outcomes
So, I said that if users only add data, why not always just let them do that and
sync later? Well, it turns out that things aren‘t quite as simple, and that context
really matters.
Here‘s a fairly simple chat example that illustrates some of the things you‘ll
have to keep in mind:

View Slide

10:00 - Hi
10:01 - Yo
A
B
10:02 - Meet on Thursday?
A
10:03 - Sure, I‘m free.
B
10:04 - Ah wait, meant Tuesday.
A
Now imagine that B‘s second message was written while one of the two was
ofﬂine. On a train, in a tunnel or something.

View Slide

10:00 - Hi
10:01 - Yo
A
B
A
A
…
Then the ofﬂine user reconnects and the messages sync up again. A receives
B‘s missing ofﬂine message. So where do you put it?

View Slide

10:05 - Hey A
10:06 - Hi C
C
10:07 - Hey, you free on Tuesday?
A
10:08 - Lemme see…
10:09 - I asked B too, btw
A
A
A
C
You can put it in the chronologically correct place, which makes sense in a
thread context, because the order carries meaning. But that might mean the
message appears somewhere out of the user‘s current view, way up there
somewhere. That‘s a new UI challenge in itself. Or you could do what
Imessage sometimes seems to do: display it in the ﬂow according to the time it
arrives at.

View Slide

10:00 - Hi
10:01 - Yo
A
B
A
10:03 - Sure, I‘m free.
B
A
This guarantees that the message will actually be seen by A, but this approach
has the potential to change meaning, because message order is meaningful.
And this is only text-based, one-dimensional data. A simple chat, one of the
simplest examples I could think of.
What to do with deleted items, things that can’t be organised in lists, objects
that aren’t in themselves immutable? There‘s a lot of potential for complexity
here, so that‘s something to beware of.

View Slide

Because the web platform is becoming more an more powerful and capable.
Here‘s a photo editor. It‘s not photoshop, nor is it trying to be: it‘s quick, easy,
no installation, cross-platform, auto-updates, and does most of the things you
want in a simple photo editor.
You‘d probably want it to work ofﬂine, though.

View Slide

This is an experimental collaborative multitrack recording app, with synths and
drumkits and audio, and it runs in the browser. This is part of a masters thesis
by Jan Monschke, and it‘s really bleeding edge, but just imagine where this
tech will be in a year. Cross-platform garage band? That‘s pretty damn cool.
But again, it can‘t be used ofﬂine, and that‘s a disadvantage in comparison to
the native apps it competes with.
So there‘s much more complex stuff on the horizon already, and we have no
proper strategies for dealing with it.

View Slide

That sounds
complicated
And it is.
But there‘s a second point to this escalation in complexity: Offline First isn‘t just
going to be a nice-to-have feature for commuters. When you‘ve got web apps
that rival native apps in functionality, they really have to be offline-capable to
be competitive. In many cases, it‘s going to be a necessity.
But there‘s more to offline first that bad networks and competing with native
apps: there are a lot of advantages and opportunities besides that:

View Slide

Oﬄine-First
Advantages
So let‘s talk about those.

View Slide

• Performance
OFFLINE-FIRST ADVANTAGES
First: Performance. We put stuff in CDNs to move it closer to the user, but the
closest thing to me right now is this (phone in pocket).
Put your app in here.
Put your data in here.

View Slide

• Performance
ZERO LATENCY
That's zero latency for me. This is the way to the snappiest experience. The
data may be old, but at least it‘s there. And in many cases, time isn‘t doesn‘t
even invalidate the data, so there‘s still a beneﬁt to having it.

View Slide

• Performance
ZERO LATENCY
• Robustness
Robustness. Ofﬂine capability protects from service interruptions. Interestingly,
we hadn‘t even anticipated this. We have a fairly large service running on
Hoodie and had to brieﬂy take it down for maintenance, and most people using
the app at that very moment didn‘t notice.
Turns out: It doesn‘t matter if your app can‘t reach the server because the user
is on the subway, or because the server is down. It‘ll still work.

View Slide

• Performance
ZERO LATENCY
• Robustness
SERVER DOWN? I DON‘T CARE
• Better experiences
Better experiences. Apps don‘t lose data. Apps are more trustworthy. Apps are
more usable and useful. Apps cause less frustration.

View Slide

• Performance
ZERO LATENCY
• Robustness
SERVER DOWN? I DON‘T CARE
SAVE ALL THE TIME
And remember, you‘re saving to a local store first. You can save after every
single keystroke if you want, and sync to the server every couple of seconds.
Forget save buttons altogether.
There‘s a lot to be gained from an offline-first architecture that‘s not completely
obvious at first glance.
And you can start asking yourself new, exciting questions:

View Slide

Do you need
your users‘ data?
It gets you thinking more about the data you‘re collecting, since you have to
decide upon syncing strategies. And you may even ﬁnd that you don‘t actually
have to or even want to store your users‘ data on your servers. This can do
wonders for scalability and privacy concerns, and may even be a business
beneﬁt for you.

View Slide

The web platform
is amazing
And this is just the start. Image manipulation, maturing web audio APIs, and
there‘s a lot more to come. At JSConf EU this year, there was a lot about
ServiceWorker, client side storage and web crypto: all just coming in to
existence, but wildly promising. By this time next year, we‘ll have these tools.
We‘ll build apps that encrypt user data before it gets backed up to the server,
and there‘ll be new business opportunities and markets for that.
We‘ll build apps that use service worker to deliver fantastic offline
experiences.
And offline first will be the underlying paradigm for many of them.

View Slide

Any application that can be written in
JavaScript, will eventually be written in
JavaScript.
—Jeﬀ Atwood
„Atwood‘s Law“
And if it‘s in the browser it‘s going to be used in a mobile context, and it‘s going
to be ofﬂine at some point.
And it‘s not just about increased mobility any more:

View Slide

At some point recently, the browser
transformed from being an awesome
interactive document viewer into being
the world’s most advanced, widely-
distributed application runtime.
—Tom Dale
Progressive Enhancement is Dead
The web is very attractive platform for developers for many reasons, and as
web apps gain complexity and mobile native app usage increases further,
users will simply expect a mature and solid experience.
Waiting for more cell towers to be built won‘t help them. Your apps have to
work regardless of the circumstances.
Source: http://tomdale.net/2013/09/progressive-enhancement-is-dead/
So. Let‘s recap.

View Slide

So, is Oﬄine-First
worth it?
You may be looking at all this and thinking: „this seems like a lot of work for a
reeeally speciﬁc issue, and networks are getting denser and better all the time,
so why bother? We could just do what we‘ve always done.“
Well, let‘s start with networks:

View Slide

Think of your everyday mobile experience, in your wealthy, well connected ﬁrst-
world cities, think of your mobile experience in the countryside, while travelling,
in other countries, and then realise that global mobile trafﬁc is on this kind of
growth curve, and we‘re just in the middle of that at the moment.

View Slide

51 percent of smartphone users are very
satisfied with their operator’s network
and only 3 percent are outright
dissatisfied, leaving almost half in a
position where their satisfaction could
easily be improved.
— Ericsson
Traffic and Market Report, June 2012
Half of everyone is already somewhat unhappy with their coverage.
I live in the capital of one of the richest, most developed nations on earth, and
even with a modern 600€ phone, I frequently only get unresponsive EDGE
connections, or none at all. And that‘s before I even start traveling anywhere.
My provider wants to charge me 80 cent per MB while I‘m here. So I‘m offline.
And yes, that will probably change in the coming years thanks to EU
regulations, but…

View Slide

Don‘t just wait it out
and hope it will
solve itself
Because the networks aren‘t the only thing. Web apps are popular. They‘re
competing with old-school native desktop applications that save to disk in
many ﬁelds. They can iterate quicker and cover more platforms. People are
moving their stuff to the web and to web services in droves. It‘s only going to
increase:

View Slide

As I said, the web platform is amazing.
But you‘ll increasingly be competing with native capabilities. And that means
working offline, too.
Plus, with offline first, your apps benefit from being…

View Slide

• Performance
• Robustness
faster, more robust, and more trustworthy. And while you can optimistically
hope for more cell towers, you can‘t really argue with that list, in my opinion.
So. In closing:

View Slide

We can’t keep building apps with the
desktop mindset of permanent, fast
connectivity, where a temporary
disconnection or slow service
is regarded as a problem
and communicated as an error.

View Slide

We can
and should
do better
At the same time…

View Slide

It‘s not magic,
it has a spectrum
of usefulness
Ofﬂine First won‘t make everything wonderful for everyone, nor is it an all-or-
nothing solution: it starts with not forgetting data, and ends with full sync and
using the user data in the browser as the deﬁnitive copy. And there‘s a lot you
can do in between that, too.
But you‘ve seen the opportunities you already have right now. But…

View Slide

It‘s early days,
and there‘s a lot to
talk and think about

View Slide

There are still
many technical
challenges
With Hoodie, we have a solution for some data scenarios, but it may not be
what you need. To be honest, what you need may not even exist. People want
weird stuff. But as time passes, more people will ﬁnd new and different ways of
solving the problem for different scenarios. And one of them might be you!

View Slide

There are still
many technical
challenges
But it basically works, right now. I just finished a prototype web app that works
completely offline, it has offline maps, and it can even take photos while offline
and store them until you‘re back online. It runs well on my wonky 2 year old
Samsung android phone. It‘s only going to get easier, faster and more stable
from here on out.
But we need to worry about more than just tech:

View Slide

We still need
a design language
for offline first
There aren‘t really any UI pattern libraries or established design metaphors for
save vs. sync, sync states, connectivity states, simple conflict resolution etc.
And finally:

View Slide

We need more
awareness that
this is a thing
People need to get used to their browsers working while ofﬂine. Like Email
works when ofﬂine. Nobody thinks about that anymore.
But it‘s also awareness among developers:
More awareness of the problems, especially those we ourselves may not be
exposed to, more awareness of the technical possibilities, and more
awareness of the opportunities of embracing this paradigm.

View Slide

We started ofﬂineﬁrst.org to start bringing people together on this. We‘ve got
some discussions going on github, we hold workshops and talks and travel
around and talk to people. We‘ve started collecting other resources and
projects, as well as people‘s feedback, and we‘re aiming to add more. And
we‘d like to invite you to add your own ideas and issues.

View Slide

Please join in!
And also:

View Slide

Don‘t panic,
use Hoodie
And come talk to me if you want to know more about hoodie or ofﬂine ﬁrst. I‘ve
also got really sweet hoodie stickers :)

View Slide

Thanks!
Please come see me for info and stickers!
@espylaub
And please check out http://hood.ie
❤

View Slide

Offline First (Web) Apps - Fronteers 2014

Offline First (Web) Apps - Fronteers 2014

Alex Feyerke

More Decks by Alex Feyerke

Other Decks in Programming

Featured

Transcript