Should we design for iffy internet?

As mentioned, this article is more about slow internet than about "iffy" internet. People are commenting about the need for slimming down pages, removing bloat, but...

There are lots of cases for sending MORE data on "iffy" internet connections.

One of our websites is a real estate for-sale browsing site (think Zillow). It works great from home or office, but if you are actively out seeing properties it can be real frustrating when Internet comes and goes. Where any interaction with the page can take 10-60 seconds to refresh because of latency and packet loss.

A few months ago I vibe-coded a prototype that would locally cache everything, and use cached versions primarily and update the cache in the background. Using developer tools to simulate bad networking it was a day and night experience. Largely because I would fetch first property photos of all properties as well as details about the first few hundred properties that matched your search criteria.

"Bloat" when used intelligently, isn't so bad. ;-)

I've shipped stuff used in parts of Latin America and Southeast Asia and one of the biggest lessons was this: latency, not bandwidth, is what kills UX.

A 10mb download over 3G is fine if you can actually start it. But when the page needs 15 round trips before first render, you're already losing the user.

We started simulating 1500ms+ RTT and packet loss by default on staging. That changed everything. Suddenly we saw how spinners made things worse, how caching saved entire flows, and how doing SSR with stale-while-revalidate wasn’t just optimization anymore. It was the only way things worked.

If your app can work on a moving train in Bangladesh, then it's gonna feel instant in SF.

Just get on the road with a 3/4/5G connection on a mobile phone if you want to understand why we still need to design for "iffy" Internet. So many applications have a habit of hanging when the connection isn't formally closed but you're going through a spotty patch. Connections to cell towers with full bars and backhaul issues are surprisingly common. It's a real problem when you're dealing with streaming media (radio can be in the low kbps) or even WebSockets.

Physical businesses need to think about this too. Too many seem to assume every customer is tech-savvy and equipped with an iPhone.

Should you assume all your customers have smartphones? Smartphones with internet connections? Working cameras? Zelle? Venmo? Facebook? WhatsApp? Uncracked screens (for displaying QR codes to be scanned)? The ability to install an app?

I recently bought a snack from a pop-up food vendor who could only accept Venmo, which luckily I have, or exact cash, since he didn't have change. I'm pretty sure he only told me this after he handed me my food. I know lots of people who don't have Venmo—some don't want it because they see it as a security risk, some have had their accounts banned, some just never used it and probably don't want to set it up in a hurry while buying lunch.

I also recently stayed at a rural motel that mentioned in the confirmation email that the front desk isn't staffed 24/7, so if you need to check in after hours, you have to call the on-call attendant. Since cell service is apparently spotty there (though mine worked fine), they included the Wi-Fi password so you could call via Wi-Fi. There were also no room phones, so if the Wi-Fi goes out after hours, guests are potentially incommunicado, which sounds like the basis of a mystery novel.

Despite the title, the article doesn't talk about "iffy internet" at all. It's all about "slightly slow" internet which is a complete non-issue except for large downloads (e.g. modern games).

Congested and/or weak wifi and cell service are what "iffy" is about. Will a page _eventually_ load if I wait long enough? Or are there 10 sequential requests, 100KBs each, that all have succeed just to show me 2 sentences of text?

I had a frequent 1:30-hour train commute every couple of days to my previous role, and during that time, I learned how horrific our product was to use on a spotty connection.

Made me think more about poor & unstable connections when building out new features or updating existing things in the product. Easily parsable loading states, better user-facing alerts about requests timing out, moving calculations/compute client-side where it made sense, etc.

Assume terrible internet and then anyone with good internet is pleasantly surprised how not terrible your websites are.

Youre also opening up to more potential customers in rural areas or areas with poor reception, where internet may exist but may not be consistent or low latency

This article assumes people are primarily accessing these things at home. Maybe for most apps / websites that’s appropriate but people access these things internet on phones in places where connections can be spotty, and it’s very frustrating to be driving through a dead zone and have apps freak out.

I hope people making apps to unlock cars or other critical things that you might need at 1am on a road trip in the middle of nowhere don’t have this attitude of “everyone has reliable internet these days!”

Concrete example: I made an app for Prospect Park in Brooklyn that had various features that were meant to be accessed while in the park which had (has?) very spotty cell service, so it was designed to sync and store locally using an eventually consistent DB, even with things that needed to be uploaded.

"Remember that 4G is like 5/1Mbps, and 3G is even worse" this is just completely untrue. 4G can do 300meg+ real world no problem, and even back in the day with DC-HSPDA on 3G you could get 20meg real world.

HOWEVER the main problem (apart from just not having service) is congestion. There is a complete shortage of low bandwidth spectrum which can penetrate walls well in (sub)urban areas, at ~600-900MHz. Most networks have managed to add enough capacity in the mid/upper bands to avoid horrendous congestion, but (eg) 3.5GHz does not penetrate buildings well at all.

This means it is very common to walk into a building and go from 100meg++ speeds on 5G to dropping down to 5G on 700MHz which is so congested that you are looking at 500kbit/sec on a good day.

Annoyingly phone OSs haven't got with the times yet. And just display signal quality for the bars. Which will usually be excellent. It really needs to also have a congestion indicator (could be based on how long your device is waiting for a transmission slot for example).

I mainly work in a rural area. We have some clients who access the internet through private fixed wireless backhaul mounted to grain silos, satellite such as hughesnet, and DSL. Modern web design on connections like that means that these guys can be unable to download websites the normal way but they can stream a desktop over VDI and browse the net that way pretty reliably.

One of our biggest sticking points when new forms of multifactor came around is that it can sometimes take longer than a minute to deliver a push notification or text message even in areas that are solid red on Verizon's coverage map.

> This is likely worse for B2C software than B2B.

These are regional retail banks that all use the same LOB software. Despite the product being sold mainly to banks, which famously have branches, the developer never realized that there could be more than a millisecond between a client and a server. The reason they have VDI is so their desktop environment is in the same datacenter as their app server. It's a fucking CRUD app and the server has to deal with maybe a couple hundred transactions per hour.

I think this is pretty typical for B2B. You don't buy software because it is good. You buy software because the managers holding the purse strings like the pretty reports it makes and they are willing to put up with A LOT of bullshyt to keep getting them.

There is a (perverse?) incentive to have an always-on network connected to services that can be metered and billed -- that is how we get monthjly recurring revenue. Even hardware companies want in on that -- think HP printers and authorized toner cartridges.

A different perspective on this shows up in a recent HN submission, "Start your own Internet Resiliency Club" (https://news.ycombinator.com/item?id=44287395). The author of the article talks about what it would take to have working internet in a warzone where internet communications are targeted.

While we can frame this as whether we should design our digital products to accommodate people with iffy internet, I think seeing this as a resiliency problem that affects our whole civilization is a better perspective. It is no longer about accomodating people who are underserved, but rather, should we really be building for a future where the network is assumed to be always-connected? Do we really want our technologies to be concentrated in the hands of the few?

Even a regular mobile connection 4G-5G can feel spotty with connections/disconnections dropping for a few seconds. I spend some time every summer in rural Haliburton Highlands/North Hastings (middle Ontario), cellular reception is hit and miss, one bar maybe two, voice calls, when successful, sound awful and text messages frequently stay unsent (or send multiple times inexplicably). Unless you can afford starlink, or drive into the next town and hit the library wifi, you're out-of-luck. As you're driving cell service will drop depending on elevation. A quick check of facebook messenger and maybe loading a webpage for information. Forget a fancy app.