Comment by hn_throwaway_99
1 day ago
Yeah, when I read the article I thought "Great, more paternalistic advice that pretends we have infinite resources/time/money."
Anyone who has ever done website or mobile development knows there is a huge array of browsers and platforms, and supporting the very long tail of configurations is sometimes nearly impossible, let alone almost never cost effective. When I last ran some web apps, we'd see substantial numbers of errors just due to f'd up (or sometimes outright malicious) browser plugins. I'm not checking every random configuration of browser plugins against my website to ensure they all work.
Like you say, it really depends, which is why I hate blanket directives like the article gave. If suddenly 2% of people couldn't log into gmail, that would be a huge deal affecting 10s of millions of people. As the adage goes, "You're not Google", and for a lot of small e-commerce websites trying to fix someone on some decade+ old browser just doesn't make sense (and, as another comment mentioned, these users are often the least likely to convert in any case).
He wasn’t actually giving a blanket directive. The article was suggesting that you think about whether 98% is actually good in your use case by doing the math and thinking.
Yeah, but the guy writing the article seems to be bad at math and thinking.
Can I imagine a venue kicking out 2% of their former clients on some criteria? Absolutely yes.
Kicking out 2% of website visitors may still be totally reasonable if the cost to serve them is meaningful, or if they are less than 2% of revenue.
His defense for 98% being bad is that some CSS thing people were arguing about only had 70% coverage on his website.
Our b2b dashboard didn't support Safari for a while at all and it was entirely not an issue because everyone had a simple workaround to just use Chrome and the dashboard wasn't really the main product.
I think you're not being generous in your interpretation. How I read it he could be talking about the number of 9s a server's uptime is. If you pay for 1 9 you'll lose a lot of customers. Hell, true for even 3 9's. Look at all the complaints about GitHub this year. 5 9's is the standard and that's 99.999%!!
The thing is that it is all context dependent. A lot of times 0.1% is nothing and can be ignored or pushed off. But sometimes that 0.1% is worth billions of dollars.
The point is that data means nothing without context and interpretation. If you're lazy in your analysis you are going to have lots of issues
1 reply →
Kicking out 2% of your existing customers in a physical venue violates people's expectations, so it's going to get you disproportionate bad reviews and word-of-mouth.
Good thing that we've managed to keep everybody's expectations a hell of a lot lower for software quality then :)
2 replies →
imagine not 2% of users not being able to use the site, but any given user not being able to use the site 2% of the time, and see if that changes the calculus for you.
2 replies →
Except there was 0 analysis of the cost/benefit of supporting the end of the long tail, instead it was just economics-free shaming. Of course, you want to see who those 2% of users actually are. But nowhere in this article did I find any advice I'd actually want to use in a really business scenario.
Isn't the end of the article saying that their users are mainly in that tail? Seems to be exactly what you say: figuring out who those 2% are. In the OP's case, it's 30% of their users
98% of HN commenters reply to the interpretation of the article they feel most capable of arguing against, which is usually the least charitable one.
I mean the name was "98% isn't much" and the article made it sound like 98% isn't good enough
Respectfully: To me these just sound like excuses.
I can write a web page that works correctly on all browsers. We all can. That web page won't do much of anything, but it's possible. So, there is a baseline "target subset of HTML/CSS" that gives you 100% coverage. From there, it's purely developer choice: When you add something, are you choosing technology that is widely available and supported, or are you choosing to throw 0.N% of users under the bus for some benefit (development speed/comfort)? Obviously, it's a trade-off, and no final product is going to work on 100% of configurations. All these choices deliberately made during development add up to the product you deliver at the end of the day. All I'm asking is that we recognize browser/platform incompatibility/inaccessibility as choices and not some inherent property of software.
When a developer says "it's too expensive to develop this for a dozen configurations" that just means they have already chosen to make their applications inaccessible, and are justifying it after the fact.
The inherent property of software is that the only way to be sure your software works on a particular platform is to test on that platform.
There is not a baseline target subset of HTML/CSS that reaches 100% coverage that can be statically verified. HTML tables usually work in old browsers, but there were subtle bugs in old versions of Internet Explorer, bugs that you're especially likely to hit if you're using tables for layout (because you can't use modern CSS layout features). The only way to be sure that you didn't trigger one of those subtle bugs is to test your web app on ancient browsers.
The cost of reaching the last 0.N% of users rises with each platform you add to your test matrix. It costs money to test your web app on Internet Explorer. It costs even more money to fix bugs that only affect Internet Explorer.
I think you can't deny that doing that work is expensive. The question then has to be whether that work will repay itself somehow. But the last 0.N% of users will only provide ~0.N% increases to your revenue. Unless your revenue is astronomical, you can't afford even one full-time engineer to test and fix bugs on 0.N% of browsers.
But again you're flattening all browser compatibility into ancient browsers that 10 people use and saying closing the end of that gap is far too difficult to justify the time and expense required, but what exactly are we talking about there? What broke? Can people on IE6 get the majority of the content but the subscription popup is broken, or does the page fail to render entirely and leave them completely high and dry?
It's impossible for me to engage with this thought experiment without thinking of hundreds, perhaps thousands of sites I've been to (their provider rhymes with Rare Mace) where literally nothing works without JavaScript, and I don't mean animations are broken or images look funny, I mean the website is a white fucking screen because literally everything is loaded in via esoteric new JS frameworks which aren't firing because the engine choked on an analytics package and died before it even got that far, and that site is showing...
... text. Formatted text. With perhaps some pictures. And animations nobody outside of marketing cares about.
So like, is your site broken because it's legitimately cutting edge shit, doing difficult work, and providing an answer to a complex user problem? Okay cool, IE6 support is probably not a high priority, I agree. Or, is it an utterly run-of-the-mill ad for your company's services, that was made incorrectly by people who don't know what they're doing, and/or have overengineered it beyond recognition of the actual problem it was trying to solve? If it's that one, then put your shiny toys down, rebuilt it simply and with regular tooling, and THEN see how your IE6 compatibility is doing.
I'll tell you this much: I've NEVER tested for IE6 on my personal website. I just did. Navigation is a bit wonky and my blur filter effects are broken, obviously. But you can still read my posts and navigate about.
At what point is a good point to call it a day though?
Unless I am very specifically being paid for it, which I would love to be and I would enjoy doing because I love CSS, there are features that would rather make my experience, and the experience of the entire site better over the course of a decade+, such as nesting. Nesting has changed everything about CSS for me with project organization that makes changes significantly easier, AND significantly easier to pass off to another person. Now that it's at about 90% browser compatability[0] I actively use it in every single project I can, but it's still not supported if you haven't updated your browser in 3 years or use a random oneoff browser that may come with your knockoff smartphone.
It is an excuse, but it's also an honest question. Granted, not all projects are created equal, some of them are for people looking for bleeding edge technology, where it makes sense they would have their browsers updated. Some are government websites that should be accessible to 100% of everybody even if they're looking at your page on a 14 year old psp.
[0] https://caniuse.com/css-nesting
This goes to show you’ve never been anywhere near the actual development cycle of a real-world front-end web application. “So, there is a baseline "target subset of HTML/CSS" that gives you 100% coverage.” Oh really? Which subset? Which “HTML/CSS?” And 100%? Absolutely laughable.
Do you know any browsers which don’t support https://motherfuckingwebsite.com/ (if you remove the google traffic tracking js that’s iirc tacked on at the end of the page (or maybe I’m thinking of better mfing website (which adds a tiny bit of css)? Idr.)) ?
I get that asking a commercial website to be as basic/supported as that website is a big ask. I don’t think the other commenter was saying that such websites should reach 100%, only that they should start from there and sacrifice only as much as is necessary.
1 reply →