
Designing for Accidental Disconnects: Our first attempt at an offline approach - mmastrac
https://blog.getchop.io/designing-for-accidental-disconnects-our-first-attempt-at-an-offline-approach-2ac0bdb6d170#.oka1o57xw
======
jslabovitz
I live less than two hours west of DC, yet my only connectivity options are a
1.3Mbps DSL link or a ~128Kbps 1x/RTT cellular link. This is pretty normal for
West Virginia and other mountainous and rural places in the US. The DSL link
isn't too bad as long as I obsessively block all ads and trackers, never
stream anything, and reset the router if I've pushed too much traffic through
it. If I'm careful about managing TCP connections and very patient, I can get
by with the 1x/RTT link; it's slow but steady.

I invite any networked application engineers to come spend a week developing
here. You can go for peaceful walks in the woods and question your bad
assumptions about always-on/always-fast networking!

------
TeMPOraL
Well, thank you for noticing. I really do appreciate that. This puts you in
the very small group of companies/developers who understand that _Internet is
not electricity_ and you can't assume it's always available.

I wish more companies would embrace the two - one would think obvious -
points:

\- there is such thing as "cache"

\- if a thing can be done off-line, it _should_ be done off-line; stop pushing
shit to cloud out of laziness

Signed,

A person who is constantly infuriated by the shitty, cloud-first state of
mobile infrastructure.

~~~
illumin8
Amen! Even companies like Spotify that support full offline mode do a terrible
job of testing their actual software in intermittent connectivity areas.

Think about a Metro North train traveling underneath midtown Manhattan in
tunnels until it gets to 125th st. in Harlem. While underground, even the best
wireless carriers like Verizon and AT&T can't get much of a signal through
layers of earth and the metal faraday cages that are train cars.

The most infuriating thing is that if Spotify thinks it should have a network
connection, because it has a 1xRTT signal with only 1 bar, but no data is
actually flowing, the app will just hang and spin trying to connect forever,
and become completely unresponsive. You have to enable airplane mode to
convince the app that yes, there really is no data access underground.

In general mobile developers do a terrible job of actual real-world testing
connectivity under a variety of packet loss and latency scenarios.

I would strongly recommend that you automate unit testing that inserts random
amounts of packet loss and latency into the network connection to see how your
app performs. There is open source software like WanEM (WAN emulator) that can
do this for you:
[http://wanem.sourceforge.net/](http://wanem.sourceforge.net/)

~~~
Fnoord
Is there a series of tests (apart from ping) which Spotify could perform, or
libraries they could use, which would give them beyond reasonable doubt an
indication there is connectivity? Should the application perform this, or the
OS?

~~~
illumin8
I don't know, honestly. I'm just proposing that developers automate unit
testing that includes intermittent network connectivity and understand what
the failure modes of their app are, and make design decisions based on
improving the UX.

For example, if you're Spotify, and your app spins for 3 minutes and has to be
force quit because network connectivity is degraded, you should probably
identify this in automated unit testing and not force your customers to live
through this terrible user experience.

------
timthorn
The "generic splash page with a positive emotion" as an error message would
infuriate me, I'm afraid. I don't know if it's due to cultural factors or age
or something else, but I find the trend to anthropomorphise machine/user
interaction with informal language very annoying. It's even worse when used in
error conditions as it piles my annoyance at the attempt to make my inanimate
computer sound cute on top of my instantaneous frustration at the error.

~~~
throwanem
I think it's just lack of experience - specifically, experience dealing
directly with users whose things aren't working right. It takes very little
time in such a role to learn that, when someone is already annoyed because one
of their tools is malfunctioning in a way that takes time away from things
they actually care about, being cutesy about it helps nothing and nobody.

~~~
nerdponx
Being cutesy is worse than unhelpful, it's frustrating and patronizing.

------
DiabloD3
As cool as this is, I'd literally be handing out Unifi AP AC Pros to customers
with their tablets (at least, I think that's how the article explained what's
going on).

Murder _all_ of the bad Wifi. It'd fix half the problem.

~~~
sdenton4
Nope! Consider the Bart problem, and then after that, consider the Wyoming
problem. And then think about the India problem. Wifi just isn't available
much of the time. It's important for apps to build out functionality for core
user journeys in offline mode.

Of course, you can't offline the whole internet... But with reasonably good
personalization, you can get some of the parts that matter most. For example,
in the case of a food ordering system, the app can know the menus for
restaurants used before, and have those ready to go offline. And then get the
menus for restaurants that match the user profile, in the local area.

~~~
Fnoord
What is the Bart problem?

~~~
mberger
Im not from the states either but I assume it's the Bay Area Rapid Transit, or
the subway. I'm assuming wifi is spotty because of the difficulty of
connecting to a moving access point. No idea what the Wyoming problem is. Im
assumign the India problem is access point overloading.

~~~
Fnoord
> Im not from the states either but I assume it's the Bay Area Rapid Transit,
> or the subway.

I see. Since its an acronym and doesn't reference to a person named Bart lets
call that the BART problem.

> Im assumign the India problem is access point overloading.

On WiFi? In large cities the WiFi problem is bigger, but 5 GHz alleviates a
lot of the pain if you are stationary. I've been seeing a lot of cheaper
phones (even recent) only having 2,4 GHz. My router can only set itself it
either 2,4 GHz, or 5 GHz, so having one device which only can do 2,4 GHz is a
problem. In large cities, the solution here appears to be more 4G APs.

If you're moving, 4G (or WiFi AP in the mobile vehicle using 4G like the
trains have here) solves the problem since it supports roaming very well and
has a longer range than WiFi. There's also the option of Femtocell. For subway
systems, the tunnels are already there (which includes safety exits and such)
so building connectivity via Femtocells seems like a logical way to solve the
problem. This does have a cost attached to it, and also planning and testing.

~~~
sdenton4
India is mostly 2g and 3g, though there's a major new 4g network being rolled
out now. That said, recent studies show that 4g networks greatly reduce in
speed as they near capacity; many US cities have seen 4g speeds cut in half as
more people have come into them.

------
nine_k
I applaud to the sane approach. Kudos for not only noticing the obvious but
actually doing something about it.

Sometimes I wonder how many applications are built essentially around a
distributed, replicated database, and how useful periodic sync without a
constant connection turns out to be. Email, IM, Dropbox, git are all great
examples of that. Why can't more tools be built with the assumption of
intermittent connectivity from get go?

