Testing over a heavily throttled connection that drops packets should be a mandatory part of usability testing for anything intended to be used over the Internet.
The NPR One app used to chew through a few hundred mb of data in "caching" every time you started it. No way to restrict this function to wifi only. And no, you can't select bit rates.
Also Zoom has little ability to minimize the audio or video data usage (but I've learned you can reduce how much of others video is sent to you by reducing the window size). Just wish I could set myself to 480p to be present but not destroy my data while working at the cabin.
Likely true. Zoom doesn't chew up much bandwidth. I always find it funny when people think they need to upgrade their home internet bandwidth because a family "works & studies from home". Unless you're up/downloading huge media files, several instances of Zoom and virtual desktops will consume less than a 4k Netflix stream.
Would this be achieved by plugging in a crappy camera and only giving that to Zoom?
People used to say the same about accessibility until the ADA lawsuits started coming in forcing businesses to take it seriously.
There needs to be a business incentive to spend developer time on low bandwidth. Progressive web apps that cache stuff are about all you're gonna get for now.
Which is a shame, since FF dev Tools have a quite comfy tool for testing the we page in low bandwidth environments:
* https://firefox-source-docs.mozilla.org/devtools-user/networ...
(I haven't done web de for a good ten years now, yet, even I somehow know about these)
> Testing over a heavily throttled connection that drops packets should be a mandatory part of usability testing for anything intended to be used over the Internet.