Topic on Talk:Recommendations for mobile friendly articles on Wikimedia wikis/Flow

Hello @Jdlrobson. I'm currently writing a French Wikipedia survey to ask the community's opinion on moving the first introductory paragraph before an infobox or image.

However, after submitting the draft, I'm thinking that it's a rather heavy modification of a long-established community practice, and one that could possibly affect the entirety of articles, i.e. more than two million articles. We could end up with articles with the usual pattern and others with the recommended pattern. Small chaos.

If the infoboxes of a WMF-hosted wiki use the standardized CSS class for infoboxes, is it worth making such a change? Thanks.

We provide code to move the infobox below the first paragraph. I don't see this going away any time soon as many projects like you say have established practices around not doing this. I do think it's worth doing for new articles (I do that when I edit articles for examples).

I do think it would be more important to use the standardized CSS class for infoboxes in the case of French Wikipedia and would recommend focusing effort on that instead.

Hope that's helpful!

I don't want to sound like a creep, but an English Wikipedia contributor has reversed this order on the article about The Amazing Bubble Man, for example. So I don't know if proposing to put the infobox in the second part wouldn't cause new editorial muddles over the years for no reason at all, instead of keeping the order that already exists... Then, on this article was question of a personal initiative, maybe it would find more adherents with a survey.

For the time being, I'm really divided on the gain, especially if MediaWiki takes care of the paragraph move ad vitam æternam and that the feature is stable and amply sufficient. I really feel like I'm going to propose a major change for little benefit. Thanks for your opinions.

Let's put it this way - if you are putting the infobox at the top of the page you are introducing additional processing time on the server to do a relatively expensive operation of converting the HTML to a DOM tree and then changing that order, resulting in a slower rendering time on mobile. This can be avoided if the article has already put it in an appropriate place and for desktop there should be no visual difference.

From a personal perspective, I think the on-wiki policy is outdated and written for websites written in 2000 and should be revisited. This is not a dig on any wiki in particular, I think many of our on-wiki policies should be revisited through the lens of mobile e.g. Wikivoyage:Image_policy#Minimal_use_of_images comes to mind which doesn't make any sense to me as a MediaWiki contributor (since it doesn't seem to consider on mobile images are lazy loaded and that most people traveling use WiFi or data plans these days). Arguing policy requires specific skills and patient that I personally don't have :-).

It's not the purpose of this document to make policy change, only to express what the teams maintaining this code would recommend to any new projects that are starting out today to ensure their content is as mobile friendly and optimized as possible. (Hence why these are "recommendations" and not enforced in any way.

Thanks for the written clarification. It's easier to clarify when you can source the technical effects of community practices with WMF engineers comments.

"since it doesn't seem to consider on mobile images are lazy loaded and that most people traveling use WiFi or data plans these days", it's hard to keep up with MediaWiki without working on it, so just imagine for people who don't do this for a living... If I remember correctly, lazy-loading is more or less recent. So perhaps we need to look at the problem from several angles: what's the benefit of loading a large number of images? What is the impact for someone with a limited monthly data consumption quota, for example?

I personally like these recommendations as a base, but somehow, it lacks details of actual effects. I can quote the recommendations all I want, that it improves performance, but if it's not written in black on white about the implications of keeping the existing and what happens by not adopting the recommendations, it's hard to convince, because I'm not from WMF.