Last modified: 2014-06-12 19:12:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65903, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63903 - Thumbnails should use a square bounding box by default
Thumbnails should use a square bounding box by default
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: C. Scott Ananian
https://www.mediawiki.org/wiki/Reques...
: community-consensus-needed, design
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-14 14:57 UTC by C. Scott Ananian
Modified: 2014-06-12 19:12 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description C. Scott Ananian 2014-04-14 14:57:18 UTC
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.
Comment 1 Gerrit Notification Bot 2014-04-14 15:41:29 UTC
Change 123683 had a related patch set uploaded by Cscott:
Use square bounding boxes for default-sized thumbnails

https://gerrit.wikimedia.org/r/123683
Comment 2 Gerrit Notification Bot 2014-05-21 22:18:02 UTC
Change 123683 merged by jenkins-bot:
Use square bounding boxes for default-sized thumbnails

https://gerrit.wikimedia.org/r/123683
Comment 3 C. Scott Ananian 2014-05-22 16:11:23 UTC
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.
Comment 4 C. Scott Ananian 2014-05-29 19:17:33 UTC
Landed in core; switching component to Parsoid to track corresponding patch there.
Comment 5 Tsui 2014-05-31 01:29:26 UTC
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.
Comment 6 James Forrester 2014-05-31 01:45:10 UTC
(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.
Comment 7 C. Scott Ananian 2014-05-31 01:55:00 UTC
@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.
Comment 8 C. Scott Ananian 2014-05-31 01:58:33 UTC
(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.)
Comment 9 DerHexer 2014-06-01 10:02:55 UTC
(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.
Comment 11 DerHexer 2014-06-01 10:45:16 UTC
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).
Comment 12 Rainer Rillke @commons.wikimedia 2014-06-01 23:15:46 UTC
(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.
Comment 13 MZMcBride 2014-06-02 01:55:00 UTC
Tim is reverting this change now.
Comment 14 C. Scott Ananian 2014-06-02 02:34:51 UTC
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.
Comment 15 Tyler Romeo 2014-06-02 04:00:19 UTC
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.
Comment 16 Rainer Rillke @commons.wikimedia 2014-06-02 09:05:34 UTC
(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.
Comment 17 C. Scott Ananian 2014-06-02 14:40:54 UTC
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.
Comment 18 Tyler Romeo 2014-06-03 01:00:54 UTC
(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.
Comment 19 Rainer Rillke @commons.wikimedia 2014-06-04 19:54:21 UTC
C. Scott Ananian, is it possible having a link to or additional thoughts about why it is WONTFIX'ed now?
Comment 20 C. Scott Ananian 2014-06-04 20:34:17 UTC
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.
Comment 21 Nemo 2014-06-12 19:12:45 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links