[Spike] Image Browsing: size "jump to article" options

Goal: Size and break down the "jump to article" options to inform the product decision. Each option lets a reader move from an image to that image's position in the article, addressing the editor community's "images taken out of context" concern. Options differ by entry point (carousel tap vs. Media Viewer) and by how much they change existing behavior and page real estate.

Assumptions

• Carousel images have captions (whether to add captions is out of scope for this spike).
• Minerva skin, mobile and desktop. No hover; any dismiss/reveal must work on tap.
• The viewer is Media Viewer (MediaWiki's MultimediaViewer extension). Also known as the "detail view" internally, based on a past experiment.
• Estimates assume 1 engineer, and exclude design, code review, and QA. Implementation and instrumentation are broken out into separate tasks.

Requirements

• Implementation: Respects motion preferences (prefers-reduced-motion). When reduce motion is enabled on iOS and Android, fallback to an instant jump (behavior: 'auto') instead of an animated glide.
• QA: Minerva mobile and desktop; accessibility check for keyboard and screen readers; jump behavior on Minerva mobile and desktop; respects motion preferences (prefers-reduced-motion)

Summary

The key risks are regression and page impact, not effort. The Media Viewer option adds an element and does not affect any existing carousel logic. Every carousel option rewires what a tap does, and 1B/1D also pushes article content down, which is specifically one thing the community objected to.

---

Carousel entry (all change carousel tap behavior)

Option 1A — Feature highlight popover

Implementation

• Add new feature highlight and dismissible guidance popover on page load
• Change carousel tap to jump-to-article (keeps reader on the article page)
• Persist new feature highlight "seen" state (cookie/storage)

QA

• Popover is reachable via keyboard and screen reader; popover is dismissible (dismiss works on tap)
• New feature highlight "seen" cookie/storage persistence

Instrumentation

• Popover shown, popover dismissed, and jump event

Total: 1–2 weeks. Caveat: on load, the popover is disruptive; if missed or dismissed, the new tap behavior is unexplained, which leads to user frustration.

Option 1B — Hat note with instructions

Implementation (~1 day)

• Add instructional hat note text
• Change carousel tap to jump

QA — minimal

Instrumentation

• Jump event

Total: ~1 day. Caveat: easily missed; announced to screen reader after the carousel; adds height.

Option 1C — Popover with buttons

Implementation

• Tap opens a popover with two buttons (open viewer and jump to article), replacing the single tap to open the viewer
• Wire both click paths
• Explicit dismiss affordance (refer to open questions)

QA

• Touch dismissal; keyboard trap check; screen reader labels on both buttons

Instrumentation

• jump and open viewer buttons, dismiss popover

Total: ~1-2 weeks. No page push, but multistep to the viewer. No explicit dismiss affordance.

Option 1D — Resized in-carousel preview

Implementation

• Add a conditional enlarged preview component on tap (close button, full caption, open viewer button, jump button). Preserve scroll position and focus within the carousel. Prevent the focus from getting lost when the carousel item swaps.
• Handle carousel reflow/layout shift
• New and changed carousel click interactions
• Assumption: one image can be selected at a time (refer to open questions)

QA

• Layout shift; enlargement on small viewports

Instrumentation

• Track carousel click and all button clicks

Total: 1–2 weeks. Risk: High. Flag: layout shifts and pushes content down (directly counter to community feedback); multistep to the viewer; close semantics unclear - preview shows a close button, but its meaning is ambiguous (refer to open questions). It's the only option that significantly affects the carousel layout (reflow pushes content down, unexpected shift after tap), tap interaction rewrite, and conditionally swaps a carousel item for the preview.

Option 1E — Image preview overlay

Implementation

• Preview overlay on tap (caption, close, "scroll to image" button, "view details" button). Assuming the URL does not update.
• Backdrop: prevent page scroll and article clicks while open
• "scroll to image" closes preview and scrolls; "view details" button closes preview and opens Media Viewer (URL updates)
• Change carousel tap (carousel → preview → viewer)

QA

• Scroll lock; keyboard focus trap; screen reader; backdrop

Instrumentation

• Track carousel click and all button clicks

Total: 1–2 weeks. Overlay doesn't push content or cause layout shifts, but duplicates the viewer by introducing a second full-screen view on mobile. Multistep to the viewer.

---

Detail view entry

Option 2 — Jump from the detail view

Add a link/button in the viewer that closes the viewer and scrolls to the image's position in the article behind a dimmed backdrop. This is similar to what we did in the experimental phase.

Implementation

• Add link/button to the viewer; label and placement per Figma
• Click handler: close the viewer and smooth scroll to the image in the article.
• Dimmed backdrop during scroll via background-color-backdrop-* token; remove backdrop after scroll settles
• Conditional render: only when the image exists in the article body (viewer surfaces more images than the carousel, so avoid dead ends).

QA

• Backdrop dismissal; no stuck overlay
• Images that appear more than once in the article

Instrumentation

• Jump from the detail view event

Total: ~1-2 weeks. Risk: low (purely additive; nothing on the page moves).

---

Recommendation for the product decision

Option 2 (the Media Viewer/detail view entry) is the lowest risk: purely additive, no change to carousel tap behavior, and nothing on the page moves, which is exactly what the editor community objected to.

Among carousel options, 1C and 1E avoid pushing content down but add a multistep path to the viewer and new surfaces/layers to maintain on mobile (an additional full-screen view/overlay to maintain). Option 2 avoids the maintenance/testing burden by reusing the viewer. 1B is the cheapest but has real accessibility and discoverability problems, and 1D conflicts most directly with the community feedback.

Open questions and comments

• In the detail view, should the "jump to article" appear for carousel images only or all viewer-approved images? --> Discussed during refinement on July 14th that the detail view displays the jump to article link only when an image is selected from the carousel, not the article body.
• 1A: Is the popover open on every load or only the first time?
• 1C: Define explicit dismiss affordance. It's unclear how to dismiss the popover. Accessibility check: keyboard and screen reader.
• 1D: Can a user select multiple images to preview inside the carousel?
• 1D: Define the dismiss behavior. The close button is ambiguous. Does the close button minimize the enlarged image back to the carousel size, or something else? Does scrolling/tapping away also collapse the preview?
• 1E: When the image preview is open, does the URL change?

Some quick thoughts about this, since @SherryYang-WMF and I were just chatting about it.

Personally I don't love the UI fragmentation of having multiple different "detail views", but if the goal is to test different things to see what users respond to then this approach seems ok for the short term.

I think it should be fairly straightforward to do the following things:

• a carousel-specific "modal detail view" (per @JScherer-WMF's designs above) can be defined in a new resource module (either in MMV or in ReaderExperiments). You could try to adapt the Codex Dialog component or create something custom; if going the latter route, I'd recommend also using Vue's Teleport API and the #teleport-target div that MW provides (in the same way that Codex dialog does).
• The carousel.js code in MMV (which wires up the carousel-item-specific click handlers) could be updated to trigger this alternate modal detail view, while other thumbnail clicks would open the default (full screen) detail view.
• In regards to URL handling, I would recommend continuing to update the URL to a hash route based on the File name when clicked, just as both desktop and mobile MMV do now. But for this alternate modal detail view I'd also recommend including some additional URL param (?modal=true maybe). That way we could be consistent about showing users who land on the page directly with the URL (rather than clicking in their browser) the experience that they expect. This means that some code in the MMV bootstrap.js file will probably need to check for this param.

In T430688#12117469, @lwatson wrote:

Open questions and comments

• In the detail view, should the "jump to article" appear for carousel images only or all viewer-approved images?

Carousel images only

• 1A: Is the popover open on every load or only the first time?

Only when a reader interacts with the carousel.

• 1C: Define explicit dismiss affordance. It's unclear how to dismiss the popover. Accessibility check: keyboard and screen reader.

The popover won't be the eventual design. Sorry, I threw that design out while you were working on this.

• 1D: Can a user select multiple images to preview inside the carousel?

No.

• 1D: Define the dismiss behavior. The close button is ambiguous. Does the close button minimize the enlarged image back to the carousel size, or something else? Does scrolling/tapping away also collapse the preview?

Closes the lightbox, and the carousel will be available behind it.

• 1E: When the image preview is open, does the URL change?

No.

Here's a quick prototype of this behaviour.