Hacker News Reader

Comment by munro | Hacker News Reader

I hate these blurry image thumbnails, much prefer some sort of hole, and just wait for a better thumbnail (look at youtube for this, or basically any site). I'd much rather see engineers spending more time making the thumbnails load faster (improving their backend throughput, precache thumbnails, better compression, etc). The blurry thumbnails have 2 issues 1) trick person into thinking they're loaded, especially if there's a flicker before the blurry thumbnails are displayed!!! so then the brain has to double back and look at the new image. 2) have a meaning that content is blocked from viewing

View on HN

I think they're great, and it's not much different from progressive image loading that's been around for decades. Images going from blurry to sharp was a big thing back in the 1990's over dial-up AOL and MSN.

> I'd much rather see engineers spending more time making the thumbnails load faster

Generally it's a client-side bandwidth/latency issue, not something on the server. Think particularly on mobile and congested wi-fi, or just local bandwidth saturation.

> The blurry thumbnails have 2 issues 1) trick person into thinking they're loaded

I've never found myself thinking that -- a blurry-gradient image seems to be generally understood as "loading". Which goes all the way back to the 90's.

> 2) have a meaning that content is blocked from viewing

In that case there's almost always a message on top ("you must subscribe"), or at least a "locked" icon or something.

These blurry images are designed for use in photos that accompany an article, grids of product images, etc. I don't think there's generally any confusion as to what's going on, except "the photo hasn't loaded yet", which it hasn't. I find they work great.

>it's not much different from progressive image loading that's been around for decades

Progressive images suck. PNG's implementation is particularly awful, as you have to use increasing amounts of brainpower to tell whether it has finished loading or not.

What I find more of an issue cognitively is that they entice to discern their contents, but of course they are too blurry to really see anything and trigger the subliminal feeling that you forgot to put your glasses on. So they attract your attention while typically not providing much useful information yet. A non-distracting neutral placeholder is generally preferable, IMO. Even more preferable would be for images to load instantly, as many websites somehow manage to do.

> The blurry thumbnails have 2 issues 1) trick person into thinking they're loaded

But is _not_ showing blurry thumbnails during image loading any better in that regard?

- an empty area would give the false impression there isn't any image at all

- a half-loaded image would give the false impression the image is supposed to be like that / cropped

- if e.g. the image element doesn't have explicit width and height attributes, and its dimensions are derived from the image's intrinsic dimensions, there will be jarring layout shifts

> 2) have a meaning that content is blocked from viewing

For you maybe. And even when so, so what? Page context, users' familiarity with the page, and the full images eventually appearing will make sure this is at most is only a temporary and short false belief.

When browsing DCIM via sshfs, I'd kill for using this instead of having to wait for it to read every 3MB image and generate a thumb to show me. I don't have a problem with current thumbs because the status quo of waiting 30 seconds for a page of images to get thumbed is so terrible. Probably I'd love the improvement if it would use ThumbHash server-side^W phone-side instead of small pngs or whatever it does today.

I think these issues can be solved by just rendering a spinner or "loading" text on top of the blurred image.

Maybe... but solving dstraction with more distraction feels off somehow.

Definitely don't want 100 spinners over a grid of images.

Reply on news.ycombinator.com