Thumbnails should use a square bounding box by default
Closed, DeclinedPublic

Description

See https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes for context.

If the user doesn't specify an explicit size for the thumbnail, we should scale to a square bounding box so that portrait aspect-ratio images look the same visual size as landscape aspect-ratio images.


Version: unspecified
Severity: normal
URL: https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63904

bzimport set Reference to bz63903.
cscott created this task.Via LegacyApr 14 2014, 2:57 PM
gerritbot added a comment.Via ConduitApr 14 2014, 3:41 PM

Change 123683 had a related patch set uploaded by Cscott:
Use square bounding boxes for default-sized thumbnails

https://gerrit.wikimedia.org/r/123683

gerritbot added a comment.Via ConduitMay 21 2014, 10:18 PM

Change 123683 merged by jenkins-bot:
Use square bounding boxes for default-sized thumbnails

https://gerrit.wikimedia.org/r/123683

cscott added a comment.Via ConduitMay 22 2014, 4:11 PM

Merged into after RfC discussion; now I need to make the same change in Parsoid---and get the WMF imagescalers busy making the new thumb sizes before deploy.

cscott added a comment.Via ConduitMay 29 2014, 7:17 PM

Landed in core; switching component to Parsoid to track corresponding patch there.

bzimport added a comment.Via ConduitMay 31 2014, 1:29 AM

tsui wrote:

I strongly oppose such a fundamental change of the screendesign. Making the image sizes change according to this bounding-box model destroys the layout/screendesign. It will only lead to users beginning to specify an explicit size of the thumbnail again - at least that is what I will do for sure.

Jdforrester-WMF added a comment.Via ConduitMay 31 2014, 1:45 AM

(In reply to Tsui from comment #5)

I strongly oppose such a fundamental change of the screendesign. Making the
image sizes change according to this bounding-box model destroys the
layout/screendesign. It will only lead to users beginning to specify an
explicit size of the thumbnail again - at least that is what I will do for
sure.

Your comments should have been made as part of the RfC process – https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes – note that this code change has already been merged and is now live on all Wikimedia wikis.

cscott added a comment.Via ConduitMay 31 2014, 1:55 AM

@Tsui: explicit sizes are probably actually the right thing in most cases. There is some discussion in https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image and it seems to me that the infoboxes with issues were ones that assumed a fixed width even though they didn't specify an explicit width bound, which was hostile to user customization.

Remember: if you don't specify an explicit size, you are requesting that MW choose an "appropriate size", which could be anything -- and will likely vary on mobile, hi-density devices, user preference, etc. If that's not actually what you wanted, then yes you should be specifying size explicitly.

That said, I am interested in continuing discussion on image options in general. There have been various RfCs proposing a more semantic set of image options, which would allow resizing in a more meaningful way than the current inflexible "default thumb size". Contact me on my talk page if you are interested in pursuing that discussion; offhand I can't remember if there is already a bugzilla and/or RfC for that work.

cscott added a comment.Via ConduitMay 31 2014, 1:58 AM

(Oh, and for the record this particular bug is for "Parsoid should match mediawiki/core's behavior". If you want mediawiki/core to change back, then bug 65945 is the one for you. But really https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image is where the discussion has been happening to date, and we can probably find a new on-wiki or on-mailing-list place to discuss this if/when we outgrow the Village Pump. Bugzilla is very awkward for discussions like this.)

DerHexer added a comment.Via ConduitJun 1 2014, 10:02 AM

(In reply to James Forrester from comment #6)

(In reply to Tsui from comment #5)
> I strongly oppose such a fundamental change of the screendesign. Making the
> image sizes change according to this bounding-box model destroys the
> layout/screendesign. It will only lead to users beginning to specify an
> explicit size of the thumbnail again - at least that is what I will do for
> sure.

Your comments should have been made as part of the RfC process –
https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
note that this code change has already been merged and is now live on all
Wikimedia wikis.

And the RFC was announced and he invited where? Honestly, I don't see any consensus on this RFC but just a blank proposal without any discussion which does not justify at all any software change like this.

DerHexer added a comment.Via ConduitJun 1 2014, 10:45 AM

I have seen them ofc and considered adding them to my comment. But these are no community discussions but discussions of developers how or when to implement the code (as they are happening on wikitech-l). They are necessary too but just as a second step when there’s community consensus. Please first reach this kind of consensus before you implement wide-ranging software changes like this which affect millions of articles. Hence, I beg you to revoke your code implementation now and wait for the outcome of the current discussions which also take place on other wikis (e.g. https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Bildgr.C3.B6.C3.9Fe_.C3.A4ndert_sich_beim_Speichern_ohne_Quelltext.C3.A4nderung https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Kurier#Neues_Media-Wiki-Geschenk).

Rillke added a comment.Via ConduitJun 1 2014, 11:15 PM

(In reply to James Forrester from comment #6)

Your comments should have been made as part of the RfC process

which was on MediaWiki.org.

And MediaWiki.org is a wiki ruled by and for MediaWiki developers. I never had the feeling being invited editing that wiki in any kind nor sharing my incompetent opinion there. Apart from that, I've hard times not to compare this course of action to some German or even Vogon bureaucracy.

Obviously, one wanted the input by developers but ... again forgot(?) to asking the biggest consumer(s). Or did one merge this patch as some kind of mock too see how much riot it will cause?

Seriously:

  • Some information about how to deal with the software change to WIKIPEDIA would have been a great idea. More prominent announcements welcome. I thought there were Community Liaisons to do the footwork?
  • I do not expect anyone writing sample code to fix thousands of templates or articles but I would expect creating a central page coordinating update of these in all WMF projects including check lists and space for contributors adding such code as well as some means for community members to systematically identify articles containing images that (will) change their sizes, e.g. a Toolserver Tool.
  • Doing what is done now, gathering "sober reflections on image sizing and describe your use cases" - couldn't this be done before such changes? Or while doing so while running A/B-Testing?
  • Studies on how the changes (could) affect the reader's experience are missing. "provides

a better default appearance" needs to be proven.

MZMcBride added a comment.Via ConduitJun 2 2014, 1:55 AM

Tim is reverting this change now.

cscott added a comment.Via ConduitJun 2 2014, 2:34 AM

Yup, we decided in this case its better to revert now and then discuss, since some editors are considering adding an 'upright=1' workaround -- which would be bad, since 'upright' is actually the image option we most wanted to fix.

Anyway, https://gerrit.wikimedia.org/r/136708 is the revert, and I believe it is against the deployed branch so should take effect immediately. We will follow up with details about a proper discussion bringing in all the interested parties.

Parent5446 added a comment.Via ConduitJun 2 2014, 4:00 AM

Are there screenshots of the bug caused by the patch? I'm confused as to what the problem is. (Well, in reality, I never really understood the RFC to begin with, but if there was a visual it'd help me out a lot.)

(In reply to Rainer Rillke @commons.wikimedia from comment #12)

And MediaWiki.org is a wiki ruled by and for MediaWiki developers. I never
had the feeling being invited editing that wiki in any kind nor sharing my
incompetent opinion there. Apart from that, I've hard times not to compare
this course of action to some German or even Vogon bureaucracy.

This bug is for discussion about square-bounding boxes for thumbnails. If you want to discuss MediaWiki's RFC process, please use the mailing list.

Also, on a meta note, I'm shifting this bug to MediaWiki core, since it is a core change. Feel free to revert if there is a compelling reason against this categorization.

Rillke added a comment.Via ConduitJun 2 2014, 9:05 AM

(In reply to Tyler Romeo from comment #15)

Are there screenshots of the bug caused by the patch?

It was an intentional change...
http://imgur.com/a/iRTEZ#0
First 2 images before this patch was applied. Following 3 screenshots with patch applied

This is just an example. Other examples includeinfo box images that are now too small. Please provide an upgrade stategy to the communities before re-applying this patch.

If you want to discuss MediaWiki's RFC process, please use the mailing list.

The question was about adequacy of a MediaWiki RFC process for this particular change.

I'm shifting this bug to MediaWiki core, since it is a core change

It was. However, C. Scott Ananian needed to implement this change also in Parsoid; consequently shifted the component after Comment 4.

cscott added a comment.Via ConduitJun 2 2014, 2:40 PM

Yes, I should really have opened a new bug for the Parsoid component of the change after it landed in core, rather than shift component. But that's moot now.

Parent5446 added a comment.Via ConduitJun 3 2014, 1:00 AM

(In reply to Rainer Rillke @commons.wikimedia from comment #16)

(In reply to Tyler Romeo from comment #15)
>Are there screenshots of the bug caused by the patch?
It was an intentional change...
http://imgur.com/a/iRTEZ#0
First 2 images before this patch was applied. Following 3 screenshots with
patch applied

Thanks! Much appreciated. I can see where the concern is coming from.

Rillke added a comment.Via ConduitJun 4 2014, 7:54 PM

C. Scott Ananian, is it possible having a link to or additional thoughts about why it is WONTFIX'ed now?

cscott added a comment.Via ConduitJun 4 2014, 8:34 PM

The title of this bug is "Thumbnails should use a square bounding box by default". We don't plan to actually do that anymore, hence WONTFIX. I'm sorry if the resolution was confusing.

To quote gwicke, who expressed it better than I:

I think we missed one of the use cases that the bare 'thumb' is currently
used for:

  1. thumb of a reasonable size, respecting the thumb size user pref: this is what the bounding box change tried to improve
  2. column-aligned thumbs, respecting the thumb width user pref: this is what was lost in the bounding box change

    I think it would be helpful to engage the community to learn more about their current use cases, and look for opportunities for improvement together.

    In the 'thumb' case this could for example lead to a new, more semantic solution for use case 2), perhaps with a new 'column-thumb' image type. Once we have found a new solution for existing use cases & editors have switched to it we can revisit the bare 'thumb' behavior in order to better support use case 1).

So, basically: we were trying to solve a problem for gallery users and n-wide image layouts, who didn't want unbounded height, and for naive users who wanted a default sizing option that "just worked", no matter how tall your image was.

However, we missed the use case of "a aligned column of images" which was in widespread use in a number of projects. In accordance with https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle we promptly reverted our BOLD change.

It is possible that we will eventually revisit the issue, as gwicke mentions, but not until after we've got a solution for the existing "column of images" use case. And even then it's not clear that changing the default behavior of 'thumb' will be the correct behavior. The currently mooted proposal is some mechanism to add better semantic classes to images, so that a project can define a stylesheet in Common.css for "image taking up one column width", "full width images", or something similar. There's no definite proposal yet, just vague ideas.

So this bug is being closed as WONTFIX. If/when we have bright ideas for semantic classes for images, there would be a new RfC/bugzilla and it would be announced in the weekly Tech News (https://meta.wikimedia.org/wiki/Tech/News), which has been suggested as an appropriate cross-project forum for issues of this sort.

Note that bug 63904 remains open, which proposes changing the way 'upright' images are sized. In that bug there are comprehensive statistics on image option use which show that changing 'upright' should be a much less invasive change. But comments/participation on that issue are welcome. I will certainly push the 'upright' change to Tech News for discussion before actually merging it.

Bug 35756 is also open, which proposes a new syntax for cropping an image to an exact box. I think this is probably an alternative solution to the gallery issues, when consistent image sizes are wanted.

I hope this has answered all your questions.

Nemo_bis added a comment.Via ConduitJun 12 2014, 7:12 PM

Speaking of use cases.

(In reply to C. Scott Ananian from comment #20)

To quote gwicke, who expressed it better than I:

> I think we missed one of the use cases that the bare 'thumb' is currently
> used for:
>
> 1) thumb of a reasonable size, respecting the thumb size user pref: this is
> what the bounding box change tried to improve

Another request related to that is bug 7003, which also discussed this:

[...] bug 63904 remains open, which proposes changing the way 'upright'
images are sized.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.