4 ms·

Lately my internet connection has been ridiculously bad. It made me realise how often UX is ignored for bad connections. One of the things I notice with SPAs i

Lately my internet connection has been ridiculously bad. It made me realise how often UX is ignored for bad connections. One of the things I notice with SPAs is that since the browser navigation does not occur normally, I get no indication from my browser that a link is loading, so the app is completely responsible of adding their own navigation indicators (which is uncommon to see in the wild). Also sort of unrelated, I constantly see search forms that are "real time" but do not even abort previous requests, so to me it appears as no feed back, then once I finish typing I get a new set of results every second or so until it completes, making it extremely frustrating.

gregmac 3y ago
So much of this is because developers work on high-end systems with a ridiculously fast internet connection (whether at home or work). It isn't super-hard to fix this, but does take effort/time/money. For example, test on slow devices on slow connections. There are proxies that can throttle and introduce latency, or even let random connections timeout. There's a catch-22 here though: doing this early in a product's life probably doesn't make sense as it's almost certainly better to focus your efforts on creating the product. But the longer you wait, the harder (== more time-consuming == more expensive) it is -- there's more architecture to change, there's complex page logic that eg didn't account for potential timeouts while doing a callback to validate something entered in a text box is unique, etc.
- tomxor 3y ago
  There really is very little excuse for it, throttling is built right into the dev tools of both Chromium and Firefox, it's a couple of clicks away. It's as important as cross browser testing and easier to do. Another thing I've noticed a lot of sites are very poorly optimised for is latency. HTTP 1.1 is already poor in this regard due to the number of round trips required for setup, and when you start chaining these together latency becomes highly magnified, especially if they aren't on the same domain and you need a whole new HTTP setup for each step in the chain. Even with HTTP 1.1 this can be minimised by looking at the chain of requests and reorganising them to be less dependent on each other. When your latency is in the single digits and it get's multiplied by 10, that's at most 100ms, now go to mobile and it's 400ms, now in the worst case a low bandwidth connection like ADSL (which will affect latency when the weight of each request is high) or a distant connection on a different continent and you can easily get into 10s of seconds. I find this one the most annoying because the fundamental problem is poor utilisation of the connection, they don't even need to change the size of the payload, there are simply long periods when the browser is waiting to find out what to do next and the connection is mostly idle.
  - mewpmewp2 3y ago
    > It's as important as cross browser testing and easier to do. Do people even do that nowadays?
thepra 3y ago
There's the "Network Information API" but so far its a Chrom* only thing https://caniuse.com/netinfo https://caniuse.com/netinfo and I can easily see how it might be a privacy concern given that it gives yet another data point to everyone

gregmac 3y ago

So much of this is because developers work on high-end systems with a ridiculously fast internet connection (whether at home or work). It isn't super-hard to fix this, but does take effort/time/money. For example, test on slow devices on slow connections. There are proxies that can throttle and introduce latency, or even let random connections timeout. There's a catch-22 here though: doing this early in a product's life probably doesn't make sense as it's almost certainly better to focus your efforts on creating the product. But the longer you wait, the harder (== more time-consuming == more expensive) it is -- there's more architecture to change, there's complex page logic that eg didn't account for potential timeouts while doing a callback to validate something entered in a text box is unique, etc.

tomxor 3y ago
There really is very little excuse for it, throttling is built right into the dev tools of both Chromium and Firefox, it's a couple of clicks away. It's as important as cross browser testing and easier to do. Another thing I've noticed a lot of sites are very poorly optimised for is latency. HTTP 1.1 is already poor in this regard due to the number of round trips required for setup, and when you start chaining these together latency becomes highly magnified, especially if they aren't on the same domain and you need a whole new HTTP setup for each step in the chain. Even with HTTP 1.1 this can be minimised by looking at the chain of requests and reorganising them to be less dependent on each other. When your latency is in the single digits and it get's multiplied by 10, that's at most 100ms, now go to mobile and it's 400ms, now in the worst case a low bandwidth connection like ADSL (which will affect latency when the weight of each request is high) or a distant connection on a different continent and you can easily get into 10s of seconds. I find this one the most annoying because the fundamental problem is poor utilisation of the connection, they don't even need to change the size of the payload, there are simply long periods when the browser is waiting to find out what to do next and the connection is mostly idle.
- mewpmewp2 3y ago
  > It's as important as cross browser testing and easier to do. Do people even do that nowadays?

thepra 3y ago

There's the "Network Information API" but so far its a Chrom* only thing https://caniuse.com/netinfo https://caniuse.com/netinfo and I can easily see how it might be a privacy concern given that it gives yet another data point to everyone