Talk:Readers/Reader Growth/Image Browsing

From mediawiki.org

Hello, we currently don’t add much images in the articles because we lack a tool to do it in a proper way for both desktop and mobile users. If we need a lot of images to explain properly a section of the article (for example a descriptive part about the architecture of the building) the only tool we have is the gallery component. While it’s ok (but not especially awesome) on computer, it’s terrible for mobile users, because they’ll have all the images to scroll down before reaching the next section and being able to continue to read (or worse, if they want to alternate between the text and images to have the visual explanation, they’ve constantly to significantly scroll up and down).

To correct this, we don’t need fancy stuff, we just need the gallery component to have a mode for horizontal scrolling that works on both desktop and mobile. I think that before going on more complicated features, a good first step would be to give this to us and then measure how it improves the numbers of images in articles (personally I thin such a feature would make me use between two and four time more images in articles).

Then you could build more feature on it later if you want, but at least we would have something usable quickly and without many struggles in communities. Indeed, you have to be aware that all features displaying non in-wiki curated images are likely to be met with hostility from a large number of editors, who prefer to keep control on what’s shown on their articles. Runi Gerardsen (talk) 18:54, 7 October 2025 (UTC) Reply

Hi @Runi Gerardsen thanks for the note and apologies for the late response. This is a really interesting idea. It's a little outside the scope of this team's work as this team doesn't focus on editor-facing functionalities, but it could be a good fit for the Editing team, so we've passed along the feedback to them. EBlackorby-WMF (talk) 19:24, 4 November 2025 (UTC) Reply

I would support something like this as well. I often have a lot of interesting photos for a specific section, but can only use one to the right or left of the text. It would be nice it that could become a slideshow (not automatically changing the photos, but viewers have to click on it). Dajasj (talk) 05:10, 25 June 2026 (UTC) Reply

Hello and thanks for asking feedback for this project. Knowing a little bit the content of Commons and the illustrations used for Wikipedia articles, I appreciate your project a lot, but I fear Wikipedia and especially Commons, are not good at being coupled to form a easier track to visit Wikipedia. Your goal is to increase the number of readers on Wikipedia by proposing an interwiki gallery, the images of all interwikis available on one language article.

One aspect important aspect of the images on Wikipedia is that they need a caption to be understood, so the linguistic aspect remains at the foreground. An image with no caption or a caption in another language may not be so useful for a reader. My favorite example for captions and different or similar images on an article in the different interwikis is Ancient History (Antiquité in french), where you have a lot of good pictures for the same subject, sometimes similar, sometimes not the same, who knows why. Illustration on Wikipedia is often an haphazard work and paragraphs are written on the fly, so it's probably to messy and showing a deep lack of structure that will not allow to relate correctly images and texts. Don't loose time to do these connections, but I'm sure the way you propose to display images on a vertical scroll is a very good idea for mobiles.

What I suggest : propose galleries with related subjects to the reader, means, each picture links to a different article but in the same topic. This is more useful than exploiting just the resources of one article in several languages. This means, you could only ameliorate the MediaViewer which is a significative enhancement in images display on Wikipedia. The problem is : who knows that MediaViewer exists and that just double clicking on a picture opens it ? This is more like a hidden feature than a popular one. So if you could just add something (like an advice or a button) that could lead more people to open the Viewer, this would just be a first step to open Aladdin's cave of Commons. There, you can extend the features of the Viewer and allow the display of pictures from other articles (with a system of tagging or related articles) and test if this changes the way people read and click etc...

Just one warning : NEVER use Wikimedia Commons as such, as this a media base with a lot of porn stuff, so this could become very, very, problematic. Only use verified pictures, sorry to insist. One feature you can also test is adding high value pictures like these coming from contests on different thematics (Image of the year, Folklore, etc..). This is just for the fun, and below each pictures and after each display of series of pictures, you can propose a link to the corresponding and related articles. This could be interesting to be tested, does need less resources and is more safe and good looking for the public. Waltercolor (talk) 12:59, 22 October 2025 (UTC) Reply

Hi @Waltercolor, thank you so much for your thorough feedback on this topic. You raised many good points, here's some thoughts from our side on some of them:

• We hear your concerns around captions and languages, and more generally about images needing context. This is one of the reasons we’ve built the feature so that it displays the relevant paragraph next to each image. Regarding captions from other languages though, we’ve discussed this internally and right now, without translations, providing a fully relevant caption is difficult. What we can do is indicate the source wiki for each image, so interested readers can follow the link to get context. We’re also exploring the idea of a user-driven option, such as a button that says "Yes, I want to see images from other wikis", to give readers more control on whether or not they want to see these types of images.
• As for next steps, we’re planning to launch some small-scale tests for the idea to test some of these questions, including the question of whether the inconsistency between wikis is affecting whether readers interact or understand these images. For the first piece - do people use it, we'll know more from the short A/B test we're planning to run on a few Wikipedias. For the second piece - is the inconsistency bothering readers - we're currently doing some qualitative interviews with readers to see if they understand this piece. We can review what their feedback is with this specific question in mind.
• I completely agree with your caution about Commons. Right now, we’re only considering images that editors have directly placed on Wikipedia and avoiding showing anything directly from Commons without that check.
• I really like your idea of showing related images across connected topics or categories and also of highlighting high-quality media from curated sets - while we're focusing on articles right now, we've been playing around with how to explore images more generally and exploring across topics/topic areas is something that’s come up frequently (something like starting exploration with a single article but being able to easily discover more about the wider topic) - I'll bring this to the team to discuss more!

Thanks again for all your thoughts here - curious of what you think of the notes above! OVasileva (WMF) (talk) 16:26, 4 November 2025 (UTC) Reply

How do we reconcile this with Principle of least astonishment, where we intentionally try to keep certain images below the initial page fold ? —TheDJ (Not WMF) (talk • contribs) 09:52, 27 October 2025 (UTC) Reply

Hi @TheDJ! This is a good question we don't quite have a full answer to just yet. Overall - yes - this is something we’ve discussed and which has come up in some of our early testing of this feature with editors, but don’t have a 100% clear solution on just yet. In general, there’s a few things that we think can work as safeguards we've built in so far, but we’re also open to other ideas if we decide to move forward with this. First - the carousel at the top of the page shows the first three images of an article at most on pageload. While this doesn’t necessarily guarantee that we won’t display images buried a little bit further, it will lean towards more prominent images on the majority of longer articles that tend to have more images. The second piece is moderation - here, so far we’ve implemented the same logic as MediaViewer - if an image is marked up to not appear there, it will not appear here as well. That said, we’re open to other suggestions or ideas on either of these pieces! OVasileva (WMF) (talk) 16:30, 4 November 2025 (UTC) Reply

One could 1) exclude certain images, particularly NSFW images via excluding files in certain categories and structured data depicts 2) first load the images not in the article but in other language versions and maybe also those within the article which would mean those are appropriate so one would have to first scroll and load more to see any potentially unexpected ones 3) one could allow editors to exclude specific selected images easily. Prototyperspective (talk) 23:36, 2 March 2026 (UTC) Reply

Thanks for those suggestions, @Prototyperspective! For (1), yes, we are using attributes like class=notpageimage to identify these. For (2), we will not have images from other wikis in the next phase of Image Browsing since we did not see readers engaging with that part of the feature, but we are still interested in trying it out different versions of it in future and will keep this suggestion in mind. For (3), in addition to the existing image exclusions as mentioned above, we are also planning to build in an option for editors to exclude specific articles from the Image Browsing carousel as warranted. Since we are relying on existing image exclusion attributes, I would love to know if you see any gaps in the current options and we can look out for other solutions to those! SherryYang-WMF (talk) 18:28, 27 March 2026 (UTC) Reply

Thanks for the info. Re 1) didn't understand this part (don't need to understand it though and the experiment seems early-stage anyway): so is the notpageimage class set if the file has a category or SD indicating NSFW set? Re 2) interesting but I would think that this is specific to the few largest Wikipedias with many well-selected images (en, de, fr, es, ru, etc) – I think these images would be most useful if the article does not have images or not the best since its images were added. I wonder how you assessed whether readers were engaging with these though – if they're shown first it seems like it would be 'engaged' with by just looking at these without any further action...maybe if engagement is measures as scrolling to see the next set of images that may even mean that the first set of images was not good so the user had to scroll what they wanted to see where not scrolling is an indicator for good quality. Re 3) good idea! That way one could also exclude articles where the associated files on Commons aren't really useful. Prototyperspective (talk) 19:03, 27 March 2026 (UTC) Reply

I am rather concerned that every single wish in the focus area is about Wikimedia Commons, but because the focus area was vaguely titled "Improved discovery of media files" this project is about Wikipedia, excluding Commons. Commander Keane (talk) 05:36, 26 November 2025 (UTC) Reply

@Commander Keane I just want to share that Community_Wishlist/W167, Community_Wishlist/W303, Community_Wishlist/W369, all part of that bucket, have all already seen major improvements. They have simply not officially been closed yet, but the problems they identified have all already been mostly solved. —TheDJ (Not WMF) (talk • contribs) 10:44, 26 November 2025 (UTC) Reply

Who is not a visual learner? I feel somewhat confused by the background section. People who can see are visual learners. It's written in a way that seems to imply otherwise, so I assume it means something that has gone over my head. Regardless: good luck with your testing! Rjjiii (talk) 03:03, 24 February 2026 (UTC) Reply

I think it means those who gain relatively much from also having visual contents. This can be because then the content is more interesting/suspenseful to read and thereby more easily to read and remember or because the image enables better imagination or because the also included image allows better remembering or especially when it comes to diagrams it means things can be explained better while others (would) do just well with only text. Things like that I think. Prototyperspective (talk) 23:38, 2 March 2026 (UTC) Reply

Hi @Rjjiii, sorry to be a bit getting back to you here. It's a fair point! Most people are indeed visual learners. In the background section we used that term as something of a catchall to describe both learning styles and preferences; basically, we wanted to reflect that our research shows that users increasingly want and expect a more image-forward experience, that adds visual components to text-heavy content. In particular, we think that visual learners gain more from text when they have visual elements to accompany it. Does that help illuminate a bit of our thinking? Happy to chat more about it too. EBlackorby-WMF (talk) 16:22, 26 March 2026 (UTC) Reply

our research shows that users increasingly want and expect a more image-forward experience, that adds visual components to text-heavy content. In particular, we think that visual learners gain more from text when they have visual elements to accompany it Interesting. This is one of the reasons for why I think occasionally – if of good quality, not inaccurate and useful – an illustration made using novel AI-based production methods can be good to have in an article, e.g. to visualize a fantasy genre or some article about a fictional object or scifi concept just to give a few examples. I generally tend to ascribe large importance to what readers actually want and what is useful to them in practice (albeit I don't like use of Fair use non-free files when free alternatives exist). Is there more public research than the study linked on the page and if so could you link it please? Interested in the general topic and recently created c:Category:Images on Wikipedia with interesting statistics, mock-ups etc on the subject and c:Category:Media gaps including ideas how to add images where they would be really useful at scale (here is another such idea where such data would be relevant). Prototyperspective (talk) 17:05, 26 March 2026 (UTC) Reply

One interesting paper I find myself revisiting: https://dl.acm.org/doi/fullHtml/10.1145/3544549.3585900

It covers a few types of multimedia, not just images, but I think is particularly useful for considering what newer readers might want/need. SherryYang-WMF (talk) 18:52, 27 March 2026 (UTC) Reply

@EBlackorby-WMF It's all good. That does offer more insight. I'll elaborate a bit on my thoughts. There is a pop psychology idea, still popular in education, that people can benefit from material matched to their preferred learning style. Some studies supported this in the late 70s (Walter Burke Barbe, and so on), but more recent research shows that the supposed evidence didn't account for other factors, most significantly:

• the impact of individual instruction,
• and the benefits of learning material in multiple formats.

Once those two factors were accounted for, there aren't really benefits from teaching in someone's preferred learning style outside of self-motivation. So if the goal of the project is to match "visual learners" to a visual mode of learning, psychology would suggest no real benefit. If the goal is to leverage those other effects (which I suspect is likely why the idea remains popular with educators), and to give all learners multiple ways to engage with content, then psychology would suggest a potential benefit in comprehension and retention. Rjjiii (talk) 19:40, 27 March 2026 (UTC) Reply

It's a spectrum.

I care more about text, but some people care much more about images. That's fine, and it's okay to call them "visual learners" and to try to address their needs.

The problem is that I'm really not sure that the current solution actually addresses their needs. The current solution, as of June 2026, just shows a bunch of essentially random images, without captions and without relation to the text, at the top of the article. This is wrong, it goes squarely against the editors' intention, and I have strong reasons to think that they don't actually help visual learners. Amir E. Aharoni {{🌎🌍🌏}} 13:03, 24 June 2026 (UTC) Reply

This proposal would be infinitely improved if you removed the nonsense about visual learners. It is really embarrassing to read that stuff on an educational project. Also the idea that young people today learn differently or in fact want a different experience of Wikipedia than anyone else. Most pseudo claims about differences between groups turn out to be a mirage when properly analysed, such as many claims that have been made over the years about how women and men's brains might work. More images and better control of image/text layout is something I've wanted for years but introducing it as some bright idea to satisfy soft young brains who can't handle a page of text is insulting and ridiculous. You know, photojournalism, with weekly picture news magazines like Life and Picture Post, thrived in your great-grand parents generation. Wanting images to dominate what we read is very much normal and always has been. -- Colin (talk) 07:31, 5 June 2026 (UTC) Reply

From my comments here; just so it doesn't get lost and can also be found from here

• Showing also media not featured in the article from the Commons category linked to the article. There often are large amounts of very interesting and/or insightful media there (statistics, high-quality photos, etc) but very few people ever know of and go to the Category page to find these (often also requires looking over the subcategories and navigating further). I think this would be the main usefulness of Image Browsing – the few files in the article can already be glanced over and readers mostly want more images, not just having them in a modern format/UI at top.
• Contributors could be enabled to add or remove files from the carousel. (related)
• Regarding which files are included or shown first one could for example use the ones set on the Wikidata item (eg on image (P18) and schematic (P5555)), then those featured other language Wikipedia article versions, then those in the category (and it's of critical importance the Commons category is used) sorted by number of mainspace Wikipedia uses, then those in it recognized as 'Quality image'/'Featured picture', then etc. (related) -> smart surfacing of the likely best-quality / most-useful/interesting files.
• Things could work differently for articles where the Commons categories is very large and broad (like 'Art' or 'Society') compared to those that are relatively or very small (like 'c:Category:Copper(II) sulfate or 'c:Category:Whitchurch Silk Mill'). For example, in large cats, there would probably enough files in the FP & Quality images subcats and these are also the topics for which one could pull many files from other language versions.
• When showing the panel at the top, it could be collapsed by default (after some period during which users learn about this and get familiar with it). It could also be shown at the bottom uncollapsed.
• There could be a button to load more from the category and/or to go to the category page. This could be similar to MediaSearch where it loads some additional files when scrolling via lazy loading and then needs a button click to load more.
• For an example of good-quality interesting media files as well as how MediaSearch displays them (the same could be used but in a horizontal panel), see e.g. this link.
• Including the section title where the image is featured in to easily jump to it (and maybe the panel could even stay at the top of the page when jumping).
• For articles with only very few images on Commons or only very few not already featured in article, it may be better to then not show the panel.
• A 'more like this' button on each image that then retrieves files from somewhere underneath the article's linked category that is similar to that file the user would like to see more of. (If it's an image from a study, it would show more files from that study and then files from other studies. If it's a chart it would show more charts in the category (and these are often in a subcat). If it's a photo, it would show more photos etc.)

Prototyperspective (talk) 11:40, 3 March 2026 (UTC) Reply

I really appreciate these suggestions @Prototyperspective! I noticed a couple themes so I'm going to try to bucket my responses:

• Commons-related ideas. For this next phase of Image Browsing, we don't plan to borrow images from Wikimedia Commons (we just want to roll out the basic carousel without adding other scope as a first step to keep momentum). There are a lot of interesting ideas in here though that we can keep in mind for the future (for instance, perhaps a "More Like This" button would be a good entrypoint to test for some of the ). I agree that there is so much richness of content available there!
• Carousel actions. We are planning to implement multiple of the features mentioned (e.g., using contributor-controlled attributes like class to determine which images show in carousel, letting readers dismiss/collapse the carousel, enabling jump to section context for the image).

Hoping I caught everything in those buckets, but please let me know if I missed anything! SherryYang-WMF (talk) 19:52, 27 March 2026 (UTC) Reply

Thnak you for all you work, tests, call for comments and answers. After reading all the feedbacks and the message in the Bistro, I suggest something slightly different from showing images from other wikis. Why not showing images from related articles ? I'll just give an example : the article about the scottish ceramist Margery Clinton has no pictures at all. A carrousel could show images from different articles that have an internal link in the main article. Images could link themselves to their corresponding articles. Images from articles : Scotland, Ceramic, Lustreware, Ceramic glaze, Paper clay (use here the Commons file from the french article Terre-papier), Louis Comfort Tiffany, Glasgow School of Art, McLellan Galleries, Templelands, Tate, Victoria and Albert Museum, Glasgow Art Gallery , Royal Museum of Scotland., Scottish National Portrait Gallery, National Library of Scotland, The Mary Erskine School... So even there are basically no direct illustrations for the article Margery Clinton, there is a good possibility to give by the selection of the picture and the "internal links" a perspective of the subject (modern scottish ceramist, studied at art schools, is exhibited in well-knowm museums, has a specific technic of paper-clay).

It's always better to have less pictures but relevant. Pictures are known by their written datas : description, tags, captions, links. One way to ameliorate the datas and selection of pictures is to propose gamifications to the public so they collaborate to the project in a funny way. For example, AI tools like Arena propose to people to choose or evaluate two selected pictures answering to one request. Is this one better than the other one ? Are they equal ? Do they answer correctly to the request ? There is also the ISA tool from toolforge which proposes collaborative participation to the labelling of pictures.

The main idea is : explore the illustration of internal links of an article, propose a gamification to make the selection of the pictures more accurate. Waltercolor (talk) 10:26, 23 March 2026 (UTC) Reply

Ooh, this is a really interesting idea @Waltercolor! I like the notion of using blue links within articles to help inform related images. That could be something to consider for articles with fewer than 3 images, which is the threshold we've been using for selecting which articles to apply the image browsing carousel on.

I'm a big fan of Are.na, personally, as well in terms of how they integrate images with text. Their detailed categorization system seems really useful here. Thank you for this interesting idea, we will have to examine it more deeply! Do you think readers would understand that these images are coming from related articles, not the article itself? Or how do you think that would best be communicated? EBlackorby-WMF (talk) 19:41, 27 March 2026 (UTC) Reply

Thx @EBlackorby-WMF for you encouraging feedback! To distinguish the images coming from related articles, you can imagine a specific template for these kind of picture, with, below, a small clickable title of the concerned article (this could improve the average number of page views by visits for Wikipedia).

Just another idea for biographic articles with no image of the person : what about creating generic silhouette portraits with AI, displayed in light grey instead of black, to provide everywhere a "by default portrait" ? This would allow to feature in other carousels biographical articles which have no portrait. Waltercolor (talk) 08:33, 28 March 2026 (UTC) Reply

Hi, I added class=notpageimage to an image in this edit, but it's still shown in the carousel for some reason Flexagoon (talk) 15:37, 9 June 2026 (UTC) Reply

Thanks for this feedback @Flexagoon! Confirming I'm seeing this too and have filed a ticket for the team to take a look. SherryYang-WMF (talk) 19:00, 12 June 2026 (UTC) Reply

@SherryYang-WMF could you please subscribe me to the ticket if it's public on Phabricator? Flexagoon (talk) 19:05, 12 June 2026 (UTC) Reply

@Flexagoon I tried but for some reason couldn't get Phabricator to locate your handle. Here's the ticket if you'd like to follow along! https://phabricator.wikimedia.org/T428963 SherryYang-WMF (talk) 19:12, 12 June 2026 (UTC) Reply

I don't think the carousel should be shown on these pages:

• https://en.wikipedia.org/w/index.php?title=Taxila&action=history
• https://en.wikipedia.org/wiki/Special:Permalink/30435333
• https://en.wikipedia.org/wiki/Special:Diff/30435333

pon_or (talk) 18:41, 10 June 2026 (UTC) Reply

@Ponor thanks for raising, and agreed! We created a task to make sure we constrain the carousel just to views of article pages. SherryYang-WMF (talk) 19:05, 12 June 2026 (UTC) Reply

I do not see the carousel on https://fr.wikipedia.org/wiki/Session_du_Conseil_d'État even though there are more than 3 images. Escargot bleu (talk) 20:01, 12 June 2026 (UTC) Reply

@Escargot bleu thanks for letting us know! I'm not able to reproduce this issue. Are you seeing the carousel on other pages but just not this one? SherryYang-WMF (talk) 21:08, 17 June 2026 (UTC) Reply

It seems to be resolved and I now see the carousel correctly on this page. Escargot bleu (talk) 21:30, 17 June 2026 (UTC) Reply

filed a bug report on phab regarding an error I faced when accessing an article. phab:T429171 Robertsky (talk) 17:00, 15 June 2026 (UTC) Reply

@Robertsky thanks for reporting! We have put a fix out. Could you confirm if you're still seeing the issue? SherryYang-WMF (talk) 21:10, 17 June 2026 (UTC) Reply

@SherryYang-WMF looks good to me. Robertsky (talk) 01:19, 18 June 2026 (UTC) Reply

en:Minnie (singer) 1st image is currently of a file redirect. Clicking through the carousel should load the actual file rather than displaying an error message if it is possible for people to load the actual file when clicking on the image in the infobox or load the file by swiping right of the second image in carousel. (phab:T429694) Robertsky (talk) 14:14, 19 June 2026 (UTC) Reply

Thanks for this bug report @Robertsky! We're working on it and can let you know when it's fixed. SherryYang-WMF (talk) 14:39, 24 June 2026 (UTC) Reply

Hello, when I first see this feature, since the only difference is that it shows several images on the same row, I feel that it is the images at the top of the article, rather than a feature which allows the readers to browse different images. Perhaps there will be clearer navigation to highlight that the reader can interact with this feature to browse images.

Furthermore, the current media viewer only shows the license (which link to the file description page) as well as the image. Although I think it is a good direction to simplify the viewer, it seems too simplified and the reader and editors may not easily find how to access the file description page. The link at the license may mislead the reader that it is a link to the copyright license, rather than the file description page. Perhaps it would be better if there is an info icon at the bottom or upper corner in the viewer, for the reader to click into the file description page to find more info about the image.

Anyway, just my two cents and thanks for your efforts:) SCP-2000 (talk) 14:55, 19 June 2026 (UTC) Reply

Moreover, some users, especially experienced editors, may not prefer the image carousel displayed at the top of the page, as they may tend to read the text or prefer a simpler structure of the article. So it would be better if there were an easy way to switch off the feature. Thanks. SCP-2000 (talk) 15:31, 19 June 2026 (UTC) Reply

Thanks very much for your feedback! Point of clarification: by "clearer navigation" do you mean that the carousel images do not feel tappable to you?

Re: media viewer: we copied the exact feature set of the previous Minerva multimedia viewer with two changes:

1. The pagination controls appear at the bottom of the page now instead of overlaying the image.

2. The file page link used to just say "more details about this file" which was not compliant with our attribution standards (You're supposed to show the license and provide access to the file page). Now the link shows the license info, which we felt was a better attribution affordance.

To your point, we should consider more/different metadata and links in the future. Thanks for the suggestion! JScherer-WMF (talk) 14:52, 24 June 2026 (UTC) Reply

@JScherer-WMF Hi, thanks for your response:) Yes, that's what I mean. My personal first impression of the image carousel is that it is the same as a "normal" image rather than a carousel, in which it can't be slid to other images. I also agree that the change in license info is a better attribution affordance. SCP-2000 (talk) 15:37, 25 June 2026 (UTC) Reply

I realised that we may potentially cause embarrassment of varying degrees if nothing is done about the positioning of the images in the 1x1 preview of the carousel. Currently, all images are aligned center of themselves in the 1x1. For biographies, we invariably will not display the face of the person as most of the photos used are 3x4 or 9x16 crop. Instead, we are likely to see one's chest more than their face. We need some way for the editors to position the images in the 1x1 crop. (phab:T429698)

I can also see a pushback on enabling a wider rollout on wiki until the editing community is reasonably satisfied that this positioning issue can be resolved at scale. Robertsky (talk) 15:22, 19 June 2026 (UTC) Reply

@Robertsky thanks for sharing this feedback. We can look into your suggestion about cropping. To help me get a fuller picture, what would you look for in a cropping tool? SherryYang-WMF (talk) 03:12, 25 June 2026 (UTC) Reply

@SherryYang-WMF I don't think there is a need to create a separate cropped image/thumbnail? It just serves to increase the number of files generated. We just need a way for the editors to position the existing images correctly in the constrained 1x1 ratio. Robertsky (talk) 03:35, 25 June 2026 (UTC) Reply

Oh totally agree with no new file, and apologies if my word choice was confusing @Robertsky (we have actually already been talking about how to avoid duplicates when an image cropped differently shows up twice). I'm curious whether there's specific functionality you'd be interested in around that positioning within ratio, e.g., designate a "center" of the image or something else? SherryYang-WMF (talk) 12:09, 25 June 2026 (UTC) Reply

@SherryYang-WMF I am thinking of having css classes which allows the usage of the css property object-position. i.e. .image-align-top would translate to object-position: top. The css classes will allow editors to adjust the image alignment quickly in the article itself.

For files in Commons, we can explore storing the center coordinates as percentages as structured data for the files there and have the carousel in the wikis to use that coordinates with object-position css property. Robertsky (talk) 12:53, 25 June 2026 (UTC) Reply

I think automatically cropping images with portrait orientations from the top would solve the vast majority of issues here. I personally do not want to have to manually set a preference for thousands upon thousands of images. Toadspike (talk) 18:28, 25 June 2026 (UTC) Reply

That could work in the interim? I still would like to have the ability to manually set a preference where required. Robertsky (talk) 19:59, 25 June 2026 (UTC) Reply

I don't like the image carousel and I want to turn it off. This section says "After beta period, this will be found in mobile settings (the hamburger menu at the top of the page)." I can't find the setting. What's wrong? — Chrisahn (talk) 10:28, 24 June 2026 (UTC) Reply

Thanks for your feedback. There was a bug in the release that prevented the user preference from displaying. We've deployed a fix and it should be available shortly via Preferences > Appearance. Thanks for your patience! JScherer-WMF (talk) 15:00, 24 June 2026 (UTC) Reply

I still don't see it... — Chrisahn (talk) 16:09, 24 June 2026 (UTC) Reply

Now the option is available. Thanks! — Chrisahn (talk) 16:28, 24 June 2026 (UTC) Reply

i think this feature should be removed entirely. Presents more issues than whatever purpose it wants to have Pyraminxsolver (talk) 23:11, 24 June 2026 (UTC) Reply

I don't like the image carousel. It should be opt-in for logged-in users. Or at least there should be a link or button next to the image carousel to turn it off. I guess there will be a significant number of long-time users who won't like this distracting and space-wasting feature, and they shouldn't have to waste their time searching for the off-button. — Chrisahn (talk) 10:35, 24 June 2026 (UTC) Reply

Thanks for your feedback. We're considered several approaches to opting in/out of the feature. We'll consider adding an interface control for removing the carousel. In the meantime, there was a bug in the release that prevented the user preference to disable the carousel from displaying. We've deployed a fix and it should be available shortly via Preferences > Appearance. Thanks for your patience! JScherer-WMF (talk) 15:03, 24 June 2026 (UTC) Reply

@JScherer-WMF Is this fixed? There seems to be a bit of a mess in preferences about carousel still? In https://www.mediawiki.org/w/index.php?title=Special:GlobalPreferences&useskin=minerva&mobileaction=toggle_view_mobile I'm not seeing this preference anywhere, and in regular skin it is available (and off) in Beta Features.

Is there currently away for users to turn this off in production for mobile view? Xaosflux (talk) 13:39, 26 June 2026 (UTC) Reply

The WMF posted an announcement on enwiki that the feature has been rolled back to beta for all wikis. (A bit strange that they didn't announce it here as well.) That explains why the toggle also moved back to beta. — Chrisahn (talk) 14:48, 26 June 2026 (UTC) Reply

This is a very bad feature and it must be immediately disabled.

It makes articles appear in a way that is significantly different from the way in which editors intended. It shows images at the top out of context. Editors put images in specific places for a reason, and this feature just ignores this.

When editors said that "There's lots of useful media on Commons but it's not found by people searching the Web or reading Wikipedia", they were right, but I'm quite sure that showing images at the top of an article out of the context of the specific section and without their captions is not the solution that they had in mind. Amir E. Aharoni {{🌎🌍🌏}} 12:38, 24 June 2026 (UTC) Reply

I agree. On most pages, this image gallery at the top merely distracts and takes up space but isn't helpful in any way. This should be reverted. I'm sure several people invested a lot of time designing this, but it's not an improvement. — Chrisahn (talk) 13:11, 24 June 2026 (UTC) Reply

I wouldn't call it "distraction"; there are other things for which I'd use this word.

I'd rather call it "confusing": why is it there? For twenty five years, editors had exclusive control of what appears in the article, and editors have been very good at using this control. They have carefully and intentionally chosen which image to put next to which paragraph, how is it relevant in context, how to write a caption that explains this, and so forth. This feature completely ignores it and adds a bunch of essentially random images at the top.

And yes, when I say "random", I mean "random". The fact that they appear somewhere in the article doesn't make them not random. Placement matters. Amir E. Aharoni {{🌎🌍🌏}} 13:29, 24 June 2026 (UTC) Reply

Fully agree with Amir here. The images are at best confusing - sometimes misleading - when taken out of context, they block the most precious real estate on the page and the feature breaks the contract between editors and WMF that has been the foundation of Wikis. Belteshassar (talk) 14:08, 24 June 2026 (UTC) Reply

This is a horrible function. Especially in geographical articles where we are using location maps with a marker. The location map is shown in the carousel, but not the marker. Tekannan (talk) 13:13, 24 June 2026 (UTC) Reply

Is this really something that we shall have? It really disturbs the reading of an article, especially when I'm reading on a small screen, the mobile. The mobile interface shall be as compact as possible to enable fast reading when checking facts when I'm in a meeting, in a conversation with friends, watching a soccer game or a quiz show. This change contradicts all the good work done so far to make the mobile interface suitable for quick and easy browsing. Tekannan (talk) 13:40, 24 June 2026 (UTC) Reply

Thanks for the feedback @Tekannan. @Robertsky requested functionality to improve the positioning of the image within the thumbnail above. I'm curious whether you think that would address the location maps issue and whether you have any requests for that tooling--or whether you have other suggestions?

As for your question about the suitability for reading on mobile, you may have already seen the discussion of engagement that is on the project page, so I'll just add a little context from our experiment results post on VPT. In addition to strong clickthrough rate engagement (7-8%, notably higher than the typical 3-5% on mobile web), we also saw small but statistically significant retention increases across five wikis where we tested (we did not see statistically significant increase on enwiki where we tested on a smaller sample but the engagement was very similar so we think this is also a sign of reader benefit). Multiple of our qualitative and quantitative studies have shown readers respond well to images and feel overwhelmed by a wall of text, so in a way, our hope with this feature is actually that it makes the information compact for mobile, in the form of images. We also took care to ensure that the lead section still shows above the fold on small screens. Please let me know if you have suggestions in addition to the maps one above as we do want to continue improving the feature. SherryYang-WMF (talk) 12:19, 25 June 2026 (UTC) Reply

@SherryYang-WMF, this feature puts all the images indiscriminately at the top of all the articles. It cannot be improved. In its current form, it must be disabled.

Maps are just one example problem of taking an image out of context. There are practically countless other examples.

Making more images visible on mobile web is a valid thing to explore, but the solution of putting all of them at the top is way too blunt.

Valid things to explore:

• Smarter placement of infoboxes. Currently, the infoboxes are automatically moved below the first paragraph of text, even though usually editors actually put them at the top of the articles.
• Canceling the auto-collapsing of section headings. Ten years ago, the WMF intentionally hid all the sections and the images to save bandwidth, especially for countries where data is more expensive. This decision may be revisited.

Just showing all the images at the top in bulk is wrong. Amir E. Aharoni {{🌎🌍🌏}} 13:14, 25 June 2026 (UTC) Reply

@Amire80 this feature puts all the images indiscriminately at the top of all the articles. It cannot be improved. As indicated in the FAQ, exclusion of certain or all images is possible as an editorial decision. As with new features, like with the dark mode, it is up to editors to decide what images to be included here. Robertsky (talk) 13:30, 25 June 2026 (UTC) Reply

It is completely unreasonable to expect editors to go through millions of articles and exclude images one by one. Amir E. Aharoni {{🌎🌍🌏}} 13:32, 25 June 2026 (UTC) Reply

"it is up to editors to decide what images to be included here." Good - if it had been true. It's not. To bee true, the editors shall opt-in by adding the magic word "__MEDIAVIEWERCAROUSEL__" to the article and/or "class=carouselimage". No other images shall be included in the carousel. Than the editors will have the power to decide which images to be included. Now, this change is forced into millions of articles without giving the editors a chance to handle it. Tekannan (talk) 13:52, 25 June 2026 (UTC) Reply

@Amire80, @Tekannan, which is why I advocate for a phased roll out or going back to beta as what I opted for in the enwiki's rfc rather than this one-time shock all roll out. The initial beta, imo, before the bug that took the option out to enable or disable the feature, had reached only 800+ editors using it when I enabled it on enwiki a few weeks back (I did not take a screenshot, so take the number at face value), which was what I felt a like miniscule number, not even a percentage of the number of registered editors in the last 30 days there (262,922). I am not even sure if it had reached some editors who would likely have a more nuanced opinions on how to implement the feature but not necessarily aware of the earlier conversations.

A controlled roll-out would have identified the issues that may not be in consideration by the initial pool of editors using the beta and resolved progressively. Robertsky (talk) 15:16, 25 June 2026 (UTC) Reply

Combining images with appropriate text is a more effective communication tool than an image alone. This feature separates the image from the text in a random way, it is like a quiz show: How does this picture relate to the subject? This is like showing the text sections in an article in random order. Several editors have put a lot of effort to create an article, and to find the best combination of text and images. This feature is strongly violating that effort and could lead to a decrease in people willing to spend their time to create a better Wikipedia. Tekannan (talk) 13:23, 25 June 2026 (UTC) Reply

Discussions on Wikipedias whether to disable this feature on their sites:

• en:Wikipedia:Village pump (policy)#RfC on the new Image Carousel feature
• de:Wikipedia:Fragen zur Wikipedia#Neue Bildergalerie oben auf mobilen Seiten bitte in der deutschen Wikipedia abschalten
• nl:Wikipedia:De kroeg#Image browsing

— Chrisahn (talk) 16:13, 24 June 2026 (UTC) Reply

Let me start by saying that I welcome experiments, a focus on readers and generally the work the GrowthTeam has done. However, I think there are too many problems, such as duplication, placing images out of context and a bit too much focus on the photos. I have therefore also asked for comments on the Dutch Wikipedia whether we should remove it. I am however willing to think along in the future in what other way this goal can be addressed. Kind regards, Dajasj (talk) 05:27, 25 June 2026 (UTC) Reply

Have to admit, there was no support for my proposal Dajasj (talk) 09:09, 7 July 2026 (UTC) Reply

Please, make it a bit harder to find out, what this feature actually does. The frontpage currently contains much too less PR gibberish.

But honestly, this help page is not well structured. This most important message of the page should be the information what Image Browsing actually is and does. But before you find this information, you at first have to read a lot of boring text that doesn't help you at all. That's very unfortunate.

Please add a brief and concise summary, best directly in the introduction. Chaddy (talk) 15:47, 24 June 2026 (UTC) Reply

It also looks like the page hasn't been updated since launch, it's still talking in the future tense about a full rollout in June 2026. Belbury (talk) 17:30, 24 June 2026 (UTC) Reply

Saya ingin mengadukan bahawa Gambar di atas tidak berapa cantik dan nampak sangat buruk, mohon kembalikan seperti biasa. ~2026-36618-10 (talk) 06:38, 25 June 2026 (UTC) Reply

@~2026-36618-10 Hello, you can add class=noviewer, which will exclude that image from being shown in MediaViewer and in an article's carousel, or add the magic word __NOMEDIAVIEWERCAROUSEL__ to remove the image carousel from an article. Thanks. SCP-2000 (talk) 10:40, 25 June 2026 (UTC) Reply

I was wondering about the CTR, which is quite high. How high was the CTR for images before the carrousel? And did it have any (positive or negative) effect on readership of the article text as opposed to viewership of the images? Do people leave after clicking on the image? Dajasj (talk) 12:23, 25 June 2026 (UTC) Reply

I hadn't got around to commenting on the en.wiki RFC, as I was still assessing the carousel on various pages.

Reviewing the carousel for various local places, some photogenic tourist destinations, some not, the results were often drab and would not improve the reader experience. I am thinking here of en:Alloa, en:Tullibody, en:Fort William, Scotland, en:Millport, Great Cumbrae. The last of these included a photo of a bog-standard school building not even on the island itself; that photo plays an explained part in the article text but is inappropriate outwith its context.

Fundamentally, I question whether anyone's desire for "more images" is met by displaying the same images to be seen throughout the article. Another approach might be to present different photos from the linked de.wiki, fr.wiki articles, for example, for a different perspective. Or the broader approach suggested by Waltercolor above.

However, a more structured and controllable image resource exists within the wider project: Commons category pages. It seems remiss not to utilise this to meet readers' desire for more images (a point which also returns to Commander Keane's comments above). Articles sometimes link to it (e.g. the commons category template under See also on en.wiki), but not always (e.g. Tullibody), however the link is also accessible via Wikidata P373. I realised this is some way from the expended effort on developing the carousel, but coding and presenting a discreet button link to the Commons category page near the top of the wiki article might be an alternative approach (subject to community approval)? AllyD (talk) 12:12, 26 June 2026 (UTC) Reply

So the feature is back to beta. This was the right decision.

In the English Wikipedia RFC, @MMiller (WMF) writes:

Our research shows that readers want more access to images, and we continue to think that elevating images in this way makes them more likely to reach for Wikipedia in the future as a knowledge source – that’s why we’re going to continue to work on this and discuss with you.

The question is what is "elevating images in this way".

If "this way" means "taking all the images in the article and putting them at the top", then Don't.

That's why so many people including myself demanded to disable it, and they will demand it again.

For twenty-five years, many thousands of editors have been deciding how to place images in relevant places. That's what made the "Wikipedia" brand. Showing images in other places under the "Wikipedia" brand is wrong.

It looks like so far, the assumption that the feature designers have made is that the fact that an editor included an image in an article makes that image relevant for the whole article and can be shown at the top. This assumption is wrong. An editor included an image in a specific place in an article, and it is relevant to that place. The top of the article is another place, and "elevating" any image there makes it irrelevant. This irrelevance is the rule, not the exception.

Other things not to do:

• Autocrop. This always works badly. Saying that "all other websites do it" is wrong: Other websites can do it as much as they want, and we don't do it, and that's exactly the kind of thing that makes respected media organizations publish a story that says something like "Wikipedia is the last good place on the internet" every few months. Wikipedia editors, and only Wikipedia editors decide how to crop (or not crop) images that are shown in articles.
• Use an automatic algorithm to decide which images are relevant enough to be elevated or not. Ironically, it's kind of possible that in practice, showing images that were selected by some "AI"-style algorithm will be relatively better than just showing all the images from the article there, but for goodness' sake, don't actually do it! No, only human editors must decide what is shown in the article and where.
• Say that the editors can "control" the feature because they can exclude certain images, pages, categories, or templates, but elevate everything else by default. No, this is not "control".
• Make a solution that works significantly differently on mobile and on desktop. The two platforms are equally important and should be as close as possible.^{[aea 1]}

If the WMF wants to show more images to readers, it's a reasonable goal, as long as those are relevant images. There are many creative things that could be done to achieve this. The page Readers/Reader Growth/Image Browsing has a lot of sensible ideas about images' context and relevance in the "Research" section, which makes it all the more puzzling that the WMF decided to solve this problem by simply putting everything indiscriminately at the top.

Finally, I should mention that I'm not much of a media person myself; I'm much more text-oriented in my writing and reading. I upload relatively few images and I add existing images to articles only occasionally. I hope to see more comments from people who are bigger media contributors than I am.

With all those things out of the way, in the next sections, I shall suggest positive things to do. --Amir E. Aharoni {{🌎🌍🌏}} 11:15, 27 June 2026 (UTC) Reply

I'm a visual learner myself, sort of, I like "reading" my sci papers from figures and their captions. Many sci journals will show them ([1]) if they don't let you read the text until you pay. But I agree, this can be done in less intrusive and more meaningful ways: 1) provide context: full scrollable caption (in mediaviewer), and the ability to jump to where the image is in the article 2) instead of the carousel fighting for space with other top-of-the-page stuff (see this wiki on mobile), there could be an inviting media button somewhere in the title area to show a clickable gallery of all images. pon_or (talk) 12:14, 27 June 2026 (UTC) Reply

The Reading/Web/Projects/Lead Paragraph Move feature from 2017 could be reconsidered. Note that I'm not saying "remove it", but "reconsider it", although removing it is a conceivable conclusion.

That feature, though hacky and problematic in some ways, was an understandable response to a real problem: in wikitext, the infobox is usually written before the lead paragraph, and in practice, on desktop screens it usually causes both the lead paragraph and the infobox to be shown at the top, but on narrow mobile screens, only the infobox was seen, and some people thought that it's not great not to see any text at the top.

Infoboxes very often include an image, so if the infobox is pushed down, so is the image.

Ironically, the editors who created the infoboxes in the 2000s essentially did what the "visual learners" allegedly want: they put an image at the top. (Some infoboxes actually include several images, which I guess is even better for the people who want lots of photos.) Then that feature removed the image from the top, overriding what editors did. So in a way, the editors' intuition was perhaps always right, and overriding it by simply moving the text up was wrong.

I could immediately think of several solutions for this, but I'll start from an approach that you shouldn't take: don't get articles that were already published in a certain way and transform them yet again for mobile view. That was the approach taken when that feature was developed, and it brought us to the current situation, which, at least according to some people, is not great for visual learners.^{[aea 2]} Rather, the editors must clearly see how the article will eventually be rendered on all platforms and be able to control it without unexpected subsequent transformations that are out of their control.

The ideal solution would be to work with editors in the bigger languages on updating the manuals of style for infoboxes and lead paragraphs. I don't know what the conclusion would be. For example, it could be a suggestion to limit the lead paragraph to something very short so that the infobox with the photo would fit above the fold. But it's just an example; what I'm talking about is not the eventual solution, but the right way there. (However, if this specific solution is adopted, the "Lead Paragraph Move" feature can probably be removed.) --Amir E. Aharoni {{🌎🌍🌏}} 11:15, 27 June 2026 (UTC) Reply

On w:en:Wikipedia:Village pump (policy)#More context from WMF, @MMiller (WMF) writes:

We know from surveys of readers that seeing more images is a top-requested improvement (though this doesn't bring more images to the articles, it makes it much easier for readers to see the ones the articles have, which otherwise are inside collapsed sections in the mobile experience).

MobileFrontend has been auto-collapsing section headings for many years. In 2016, an official WMF blog post said that it's good because it saves bandwidth, and in some countries it also saves people money because bandwidth is very expensive. The post literally opens with the words:

As the saying goes, a picture is worth a thousand words. Yet images on mobile devices can translate to more data used. In many parts of the world, high mobile data costs present a significant barrier to accessing knowledge on the Wikimedia sites.

So showing fewer images upon the article loading was WMF's conscious decision, and it addressed a specific problem. Evidently, the WMF no longer thinks that it's a problem^{[aea 3]} because it wanted to show all the images at the top of all the pages.

Perhaps all sections could be expanded by default. Unfortunately, there are also arguments against this, as the page Readers/Reader Growth/Expanded Mobile Sections says. The eventual solution needs to take both sides of this issue into account. --Amir E. Aharoni {{🌎🌍🌏}} 11:15, 27 June 2026 (UTC) Reply

This would be bad: without the ability to jump to a section, it would take forever to scroll down (and back up) to any particular part. There are many articles where the infobox alone spreads across 4-5 screens on mobile. Maybe they could make mobile experience more like the Wikipedia app experience, though. There are things they do better in the app. pon_or (talk) 12:23, 27 June 2026 (UTC) Reply

Yeah, I'm certainly not strongly pushing for dropping the auto-collapsing. I'm just responding to the issue that the WMF staff brought up: part of the motivation for the carousel is that the images are hidden in the collapsed sections.

We get a bit of a paradox here: collapsing sections is both good and bad. Good because it helps navigation and (maybe) saves bandwidth. Bad because it hides images that would possibly be good not to hide. And there may be more points for and against it.

All I'm saying is that the section collapsing in its current form is not eternally set in stone, and it can be thoughtfully reconsidered. Amir E. Aharoni {{🌎🌍🌏}} 09:50, 28 June 2026 (UTC) Reply

Compromise solution: Collapse the sections and instead of the text show an image carousel under each section header with the images of the section. ;-) — Chrisahn (talk) 10:26, 28 June 2026 (UTC) Reply

This is actually kind of not bad, but:

• Given what @Robertsky writes below, that bandwidth may still be an issue in some countries, this should probably be taken into account and not dismissed. "Every single human being" and all that.
• Putting an image in the section in which an editor put it brings it closer to its context, but not necessary always perfectly. Some sections are very long,^{[aea 4]} and putting all the images at the top of the section can be practically as irrelevant as putting them at the top of the article.

But yeah, it's a legitimate direction to explore.

Just thinking out loud: Perhaps there could be some new wikitext that lets editors define text that accompanies images while they are not in their usual context. (I thought about suggesting to use structured data on commons for that, but it probably won't work, because this would be different in every article.) Amir E. Aharoni {{🌎🌍🌏}} 08:17, 29 June 2026 (UTC) Reply

i am currently in a country where bandwidth is an issue. I would suggest that the team explores on how to offer bandwidth efficient designs on a country level basis. Such as parking the image carousel behind a feature gate that's to be activated base on the IP address of the user. Robertsky (talk) 11:43, 28 June 2026 (UTC) Reply

If the WMF wants to show more images, its designers can propose changing policies and manuals of style so that it allows more images in Wikipedia articles. The two important pages about this in the English Wikipedia are w:en:Wikipedia:Image use policy and w:en:Wikipedia:Manual of Style/Images. Currently, they have many points that go squarely against the carousel feature as it was deployed on June 24. Here are just a few examples:

• "It is common for an article's lead or infobox to carry a representative image—such as of a person or place, a book or album cover—to give readers visual confirmation that they've arrived at the right page. For some topics, selecting the lead image can be difficult."
  • Note especially the selecting the lead image can be difficult: this is often true, and this is an expression of the sweat of the brow that goes into selecting that image. It's true for all images on a page, and not just the lead ones, and that's why simply automatically copying them to the top feels so wrong to so many editors.
• "An image should generally be placed in the most relevant article section; if this is not possible, try not to place an image too early, i.e., far ahead of the text discussing what the image illustrates, if this could puzzle the reader."
• Referencing galleries, which are similar to the carousel: "Images should be captioned to explain their relevance to the article's subject and to the theme of the gallery, and the gallery itself should be appropriately titled (unless its theme is clear from context)."

You should of course look at policies and manuals of style in other languages, too. They are probably similar in spirit, but may be different in details.

You can also change the <gallery> tag to allow horizontal scrolling like in the carousel (as far as I know, currently it's impossible). And then you can encourage editors to use it more in a prominent place in the article. Encourage, not force.

If you convince the community to do it, you'll get the same effect that you got with the automatic carousel, but with only relevant images and without the community pushback.

Nobody said it was easy. I know that conversing about policy changes with editors' communities sounds like a hopeless task that is somewhere between ultra-slow and unachievable, and you don't want to be ultra-slow when you want to urgently fix the readers decline problem. But if you actually want to get somewhere with this project, there's no other way. --Amir E. Aharoni {{🌎🌍🌏}} 11:15, 27 June 2026 (UTC) Reply

On one hand, this topic is super-touchy because of the MediaViewer and superprotect saga.

On the other hand, there is a real issue here: The MediaViewer shows the image with the caption, and if there's no caption, then it shows the description from the {{Information}} template on Commons. The description is sometimes OK, but sometimes it's missing or badly written, and sometimes it's OK as a description on Commons, but not great in the context of the article.

And there's no obvious invitation to improve anything.

Being a Wikipedian, I may be overthinking here. Maybe the visual learners don't read those captions anyway, and don't plan to contribute. This begs some questions, however. If not reading and contributing, then what is the follow-up that we want from these people, and why do we care about the CTR that comes from them? And isn't the contribution pipeline very small anyway? And if they are visual learners, maybe a few of them can turn into visual contributors?

Less prominently, MediaViewer also shows some things that are useful to Wikipedia editors, such as licensing information, media creator's name, and uploader's username. Of these, only the media creator's name may be useful to the casual reader who isn't going to contribute.

All those things may seem unimportant, but they aren't. If the point of this feature is to get people to tap the images, you should also think deeply about what happens after the tap: learning, contribution, sharing, etc. Otherwise, it's just shallow CTR chasing. --Amir E. Aharoni {{🌎🌍🌏}} 11:15, 27 June 2026 (UTC) Reply

You probably don't need to reply anything here. It's just a placeholder for footnotes. --Amir E. Aharoni {{🌎🌍🌏}} 11:17, 27 June 2026 (UTC) Reply

Currently, in beta, I think we need editors to easily assess what images should be in the carousel. Since many editors are on desktop, it would be easier to let editors preview the carousel on desktop. Robertsky (talk) 17:41, 29 June 2026 (UTC) Reply

My understanding of the image carousel is that it presents images from the article at the top of the article page on a mobile device that "rotate".

I use En Wiki.

Accessing articles on my phone through a google search, I don't see any change - I see the lead followed by the infobox.

Accessing articles through the app, I see a single image that does not "rotate" through images and the infobox is hidden.

Cinderella157 (talk) 00:23, 30 June 2026 (UTC) Reply

@Cinderella157 have you enabled the carousel through Preferences > Beta on your mobile yet? Robertsky (talk) 19:02, 30 June 2026 (UTC) Reply

I have the same problem as Cinderella. I have enabled the carousel in Preferences > Beta features, but I don't see any carousel anywhere. I tried several ways to enable the feature: As a global setting and as a local setting. Nothing works.

While the feature wasn't in beta, I disabled it in Preferences > Appearance. Could that be the reason why I don't see the carousel? @Cinderella157: Did you also disable the feature in Preferences > Appearance while the toggle was in that tab?

— Chrisahn (talk) 21:51, 30 June 2026 (UTC) Reply

I have very little experience using a mobile phone/device. I will describe what is happening on the device. If I search from google to a WP article, I see the WP banner which allows me to access preferences. I have downloaded the WP app and the WP beta app. In both cases, I don't see the WP banner and I am not seeing a way to access preferences. Cinderella157 (talk) 00:47, 1 July 2026 (UTC) Reply

I think the feature isn't available in the app, only in the mobile web version. Did you activate the feature in the mobile version in your browser? The toggle is in Preferences > Beta features. I think you have to be logged in. — Chrisahn (talk) 19:56, 1 July 2026 (UTC) Reply

Hi, it took me a certain time to understand why I didn’t see the carrousel, so I couldn’t give a feedback about how it looks. I now realize that it is disabled by default, so I changed my preferences. A quick feedback : it has to be activated language by language, so I don’t actually see the gallery in the english version, only in french, so I cannot compare the results by languages. Just asking myself if it will work for newbies if they have to activate it voluntarily (or is it automatic for them?) in every language ? Concerning the aspect, I’m not sure it looks great because, as it is often the case in mobile versions, several images appear as cropped in an unaesthetic way, so they loose their power of attraction.

So, just an idea for Reader Growth and Image Browsing projects : did you see this new game published in june by the young game developer Neal Agarwal ? It’s Wiki-Spy. This game is really awesome, have a look on it and test it ! Thus the concept could look, at a first glance, like a Wikipedia rabbit hole, it’s much more sophisticated because it’s visually marvellous and it makes the perfect bridge between image and the corresponding Wikipedia article where the image comes from. Agarwal is a genius because he had this incredible idea to present edge-emphasized images froms commons, instead of just plain images. So the set of images you get on the white board, may it be by shuffling the more than 43 000 images he has yet, or by searching for a precise subject, appear visually like a giant sheet of stickers.

And each of the stickers are clickable and redirect to the concerned Wikipedia article. In a couple of minutes, just by clicking randomly on pictures, I had the opportunity to discover the Chandelier article, which has a lot of marvelous other pictures, and the article about Mindon Min, the penultimate king of Burma (Myanmar) from 1853 to 1878. frankly speaking, I would never had the idea to click on this article and the chance that it appears in our average « random article » function is equal to zero. But thanks to the appealing picture of the reverse of the 1 Kyat (Rupee), the first machine struck silver coin of Burma made in 1853 AD, I had the opportunity to enter this « magic encyclopaedic world » which is Wikipedia with its numerous photos on articles.

My opinion : the carousel idea is not a bad one, and congrats to the people who made this projects, but it looks more like an additional tool than an opportunity to get more readers on Wikipedia (and we urgently need more readers).

With creations like Wiki-spy, we see that there exist excellent opportunities to propose new ways to discover Wikipedia and make more clicks on the articles, and it’s by gaming, use of our pictures library in Commons, beautiful design and transversal ways to navigate on the site. Our Random page feature is just depressing, and AI generated content is boring and has the level zero of humour and unpredictable results. So let’s play the card of gamification for the discovering of Wikipedia, amazing sightseeing tours by images etc... I believe that in our vision, we always stick to close to a concrete result and produce tools where we need games. Sometimes it’s necessary to take risks and think out of the box.

Guess you’ll have better results for the reading growth if you implement something like Wiki-spy, and its various pictures linked to a whole range of different articles, than with a simple carousel displaying the visual content of just one article and in the same article. Gues which one brings the reader to explore Wikipedia and make more page views ? Waltercolor (talk) 14:59, 4 August 2026 (UTC) Reply

In the Czech translation, the text "span id="srpen 2026:_Improvements_and_retest"" appears under this translation. Rebulka (talk) 17:14, 8 August 2026 (UTC) Reply

While a good idea, images are placed in certain areas or sections that make sense to why is been placed. For example, you could be on Wikipedia pages and its other sister projects that make sense about this explanation that you could be explaining about lets say a certain model of something, with it being at the top, there is no context for the reader on mobile to even know why the image had been placed, it would be good if there is multiple images in that section. Perhaps have the carousel placed in each section of the image? Wikiediter2029 (talk) 21:22, 10 August 2026 (UTC) Reply

Retrieved from "https://www.mediawiki.org/w/index.php?title=Talk:Readers/Reader_Growth/Image_Browsing&oldid=8555170"