As a readerWe want to test **mobile page previews** — a bottom sheet that appears when a reader taps a blue link, showing a thumbnail, lead paragraph, and an option to open the article — on mobile web article pages. This is an experiment: we will deliver it to a subset of readers via an A/B test, collect usage data for approximately one month, and then turn the experiment off. If results are encouraging, a follow-up project may scale the feature to production.
=== Design Mockups
Designer: @JScherer-WMF
{F72429153}
=== Background
Page Previews (Popups) has been a successful desktop feature for years, showing a tooltip-style preview with a thumbnail and lead paragraph when the reader hovers over a link. The feature is deployed on all Wikipedias and is enabled by default for anonymous users and new accounts. Mobile web has no equivalent — tapping a link navigates immediately.
The mobile apps have their own page preview implementations and have seen positive feedback (see slides). This experiment brings a similar experience to mobile web, using a bottom sheet pattern appropriate for touch interaction rather than the desktop hover-triggered tooltip.
=== Approach
==== User flow
# Reader is viewing an article on mobile web
# Reader taps a blue link in the article body
# Instead of navigating immediately, a bottom sheet slides up showing:
#* Page image (thumbnail) where available?
#* Article title
#* Article summary, I want to be able to see a page preview when I tap on a blue link in an article so that I can find information at a glance faster.
- Mobile apps have seen [[ https://docs.google.com/presentation/d/1FBeoZy_b7-dsr8XLY2xTiA1Y72SloHH_515eiVMFMi4/edit?slide=id.g36b13bc333c_0_0#slide=id.g36b13bc333c_0_0 | positive feedback ]] on their page previews feature.truncated if needed
#* "Open article" button to navigate to the full article
# Reader can dismiss by tapping the X button or tapping outside the sheet
==== Technical components
- New module in ReaderExperiments extension, with lazy-loading to avoid payload cost for readers who don't interact with links
- If it helps to re-use elements of the Vector experience- Link tap interception on mobile article pages — prevent default navigation for qualifying links and show the preview instead
- Bottom sheet UI component (built locally in ReaderExperiments, or potentially upstream in Codex)
- Lightweight client for the REST Summary API (`/api/rest_v1/page/summary/{title}`) — same data source as desktop Popups, but independent code with no dependency on the Popups extension
- Experiment instrumentation (funnel: link tap → preview shown → article opened from preview → preview dismissed)
==== Link filtering
Not all links should trigger previews. At minimum:
- Only links in article body text (exclude navboxes, infoboxes, hatnotes, see-also sections, etc.)
- Only links to article namespace (exclude talk pages, categories, special pages, let's consider that rather than re-inventing the wheeletc.)
- Only blue links (exclude red links to non-existent articles)
The exact filtering rules should be determined during development and may warrant a subtask.
**Flow** (see also examples in [[ https://wikimedia.slack.com/archives/C06UBL7NBFT/p1770923534377329?thread_ts=1770917864.396199&cid=C06UBL7NBFT | Slack thread ]]=== Experiment Design
Type: A/B test via the Test Kitchen framework within the ReaderExperiments extension
Duration: ~1 month of data collection
Target wikis: TBD — likely the standard pilot set (ar, zh, fr, id, vi, en Wikipedias)
Navigate to an articleAudience: Logged-out mobile readers (specifics TBD)
Tap on a blue linkControl: Current experience (tapping a link navigates immediately)
See bottomsheet with (1) image; (2) lead para, truncated if needed; (3) options to open article in full or [nice to have] open it in a new tabTreatment: Bottom sheet preview on link tap
==== Success Metrics
TBD
**Work needed**=== Open Questions
- Which links should trigger previews? See "Link filtering" above — needs a concrete decision.
- Bottom sheet component: build from scratch in ReaderExperiments, or propose upstream in Codex? If Codex, what's the timeline impact?
- Set up a new module in ReaderExperiments;- How should the preview handle missing data? (Articles without a page image, very short lead paragraphs, consider an approach to support lazy-loading the full UIetc.)
- Handle link clicks in mobile article pages- What is the fallback if the API request fails or is slow? Loading state, timeout behavior? Or just go straight to the linked page?
- Create a bottom sheet component (locally or upstream in Codex)- What existing link tap behaviors on mobile article pages could be affected by intercepting link clicks? Known cases include: reference/footnote drawers (MobileFrontend), image viewer (MMV), edit section links, hash/anchor navigation, and external links. The link tap interception logic must carefully exclude all of these.
=== Links
- [[ https://docs.google.com/presentation/d/1FBeoZy_b7-dsr8XLY2xTiA1Y72SloHH_515eiVMFMi4/edit?slide=id.g36b13bc333c_0_0#slide=id.g36b13bc333c_0_0 | Mobile app page previews feedback ]]
- Fetch the p- Page pPreview information from the appropriate APIss (desktop): https://www.mediawiki.org/wiki/Page_Previews
- REST Summary API: https://en.wikipedia.org/wiki/Special:RestSandbox/wmf-restbase#/Page%20content/get_page_summary__title_