Adding design for @Nirzar

Good suggestions IMO. +1 to all.

See also:

• T135430: Updates to lazy loaded images UI
• T135434: Lazy loaded images: Images may be cut off by 2px
• T130652: Lazy loaded images: border-radius retained when images lazy loaded

Two were merged into the current task. We can continue discussion here.

I urge we aim for simplicity with the goal to approach the non-lazyload experience as close as possible. We can add fancy things later once we know the basics are fine. The most important risks, and factors to gain confidence in, are:

• Performance (no significant overhead in JavaScript processing and its forced style recalculation via used jQuery and mw.viewport methods).
• UX (perceived performance shouldn't regress).
• Bot crawling (fallbacks working properly).
• Cross-browser compatibility of added HTML, JS and CSS. (noscript mode, Grade C, and Grade A)
• Search engines (I'll elaborate on this in a separate task).
• Permalinks to section headings (with regards to UX).
• Firefox back-forth cache vs lazy-load logic.
• Stability of isElementInViewport logic (does it return true for all edge cases?)
• Stability of MobileFrontend loadImages logic (does it catch all ways in which the viewport can be initialised and/or changed through scrolling and otherwise etc.)

Proposed changes:

• Remove border and border-radius. (Complicates layout, could be tried again later in beta.)
• Insert image directly, don't wait until after loading is finished. (See T135430)
• Match behaviour of non-lazyload:
  • Placeholder is a simple container in which the browser natively loads an image. The lazyload behaviour merely changes when the load starts. There is no need for extra design elements, styles or animations. (We've never had this in the regular version, either.)
  • Don't apply background-color and spinner by default. As enhancement, maybe apply background and spinner after 1 second of loading has passed (and cancel the timer when image is ready). The background-color could be given a simple CSS transition. - (See also Google RAIL guidelines)
  • This reduces cognitive overhead for the user and increases chances of the image flawlessly loading off-screen while the user scrolls to it. The placeholder should only introduce extra intermediary visual state in case the image fails to load quickly. The default experience should be the same as without lazyload. There's reserved space (just like the browser does normally) and the image loads into it. Nothing more, nothing less.
• Unwrap image from placeholder once loading completes.

I imagined the spinner experience to be different than what we have now.

I think we are missing a big issue here which is the threshold for "isInViewport?" we need to fix that value which will fix most of these issues mentioned here. The lazy loading starts pretty late and last second of something coming into the viewport, if we can change that and load images a tad bit earlier, we will not have the abruptness we are experiencing on fairly fast connections.

I am not against removing spinners here but as i said, if the image is still not loaded (even after we increase the threshold), we need some kind of indication.

the third thing about the treatment, we can remove the border (and radius) and make the background color #f5f5f5 the one we use for base colors. which is much lighter. I wouldn't remove it completely, though. it's difficult to grasp what to expect as a reader without bounding boxes.

I'm re-tagging with sprint 74 in acknowledgment of @Nirzar's comment and to accommodate for more time to analyze design, while we wait for T133565: Images do not load until scroll event completes (not during scroll) on iOS to be built and settle in.

In T135476#2317075, @Nirzar wrote:

I imagined the spinner experience to be different than what we have now.

I think we are missing a big issue here which is the threshold for "isInViewport?" we need to fix that value which will fix most of these issues mentioned here. The lazy loading starts pretty late and last second of something coming into the viewport, if we can change that and load images a tad bit earlier, we will not have the abruptness we are experiencing on fairly fast connections.

Even with that fixed there is an unavoidable situation where the image will sometimes not be present due to fast scrolling (rendering of page is blocked during scroll events).

I am not against removing spinners here but as i said, if the image is still not loaded (even after we increase the threshold), we need some kind of indication.

The spinners currently do not act as an indication until the scroll event stops at which point the image has usually loaded (loading of image is not blocked during a scroll event). I would thus agree that removing them is a good idea.

the third thing about the treatment, we can remove the border (and radius) and make the background color #f5f5f5 the one we use for base colors. which is much lighter. I wouldn't remove it completely, though. it's difficult to grasp what to expect as a reader without bounding boxes.

@Krinkle @Peter is this okay with you?

Change 289012 had a related patch set uploaded (by Krinkle):
Lazy-load: Remove animations

https://gerrit.wikimedia.org/r/289012

Change 289013 had a related patch set uploaded (by Krinkle):
Lazy-load: Remove the placeholder once the image has loaded

https://gerrit.wikimedia.org/r/289013

@Nirzar Could you comment on the matter of animations? Previously mentioned in T135476#2302505 and T133565#2310070.

Currently the animation is triggered after the image has finished loading. This has two kinds of issues:

• The user doesn't see the image until it is completely loaded. Normally, when browsers render images, there is progressive loading. Which has the benefit of giving the user a partial image if loading gets interrupted or is slow - instead of waiting for the loading to time out and nothing being shown (current behaviour).
• The browser is informed about the animation after loading has finished loading, via JavaScript. For performance reasons, the event handler of the image load completing is not prioritised by the browser when handling scroll events. As such, even when loading very slowly and on a fast connection, the image does not show up even when it finished loading until scrolling stops and our JavaScript starts the animation. The browser is perfectly capable of drawing to the screen while scrolling, but it has to be either native image loading, or CSS that the browser knew about ahead of time.

It sounds like you want the animation to be kept, however we'll need to decide how to do that with progressive loading.

I propose that we schedule the animation via CSS at the same point that we start loading the image itself. In other words: Insert the image element into the DOM and start the animation (for example: a 0.3 second fade-in animation with a 0.5s delay). Which means after 0.5s the image canvas will fade in whether completed or not. If not completed, the rest of the image will load progressively to the user directly. All which can happen concurrently with scroll events.

Normally, when browsers render images, there is progressive loading. Which has the benefit of giving the user a partial image if loading gets interrupted or is slow - instead of waiting for the loading to time out and nothing being shown (current behaviour).

Are you sure they work on mobile browser? if browsers have elegant (non abrupt) ways to progressively load the image we won't need the fadein. currently, from what i can see, images load abruptly without the fadein.

I just talked to @Jdlrobson about workaround the issue you have mentioned.

The browser is informed about the animation after loading has finished loading, via JavaScript.

If we have -webkit-transition in the default image class we can get around the JS entirely?

I propose that we schedule the animation via CSS at the same point that we start loading the image itself. In other words: Insert the image element into the DOM and start the animation (for example: a 0.3 second fade-in animation with a 0.5s delay). Which means after 0.5s the image canvas will fade in whether completed or not. If not completed, the rest of the image will load progressively to the user directly. All which can happen concurrently with scroll events.

that sounds good.

Change 289012 abandoned by Krinkle:
Lazy-load: Remove animations

https://gerrit.wikimedia.org/r/289012

Change 289013 abandoned by Krinkle:
Lazy-load: Remove the placeholder once the image has loaded

https://gerrit.wikimedia.org/r/289013