411–420 of 622 posts
Earlier quoted context omitted.
I love this visual, but elevators have way more safety mechanisms than poorly-designed web sites. Check out the source HTML of instagram.com for a great example. /-:
Well, my point isn't about safety, it's about usability. Escalators can still be used as stairs when they fail. Elevators can't be used at all.
Earlier quoted context omitted.
Disable JavaScript. You’ll be surprised at how most of the web still works and is much faster. Longer battery life on mobile, too.
FWIW, I just tried this in Firefox (set javascript.enabled=false) and went to my bank's website to see how it would fare. Firefox crashed. Tried again with no other tabs open, still crashed. Crash report sent. OTOH, in Chrome the website actually works fine and feels more snappy with JS disabled. So, thanks for the tip!
Joey Hess (joeyh) has been writing about this for a long time (because he uses dial-up at his home). Here is a recent thread about a 2016 blog post on this: https://news.ycombinator.com/item?id=13397282
> Please, please, if your site requires AJAX to work at all, then retry failed AJAX queries. Anyone here have information on the most reliable heuristics to do retries? Or information on the implementations used by say Gmail or Facebook?
Something I have had at the back of my mind for a long time: in 2017, what's the correct way to present optional resources that will improve the experience of users on fast/uncapped connections, but that user agents on slow/capped connections can safely ignore? Like hi-res hero images, or video backgrounds, etc. Every time a similar question is posed on HN, someone says "If the assets aren't needed, don't serve them…
This seems like the thing that we'd want cooperation with the browser vendors rather than everyone hacking together some JS to make it happen. If browsers could expose the available bandwidth as a media query, it would be trivial to have different resources for different connections. This would also handle the situation where the available bandwidth isn't indicative of whether the user wants the high-bandwidth experi…
I don't know why this seems like such an imposition, but I think I'd be uncomfortable with my browser exposing information about my actual network if it didn't have to. I have a feeling way more people would be using this to track me than to considerately send me less data.
That said, browser buy-in could be a huge help, if only to add a low-tech button saying, "request the low-fi version of everything if available." This would help mobile users too -- even if you have lots of bandwidth, maybe you want to conserve.
Earlier quoted context omitted.
A lot of people naively assume that if you can use a resource more efficiently, then total use will go down, "because you don't need as much, right?" See: the entire popular support for efficiency mandates. (Edit: Also, this very example -- I certainly didn't expect that a faster site would allow that many more users: my model was more "either they want to see your site, or they don't", i.e. inelastic demand.) The (c…
This sounds like the reason widening roads doesn't usually ease congestion. Which, really, can be summed up by my favorite Yogi Berra-ism "No one goes there nowadays, it’s too crowded."
Earlier quoted context omitted.
This was the baseline experience everywhere in the 90s: people would just do something else while they waited for things to download over dialup. Clients for things like email, Usenet, browsers, etc. commonly had batch modes where you could queue large downloads so you could basically see what's new, select a bunch of large things, and then let it download while you got a cup of coffee / dinner / slept.
There was a time when Netflix was young, and I had slow internet, that if you queued up a movie and then paused it, it would continue to load. So you'd pick a movie, queue it up (literally) and then go make snacks and get situated. When the bar looked long enough you'd start watching. Then if it stalled (which it would do like clockwork every evening around 8 pm) you'd take an intermission. By the time I got stuck wi…
Earlier quoted context omitted.
FWIW, I just tried this in Firefox (set javascript.enabled=false) and went to my bank's website to see how it would fare. Firefox crashed. Tried again with no other tabs open, still crashed. Crash report sent. OTOH, in Chrome the website actually works fine and feels more snappy with JS disabled. So, thanks for the tip!
Can you share the crash report IDs from your Firefox's about:crashes page? Can you share a link to your bank's crashing web page? I'd like to try to reproduce the crash. Thanks!
Earlier quoted context omitted.
Well, that's just the default way interactivity in websites works - submitting forms.
You could have used an iframe for each button instead of a normal form to prevent the reload of the page. Using an iframe with data: should take no longer to load than a normal form.
I guess we're almost all on evergreen browsers now anyway...
Earlier quoted context omitted.
Not really. It's very easy to get bloat if you integrate ad-networks, analytics tools, social media tools etc. willy-nilly without looking at all the resources they fetch. The lazy approach WILL lead to bloat. No news agency is running a plain jane HTML website.
Your kind of proving my point. If you add these things in, it's more work. If you make a plain html site, which is what these sites should be doing, then you aren't going to add that stuff in, which means less work.
There is definitely a trade-off between ease-of-use and cost-of-use and I feel this gap is bridged by the content created by those who could not publish bare bones.