https://i.kym-cdn.com/photos/images/original/001/333/130/835...
Sadly, the tech may have changed but both our ideas on usability and the incentives at play have remained the same. Which is to say, the devs I know of all know that popup videos, banners, modals, etc. are all trash much like the popup ad banners of 1997. But we do them anyway because the people that pay us have financial incentives that have been proven via misguided A/B testing that they work. And by misguided I mean... we're talking about manipulation, right? That's the whole shell game of A/B testing. You're testing your way to what works best for you and not your users. It's Tinder knowing the perfect match for you but not showing you that person because you'll quit the app if you ever met them.
I can't even take a11y or people that advocate a11y seriously today. You built modals and carousels with frustrating timeouts that slide content before I'm done looking at it! You're a circus clown.
A/B testing is a tool. Any tool can be misused.
On the other hand: marketing and execs could misuse and abuse an empty room if they do desired, so I wonder why we bother giving them tools in the first place.
That’s quite the claim.
Yes. It is totally possible to misuse the tool and run bad tests. That’s why, at least where I work, we don’t run live A/B tests until we’ve done some initial validation that the idea isn’t just terrible, and we have some level of confidence it will work and not harm the user’s experience. For example, we could segment user feedback and customer support issues we received by test variant so we could look for unexpected issues we might have inadvertently caused with the challenger design.
I can’t speak for how A/B testing is used elsewhere, but every A/B test I’ve run has been because we thought it would improve things for the user.
You certainly could run an A/B test to see which banner ad is more deceitful, just like you could use React to build the website that sells the scam medicine that banner ad is advertising.
Then: Page was slow because the delivery was via a 56k analog modem.
Today: Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.
I think it's mostly blocking chains of multiple networks requests that execute in sequence (taking a network round-trip each time). I inherited a slow ~2mb frontend app at work, which seemed horrendously bloated to me. It turned out to be not that easy to reduce to the size (due to large amounts of code depending on large libraries), but it also turned out to be possible to make it load fast without reducing the payload size.
- Every single database read depended on it
- Many of them were subscriptions rather than simple reads, and so couldn’t be trivially replaced by an API call.
Don’t use firebase guys.
You can see the size of each bundle in here: https://firebase.google.com/docs/web/sdk-metrics
I work for a large health care company. They got on the JS bandwagon a while ago. We used to have huge sites that loaded fairly quickly (under 2 seconds) and cleanly. Now? The last two years doing accessibility work - a lot of these same sites which have been converted to Angular or React? They're taking in excess of 15-20+ seconds to load.
By my second or third job, nobody seemed to care about it and when I brought it up, it was brushed aside as a "browser issue" and not something we devs needed to worry about.
You make a great point, and something I'm seeing a lot more of now that I'm in accessibility.
Because if you provided these, the browser would know how much space to leave for the image to occupy after it had downloaded [this was back in the dial-up modem days. So images usually loaded gradually after the rest of the page] and so the layout of the page would not change. Conversely, if you didn't provide 'width' and 'height' attributes, the browser would only leave a default small icon sized space for the image and then you'd have the page content move and shuffle about as each image downloaded and the rest of the page content got elbowed out of the way, to accommodate it.
It's funny how such basic concepts of usability seem to have fallen by the wayside in our new modern Web3 [or whatever version buzzword we're on now] in favour of moving content, modal overlays and the like. And, since so many sites these days just aggregate content from countless other external sources, even that basic notion of pre-defining your image sizes is often neglected too.