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.
The very bad idea is to change element order for mobile view. Loosing presentation control! Not all wikis are wikipedias, or have articles! -- ◄ David L • discuter ► 19:02, 15 June 2024 (UTC)
The "Limit number of images in a page" section says "Ideally, a page should have no more than 100 images (regardless of how small)." What is the logic behind this recommendation?
This relates to the prior statement Because the mobile site lazy loads images, articles with large numbers of images will timeout on mobile. The number of round trip requests between the browser and the servers to fetch the images becomes a performance issue.
But why 100, and not 75 or 500? Is it just an arbitrary selection?
I would guess it was a relatively arbitrarily chosen number, but was probably at least informed by some experimental testing. The mention of 10,000 images in the same area makes me think the author was thinking about orders of magnitude when giving the advice. This is all speculation of course by me.
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.
The provided examples do not work. The ambox class seems to trigger javascript only when applied to table elements, not divs. Moreover, a second requirement is to include text inside an element with mbox-text class, though it is not even mentioned here. Finally, mbox-text-div is supposed to ensure everything looks fine with CSS. But then again, I don't see the point of recommending to leave other elements outside of mbox-text-div. Those would still partially appear on mobile in a crappy way which could confuse the reader. Either I have misunderstood something or the examples are obsolete and need an update.
I think you might be right but that shouldnt be the case.
I'll talk to the team about updating this line of code: https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/pageIssues.js#L124
I've submitted a patch to fix this problem. Amboxes do not need to be tables: https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/488191 Not all amboxes are tables
Thank you. However, it seems we are having delays or something? As you can see here, JS is still working only on tables. I don't understand the reason, given that the patch looks merged.
Sorry for the confusion. We deploy Tuesday through to Thursday. This change should be live on all wikis by Thursday provided everything goes to plan.
I've just checked the result and found out that this selector specifically points to td elements. Without those declarations, icon and learn-more link leak out of the div.
Looks like this can be generalised. What selector should I add?
Would the following address this?:
.client-js .ambox > div {
}
Can you point me to some examples or the Template for which this is not working?
If you can you can also use Extension:TemplateStyles to add the position relative? e.g. scoping to .skin-minerva ? Long term, we'd like to remove these styles in the codebase and rely on definitions within the template so that might be the best solution here.
Sorry, I've been busy and I forgot to reply. Here's the examples. The first one is the expected result generated with a classic table, while the second one shows the issue. At the bottom I've transcluded Template:Tmp/Sandbox which is designed via TemplateStyles as suggested (see it:Template:Tmp/styles.css). Looks good to me. Considering your plans, I suppose we should go ahead with this solution then. EDIT: since I'm going to delete the test page on it.wiki, I've copied the examples here just in case.
What does that "ambox" word mean in English? My dictionary doesn't know. On cswiki we already use the class/class prefix "labelced", which could be translated to something like "banner" in English. It would be really inconvenient to rename or add hundreds of classes to prefix "ambox" if we already use "labelced" (transl. "banner") everywhere.
"ambox" is an abbreviation of "article message box". On enwiki there's also "tmbox" ("talk-page message box"), "cmbox" ("category message box"), "imbox" ("image message box"), and a few others.
I see. On cswiki we have got "cedule" template ("labelced-page" class) for articles and "cedule diskuse" (resp. "labelced-talk") for talk pages. It would be much easier to set somewhere our prefix than change things like:
labelced-image -> labelced-image ambox-image
labelced-content -> labelced-content ambox-content
and so on...
Dvorapa I've love your feedback on https://phabricator.wikimedia.org/T206177 I've been pushing for us to use some more neutral language that's not based on the English templates. While supporting different selectors per projects seems like over-engineering, it makes sense to encourage consistent markup across project that uses a common language e.g. `page-issue` / `page-problem` rather than `ambox`
I had to look it up, the ambox (or rather mbox) structure, classes and styling is 11 years and 2 months old now !
Basically the only thing that was added to it was hide-when-compact (terribly named btw).
Ah, there is also another task like that: T201975. BTW this page should be categorized and also linked from other how-to create-template pages on mw, shouldn't be? BTW the order of templates at the top differs on cswiki per our rules, where broken templates (.ambox) should be above info templates (.hatnote) and all the other content.
This addition seems to be more about making them more amenable to being hacked up by MobileFrontend or Mobile Content Service than about actually making them friendly for mobile devices.
A better long-term solution, IMO, would be for people to work on using TemplateStyles to make the mbox templates responsive so they wouldn't have to be hacked up. That way people using the desktop site on mobile and people copying the templates to other wikis would benefit too.
Consistent and predictable markup is important for skin developers.
Semantics and page structure is the problem here not "responsiveness styles".
We are making heavy use of TemplateStyles buy it only gets you halfway there.
IMO skin developers shouldn't be trying to hack up the content based on CSS classes any more than MobileFrontend or Mobile Content Service should be.
What do you all think about adding something regarding tools that folks can use to preview content for mobile devices. Assuming of course that some folks might not have access to a mobile device. Things like desktop Chrome's "Device toolbar" and Safari's "Responsive design mode". As a tech-savvy person I've learned of things like this over time, but for editors I don't want to assume folks know these are available. Letting them know of tools they might already have at their finger tips might make it easer for folks to act upon these recommendations.
We definitely need this. I don't think a mobile preview is useful, but certainly a browser extension could help here.
I've pitched a linter/editor warning built into MediaWiki along those lines here and am trying to win backing to make this a reality: https://phabricator.wikimedia.org/T200880
Just to throw another tool in the mix, m:User:Brion VIBBER/mobile-sidebar.js does a good job for some folks as far as I know.
I think it might be good to mention something about this as well.. Large tables are common and have issues that cannot easily be avoided.
Would it just be an FYI, to check table styles in a mobile device or do we have some thoughts here on how editors should approach tables?
Right now we add horizontally scrolling in the skin itself, and I think that solves most of the problems with tables without any input from editors so keen to hear what you think!
The guidance on the previous page seems focused primarily on (encyclopaedic) articles. I am wondering how this guidance would be structured if users are looking at Commons, Wikisources, Wikispecies, Wikiquotes, etc.
From a Wikisource perspective numbers of those points made are particularly problematic when replicating a published work. It would be useful to start a conversation about these issues to see how the more structured Wikisources can work better within mobile, countering the strictures of header fields, images, metadata, tables, etc.
It almost seems that the Wikisources may need a project of their own to address the issues and differences that exist with management of css, skins, and mobile views.
I think the guide should be universal to Wikimedia projects although admittedly with my experiences of using Wikipedia and Wikivoyage right now it likely to be catered to encyclopaedic (but things like table usage still apply!).
I'm happy to take a look at some wikisource problems and provide some recommendations. While wikisource has very clear mobile issues relating to the MediaWiki software itself, are there particular issues with user generated content that you can surface to me?
@Jdlrobson where is the best place to have an extrapolative point-wise conversation? In some senses the Wikisources have struggled, usually through enthusiastic transcribers with limited css knowledge, to come to terms with reliable means to replicate works, especially where some wish to have a facsimile. Even the page width of an original work in a book, or with pages with columns, don't migrate well to a computer screen.
Of the ten listed points, I reckon that the WSes probably break six straight out. Some examples (as I perceive the commentary)
We are possibly redeemable in some sense, as we do try to template code as much as possible, rather than work with raw code. We have also long been trying to not force widths, or specific sizes, instead using relative settings. Our enthusiasm and comfort to focus on the production of an old work inhibits and deters the conversion to a new world of underlying publication means. Probably many of us are of a generation that does not have that familiarity with css, style, class and elements. It has been hard enough to explain span and div, and to get users to get those working to avoid Linter issues. <shrug emoji>
There are sites with many recommendations for mobile devices in their, e.g. wikia staff's, portability.wikia.com . While many things aren't applicable to wikimedia largely because they have some extensions that provide functionality not available here (e.g. Portableinfobox), and vice versa (templatestyles), many suggestions apply to all wiki sites
Generally though, wikia chose to use the nuclear option of stripping most mobile inline styling because they probably didn't want to bother with all the hacks wikimedia uses. Still, it is better to reuse whatever developers deem useful rather than starting from scratch here.
Side note: Mediawiki itself seems to lack any the ability to facilitate mobile friendly websites. There is no preview for mobile, nor any default mobile detection or any special page highlighting mobile problems. It might make more sense to let this page be about mediawiki itself, and create a subpage about wikimedia specific sites (e.g. amboxes aren't universal). Considering that this is mediawiki.org and not wikimedia.org, most documentation should strive to be neutral.
That's fair feedback. This was indeed intended for a Wikimedia-content centric audience. Maybe meta.wikimedia.org might be a better place for this article?