[HN Gopher] Should we design for iffy internet?
___________________________________________________________________
Should we design for iffy internet?
Author : surprisetalk
Score : 49 points
Date : 2025-06-16 15:34 UTC (2 days ago)
(HTM) web link (bytes.zone)
(TXT) w3m dump (bytes.zone)
| MatthiasPortzel wrote:
| Upvoting not for the surprising fact that North Dakota has great
| gigabit fiber.
| dbetteridge wrote:
| 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
| rkagerer wrote:
| Yes.
|
| Next que... _< loading>_
| Xunjin wrote:
| Your comment will probably get flagged, but take my upvote, as
| this is a good/constructive joke.
| pfych wrote:
| 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.
| steelegbr wrote:
| 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.
| metalman wrote:
| 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.
| londons_explore wrote:
| 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!)
| theragra wrote:
| Whatsapp is famous among Ukrainian war soldiers on both sides.
| It is the only thing that works when you have around 2 bars
| cell connection.
|
| Funny that American civil service is used by militaries on both
| sides. At least it was used in some role during the war, bot
| sure about now.
| tguvot wrote:
| discord video for real time drone footage also nice
| hosh wrote:
| 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?
| divbzero wrote:
| 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.
| _-_-__-_-_- wrote:
| 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.
| CommenterPerson wrote:
| 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!
| xp84 wrote:
| 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.
| nottorp wrote:
| 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.
| smelendez wrote:
| 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.
| unsnap_biceps wrote:
| I live in a pretty remote community, but we have a weekly
| farmer's market during the summer. A few years back, one of the
| vendors evidently ran some sort of scam on Venmo and Venmo
| banned _everyone_ that bought anything from the vendor.
| Practically like a quarter of our community is banned which is
| a huge issue for other vendors that show up now that only
| support Venmo.
| no_wizard wrote:
| I'm surprised, mostly because I don't understand the logic of
| only taking Venmo and nothing else. The company isn't well
| known for great customer service and can be quite hostile to
| helping with fraudulent transactions (to the point of this,
| they banned the end users who got scammed, not just the
| scammer. I also wonder if they were made whole).
|
| Seems like a bad idea to me. Even Square with Cash App
| support would be better
| ChrisMarshallNY wrote:
| 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.
| mschuster91 wrote:
| 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.
| pianom4n wrote:
| 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?
| chung8123 wrote:
| 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.
| pluto_modadic wrote:
| amtrak /s (that or hiking someplace)
| martinald wrote:
| "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).
| jdwithit wrote:
| Yeah the signal strength indicator being BS (or, if we're being
| charitable, incomplete to the point it's misleading) is
| extremely frustrating. It's quite common for my iPhone to say I
| have full bars of LTE or even 5G, yet the data connection is
| unusable. There's seemingly no correlation between showing a
| great signal and content actually loading. I would love to see
| at a glance that there is no point in even trying versus
| spending a minute fiddling with my phone before giving up in
| frustration.
| ItCouldBeWorse wrote:
| 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.
| jabroni_salad wrote:
| 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.
| linsomniac wrote:
| 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. ;-)
| Swizec wrote:
| > 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.
|
| Essentially local-first apps. Have a local database with all
| the info, use straight up SQL (or whatever) for your
| interactions, sync periodically with the mothership. Great
| solution for many usecases.
|
| This was one of the original promises of mobile apps and what
| makes them better than websites. But the industry went a
| different way - many mobile and desktop apps became glorified
| browsers where nothing works without good internet.
| pluto_modadic wrote:
| 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!
| LAC-Tech wrote:
| 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.
| klik99 wrote:
| 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.
| maxcomperatore wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-18 23:00 UTC)