zlacker

[return to "Someone at YouTube needs glasses"]
1. rozab+V8[view] [source] 2025-04-30 15:59:09
>>jayden+(OP)
For a long time the grid of videos on the homepage has been slightly misaligned. I imagine the different rows belong to different teams. This means you can't hover your mouse in the gaps between columns while you scroll to prevent videos autoplaying when moused over.

I find the autoplay so annoying because it hides the thumbnail which was carefully designed to communicate why I should click on the video and replaces it with, usually, a talking head or stock footage. Often the video gets inexplicably added to my watch history, and if I do choose to click on it I have to go back to the beginning because I missed the start of the audio

◧◩
2. matsem+yh[view] [source] 2025-04-30 16:32:52
>>rozab+V8
What kills me with the autoplay (at least on mobile), is that the video continues from where it was when you click it. But the autoplay had no sound, and I probably didn't watch it closely. So I always have to scroll back to the beginning, as I've just now been put in the middle of a sentence a bit into the video. Especially for channels which actually gets straight to the point (like Numberphile) it's annoying. Such a stupid design.

Additionally there's a bug on the Android app that it sometimes doesn't show video titles (or the worlds worst A/B test?), so scrolling through I just see talking heads (since it autoplays instead of showing the video thumb) and have to force restart it to actually understand what's going on.

◧◩◪
3. prince+Gn[view] [source] 2025-04-30 16:57:03
>>matsem+yh
Mobile? There's also another sneaky piece of crap Google pulls - even if you're a Premium user and set your video preferences to high quality, they only play videos for you at 480p, even though higher resolutions up to 4k are all available.

If you manually increase the quality on that video, it will only apply for that video, and whatever videos you play next, will still be limited to 480p.

All this is just to save costs..A truly fucking shady tactic to fuck over paying users. Fuck Google for what they do and how they cheat naive users.

◧◩◪◨
4. nerdsn+ls[view] [source] 2025-04-30 17:21:26
>>prince+Gn
This is also an issue on desktop web. YT will arbitrarily change the quality/resolution but doesn’t update the selector displayed in the UI. So for every single video I have to select 4K just in case YT might be serving it at 1080p or some other resolution even though it displays “4K” on the UI element.

Also the compression algorithm is very aggressive and it works reasonably well for general content but for edge cases (like starcraft streams), the 1080p loses enough details to make it hard to see important things like observers and outlines of individual units in crowded clusters. The compression algorithm just isn’t trained/tuned for these types of content, so even on a 1080p screen I need to stream at 4K just to see the details properly.

◧◩◪◨⬒
5. Nathan+6F[view] [source] 2025-04-30 18:27:40
>>nerdsn+ls
The desktop issue was an intentional change that happened sometime in like 2017 or so.

The original functionality of the quality selector was to throw out whatever video had been buffered and start redownloading the video in the newly selected quality. All well and good, but that causes a spinning circle until enough of the new video arrives.

The "new" functionality is to instead keep the existing quality video in the buffer and have all the new video coming in be set to the new quality. The idea is that you would have the video playing, change the quality, and it keeps playing until a few seconds later the new buffer hits and you jump up to the new quality level. Combined with the fact that YouTube only buffers a few seconds of video (a change made a few years prior to this; back in the Flash era YouTube would just keep buffering until you had the entire video loaded, but that was seen as a waste of both YouTube's bandwidth and the user's since there was always the possibility of the user clicking off the video; the adoption of better connection speeds, more efficient video codecs, and widespread and expensive mobile data caps led to that being seen as the better behavior for most people) and for most people, changing quality is a "transparent" operation that doesn't "interrupt" the video.

In general, it's a behavior that seems to come from the fairly widespread mid-2010s UX theory that it's better to degrade service or even freeze entirely than to show a loading screen of some kind. It can also be seen in Chrome sometimes on high-latency connections: in some cases, Chrome will just stop for a few moments while performing DNS resolution or opening the initial connections rather than displaying the usual "slow light gray" loading circle used on that step, seemingly because some mechanism within Chrome has decided that the requests will probably return quickly enough for it to not be an issue. YouTube Shorts on mobile also has similar behavior on slow connections: the whole video player will just freeze entirely until it can start playing the video with no loading indicator whatsoever. Another example is Gmail's old basic HTML interface versus the modern AJAX one: an article which I remember reading, but can't find now found that for pretty much every use case the basic HTML interface was statistically faster to load, but users subjectively felt that the AJAX interface was faster, seemingly just because it didn't trigger a full page load when something was clicked on.

And, I mean, they're kind of right. It's nerds like us that get annoyed when the video quality isn't updated immediately, the average consumer would much rather have the video "instantly load" rather than a guarantee that the video feed is the quality you actually selected. It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.

This is also why Google's Lighthouse page loading speed algorithm prioritizes "Largest Contentful Paint" (how long does it take to get the biggest element on the page rendered), "Cumulative Layout Shift" (how much do things move around on the page while loading), and "Time to Interactive" (how long until the user can start clicking buttons) rather than more accurate but "nerdy" indicators like Time to First Byte (how long until the server starts sending data) or Last Request Complete (how long until all of the HTTP requests on a page are finished; for most modern sites, this value is infinity thanks to tracking scripts).

People simply prefer for things to feel faster, rather than for things to actually be faster. And, luckily for Internet companies, the former is usually much easier to achieve than the latter.

◧◩◪◨⬒⬓
6. jacobg+oa1[view] [source] 2025-04-30 21:37:15
>>Nathan+6F
> In general, it's a behavior that seems to come from the fairly widespread mid-2010s UX theory that it's better to degrade service or even freeze entirely than to show a loading screen of some kind.

> It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.

So they decided it's better to show lower-quality content (or not update the screen) than a loading screen, and it's the same school of thought that led to a loading screen being implemented? I agree both examples could be seen as intended to make things "feel" faster, but it seems like two different philosophies towards that.

(Also, I remember when quality changes didn't take effect immediately, but I've been seeing them take effect immediately and discard the buffer for at least the past few years-- at least when going from "Auto" that it always selects for me to the highest-available quality.)

[go to top]