Add next and previous buttons to image content in a series

[philmcmahon]

What does this change?

Modifies the lightbox for image content to add next and previous buttons.

This is achieved via the next/previous functionality added to the content api. When someone opens the light box, if the content is of image type and there's only one image available then a request is made for the next/previous 100 images in the same series.

I wrote all the javascript so there's probably a lot wrong with it...

Screenshots

Here's a video showing the network requests on an example with https://www.theguardian.com/commentisfree/picture/2022/may/22/brian-adcock-on-the-looming-sue-gray-report-cartoon :

Screen.Recording.2022-06-08.at.14.32.18.mov

What is the value of this and can you measure success?

We've got tracking on the attention time of images, we also know when people have opened a lightbox, so something like 'difference between attention time for people who open the lightbox before and after this change'

Tested

• Locally
• On CODE (optional)

[PRBuilds]

PRbuilds results:

Screenshots
wide.png • desktop.png • tablet.png • mobile.png

💚 Exceptions
thrown-exceptions.js

💚 A11y validation
a11y-report.txt

💚 Microdata Validation
microdata.txt

Apache Benchmark Load Testing
loadtesting.txt

LightHouse Reporting
lighthouse.html

--automated message

[paperboyo]

💎× 💎

I hope it’s just a beginning, a beginning of a Neverending Story. Because whenever we present readers with any kind of ending, we are asking them to leave. And they do. This is wrong.

This has been 6 years in the thinking. @philmcmahon is wholly credited with actually making this happen, @mchv for the other crucial piece. @regiskuckaertz for another (how to increase the limit not to 200, but, simply, to all?). Thank you all, but Phil – twice!

Now, for something incredibly pathetic, but I want to mention some (not all!) the people I bored with this over the years (to the point that most of them aren’t here any more): @gklopper (“it’s Latin civilisation: all textual content is one vertical scroll from top to bottom, all multimedia – left-to-right”), @theefer, @phamann, @rich-nguyen @jamesgorrie, @mattosborn, @akash1810, @currysoup, @blishen, @hoyla. Terribly, terribly sorry for the spam, I am just a little happy right now.

Current, initial, implementation (test here) should not be controversial. Nor are there any UX/UI dilemmas to solve (just yet). Apart from where one lands on Lightbox close (we opted for the easier answer here).

Next are all galleries, next – videos, next – content beyond series, next – starting with any in-article image, next – landing on something unexpected but related, next – making informed turns in a journey, next – a browser for this here viewer, next – all textual content, next, next, next, next…

What is the value of this and can you measure success?

Don’t care much for using numbers as justification for stuff that’s obvious. But this approach should prolong session time (a tiny bit). If we cannot turn that into advantage, let’s close shop.

[SiAdcock]

Could this ever be null or undefined? Might be worth specifying a default of '' (empty string), as the second parameter to this function call.

[SiAdcock]

We could destructure the arguments of this callback:

.then(({ next, previous }) => {
  const allImages = previous
  // ...
})

[SiAdcock]

We could destructure this result array

.then(([nextResult, previousResult]) => ({
  next: nextResult.map(e => e.images[0])
  // ...
})

[SiAdcock]

Naive question time 😊

Will this happen every time the lightbox is opened? Is there a mechanism to prevent us from loading next and previous images that have already been loaded?

Perhaps it would be better to move some of this logic into the FSM.

[philmcmahon]

The galleryJson.images.length < 2 will prevent this from running if the images have already been loaded, but maybe more stuff could be done in the FSM hmm I'll take a look

[mchv]

@philmcmahon one think which I think may be broken, or work differently, is attention time. Ophan & Datalake expect attention time to be bound to a Content API id and therefore to a page. When loading asynchronously another piece of content into an existing page, attention time will increase for the initial page, unless, I think, you update orphan tracker to handle this case properly.

[paperboyo]

attention time

How does the tracker (dis)count idle time? Scrolling? Will a stationary mouse pointer mindlessly clicking one button count as spent attention? How about just swiping?

[mchv]

@paperboyo we use the strategy from upworthy, see code, which is quite similar to parse.ly one and AMP engagement measurement.

[katebee]

Is it worth typing this to avoid using Object?

We have the GalleryJson type that is used in this file, hopefully this overlaps with the structure of the newGalleryJson? 😁😁

type GalleryJson = {
    id: string,
    headline: string,
    shouldHideAdverts: boolean,
    standfirst: string,
    images: Array<ImageJson>,
};

[SiAdcock]

@mchv

When loading asynchronously another piece of content into an existing page, attention time will increase for the initial page, unless, I think, you update orphan tracker to handle this case properly.

A similar question cropped up when we were discussing using the YouTube end slate to handle onward journeys from videos instead of our own end slate. Clicking the YouTube end slate would keep the user on the same page but show a new video in place, increasing the attention time for the page, but effectively as a result of the user watching a different piece of content.

From Stuart Mutter:

I'm imagining these will be edge cases and we tend to report on median attention time which is less affected by massive outliers.
if we start noticing large increases in attention time though we will definitely investigate further (looking at multiple videos first!)

Perhaps users scrolling through images would be considered outliers in the same vain?

[philmcmahon]

@SiAdcock I think I've sorted things out as we discussed, when you get a chance let me know what you think! Essentially fetchSurroundingJson has become just a function that returns a promise, which is called by init before loading the lightbox.

[SiAdcock]

This looks much clearer, thanks for the refactor!

[prout-bot]

Seen on PROD (merged by @philmcmahon 16 minutes and 49 seconds ago)

• Check your changes on www.theguardian.com ✔️
• Keep an eye on the deploy dashboard 📉

[paperboyo]

OMG! Thank you!

Just because I couldn’t help with code, I spent last couple of weeks upgrading image resolution on an abandoned series of best daily photographs. Some beautiful, some funny, some terrifying shots there good for testing this feature!

Currently, to see the whole series (go beyond a limit of 50), easiest is to Google the caption of the last photo to pick up the stream further in.