
Say hello to offline first - steveklabnik
http://blog.hood.ie/2013/11/say-hello-to-offline-first/
======
timruffles
I hope this becomes a popular maxim - fed up of offline not working for
productivity tools (not necessary for other types of apps, but Trello is a
shining example of this omission making productivity apps near-useless).

~~~
npsimons
This could be seen as an extension of "YAGNI" (You Aren't Gonna Need It). Does
your app _need_ to hit the server constantly? Can it not cache data and _only_
do network operations on an as needed basis?

~~~
catwell
This is not really caching. Caching is about not hitting the network to get
data you have already gotten before. Offline is about having an application
that works correctly in the absence of network, which means preemptively
getting all or a subset of your data.

But I agree that you could see the server as YAGNI, especially if all your app
is doing is data consumption and your data is small enough to be downloaded to
the device in its entirety.

I have written about caching and offline here:
[https://winch.io/blog/article/caching-prefetching-and-the-
of...](https://winch.io/blog/article/caching-prefetching-and-the-offline-
mode/) (warning: promotional content for a service that helps you do that for
native mobile apps at the end).

~~~
npsimons
Apology not needed for promotion; I'm biased, but I think far too much
emphasis is put on services that encourage needless reliance on constant
connectivity and third parties' servers. Offering an alternative is welcome.

As for local storage, even on smaller capacity devices, there's a whole lot
that can be kept - why, for instance, does a todo list, addressbook,
appointment manager, workout tracker, etc, etc, need to connect to a remote
server for it's very basest of functions? Sure, backup, synchronization,
sharing, etc need connectivity, but those aren't (IMHO, shouldn't be) the main
focus of these apps.

------
lstamour
I'd like to echo this, specifically focusing on AJAX. It's not enough to be
offline-friendly if your requests don't themselves retry or work well when
internet is spotty. A problem I've often encountered in online-only scenarios
is when AJAX calls fail. How do you ultimately retry them? At a certain point,
you need the same infrastructure you'd be building for an offline app to cache
and queue requests, as well as present sensible non-success responses. So,
just as mobile first solved problems for both tablets and focusing a design,
offline first can solve problems with error messages, caching to speed up
online responses and AJAX retries.

~~~
gr2m
or you go away of AJAX calls entirely, by storing all data offline and having
a separate process that synchronizes all changes, like remotestorage.io does
it, or hood.ie

~~~
lstamour
That's what I implied by AJAX retry. That you need some method that sensibly
queues the request, until it succeeds or is no longer needed. That process
could easily be called synchronization, sure. Depends on the app, really. The
request might "expire" or be no longer necessary, so it wouldn't show up at
"sync" time. Perhaps the request could be automatically retried through other
devices that are connected -- imagining for the moment, an app that could use
bluetooth or local wifi to communicate an operation across to other running
instances even when offline.

------
GrinningFool
"This is quite literally a new frontier, largely unexplored and full of
interesting problems and unimagined edge cases. In most other realms of app
design we are spoilt with UX/UI patterns we can readily employ, but offline-
first is terra incognita, there is practically nothing to go on in terms of
patterns and metaphors."

Alright, let's step back a minute here.

We have over a quarter-century of offline-ONLY desktop applications to draw
on. There are also a fair number of intermittently-online desktop applications
that have been in existence for years. I realize it's not fashionable to
consider these as applicable, but the only thing new here is the platform
(browser). UI patterns abound - though unsurprisingly a quick google search
for UI design patterns doesn't show anything except the latest web ui
patterns.

These desktop applications still power the everyday work of most computer
users[1], to a large extent more than most transient web-based apps. Why would
we start any discussion on the assumption that they're not relevant?

[1] and before you tell me that you do just fine on your chromebook using only
connected services: you are NOT most desktop users.

~~~
lstamour
Generally speaking, when offline apps went online, they would "sync". This
process is not straightforward, quick nor modern. Web apps don't "sync", they
just "work". How can you design a native app that behaves like a web app?
That's a less explored question. I'm not saying it hasn't been looked at yet,
of course, and phones are some of the first to do it. Microsoft could take the
lead here, with their approach of "only showing icons for connectivity when
the connectivity changes" and of hiding buttons when they aren't going to
work, so you can presume that anything you see on screen is going to work even
when offline. Windows Phone and Windows 8 guidelines have a few more examples
like this. On the other side of the fence, Apple has done similarly with their
apps. iTunes Radio will continue caching the next song and part of the song
after it, so even when I go down to the subway and lose signal, I still get to
hear another 5 min of music. That said, the rewind and replay features of
TuneIn were still superior and it'd be nicer still if iTunes radio
transitioned into playing back either cached tracks or my own library instead
of stopping dead. (Wouldn't it be nice if while listening, between tracks or
when it stops, Siri stepped in and announced why the track can't play and
suggests alternatives?)

Part of this new medium is to come up with techniques of explaining that apps
work offline -- people's expectations, still, are that if they visit a
website, they need to be online. That alone is a huge hurdle.

In addition, some of the best services, e.g. browser-based push notifications
from Apple (rather than those of native Chrome) will not work without Internet
since they use the same push protocols as native push notifications on iOS
(iirc). That said, even on iOS, I think apps can now add notifications without
internet, so that should be changing, just as apps can sign up to do
background pre-caching of data.

There are some HTML-only problems too: How do you version web requests from
remote hosts? How about third-party JS? There are so many considerations in
offline scenarios that most web developers never need consider. I really hope
offline first takes off as the next "mobile first" or "responsive design". If
nothing else, it will make for more robust online-only apps.

~~~
stan_rogers
The paradigm is not particularly new, even if the implementation needs to be.
You're essentially describing IBM (Lotus) Notes _sans_ cruft (proprietary rich
text structures, UI, etc., that predate HTML/WWW). Space- and/or time-limited
replication when getting the whole data set is unnecessary, local design/code
caching and so forth are solved problems, so to speak. (They've been solved at
least once before, and so an be solved again.) Say what you will about the
Notes client (as a developer, I had to fight it every step of the way), but
the underlying _ideas_ are still valid and, IMHO, still necessary.

~~~
dan_s
To be explicit, 20 years ago, there were people on airplanes reading,
composing, responding to email and reading creating updating, deleting
documents in multiple applications. They were creating and following links to
docs and email in applications. All offline. When they reconnected via modem
in the hotel room, it all synched with the the servers. Code and design
changes also replicated so the apps as well as the data were always up to date
and in synch. Replication could filter only those records that the users
needed. Even long-running background processes could be run locally. That was
Lotus Notes 20 years ago. CouchDB and its relatives can do this because Damien
modeled it after the Notes Database, but with open protocols and standards
(yay!).

Back then, even online was slow and expensive so many people worked in offline
mode even when connected. Many still do this today, even on fast local
networks. Perhaps there is yet more to be learned from the ancestors.

~~~
lstamour
I agree with both of these replies. Lotus Notes was an interesting beast to
learn about, back in the day. I suppose it's always been a problem to solve,
though: We're not suggesting that before the WWW, there were no online-only
services either. But graphical web browsers changed people's expectations. An
offline only app that runs in a web browser... has about the same impact, for
both the technology architecture and expectations. I look forward to this
future and what new frameworks/"cloud" evolve, and I'll have to investigate
more in this personally. :)

------
Procrastes
Living in the mountains of Northern California with crappy cell coverage, I
hope thinking "offline first" really takes off. Through my day I pretty much
only use apps that can "hold it" until we get to another wi-fi or cell
coverage oasis.

Besides my personal coverage challenges, any mobile app should just be smart
enough to handle loss of connection gracefully as a matter of course. It's one
of the error conditions (along with low battery) that is guaranteed to happen.

I will definitely be watching hoodie for my own projects. Most of the US (by
area) is in the same boat, I suspect.

------
branksy
> We can’t keep building apps with the desktop mindset of permanent, fast
> connectivity...

That's just silly. A lot of apps are rightly useless without normal
connectivity, like checking the weather [edit: for current conditions], or
sending e-mails, or Facebook, or shopping on Amazon. There's no reason for
these to work offline.

I mean, an app is pretty much online-only, or mostly offline (like most games,
for example).

I don't see a big middle ground between the two where online apps need to be
made to work better offline. And the few which do (which involve syncing
data), seem to work fine.

So... I don't get it. What is "Offline first" trying to accomplish in the real
world?

~~~
janl
We are trying to get people to talk about offline-first app design for when it
makes sense.

Weather is a great example, being offline could communicated as an error,
leaving the user with an abysmal experience. Or some older content could be
shown with the note that it is likely that the accuracy is off, but if the
user just needs a general idea of the weather, that suffices and is not at all
an “error” in the networking sense.

We have no common UX/UI language for these things and we’d like to change
that. ;)

~~~
wrongc0ntinent
Good luck. Anecdote: after finding a small scorpion on the bathroom wall in
the Honduran jungle, I had a huge compulsion to tear everything apart to make
sure there's no nest. The only thing that calmed me down was access to
offline, text-only Wikipedia on my Nokia n800. It was 2 a.m., slept like a
baby when I found out this species was harmless. To this day, I never travel
without it. (Edit: Wikipedia, not the n800 ;)

------
205guy
I think this offline-first approach is very interesting, and definitely
something that is overlooked in UI and app design. The OP is correct about
telco and wifi signals being far from total coverage. There are lots of
"holes" and in some places, it's more a metaphor of moving between islands
that have connectivity.

There is also another case of artificial data "scarcity" and that is the case
no-data plans. To save money, I have a low cost ($10 and up) minutes-only
phone plan. With apps that work with the offline-first mentality, being
offline could be almost invisible on a 1-hour commute between the wifi at home
and the office (no, I'm not one of those people who needs to read and write
tweets in real-time).

Sometimes it is also a hardware issue. The first time I tried to use my phone
as a true GPS with MotionX (this was 4 years ago on an iPhone 3G), I
discovered it's not possible. The app does download maps and cache them so you
can go hiking out of cell range, but the iPhone does not support GPS-only
operation. Either I leave the radios on and it depletes its battery looking
for a signal, or I put it in airplane mode and GPS is disabled. I don't
believe a GPS-only configuration is possible even today.

Another point is that offline-first does not only apply to smart-phone apps,
although that is probably the biggest problem space. But there are a lot of
people who commute with laptops, and who could maybe live without a 4G dongle
if their apps supported it.

I have also thought a lot about the sailboat cruising community (see the last
sailboat picture in the OP). There are many recreational boaters out wandering
from port to port, using sparse wifi and sailmail (very limited email services
via marine HF SSB radio). A lot of them blog and send text and email to their
family, friends, and followers, but have to struggle to time their online
windows. Just imagine a laptop app that lets people write emails and blog
posts whenever they want (in the middle of an ocean), and maybe it uploads the
text to their blog via sailmail immediately (but slowly), and then adds the
pics automatically when they get to port and connect to wifi (or have a 4G
dongle within range of a cell on the coast).

So not only are there online and offline states, but also limited bandwidth
states such as sailmail (it allows short text emails in both directions, but
not images).

~~~
npsimons
_I don 't believe a GPS-only configuration is possible even today._

Are you referring to iPhone? I'm fairly certain that's a software limitation,
as I know of non-iPhone smartphones that can easily enable GPS alone (no cell,
no BT, no WiFi, etc).

~~~
205guy
Yes, I'm referring to the GPS on the iPhone. Of course it's ultimately a
software limitation, but from the consumer/non-jailbroken point of view, it's
baked into the product. No app can override it.

------
elchief
Been working with SymmetricDS (open-source Java database syncer over HTTP).
Works on Java desktop, Android, Java web servers. An IOS version in the works.

Anyone else using it?

Would be nice to see a pure AJAX / IndexedDB plugin.

Since a local database would write directly to a central database, you really
want row-level security and good triggers, so a user can only screw up their
own stuff.

------
pepijndevos
Related: CouchDB for mobile.

With its master-master replication and explicit conflict handling, it handles
being offline extremely well.

------
JacksonGariety
Did this post get nerfed? It had 45 points in one hour but it seems to be
stuck at the top of page 2.

~~~
npsimons
It was at the top of page one at one point in time; along with another
interesting article (that was killed) about a new operating system that looked
promising, I'd say someone with an agenda has been flagging perfectly relevant
articles today. Perhaps it was branksy. Or mobile app developers who don't
like the idea of their users disconnecting because then they can't track their
every move. Or web app developers who can't conceive of an app that doesn't
involve a web server.

------
digitalsushi
Doing my college homework, if I had assumed I was offline and then only went
online if I determined I was, then I might have spent half the time debugging
my homework.

~~~
npsimons
Explain, please? You appear to be comparing a state of mind (assumption of
being offline), to a way to design apps (don't assume constant connectivity),
with an unclear result (what do you mean by "spent half the time"? would it
have taken you half as long as it originally did if you assumed you were
offline? or you would have spent half your time debugging instead of looking
up answers?).

