Hey! How can I make it so that the template is not displayed in this block? Or so that it has a different name. The Russian wikipedia uses 'ambox' templates to display Featured articles.
Look at the bottom of this page: ru:Иль-Гази_бен_Артук.
Talk:Reading/Web/Projects/Mobile Page Issues/Flow
About this board
 | This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page. |
@OVasileva (WMF) can you help me plz :)
@Iniquity is this an issue on both mobile and desktop, or just desktop? It seems like the link you provided is for desktop.
@AHollender (WMF), hi:) I have filled: https://phabricator.wikimedia.org/T282984
- hi, am on Mobicel X4 mobile phone. Chrome 87.0.4280.141. browser..
need help with tech problem ..please advise.. Gfigs (talk) 07:32, 18 January 2021 (UTC)
One question that has never been answered: Does it actually matter if readers see these maintenance templates? The hope has always been that readers will see a {{Copyedit}} template, and be inspired to click the edit button. I'm not sure that it actually matters for typical readers. There are a few things that might matter under unusual circumstances (e.g., you might want to see the copyvio warning if you're planning to re-use the content), but overall, displaying these notices to logged-out readers might be a complete waste of time. I don't think that asking readers whether they were glad to see the notice will actually get at the real question: Does seeing it actually change their behavior (and not just what they say about what their behavior might be, while someone's asking them leading questions about whether it would change their behavior)?
@WhatamIdoing - we will be A/B testing these changes to see their effect on the user behavior. We will be looking at clickthrough to the issue modal to see if it increases with the changes and also to see if people tend to view extra details on more severe issues. We will also look to see if the changes have any impact on mobile edits. Additional details can be found in phab:T191532, but I'll also add a note on this on the project page as well.
Thanks. I hope that you get actionable results.
I do believe that at least alerts to lack of references and other quality or maintainance issues of the article should not be hidden from IP-users.
They need the info to help them assess the reliability of the article and might want to contribute towards an improved article quality.
Hiding what we display for desktop users as a matter of course from users of another platform feels completely arbitrary and lacks any reasonable justification.
I believe that most readers are able to identify the presence or absence of references for themselves.
On the real question, if you believe that the maintenance template is to encourage maintenance (i.e., it's not a disclaimer like de:Vorlage:Gesundheitshinweis, but a message asking the reader to please improve the article), and if those messages don't work in identifiable circumstances, then it's logical to quit sending them in those identified circumstances.
@Tbayer (WMF), I just read your comment at phab:T200794. It looks like making these banners more visible increased the number of people reading them during the four-week study, but it decreased the number of people editing the article by ~5% at the English Wikipedia.[1]
Will you be watching this long-term? It is not unusual with a UI change for everyone to click on it once or twice to figure out what it is, and then to ignore it afterwards. Consider, e.g, Facebook when added links to Wikipedia articles about the newspapers to their news feed. Everyone expected a spike in page views, but my spot check indicates that the October 2018 page views for those articles seem to be the same (or even slightly lower) as the October 2017 page views. The spike came – and went.
So what we've got now is a ~4x increase in reading the banner, when the banner was newly visible, but will that increased rate be sustained, or is that a temporary spike that appeared and then left?
This matters. The communities could decide that 5% fewer edits is okay, if 1% of readers are getting more information about how Wikipedia works. That could be a lose-win combination that we decide to accept as a tradeoff.
But if that 1% drops back down to the previous miniscule level, then we're left with (1) fewer editors, (2) no additional information, *and* (3) a more cluttered interface. That sounds like a lose-lose-lose result.
[1] It is not hard to hypothesize a mechanism for this: "Oh, look, they already know about this problem. I don't need to fix it, then."
@WhatamIdoing As noted in the comments you linked to, those were not yet the final results for the entire "four-week study", but preliminary data quickly queried before the end of the experiment, and we'll publish a report soon with the fully vetted results for the entire timespan, including an assessment which of the changes were statistically significant.
"It is not unusual with a UI change for everyone to click on it once or twice to figure out what it is, and then to ignore it afterwards" - yes, that's called a novelty effect, and we anticipated that to occur (see e.g. the task description of T200792). However, we also usually assume that for such a fairly simple feature, they don't last longer than a day or two (for the individual user). This is supported by results from the page previews A/B tests. Still, this is a good point and I'll be plotting the time series of the clickthrough rates for the 4+ weeks we have, to see if they show a decay over more than just the initial few days.
BTW, are the details of your Facebook pageviews analysis published somewhere? I'm curious how you controlled for other factors and trends that may have influenced the traffic to those pages in October 2017 and October 2018.
You are being very generous when you call my spot check an "analysis". :-) I didn't spend more than 10 minutes checking, the pages checked were non-random (i.e., newspapers whose names I could remember offhand) and I controlled for nothing. But here's another spot check, with 10 newspapers and the same results (you'll have to switch the dates to the other year to compare them; I was looking at the total average page views for all articles combined). Here's another, this time with all the papers being "The Times" from different cities. It just seems to be very steady.
Well, using the public data available in the pageviews tool is reasonable for a spot check to exclude the possibility that the Facebook feature increased views to those pages by several 100%, say. But it's hard to reliably detect smaller effects that way, for the reasons mentioned. In T191429we used geolocation and referrer data to narrow it down more regarding the initial impact. If there is interest, @MNeisler (WMF) might be able to re-run her queries from back then, to see where the Facebook-referred US views to the six articles from F16923024 have returned to pre-rollout levels. Anyway, offtopic here ;) but feel free to follow up on the linked task.
Please forgive (and redirect) me if this is not the most appropriate place to bring this up. One of my long-standing annoyances is that if I am on mobile and am sent a "regular" (e.g.: https://en.wikipedia.org/wiki/Norwegian_butter_crisis) URL, the responsive magic works and I am silently redirected to the mobile URL (https://en.m.wikipedia.org/wiki/Norwegian_butter_crisis) appropriately.
The problem is, this only works in one direction: Desktop -> Mobile. I'm often using a desktop browser and often find myself looking at the mobile experience because the person who shared the page was on a mobile device. Why does the responsiveness not work this way?
Hey — thanks for your question. One thing that comes to mind here is: the desktop site is a poor experience on mobile (so re-directing to the mobile site is easy to justify), whereas the mobile site on desktop is a fine experience (so re-directing to the desktop site is less obvious/necessary). However I do see your point. Two ideas that come to mind, in terms of how to handle this:
- default them to the desktop site but include a easy-to-find-but-not-annoying popup that says “switch to mobile view”
- leave them on the mobile site but include a popup that says “switch to desktop view”
Of course currently it is possible to get from the mobile view to the desktop view (and vice versa), however it perhaps could be made much easier given a case where you're using a mobile URL on desktop.
Regarding whether or not this is the right place for this comment, not exactly. It seems like there's a relevant conversation here: https://phabricator.wikimedia.org/T214998
Thank you for the reply and especially for the link to the conversation which certainly speaks to my concern. The only thing I would take issue with is your assertion that "the mobile site on desktop is a fine experience." While it certainly does not present the same usability problems as a mobile user encounters with the desktop site, it's (and I realize this is subjective) far from "fine" - controls exist that don't make sense in a desktop context, media is arranged oddly or hidden entirely from view, etc. But that's really only a minor quibble. I'll follow T214998 going forward, with thanks.
Ah yes, good point. I suppose I meant for the purposes of simply reading an article it is a fine experience.
See the screenshot below! Not sure if the reading team is aware of this issue or if it affects other wikis. Please let me know asap if we should fix this within the Spanish Wikipedia community or if we should wait for the general fix promised some weeks ago. Cheers!
Hey @Sophivorus thanks for reaching out. There is some technical documentation here that hopefully will give you sufficient guidance to making the Ambox template on es.wiki mobile-friendly: Making page issues (ambox templates) mobile friendly. It was written by @Jdlrobson who may be able to provide extra guidance.
I'm trying to find out how to implement this feature on Portuguese Wikipedia. I'd be grateful if someone could help me out.
We have a guide here Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Making_page_issues_(ambox_templates)_mobile_friendly
1) I think first thing to do is to put ambox class where it says class="noprint" https://pt.m.wikipedia.org/wiki/Predefini%C3%A7%C3%A3o:Ambox?action=edit
2) Replace ```style="width: 8%; text-align: center;"``` with ```style="width: 8%; text-align: center;" class="mbox-image"``` (style="width: {{#ifeq:{)
I think this will get you most of the way!
Thank you!
So when will this be done?
I am creating a module to ambox in ptwiki, and I am experiencing some difficulties in mobile version because there are too many things hardcoded in the extension. We need more freedom to choose the image, if the image are too big for mobile, so the solution is create a way to make the image smaller in mobile, and not change the image as the extension does today. It is also difficult to make tests, because some features only work in the main namespace, and we can not have sandbox pages in main namespace.
Hey Danilo.mac, my apologies for such a slow reply. I am a designer on the team that worked on mobile page issues. Regarding the icons: we decided to simplify the icon system for these "page issue" amboxes in order to help readers more easily identify them. The hope is that readers can quickly understand the severity of the issue, before reading the description of the issue. Part of the challenge with so many unique images is that it becomes difficult to keep track of them and quickly understand what kind of issue it is. Also, as you noted, many of the unique images from desktop do not look good so small on the phone.
I hope that information is helpful to you. If you have further technical questions I suggest reaching out to User:Jdlrobson (https://en.wikipedia.org/wiki/User:Jdlrobson).
Is there any support for having mobile page issues on external wikis? Honestly, this seems like something that would be beneficial to a number of wikis that are powered by MediaWiki, not just those ran by WMF.
Well the good news is that hopefully you wont't need to do anything special for page issues on mobile! Wikimedia wikis have a history of being predominantly desktop-focused and created by numerous volunteers with various skill levels over years of development. If you have a wiki and you're wanting to follow best practices for mobile content – including notifications of issues with pages – take a look at some documentation we have that might help. Basically don't use tables for displaying information and TemplateStyles might help with mobile-targeted styling.
Recommendations for mobile friendly articles on Wikimedia wikis
Hi everyone.
In Japanese, many are translated. There are parts that have not been tagged. Also please give us a translatable tag below as well: Recommendations for mobile friendly articles on Wikimedia wikis. This document seems to be important for actual efforts. If Japanese documents are prepared, Japanese version templates will change as well.
I finished translating to japanese, most of the important documents.
Wow, thank you for you help with this.
I think this project is a very necessary improvement for usability improvement of mobile.
Question
What does MobileFrontEnd read? What do we need to prepare in Japanese Wikipedia?
For example "hide-when-compact" class.
- MobileFrontEnd determines the class name to be read. I can read like that. If this is correct. We will use a class with a fixed name in a template.
- common.css requires a class name in each wiki. In order to hide this we need CSS designation for each wiki. I do not understand this part. Or, we do not need to edit common.css (etc).
I think you have the first part correct. Use the class in templates to control what appears in the mobile view. I'm not sure on the second.
@Jdlrobson could you help with this question?
> ommon.css requires a class name in each wiki. In order to hide this we need CSS designation for each wiki. I do not understand this part. Or, we do not need to edit common.css (etc).
I'm not 100% sure on the context here, but if we are referring to Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Use_standardized_class_names_in_HTML_markup_for_components_in_templates_across_projects the word "common" here is more to do with using a "standardized" class name (not common.css). One challenge we have with standardising displays across wiki is the class attribute usage in HTML markup.
For instance
<div class="m-elephant"></div>
In Chinese/Japanese might be
<div class="m-大象"></div>
To avoid having to localise class names, we're attempting to standardise on a single class across all the wikis.
So in the above case if m-elephant is the "standard", the markup for Japanese/Chinese might become:
<div class="m-elephant m-大象"></div>
Thanks, CKoerner, Jdlrobson.
I try using unique class names. I will experiment when I have time. It seems to be activated just. : Tech/News/2018/51
To avoid complicated clutter. It would be better for MobileFrontEnd to determine a single unique class name. Furthermore, it is easier when MobileFrontEnd outputs the corresponding CSS.
"m-elephant" is OK as "m-elephant".
HTML and CSS are originally in English. We do not need to use kanji for this. The use of kanji is not practical.
sorry for adding to the confusion. This is exactly what we are doing. I wasn't suggesting to use kanji. I was trying to explain the idea that in certain wikis you may want to use both classes.
To provide a more concrete example hatnotes in german wikipedia do not use the .hatnote class in Template:Begriffsklärungshinweis but have classes "noprint navigation-not-searchable". The germand could use the hatnote class along with those existing classes and attributes to become more mobile compatible
E.g. "noprint navigation-not-searchable hatnote"
It could also use a class begriffsklaringshinweis if it wanted to but that would be ignored by Minerva skin.
I am a user who used to view articles from my mobile. I haven't yet tried to edit wikipedia through it. I have recently opened wikipedia from my mobile phone through Google Chrome browser. I then took the 'view history' page of a random article. I then tried to thank an edit done by a user. In the text that appears ie. 'Publicly send thanks?', I am seeing it in a too low font. I mean the size. So I suggest you to increase the font size for that specific text including the buttons thanks and cancel. All these changes needs to be made only in that confirmation menu.
Just for posterity, I replied on English Wikipedia and created a task for you. :)