This is a really bad advice. Mobile experience is obviously important and we should make reasonable amends to make that experience better, but unless desktop version will have adjustments for mobile’s preferences, it is detrimental to desktop experience to put infoboxes or images after lead paragraphs (since it would look bad and inconsistent with most articles).
I don’t exactly know how to make this advice better other than drop it entirely.
I agree, this seems to be a really bad idea. Mobile skins should move them on their own if they'd like to do so, as it's already happening right now. If @Jdlrobson doesn't have anything against it, I would like to remove this paragraph.
"it is detrimental to desktop experience to put infoboxes or images after lead paragraphs (since it would look bad and inconsistent with most articles)."
Could you elaborate on this? Is the problem inconsistency (if so wouldnt a bot migrating all these pages address the problem) Or is this about where the infobox appears in desktop being impacted? (From what i can see the existing styling/positioning of infoboxes on desktop could be achieved with styles rather than relying on HTML order.)
While it's true mobile works around this, this code is one of the more complicated parts of MobileFrontend and comes with a cost.
if we were starting a new wiki i would strongly urge following this recommendation from the offset.
All these are recommendations, not rules and communities should feel free to show somehow which are supported. Maybe a subsection "implementation notes" is needed to highlight problems in the implementation of certain recommendations?
Both: it is natural for infobox to appear at the top on desktop and it is expected for it to be due to large amounts of articles across language versions to appear it that way on desktop. If infoboxes aren’t supposed to be put at the top of the article, they aren’t infoboxes anymore and they probably can’t look like infoboxes, really, and it would be more apparent in smaller articles.
I get that these are recommendations, but this recommendation goes against all current Wikipedia design, so it’s bad that it’s there at all. Mobile complications should be accounted in some way (maybe with moving all section 0 above infoboxes), but desktop experience is still important.
I agree with Saint Johann. In desktop view, it looks super awkward to have Infoboxes that start after the start of the article, as they exist to present important data at first glanxe. Furthermore, there would be a weird gap in the layout above the Infobox.
I agree that we should do effectively this on mobile view, but this is a task for skins (in narrow mode - we should have responsive skins like Timeless instead of spearate mobile skins) and apps.
I dont understand. Infoboxes are floated to the top right so where does such a gap exist in desktop? Such a gap can be easily avoided with CSS. Lead paragraph and infobox can both be at the top on desktop provided the ordering is correct which it seldom is on enwiki.
> this is a task for skins (in narrow mode - we should have responsive skins like Timeless instead of spearate mobile skins)
Minerva is also a responsive skin. I think you are misusing the term here.
Timeless has exactly the same problem when viewed on a mobile phone - the infobox is at the top. So while MobileFrontend can reposition the infobox on our mobile domain it doesnt help people using Timeless or Minerva desktop skin on a mobile phone.
If we didn't have a mobile domain (and some wikis dont) we would have a big problem dont you agree?
This problem is not really solvable, due to how floating works (the top is pinned to where you place the floating element). Ergo, if you put the infobox after the lead, it will float below the lead instead of next to the lead. "Infoboxes are floated to the top right" is therefor incorrect assessment. Float has no concept of the 'top' of other content, it only knows it's own top.
I think the best is to move them in post processing, if need be using assistance of an additional marker tag to indicate potential valid document positions:<infobox-position/>. Javascript can be used to dynamically move/clone the section between eligible positions, if/when the viewport dimensions are changed.
This is a limitation you cannot fix with responsive CSS, because you want to change the order of HTML structure, in a space where such structure cannot be provided (multiple unannotated <p> siblings). At most with parsoid sections and maybe CSS grid, you could achieve something like this, but that seems too far fetched to me at this time.
> Minerva is also a responsive skin. I think you are misusing the term here.
I don't think so. A reponsive skin should deliver a good experience not only on mobile, but also on Desktop. And I don't consider this to be a good experience.
> Timeless has exactly the same problem when viewed on a mobile phone - the infobox is at the top. So while MobileFrontend can reposition the infobox on our mobile domain it doesnt help people using Timeless or Minerva desktop skin on a mobile phone.
We could just reposition the infobox in the skin if the screen is too narrow to display infobox and page content next to each other. Ideally, this shouldn't depend on mobile/desktop, but just on screen width. Timeless changes it format as well if the screen is narrower. I agree that this doesn'T directly solve our infobox problem. There probabaly should be a way for skins to detect infoboxes and handle them separately (Multi-Content Revisions might play an important role here.)
> If we didn't have a mobile domain (and some wikis dont) we would have a big problem dont you agree?
Actually I'm not entirely sure what we need it for. Can't we recognize mobile devices in a more dynamic way?
> Can't we recognize mobile devices in a more dynamic way?
No, not while also doing things like modifying the content to make it fewer bytes in the initial view, use structured sections, use image lazy loading and modifying the html structure.
> And I don't consider this to be a good experience.
Hmm, infoboxes used to float in non-narrow (aka 'tablet') layout for minerva. Seems like something was changed here recently.
<edit> ah never mind. That's a table with a float statement, it's not an infobox.
> I don't think so. A reponsive skin should deliver a good experience not only on mobile, but also on Desktop. And I don't consider this to be a good experience. A responsive skin simply means the content adapts at different displays (https://www.smashingmagazine.com/2011/01/guidelines-for-responsive-web-design/). Thus by definition both Minerva and Timeless are responsive skins.
"A responsive skin should deliver a good experience not only on mobile, but also on Desktop" - exactly and exactly what this article is about! Lots of our content is made for desktop. The Minerva skin primarily caters for mobile "readers" (not editors who prefer to use desktop skins on mobile) so has to work hard around these for its main audience, sometimes at the minor cost of desktop experiences like this. In the example you give, the infobox is not floated on Minerva -but that's exactly why this page exists - that's user generated content that hasn't been made mobile friendly (in this case it looks like it was wrapped in an element #Vorlage_Dieser_Artikel) and the software can't save it! In Timeless on a mobile device the experience is also not so good - it is at the top of the page and I have to scroll 5 screens to get to the content. This is what the recommendation is trying to improve :)
If the existing recommendation is not the best one, let's find a better one! The fact is that if the infobox is at the top on mobile we push down an important summary of the article.
@TheDJ in mobile we rely alot on flexbox,I had thought this would be addressable using flex order?
PS. The Germany article MGChecker posted has 2 clear problems - it uses a table, and uses a float as an inline style. Both Timeless and Minerva hack around this with mixed results. How do we make those problems visible to editors and thus get them fixed?
I wasn’t exactly taking in mind German Wikipedia since it’s quite indifferent to infoboxes as templates (all other wikis have more or less same template and design for them, deWP doesn’t). I don’t have the exact solution for this type of problem (I suggested flex order sometime ago but lead paragraph would still have to be wrapped programmatically), I just wanted to emphasise that the current solution suggests a thing that isn’t done pretty much everywhere, and it is the only one to do so here.
I've revised https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles#Don't_put_infoboxes_or_images_at_the_top_of_the_wikitext to explain that MobileFrontend takes care of this and it's not practical for all projects. Does that seem clearer now?
What exactly was revised (as I see in history, some sentences were moved or expanded and that’s all)? This is still a controversial solution to suggest to any potential readers, and will no doubt cause conflicts if people will go on about this. It should be marked as controversial or requiring community discussions before going through outright, and this hasn’t been fixed anywhere.
