5 ms·

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

47 points by mmastrac 10y ago

DiabloD3 10y ago
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 10y ago
  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.
  - DiabloD3 10y ago
    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.
  - Fnoord 10y ago
    What is the Bart problem?
    - throwanem 10y ago
      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.
    - mberger 10y ago
      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.
      - gvb 10y ago
        The Wyoming problem is miles and miles of empty land with no cell towers within reach.
      - Fnoord 10y ago
        > 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 10y ago
        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.
timthorn 10y ago
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 10y ago
  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 10y ago
    Being cutesy is worse than unhelpful, it's frustrating and patronizing.
TeMPOraL 10y ago
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.
- tyingq 10y ago
  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.
  - nine_k 10y ago
    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.)
    - tyingq 10y ago
      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.
jslabovitz 10y ago
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!
nine_k 10y ago
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?

47 points by mmastrac 10y ago

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 10y ago
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.
- DiabloD3 10y ago
  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.
- Fnoord 10y ago
  What is the Bart problem?
  - throwanem 10y ago
    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.
  - mberger 10y ago
    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.
    - gvb 10y ago
      The Wyoming problem is miles and miles of empty land with no cell towers within reach.
    - Fnoord 10y ago
      > 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 10y ago
        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.

timthorn 10y ago

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 10y ago
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 10y ago
  Being cutesy is worse than unhelpful, it's frustrating and patronizing.

TeMPOraL 10y ago

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.

tyingq 10y ago
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.
- nine_k 10y ago
  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.)
  - tyingq 10y ago
    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.

jslabovitz 10y ago

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!

nine_k 10y ago

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?