This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility articles
This page is within the scope of WikiProject Usability, a group of editors promoting application of web and user-interface usability best practices in the presentation of Wikipedia content. For more information, such as what you can do to help, see the main project page.UsabilityWikipedia:WikiProject UsabilityTemplate:WikiProject UsabilityUsability articles
Let's flip the rows and columns. It's unlikely that devices will increase much if at all, and we hope that bugs won't, but the reality is that we'll probably find or register more bugs as time goes on, and there's no theoretical limit on the number of them. That argues for having bugs as rows, devices as columns. Before I (or someone else) does this, I wanted to ping
User:Suffusion of Yellow for your thoughts, and also ask if anyone knows of a "transpose wikitable" tool. If not, it might be worth writing one. (Such tools exist for html, and if there's a method of converting wikicode to html—maybe an extraction of the page source?—then perhaps we could apply that method.) If a tool isn't available, I might try my hand at a mega-regex, but if it works at all, it probably won't work 100% and would require a fair bit of manual post-processing, and would probably be pretty tailored to this example, and not scale well. The table isn't that huge, that a manual rewrite is ruled out, and perhaps that's about the same level of effort as the other solutions. (please mention me on reply; thanks!)
Mathglot (
talk)
19:52, 21 April 2021 (UTC)reply
Today we've had the umpteenth ANI report about this sort of situation (uncommunicative disruptive mobile editor), and it may be helpful to have an RfC to get global consensus for a standard protocol for administrators to follow in these situations. Something like this, but fleshed out better:
If an editor is making disruptive edits, and
their edits are tagged as mobile edits [we should be specific about the tags], and
they have made no discussion namespace edits [we should list those namespaces?], then
a non-template message should be posted on their user talk page, which can be done by anyone, and
if they continue making disruptive edits after the user talk page message is posted, then
any admin is authorized to partially block the user from mainspace or, if necessary, to indef block the user with the standard block message: ["mobile communication bug" block message], and any editor may request such a block at ANI if the above requirements are met.
I'm not sure what to "fill in the blanks" with and/or where to document this, or if we already have something like this documented somewhere. I feel like it's really just a restatement of blocking policy and these steps would apply to any disruptive editor, mobile or otherwise, but I envision something like where an editor can go to ANI with "requesting a
WP:THEYCANTHEARUS block" and then any admin would know how to respond to such a request (per global consensus).
Levivich17:43, 30 September 2021 (UTC)reply
I really like the block message since afaik isn't actually being used currently. Although I'd like to amend it and say something along the lines of if the editor in question genuinely appears to have not realized they were doing something wrong they may be unblocked as long as they behave appropriately (maybe a partial block would be better just to make sure they're being honest). ―
Blaze The WolfTalkBlaze Wolf#654518:34, 30 September 2021 (UTC)reply
It might make sense in step 4 to clear the user's talk page except for that one message, so the important stuff ("please communicate") is easier to see. I also agree with Blaze The Wolf; I think a standardised block message should try to direct the user to their talk page as a final effort in telling them how to communicate with other editors. –
Rummskartoffel21:00, 30 September 2021 (UTC)reply
Maybe collapse (with some conventional, and helpful collapse bar title) instead of clear the page. Many won't know how to access history, and a collapse would provide essentially the same thing, that is, leaving (almost all) screen space for the latest message. Also, some messages shouldn't be cleared (maybe not even collapsed?).
Mathglot (
talk)
16:38, 1 October 2021 (UTC)reply
Collapsing doesn't work properly in at least the Android app and the mobile web interface. In the Android app, collapsing does nothing (except pointlessly add the completely unformatted text "Extended content"); the collapsed text is just displayed as if the collapse templates weren't present at all. In the mobile browser interface, if the section header is inside the collapse template, the section is completely invisible and cannot be expanded; if the section header is not inside the collapse template, the only thing the template does is to put a box around all the comments inside the section. I have created an example at
User talk:Rummskartoffel/sandbox (
direct link to mobile web version). –
Rummskartoffel19:43, 1 October 2021 (UTC)reply
@
Sdkb:, also, to point 2: yes, please! I recently wondered about this factor at
this ANI case (perm). I was uncertain whether mobile user deafness could be involved in this user's non-responsiveness and ANI case, and linked this page. But, it turns out I was in error; as
Asarteapointed out, "their contributions are not tagged with one of the mobile tags", which I hadn't considered, and was dimly aware of, if at all. (Btw, is the converse also true: that is, if someone is editing on mobile, will that *always* be tagged?)
So, the user in the ANI case appears to be a non-responsive desktop user and so apparently does not fall into the scope of these mobile comm bugs, and I likely would not have responded there as I did had I known about the tags. So as a corollary, I'd like to see a section added to this page about the mobile tags, which would list and briefly explain them, including what can (and cannot) be gleaned from their presence/absence. If this is covered somewhere else already in detail, then maybe just a
WP:SS-style summary section with a {{Main}} or {{Further}} link; if it's covered somewhere, but only briefly, then maybe
slurp the whole section. (Pinging
Suffusion of Yellow who created the page and is the main developer, in case they prefer to keep this page lean and not branch off into related issues that are not strictly "bugs".) At a minimum, we should link to the tag information from here, and any new "mobile deafness" block consideration could point here, or link the same thing.
Mathglot (
talk)
19:57, 26 October 2021 (UTC)reply
@
Mathglot: If the "tag" row isn't enough, I have no objections to a simple "how to figure out if you're dealing with a mobile editor, and if so what kind" guide. I've just been to lazy to write it.
Suffusion of Yellow (
talk)
00:25, 30 October 2021 (UTC)reply
Glossary or definition notes
@
Suffusion of Yellow: or anyone, could we have either a brief Terminology/Glossary section or more explanatory notes, to explain some of the terms used here? For starters, in the boxed material above the table, I see the terms mobile web interface as well as mobile app, and I'm not entirely sure what the difference is, other than the latter must be an app loaded from the app store (iOS or Android, I assume), which implies, since there are two terms, that the former term is not an app. Is the first one what I get when I click 'Mobile view' regardless what device I am on? Likewise for all the table column headers; I'm pretty fuzzy on what's meant by Mobile Web (IP) vs. iOS (IP), and so on. I can guess for most of them, but I'd rather have an explicit definition (linked, if possible) and not guess, as clearly these are shorthand for well-defined terms. Thanks,
Mathglot (
talk)
16:33, 1 October 2021 (UTC)reply
"Mobile Web" refers to the interface shown by default when viewing Wikipedia in the browser on a mobile device. You're right to assume that's the interface you see when you click "Mobile view". Android and iOS, respectively, refer to the Wikipedia apps for those platforms. –
Rummskartoffel19:43, 1 October 2021 (UTC)reply
@
Greatder: You are talking about
this edit at
MobileCoin, I believe. Whatever you saw, it sounds like it could have been a whole lot of things, not necessarily related to mobile communication bugs. The known issues listed in the table are all easily reproducible. If the effect you saw can be reliably reproduced, please leave instructions on how to do it. Otherwise, there just isn't enough information here to proceed.
Mathglot (
talk)
10:04, 29 October 2021 (UTC)reply
"Read more" suggestions -- where do they come from?
(I don't know if this is a bug, but it seems like a usability issue; if I'm in the wrong place, let me know!)
I've gotten some very weird suggestions from the "Read more" sections. From
Cincinnati chili I got a suggestion for
Spaghetti Red, a similar dish that has been tagged for notability since 2011 and for zero sources since 2018 and which I've just AfD'd. Why would we want to suggest such a low-quality article to mobile readers? In Spaghetti Red's "Read more" our suggestions are
List of Japanese dishes,
List of Korean dishes, and
Luosifen. Other than being food-related these have zero to do with Spaghetti Red. Where are these suggestions coming from?
—valereee (
talk)
15:05, 12 November 2021 (UTC)reply
@
Levivich, thanks! Somewhere in the rabbithole that led me down I found a template to use to override the rando suggestions (which btw is {{#related: article}}, and you can specify up to three) that worked for a short while. Not sure why it stopped working again, but we're back to rando stuff.
—valereee (
talk)
19:02, 12 November 2021 (UTC)reply
@
Levivich, I'm sure I'm doing something stupid. Right now I'm getting Skyline Chili, Coney Island hot dog, and Cuisine of Kentucky. Which aren't bad choices except that the first two are already linked in the article. Refreshed and got Slinger (dish), Hot dog variations, and Cheese dog, also not bad choices. Refresh again, Cuisine of the Midwestern United States, Chili con carne, Chili dog.
—valereee (
talk)
22:00, 12 November 2021 (UTC)reply
Weird, it's still showing me those same correct articles every time I refresh. I'm not sure why the overrides are showing for me but not for you; beyond my technical knowledge. Maybe move this thread to
WP:VPT? (This page may not get the right eyes for this as this isn't a mobile communication bug.)
Levivich22:07, 12 November 2021 (UTC)reply
maxage=86400 means that your browser might cache the result for to 24 hours.
smaxage=86400 means WMF servers might cache the result for to 24 hours, even if your browser doesn't. (So clearing your cache won't necessarily change anything)
Hi folks! Just a note that edit notices are now shown in the Android app (when entering the workflow of editing the wikitext of any section). Also, talk page banners are also shown, albeit as a separate topmost "topic" in the Talk interface.
DBrant (WMF) (
talk)
17:51, 26 January 2022 (UTC)reply
So I just spent the last hour tearing my hair out trying to test if a "fixed" bug is actually fixed. I'd like to spend my time doing something else, or I'm going to say something I regret.
On your mobile device, either clear all cookies, or close all browser tabs, and open a new private tab. This is important. You may have left over session cookies, even if you're logged out, or even if you never logged in.
On your mobile deivce, go to
https://en.m.wikipedia.org/. Click on mainspace links until you find some article to edit. Do not click on anything that is not a mainspace link. Do not visit the desktop site. Do not visit this page. Do not attempt to view the history of any page, or do anything apart from read articles.
On your mobile device, make an edit to an article. A
WP:DUMMYEDIT is sufficient. A
WP:NULLEDIT is not. (This step of course will expose your IP)
On your desktop device, while still logged in, leave a message on the user talk page of the IP you recorded in step 2.
On your mobile device, attempt to edit the same page.
You should see a "you have new messages" alert.
This is all seems complicated, but it's really just the normal steps of "reader sees something to fix, tries to fix it, but breaks it instead, and you need to tell them that they broke it or they'll do it again".
Now I already know this works some of the time. So we can't just look for mobile IPs responding to talk page messages; that would prove nothing. Ideally as many people as possible should try this, and get an alert every time.
Suffusion of Yellow (
talk)
17:42, 2 May 2022 (UTC)reply
Indeed it does not work. A light yellow banner is visible on pages of every namespace except the article namespace. [android:ff/chrome] –
SJ +20:44, 2 May 2022 (UTC)reply
Thank you! @
Sj: Just to be totally clear, it doesn't appear even when you click "edit" in step 7? In mainspace, it's never supposed to show when you're just reading. (This is to avoid bothering the next person who got assigned the IP). You need to attempt to edit something.
Suffusion of Yellow (
talk)
20:53, 2 May 2022 (UTC)reply
Thanks again. What's happening here is that you're seeing the cached version, because your session cookies aren't set. So the banner should always show on uncachable pages (Special:Whatever), or pages that don't happen to be cached (e.g. obscure talk pages). But the talk page of TFA is probably getting lots of hits, so it's cached. Now successfully saving an edit is supposed to set session cookies. I don't know why it's not.
Suffusion of Yellow (
talk)
21:14, 2 May 2022 (UTC)reply
Ok, the following is replicable for me on chrome (ff, after a hiccup, now shows a banner persistently on all edits and talk pages, even on a new private tab):
Also noted: sometimes when loading a page, it will first show an older, more colorful (desktop-like layout, from before recent years' updates) banner at the top, and only after a second or so redraw the whole page w/ the smoothed modern mobile interface. Could there be a race condition w/ multiple style sheets for the same names rendering at different times based on [???]? –
SJ +21:28, 2 May 2022 (UTC)reply
Are you using your iOS devices' browser (probably Safari) or the Wikipedia iOS app? The table means "iOS" to refer to the app – browser users on iOS would fall under Mobile Web or Desktop, depending on which they use.
Rummskartoffel19:49, 21 June 2022 (UTC)reply
Ah ok. I'm using safari not the app. That would explain that. (I'm sure from the table that would be obvious to the more tech-literate, but not me!) Thanks.
DeCausa (
talk)
20:31, 21 June 2022 (UTC)reply
It may be obvious to some users, but there's nothing to be gained from it being hard to understand to anybody else, so I've gone and added "app" to the relevant table headers in an attempt to make it more easy to understand in future.
Rummskartoffel21:01, 21 June 2022 (UTC)reply
Duplicate notifications
There was a question at the Teahouse about someone recieving duplicate notifications relating to edit milestones. See
here. I'm not sure if there's broader applicability but I wanted to mention it since this is the page that's specifically about mobile communication bugs.
Clovermoss🍀(talk)03:12, 25 November 2022 (UTC)reply
Requested move 16 January 2023
The following is a closed discussion of a
requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a
move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
I'm not sure if that would be helpful. The current title is direct and IMO it was helpful in motivating developers and decisionmakers to work on the required improvements. "Communication bugs" is, in comparison, a vague unactionable complaint.
I would actually suggest removing the "DiscussionTools" column from the page (it was added somewhat recently:
[1]), I think it is distracting from the purpose of the page and it doesn't have the kind of issues that led to the creation of this page. If you want to keep the information, I think it could go as notes in the "Desktop" and "Mobile Web" columns, like the mentions of the desktop Minerva skin.
Matma Rextalk23:52, 17 January 2023 (UTC)reply
Nah. This page had a narrow scope of mobile comm issues. Keep the scope as that, and once they're fixed this page will be redundant, and that'll be great. Other issues can be covered on another page.
ProcrastinatingReader (
talk)
15:36, 18 January 2023 (UTC)reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I went ahead and removed the DiscussionTools column:
[2]. I kept the content in footnotes, although I'm not sure if that isn't too much detail… I hope that's okay, feel free to edit if not.
Matma Rextalk23:26, 1 February 2023 (UTC)reply
Mobile DiscussionTools deployment
Hi y'all – as people motivated to improve the mobile communication experiences, the
Editing Team thought you would value being aware of, and potentially participating in, a discussion about the proposed plan to make the
suite of mobile DiscussionTools available to everyone (logged in and out) at en.wiki the week of 6 March 2023.
Please feel free to ping @
Whatamidoing (WMF) or me if the above brings any questions to mind.
@
Suffusion of Yellow, as someone who has been key in improving the mobile communication experience, I thought you'd value knowing that the
Editing Team is planning to offer the suite of
mobile DiscussionTools as default-on features for people who are logged in and out at en.wiki next week.
In doing so, "Custom edit filter messages" and "Talk page banners" will become available on mobile talk pages.
@
PPelberg (WMF): Thanks for the heads up. I can confirm that edit filter messages now work (at least while logged in). But I see no talk banners. They're still hidden behind a "Learn more about this page" link, which nearly defeats their purpose.
Suffusion of Yellow (
talk)
20:55, 18 March 2023 (UTC)reply
Talk page banners on Android
It looks like talk page banners finally appear on the top and with different styling on Android, at least in simple cases. However, I’m not sure how this copes with more complicated cases like signed comments in the lead section, or when the fix has been released (a random task I found about this matter is
phab:T310801, but that doesn’t seem to be the original task nor does it link to it), could someone with more knowledge or confidence update the table? Maybe @
DBrant (WMF), who has commented about the Android app in an earlier section. —
Tacsipacsi (
talk)
17:37, 16 April 2023 (UTC)reply
@
Matma Rex: Thanks! I new it was in the works, but I didn’t realize that it has already been deployed and enabled. I randomly chose
Talk:5th Marine Regiment, and it displays a topic (rather than a header) in which the first comment contains the message boxes as well. Screenshots:
phab:F36955529,
phab:F36955530 (app version 2.7.50436-alpha-2023-04-06). By the way, the boxes being broken is not specific to this case, even talk pages whose lead section contains no comments lack box styles. —
Tacsipacsi (
talk)
14:46, 18 April 2023 (UTC)reply
Amboxes
@
Izno:I think amboxes deserve a place here. While they are indeed not as direct attempts to communicate as most of the others, I don’t think article message boxes are less direct attempts to communicate than talk message boxes, which are already listed, and they’re just a bit less direct than editnotices. —
Tacsipacsi (
talk)
01:56, 23 April 2023 (UTC)reply
If an ambox is missing, life will more or less go on. There is no threat of a sanction and certainly there isn't active communication for someone using these systems who ignores an ambox. This is my primary reason for suggesting it's not appropriate to put them on this list.
Izno (
talk)
15:26, 27 April 2023 (UTC)reply
[C]ertainly there isn't active communication for someone using these systems who ignores an ambox – it depends. In most cases, there isn’t, but for example if someone ignores {{in use}}, they may well get active (and even quite upset) communication from the person who got an edit conflict despite having been added the ambox. On the other hand, I don’t think we should even have that strict inclusion criteria; what harm does it cause if there are more rows in the table? —
Tacsipacsi (
talk)
08:01, 28 April 2023 (UTC)reply
I don't see why not. They're not that different from talk page banners or central notices in that they're alerting readers of something specific about the page content. The very fact they used to be hidden on MobileFrontend but not anymore is a testament to this being a "mobile communication bug".
Nardog (
talk)
17:48, 28 April 2023 (UTC)reply
You are invited to join the discussion at
phab:T341305. The title of the ticket is "Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements". A couple proposals have been made so far that lower the visibility of the user talk message orange alert bar. –
Novem Linguae (
talk)
20:45, 26 June 2024 (UTC)reply