Readers/Reader Growth/WE3.1.3 Image Browsing

We want to make it easier for new readers to find Wikipedia useful. In order to do this, we want to be more accessible for different kinds of new readers, including visual learners. To do this, we plan on working on one of the Community wishlist focus areas: Improved discovery of media files.

Specifically, we want to experiment with a feature that will make discovery of images and videos easier on Wikipedia. If the experiment proves successful, we will then discuss whether we should build the feature and bring it to the wikis. We plan to run the first of these experiments by October 2025.

Our hypothesis is that if we provide a new way for users to browse through relevant image or video content within article pages, we will see at least a 3% click-through rate among users who are presented with this feature. Owner is Eric, delegate owner is Justin.

Initial ideas and feedback

We wanted to experiment with the following ideas:

1. Adding a new, more prominent entry point to images – making it easier for readers to start exploring images
2. Adding an easy way for readers to go between looking at the image and looking at where the image is in the article
3. Allowing readers to see images for the same article for other wikis

For early feedback on-wiki, we reached out to Arabic, Chinese, English, French, Indonesian, and Vietnamese wikis, where the initial test will take place. We also hosted in-person conversations with early-stage design ideas and demos at Wikimania 2025 in Nairobi and WikiCon North America 2025 in New York City to solicit ideas and responses, as well as online on the English Wikipedia Discord.

Some feedback we've received that we have taken under consideration for includes:

• Suggestion to show Commons images directly on an article
• Suggestion to create a dedicated markup for local editors to determine what images are displayed

Risks associated with this project that we are aware of, thanks to community discussions, include:

• Mixed feelings on showing images from other projects
  • Commons: Some editors liked the idea of pulling more images from Commons, while others felt there was too much risk to showing Commons images without editor oversight. For this test, we have decided to only use images that have been added to at least one Wikipedia.
  • Images from other wikis: Some editors felt that allowing readers to click to see images from other wikis for the same article could pose a risk to editor oversight. For the purposes of gathering information in this test, we are including the ability to view images from other wikis, and will carefully observe and share the results with you for future conversations.
• Risk of showing inappropriate images
  • We’ve set up this first A/B test so that you can exclude page images by adding the tag for exclusion, but we agree there’s still some risk. If we decide to proceed with this idea after the test, we’ll review ways we can expand this list to include further editorial oversight.
• Risk of showing irrelevant images
  • Here, we’ll be using the same classes as MediaViewer. Instructions on how to add these classes are available on this page. Images already excluded from MediaViewer will not appear in the experience.
• Concerns about potential violations of WP:NFCCP and of WP:NFLISTS
  • We agree this is a risk when displaying images from across wikis since not all wikis have the same level of moderation. We’ll be reviewing this piece with our legal team and current policy to make sure everything is aligned.
• Concerns about conflicts with the Manual of Style
  • The guidelines in the Manual of Style for images focus on how images are presented within article content. Since this experience is more like a navigation or browsing experience outside the main content space, similar to how images appear in Media Viewer, we’re not sure how or whether to apply the MOS here, so let’s keep talking about that.
• Concerns about VoiceOver accessibility for iOS, which is being investigated in Phabricator T408831

Experiment timeline

Phase 0 (July – August 2025): Identify problem

Steps:

• Collect qualitative and quantitative feedback from readers and communities through user research, metrics, and external trends.

• Apply data to identify the problem we need to solve.

Problem we identified:

• New and existing readers are not returning to Wikipedia as often as we would like, and pageviews to our projects are declining.
• Readers desire more images and photos on Wikipedia, as demonstrated in surveys of global internet users, and they want to experience those images in a more enriching way.

Phase 1 (July – November 2025): Experiment with feature idea

Steps:

1. Brainstorm a new browsing feature with communities and build a design based on conversations
2. Design simple on-wiki experiment for feature on mobile
3. Run experiment for 2–4 weeks
4. Turn feature off
5. Analyze data
6. Report back on results and propose next steps

Questions this phase will answer:

1. Is this feature useful to readers?
2. Does it help readers see more images in each session?
3. Does it help readers come back more frequently to Wikipedia?
4. Should we build this feature?

Hypothesis evaluation: Was the hypothesis correct?

• • ✅ If yes → continue
  • ❌ If no → stop the project and document what we learned

Here's an example screenshot of the mobile experience selected readers participating in the experiment on Arabic, Chinese, English, French, Indonesian, and Vietnamese wikis will see.

Phase 2 (November 2025 - January 2026, if experiment is successful): Build feature

Steps:

1. Discuss building the feature for mobile and desktop and identify what needs to be changed/added
2. Design and implement any changes required
3. Discuss how to bring the feature to users with communities
4. Bring feature to wikis and measure impact

Questions this phase will answer:

1. Did the feature perform as well in reality as it did in the experiment?
2. Does the feature make sense on both mobile and desktop?
3. What are the changes or customizations necessary to build?

Launch evaluation: did the feature behave as expected in production?

• • ✅ If yes → continue
  • ❌ If no → stop the project and document what we learned

Background

We want to make it easier for new readers to find Wikipedia useful

Wikimedia’s mission is to make knowledge available to every human requires ongoing work to reach new readers from many places and contexts, while making sure our readership reflects the diversity of the world and can become tomorrow’s editors and donors who will sustain the projects over time.

Within this context, we want to experiment with work that makes it easier for a wider variety of new readers to find Wikipedia useful to learn from and return frequently to learn more.

Many new readers are visual learners

The way people learn online has changed in recent years. New generations learn from and use the internet in ways different from how they have traditionally used Wikipedia. More specifically, accessibility of content for visual learners, or learners who are drawn to and find visual content as an important aid in order to learn, has been improved across many platforms.

Where before, visual learners would still need to interact with mostly textual content, now they have the opportunity to balance text with images and other multimedia experiences. This is really good overall since it’s helping more people access more knowledge.

Visual learners have difficulty with the current site

Right now, the site is difficult for visual learners to learn from. Our Reading Wikipedia research, performed on readers in English, French, and Kiswahili, showed that the vast majority of readers skim through articles and require a quick overview of the content before diving more in depth. Many of them highlighted images as a way to discover and preview the content.

Others directly state lack of visual content as an issue, especially on medium and small-sized wikis. These readers stated that a gallery containing images related to the article was within their top 5 requests for new features for Wikipedia

Community wishlist: Media files are not easily discoverable in on-wiki experiences.

Communities have also raised this issue. One of the focus areas within the Community Wishlist also requests for an improved image and media experience, specifically the improved discovery of media files. Currently, Wikipedia has a lot of visual knowledge available in articles, across wikis, as well as on Wikidata and Wikimedia commons. Yet these images are difficult to discover - whether because they are available too far down the page, or because they’re available on wikis other than the one people are currently on.

In their vote, one wishlist participant framed the problem as:

There's lots of useful media on Commons but it's not found by people searching the Web or reading Wikipedia (WP). They are also not found by Wikipedians – many WP articles are without illustrations even when there are high-quality images & videos on Commons. Media can make WP more interesting and help explain/visualize the subject.

Experimenting with image discovery

We want to experiment with image discovery, focusing on the following:

1. Make it easier for visual learners to browse images that are community uploaded and chosen by editors as relevant to specific topics
2. Make it easier for visual learners to discover images from beyond the wiki or language they most frequently visit

We would like to perform a couple of different experiments with features and ideas related to this space and use the results to make a proposal for a feature we can bring across wikis.

Metrics

We have the following two goals:

1. Make it easier for readers to browse the content through images.
   1. We will measure this by looking at how frequently readers interact with the feature.
   2. Target metric: click-through rate is 3% or more.
2. Improve the discovery of images overall.
   1. We measure this by looking at whether there's an increase in the number of images readers view.
   2. Target metric: significant increase in number of images viewed per page.

Design

Research

Design research and observations

tl;dr

• Images on wiki don't work the same way images work on other, more visual platforms. They work with textual content to help readers traverse the knowledge network and seek the information they need—more like textbook illustrations than visual content on Instagram or TikTok.
• There are several obvious usability and UX improvements we could make to multimedia viewer.
• Images are an important part of the information-seeking and reading experience on wiki, and we can leverage existing reader mental models and behaviours to improve visual content exploration.
• Unsurprisingly, our reading experiences are extremely text heavy and readers have been telling us that they want better integrated visual content for years.

By the numbers

• Images get clicked a lot. Rama et al. found that 1 in 29 page views result in at least one image being clicked. That's a whole order of magnitude higher than other types of article content like citations, which are also spaced throughout the text.
• Most articles only have a few images. “Out of the 6.2 M articles, 2.7 M (44%) contained at least one image, for a total of 5 M unique images across all English Wikipedia articles. The vast majority of the articles (91%) contain two images or less, while only 1.5% has more than eight images. On average, there are 2.3 images per illustrated article. Around 84% of images are unique to the article where they appear, while 16% of the images appear in more than one article.” Based on this, I've been using 1–10 as a conservative range for the number of images on an article in my design explorations.
• Desktop is more common for viewing images. The CTR on images in Minerva is fully half (2.5%) of Vector (5%), and the authors speculate that a better MMV experience on desktop is partially to blame for this. I suspect this is because of the default collapsed sections in Minerva, as well as the fact that you're likely to see fewer images in any one view of a mobile article compared to desktop.

Images work with textual content and vice-versa. They are symbiotic.

• Images have "information scent" and support information seeking in the article interface. We see this in eyeball-tracking studies of Wikipedia articles where the traditional “F-Pattern” is broken because readers' eyes often jump to the image and infobox first in the reading experience.
• Images do not distract from the text. They support textual information retrieval, i.e. “images can help to attract attention to the information in the textual form.” Images serve a dual role, similar to blue links, in that they are simultaneously content and navigation affordances. They provide strong information scent to aid content exploration and information seeking, but they also link out to other articles, MMV, and Commons. Images make texts more enjoyable to read, and better textual content leads to more image clicks. Images support readers with lower literacy in comprehension.
• Images are indeed "worth 1000 words". For example, CTR on page previews are counter-intuitively lower than on experiences without page previews because the image and small description in the page preview are often enough to satisfy the information need. This is much more efficient than needing to click the link and go to a new tab or window.

Based on all of this, we could hypothesize that better integration of visual content into Wikipedia articles and better integration of textual content into multi-media viewer would both lead to a better reading experience overall.

Further reading

Our team gleaned a lot of this information from A large scale study of reader interactions with images on Wikipedia by Rama et al., and highly recommend starting there if you want to learn more about this.

Engineering research

Browser support policy

We sought to identify and eliminate any bugs impacting current-generation browsers. In the course of that exploration we noticed an issue when testing the image browsing prototype on iOS 12 and checked the browser traffic, and decided to hide the prototype from iOS 14 and below and Android 9 and below. Besides these, the ImageBrowsing prototype supports all Grade A browsers (as defined by MediaWiki's Compatibility policy).

• Bug Bash: The Sequel- 2 Old 2 Browsers

This policy will have minimal traffic impact:

• iOS 14 and below represent about 0.48% of total traffic.
• Android 9 and below represent about 1.18% of total traffic.
• Combined exclusion affects ~1.66% of users.

This policy also mitigates risk:

• Implemented fallback behavior for known browser compatibility issues.
• Unresolved CORS issues in iOS 12 (and potentially other older versions) could cause a poor user experience.
• Limited testing coverage means that additional issues may surface in production for older browsers.
• Engineering effort required to support older browser versions outweighs the minimal user benefit and is out of scope for this prototype.

Image Cropping options

In order to make images appear on the page in various sizes, we need the ability to crop images in a way which centers the focal point of the image on the page. We explored different ways to do this, selected which one we wanted to start experimenting with, and documented our backups in case this approach doesn't work out.

• [SPIKE] Image Browsing: investigate how to enable image cropping / moving effect

Including text alongside images

We thought it would be useful to be able to show more context than just the image in an image view. For example, we wanted to explore whether adding the paragraph the image is from would give more relevant context than just the image below. To explore this, we looked into various ways we could pull relevant text to the image such as the image caption or Wikidata descriptions related to the image.

More details is available in the following tickets:

• SPIKE Image Browsing: Determine what is possible for including text content alongside images
• [SPIKE] Image Browsing: Investigate a keyword-based approach

Identifying relevant images

One of the goals of the project is to make learning through images more accessible. We wanted to explore different opt-in ways to add ways that users could browse through more images than are available on a given article, but that these images are still vetted by communities as being appropriate for that article. We explored adding a link to images from Wikidata, other Wikipedias, and Commons.

• SPIKE Image Browsing: Determine how relevant images get included