Talk:Recommendations for mobile friendly articles on Wikimedia wikis

Jump to navigation Jump to search

About this board

Sakretsu (talkcontribs)

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.

Jdlrobson (talkcontribs)
Jdlrobson (talkcontribs)
Sakretsu (talkcontribs)

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.

Jdlrobson (talkcontribs)

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.

Sakretsu (talkcontribs)

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.

Jdlrobson (talkcontribs)

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.

Sakretsu (talkcontribs)

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.

Reply to "Wrong examples"
Dvorapa (talkcontribs)

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.

Anomie (talkcontribs)

"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.

Dvorapa (talkcontribs)

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...

Jdlrobson (talkcontribs)

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`

Dvorapa (talkcontribs)

Good to know, thank you!

TheDJ (talkcontribs)

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).

Dvorapa (talkcontribs)

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.

Reply to "Own class?"

"Making page issues (ambox templates) mobile friendly"

3
Anomie (talkcontribs)

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.

Jdlrobson (talkcontribs)

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.

Anomie (talkcontribs)

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.

Reply to ""Making page issues (ambox templates) mobile friendly""

‘Don't put infoboxes or images at the top’

14
Stjn (talkcontribs)

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.

MGChecker (talkcontribs)

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.

Jdlrobson (talkcontribs)

"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?

Stjn (talkcontribs)

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.

MGChecker (talkcontribs)

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.

Jdlrobson (talkcontribs)

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?

TheDJ (talkcontribs)

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.

MGChecker (talkcontribs)

> 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?

TheDJ (talkcontribs)

> 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.

Jdlrobson (talkcontribs)

> 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?

Stjn (talkcontribs)

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.

Jdlrobson (talkcontribs)
Stjn (talkcontribs)

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.

Jdlrobson (talkcontribs)

Is there a ready made template I can use to add such a warning box?

Reply to "‘Don't put infoboxes or images at the top’"
CKoerner (WMF) (talkcontribs)

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.

Jdlrobson (talkcontribs)

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

Stjn (talkcontribs)
Reply to "Tools for mobile review"
TheDJ (talkcontribs)

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.

Jdlrobson (talkcontribs)

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!

Reply to "Advice for huge tables"
Billinghurst (talkcontribs)

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.

Billinghurst (talkcontribs)

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.

Jdlrobson (talkcontribs)

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?

Billinghurst (talkcontribs)

@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)

  1. Header fields, and trying to encapsulate meta data about a work itself, or its status as a transcription
  2. templating and inline formatting to represent the reproduced edition; though with template styles there may be opportunity to improve where we are
  3. tables as typeset in original publication, and similarly reproducing block center (though some of that relates to old browsers, and old ways, and with new css, there may be scope to improve)
  4. how to handle sidenotes in a published work, then translate that to either a wide screen where the sidenotes then overlap, or in a narrow screen where they take-up valuable screen space.

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>

Reply to "guidance is wikipedia-centric"
197.235.107.102 (talkcontribs)

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.

197.235.107.102 (talkcontribs)

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.

Jdlrobson (talkcontribs)

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?

Reply to "Don't reinvent the wheel"
AHollender (WMF) (talkcontribs)

Wondering if it would be good to recommend that for mobile (and in general) hatnotes should be grouped by type, as in:

Don't do this

{{page issue}}

{{disambiguation}}

{{page issue}}

Do this

{{disambiguation}}

{{page issue}}

{{page issue}}

Perhaps it could also make sense to give a recommendation around which order you should put hatnotes in? E.g.

  1. Disambiguation
  2. Redirect
  3. Page issues
  4. etc.
Jdlrobson (talkcontribs)
Stjn (talkcontribs)

Maybe we move the order? Page issues are blocks of texts and most hatnotes look like indented text on desktop, it should be reasonable to have page issues first and hatnotes second (unless there’s something about mobile version in that field that I don’t know).

TheDJ (talkcontribs)

Just for documentation purposes, the currently advised order for English Wikipedia article elements is documented in MOS:ORDER. Although I note that it specifies that hatnotes should be placed before page issue tags, which isn't strongly followed in my experience (likely because the indentation makes that look very unusual/cluttered).

Reply to "Group hatnotes by type?"
Shizhao (talkcontribs)
Jdlrobson (talkcontribs)

Could you elaborate on what you mean here? Are you asking if this template is mobile friendly?

Reply to "stub?"