Board Thread:General Discussion/@comment-27661991-20200909141301

tl;dr: can we get a firm commitment that a way to specify the thumbnail is on a todo list somewhere?

Yes, I've read https://community.fandom.com/wiki/User_blog:Kirkburn/How_images_are_picked_to_represent_articles

Did you know that article is from 2013? Has anything changed in that algorithm beyond what the comment added? Even if something has, we clearly still have issues where article references with images will show titled "Superman" but have a picture of Spongebob, so to speak. It's 2020 and, despite its reputation as a year so far, we should be able to do better.

I see two options (besides the status quo):

A. Tweaking the algorithm

I understand that this is not a light step to take as any change to the ImageServing algorithm can have all sorts of unintended side-effects*. Additionally, I'm not sure how it would be tweaked. Focus more on infoboxes? That'll work in many cases, but in others that'll break ones that were good before, e.g. articles where the infobox doesn't show an image representing the article as its focus, but does have images for related items. Always pick the first image? 'Under construction' templates' images will suddenly be the thumbnails everywhere. So I get that this is probably nobody's favorite option.

B. A tag

Remember those *side-effects? That's because it's an algorithm deciding. We all know how well that works out on YouTube; I dare say they've probably got better experience with figuring out what should be filtered in/out, and they still get it wrong often enough.

So why not let us mere mortals decide? Whether it's a custom HTML tag, a parameter in a File: call, a __THUMBNAIL__ immediately preceding an image reference, or anything else that can be easily parsed, the end-result is that for those articles where Spongebob is apparently Superman, a human can come in and fix it with a minimum of effort. This doesn't require a fancy thumbnail picker (a la the categories UI in various places) or changes to the editor, as it can be limited to having to edit the source code; any wiki facing this issue is likely to have somebody who can follow instructions to fix it without needing a UI to do so.

Yes, this has been suggested before, even in that blog post. That specific suggestion there went oddly ignored, while anything that would be a tweak to the algorithm was responded to. I get it, it's somebody's baby, they're pretty proud of it, as it does get things right, say, 99% of the time. I'm not saying we need to do away with it - only augment it. "There are so many images, so many categories, that automation is really the only way to do things" as mentioned in one of those threads is categorically false. The two can happily co-exist in a hybrid approach.

Yes, things are very busy with the UCP changeover. I'm not asking that developers drop everything they're doing and cater to this request that affects so very few. I'm asking that we get a firm commitment that this is on a TODO list somewhere, as the current works-most-of-the-time system-gaming of 1. uploading a duplicate image of sufficient resolution, 2. putting it as the first thing in the article, 3. making it 1 pixel and/or hiding it with CSS (not mobile-friendly), and 4. making sure from there on it doesn't get used too much anywhere else, is wasteful for both the Fandom servers, browser clients, and wiki editors (unnecessarily complicates the page, could break at any time).

Thank you :) 