Designing for Accidental Disconnects: Our first attempt at an offline approach | Hacker News Reader

Designing for Accidental Disconnects: Our first attempt at an offline approach

blog.getchop.io

47 pointsmmastrac24 comments

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!

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.

It is pretty ambitious, though, to try and make this work for an ecommerce app. Holding the entire product catalog locally isn't feasible. Login is somewhat tricky, and completing the purchase offline has either customer service or financial risk issues.

Kudos to them for taking it on, but I don't really fault other ecommerce vendors for giving up early on offline functionality.

Keeping the whole catalog local is not a viable option. Keeping my latest search results is.

Confirming a transaction while offline is usually not an option. Preparing my shopping cart and getting everything ready to just press the "Confirm purchase" button when the connection is available, again, is. (I actually worked for a company that builds a product where this is the core functionality.)

I agree that it's possible, but the devil is in the details. A cart ready to press the "confirm purchase", for example, implies offline functionality for coupon codes, sales tax, shipping costs, and so forth.

Holding full product page info based on just a search is tricky too. Would need the search to cache things like upsell, cross-sell, product options, and so on, that don't usually come back with search. Or short of that, an alternate product page layout that deals with missing info.

This very much depends on the target audience.

If 90% of your online purchases are made from desktop browsers, maybe you have nothing to care about. If 90% is mobile, it may be worth paying attention to this approach. Currently, AFAIK, mobile buyers are 30-40% of typical e-commerce audience.

Ecommerce is a special case here and I'm willing to excuse them for requiring a good connection. I was thinking about all other kinds of apps that don't really need to have so many things so tied to the Internet.

Honestly, I'd be satisfied with the following pattern:

- if you can't connect, fail fast - tell me that you can't do the operation because of an intermittent connection

- never ever destroy data because of a connection problem; in particular, I hate it every time when an app clears its display before attempting to execute its on-line stuff, which results with me losing the previous state - this way, I take an actual risk each time I execute an operation in the app

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/

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?

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.

By the way, I discovered that AWS Device Farm now supports testing with custom network profiles. You can even manipulate the network characteristics in realtime during the test through an API, to simulate traveling through dead zones, etc.

https://aws.amazon.com/about-aws/whats-new/2016/12/simulate-...

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.

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.

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

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.

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.

Ahh, the Google methodology of caching based on physical locality. That works well for the client side... I was suggesting Unifi AC AP Pros to fix the restaurant side if they need to fix their Wifi issues.

Also, Elon Musk now has the go ahead to put LTE-in-the-sky sats everywhere. Aren't in range of a tower? You probably have a wide open shot of the sky.

What is the Bart problem?

Since everything else I've ever heard about BART is bad, I'm going to surmise that mobile connectivity while riding it is bad too.

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.

The Wyoming problem is miles and miles of empty land with no cell towers within reach.

> 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.

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.

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?

Reply on news.ycombinator.com