Page MenuHomePhabricator

Build scroll view of image browsing UI
Closed, ResolvedPublic5 Estimated Story Points

Description

Background

We would like to build out the detailed view for the image ToC/scrolled in view of the UI

User story

  • As a visual learner, I want to be able to explore the article content through images

Requirements

  • Image appears in the order which it is presented in the article

[] Text under image shows image caption (note that we will eventually want to include additional content here) (see T404385 for this)

  • Button to view in article appears. Selecting the button
  • closes the view
  • scrolls user to the image location in the article

BDD

  • For QA engineer to fill out

Test Steps

  • For QA engineer to fill out

Design

https://www.figma.com/design/YH68yubI663iFLZfuhtOE6/FY-25-6-WE-3.2?node-id=392-2553&p=f&t=9dmSXZ7MONu8rUt8-0

Acceptance criteria

  • Build scroll view for a the article. View does not need to have:
    • scrolling/swapping behavior
    • images in this view do not need to be tappable to see more

Communication criteria - does this need an announcement or discussion?

  • Add communication criteria

Rollback plan

  • What is the rollback plan in production for this task if something goes wrong?

Event Timeline

Change #1178959 had a related patch set uploaded (by Bvibber; author: Bvibber):

[mediawiki/extensions/ReaderExperiments@master] [WIP] Visual ToC partial implementation

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

@JScherer-WMF can you explain your thinking behind the masonry-style layout for the Visual TOC items in the Desktop wireframe mockup? Is the idea that images are stacked vertically in the first column and then flow into the second column after a certain point? Or are the images distributed in rows (so image 1 and 2 side by side, then 3 and 4 side by side, etc)? What determines the height of a cell in this case? If you don't have a super strict set of rules and would prefer we just approximate your wireframes with something that seems logical, we can do that too.

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://e7f7b59049.catalyst.wmcloud.org/w/

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://e7f7b59049.catalyst.wmcloud.org/w/

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://173df9ced5.catalyst.wmcloud.org/w/

Change #1178959 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Visual ToC initial implementation

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

Change #1181772 had a related patch set uploaded (by Bvibber; author: Bvibber):

[mediawiki/extensions/ReaderExperiments@master] Use codex variables for some colors in Overlay, VTOC

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

Change #1181772 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Use codex variables for some colors in Overlay, VTOC

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

Looks good! One piece I'm not seeing is the caption appearing. Seeing the file name instead:

Screenshot 2025-08-28 at 12.00.04.png (938×760 px, 812 KB)

@ovasileva - The reason you're seeing the file name is that the image doesn't have a figcaption or alt text. There are fallback options for caption text in this order:

  1. figcaption
  2. alt text
  3. file name

There's also a discussion in Slack about these fallback options and nearby paragraph text. I'll open a discussion in T402223: Image Browsing: Implement basic "Visual Table of Contents" UI using nearest paragraph to capture decisions.

Hm, something broke somewhere along the line in the event hookup back to update the carousel. Lemme take a look at that...

Change #1182954 had a related patch set uploaded (by Bvibber; author: Bvibber):

[mediawiki/extensions/ReaderExperiments@master] Fix for resizedSrc when changing activeImage

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

Change #1182955 had a related patch set uploaded (by Bvibber; author: Bvibber):

[mediawiki/extensions/ReaderExperiments@master] WIP trying to fix scroll-to-top from VTOC selection

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

Change #1182954 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Fix for resizedSrc when changing activeImage

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

Change #1182955 merged by jenkins-bot:

[mediawiki/extensions/ReaderExperiments@master] Fix scroll-to-top on VTOC selection

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

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://173df9ced5.catalyst.wmcloud.org/w/

Hey @ovasileva – want to look this over for the sake of product sign-off? I don't think we need dedicated QA here, I can confirm that all basic functionality is working properly.

Here is a patchdemo instance where this feature can be reviewed: https://patchdemo.wmcloud.org/wikis/7b60cdc924/wiki/Berlin

You should be able to see the following:

  • Images in the VTOC have text associated with them
  • Clicking an image in the VTOC scrolls the user back to the top and updates the image (after a slight loading delay, which we will design a state for in T402973)
  • Clicking "view in article" buttons in the VTOC scrolls the user back down to the relevant part of the article and closes the overlay

Please take a look and let me know if anything seems missing or off about the current experience.

  • Image appears in the order which it is presented in the article
  • Text under image shows image caption (note that we will eventually want to include additional content here)
  • Button to view in article appears. Selecting the button

closes the view

  • Scrolls user to the image location in the article

Right now, the text appearing under the image is not the article caption, but the first paragraph for some images

Screenshot 2025-09-10 at 10.30.55.png (1×2 px, 1 MB)

My understanding is that T402223 covers the specific question of what text to show next to each image in the VTOC (particularly when we lack good alt text/captions), and that this task covers everything else in terms of this part of the UI (visual design, view in article behavior, etc).

Another potential issue is that we are showing the paragraph in the detail view as well, which I think needs to be always the caption, independent of our decision on what to do in the visual ToC view. @JScherer-WMF - could you confirm?

Another potential issue is that we are showing the paragraph in the detail view as well, which I think needs to be always the caption, independent of our decision on what to do in the visual ToC view. @JScherer-WMF - could you confirm?

Yeah, this is something that Olga and I discussed in a 1:1 a couple weeks ago that didn't get communicated out properly. Apologies for that.
Here's my thinking here:

There are basically three different information hierarchies here:

  1. images accompany text (article view)
  2. text accompanies images (vtoc)
  3. text describes images (captions)

The issue with using the paragraph as the sole text in the detail view is that the paragraph alone often doesn't describe the image adequately. If the image is in the detail view, you want text that describes images (number 3 above), and only the caption does that adequately. What we're trying to test is whether that 2nd text/image relationship is effective for readers' information needs.

So there are two options in cases when we have both a paragraph and a caption:

  1. we only show caption in the detail view, only show paragraph in the vtoc.
    • the inconsistency makes me a bit itchy here.
  2. We concatenate them in both the detail view and the vtoc when they're both available.
    • this makes them consistent, and adds more information.
    • this would be increased scope, though, I assume.

<caption> | <paragraph>

e.g.

Screenshot 2025-09-10 at 12.27.13 PM.png (1×944 px, 1 MB)

Paragraph is underlined for emphasis to differentiate them.

We probably need different design treatments for captions and paragraph text, which I'll look at for the next revision of the feature.

Ideally the thing we're trying to test in the vtoc is whether or not adjacent paragraph text assists information seeking and retrieval or not. Ultimately, I think we should go with the treatment that gives us the best signal for this. In this case, clicking "more" in the detail view gives us this signal, as does engagement with the vtoc in general. @ovasileva what do you think?

The new image/text requirements are captured here: T404385.

I think this task can be signed-off as is now.