Upvoting not for the surprising fact that North Dakota has great gigabit fiber.

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

Yes.

Next que...<loading>

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.

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.

iffy internet and iffy devices, as what works with a good signal, can go haywire with a few settings not quite right. I run exlclusivly from mobile internet, two phones, one is serving as the primary data conection for both and recently figured out that the way the wifi was configured was contributing to the signal dropping, but only in rural areas with a weak cell signal on busy towers, it took some experimenting to get things to work reliably. But there are still a lot of places where the signal comes and goes, so useing a phone as a local only device is normal, or as a degraded device with perhaps just voice and text...perhaps not.

Notably, two products that work really great in bad internet are WhatsApp and the openAI API (ie. I can ask GPT4 some question, then have the internet cut out for a couple of minutes, and when a few more packets get delivered I have my answer there!)

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?

I have fiber at home and at my office, but when I’m out I appreciate sites like HN that work well on unreliable or congested cellular/Wi-Fi.

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.

Yes yes yes we should. Bloated pages are a symptom of Enshittification. When I try to buy something on Amazon there's so much crap, menus that drop down on hover, that I just close and go away. Or search Amazon via Duck. Also part of the bloat everywhere is the unconstrained tracking and surveillance. .. Design benchmark should be lightweight pages like HN and Craigslist!

Why are all your maps only of the Western US? Most people live in the eastern half.

https://www.reddit.com/r/MapPorn/comments/vfwjsc/approximate...

I know a lot of the West has terrible broadband, but a not insignificant majority of that land area is uninhabited federal land -- wilderness, such as high mountains, desert, etc. By focusing on the West and focusing on maps that don't acknowledge inhabitedness as an important factor, it confuses the issue.

I'd argue it's more of a travesty that actual fiber optic internet is only available in maybe 15% of addresses nationwide, than the white holes in Eastern Oregon or Northern Nevada. One major reason I believe this is that even at my house, where I have "gigabit" available via DOCSIS, my upload is barely 20Mbps and I have a bandwidth cap of 1.25TB a month which means if I saturate my bandwidth I can only use it for 2 hours 46 minutes per month.

If you compare "things that would be possible if everyone had a 500Mbps upload without a bandwidth cap" vs "things I can do on this connection" it's a huge difference.

Well yes.

I can think of at least two supermarkets where I have crap internet inside in spite of having whole city decent 5G coverage outside.

One thing that never loads is the shopping app for our local equivalent of Amazon. I'm sure they lost some orders because I was in said supermarkets and couldn't check out the competition's offers. Minor cheap-ish stuff or I would have looked for better signal, but still lost orders.

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.

I write software for "budget-conscious" orgs.

Translation: shitty servers.

That means that the connection might be fine, but the backend is not.

I need to have a lot of error management in my apps, and try to keep the server interactions to a minimum. This also means that I deal with bad connections fairly well.

Yes. Go to Germany and travel from any large urban area to the next and you'll see why - it's a meme by now that coverage on trains and even Autobahns is piss poor.

And no, geography is not an excuse. Neighboring Austria has same geography as Bavaria, and yet it is immediately noticeable when exactly you have passed the border by the cellphone signal indicator going up to full five bars. And neither is money an excuse, Romania - one of the piss poorest countries of Europe - has 5G built out enough to watch youtube in 4k on a train moving 15 km/h with open doors to Sannicolao Mare.

The issue is braindead politics ("we don't need 5G at any remote milk jug") and too much tolerance for plain and simple retarded people who think that all radiation is evil.

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?

What are good ways others are testing for iffy internet?

Dropped packets? Throttling? Jitter?

I am trying to figure out if there are good testing suites for this or if it is something I need to manually setup.

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

We should design for censor obfuscation- as in the censors should not be able to grab and manipulate any system used. In that regard, ai has been a great success. Even though there are censorship systems in the prompt and in the filter, the final source of truth is not poisoned, can only with great effort be poisoned and shows itself under local interrogation.

Systems hardened against authoritarianism are a great thing. Even the taliban have mobile coverage in kabul- and thus, every woman forced under the dschador holding on to a phone, has a connection to the world in her hand. Harden humanity against the worst of its sides in economic decline. I dream of a math proof, coming out of some kabul favella.

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.

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

if you want to /design/ a website, every KB should count. Needlessly including huge bits of clunky, flakey, extra heavy bits and huge images or fancy videos is.... bleh!

I don't think most developers are capable of this. Call me elitist, but the concept of data from the network as being qualitatively different as data in memory is just foreign to most people.

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.

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.