Jump to content

Community Wishlist Survey 2022/Mobile and apps

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2022
Mobile and apps
17 proposals, 237 contributors, 530 support votes
The survey has closed. Thanks for your participation :)



Alert View

  • Problem: The android mobile app is unable to view "alerts" such as "need more sources", "tone", "reads like an advert", etc.
  • Proposed solution: Make the ability to view these alerts on mobile
  • Who would benefit: Mobile editors who look for alerts and try to fix them based on the alert
  • More comments:
  • Phabricator tickets:
  • Proposer: MrMeAndMrMeContributions 20:38, 16 January 2022 (UTC)[reply]

Discussion

Voting

Fix throbber problem on mobile view

  • Problem: On some pages containing graphs, when viewed in the Android app, the loading wheel continuously spins and does not go away. I don't know why it is there but it seems there is a problem.
  • Proposed solution:
  • Who would benefit: mobile view users
  • More comments:
  • Phabricator tickets: phab:T299536, phab:T299538
  • Proposer: Javiermes (talk) 04:01, 17 January 2022 (UTC)[reply]

Discussion

Javiermes, thanks for submitting a proposal. Could you share more details, like on what page you experience this, what OS, what app/browser and its version you're using? I'd like to clarify if the problem is only on your side. SGrabarczuk (WMF) (talk) 13:07, 17 January 2022 (UTC)[reply]
Thanks for answering! One of the pages in which I saw the throbber is https://es.m.wikipedia.org/wiki/Matrimonio_civil_en_Espa%C3%B1a (estadísticas) I use the Android App. Javiermes (talk) 15:14, 17 January 2022 (UTC)[reply]
I'm assuming you are referring to the graph ? The graph is an interactive element which is dynamically loaded upon demand (to save on resource usage). —TheDJ (talk • contribs) 15:22, 17 January 2022 (UTC)[reply]
Yes, I refer to the bar graph. So, the throbber has to stay over the bars all the time? Javiermes (talk) 18:19, 17 January 2022 (UTC)[reply]
No, but I guess the mobile apps (iOS doesn't even show the loader animation at all) simply do not support the graphs and have no good fallback. Definitely something that should be fixed, I have created a ticket for this problem. —TheDJ (talk • contribs) 16:06, 19 January 2022 (UTC)[reply]
Thank you very much TheDJ!! Javiermes (talk) 10:30, 21 January 2022 (UTC)[reply]

Voting

Show editnotices on mobile

  • Problem: Editnotices (messages shown above the edit window) are crucial communication tools. They let editors know important pieces of information, from requirements for adding entries to list articles to ArbCom revert rules and discretionary sanctions. However, they are currently not shown to mobile web editors at all. These users therefore often do precisely the things the editnotices warn against, creating general chaos.
  • Proposed solution: Implement functionality to display editnotices on mobile. Given the more limited screen real estate on mobile, it may also be necessary to create tools to help the community prioritize which notices are important enough to be shown there.
  • Who would benefit: All mobile editors, as well as anyone who's ever had to deal with a mobile editor doing something problematic because they weren't shown an editnotice
  • More comments: Previously proposed last year.
  • Phabricator tickets: phab:T201595
  • Proposer: {{u|Sdkb}} talk 22:41, 22 January 2022 (UTC)[reply]

Discussion

Courtesy pinging voters from last year: @Izno, Libcub, Kasyap, The wub, JPxG, Andrybak, Feroze Ahmad 2, L235, Jkmartindale, Kaartic, Ammarpad, Ericliu1912, PianistHere, DarkGlow, Wallyfromdilbert, GeneralNotability, MiltonLibraryAssistant, Bilorv, 2d37, SK2242, Empire AS, BoldLuis, Jh15s, LostMyMind, Mxtt.prior, Sashatrk, Pamzeis, Brewster239, Mihir Narayanan, Majavah, Some1, Matěj Suchánek, and Edu!: Please consider supporting again! {{u|Sdkb}} talk 07:16, 30 January 2022 (UTC)[reply]

Voting

Floating table of content on mobile web view

  • Problem: When you want navigate sections in mobile web view, you need to scroll up to close the current section you're reading, and close any open sections. This is cumbersome.
  • Proposed solution: A clickable floating TOC at the corner of the screen, exactly like the one in Fandom Mobile!
  • Who would benefit: All mobile web users
  • More comments:
  • Phabricator tickets:
  • Proposer: Neocorelight (talk) 23:41, 10 January 2022 (UTC)[reply]

Discussion

Voting

Links from history page in mobile advanced mode

  • Problem: Currently, in mobile advanced mode on a history page, it is just like a fully-featured history page on the desktop version as pointed out during the implementation of the feature. However, there is no link to the [read] page or [edit] page directly at all (for example, from this to this) which is incredibly inconvenient. The history page features were redesigned from the desktop version to fit the mobile web interface but the desktop version has the link above all of those features, and I think that's why these important links were forgotten.
  • Proposed solution: Add the links (read and edit) from the history page. Perhaps having something like "$wgPageName (edit)".
  • Who would benefit: All mobile web users using mobile advanced mode
  • More comments: The link that should definitely be added is that to the [read] page. This is a feature that is also available on the mobile web interface without advanced mode, so it makes no sense to not include it in advanced mode. I would be fine if the [edit] page cannot be linked since the history page is already quite crowded.
  • Phabricator tickets:
  • Proposer: Sun8908 (talk) 11:46, 13 January 2022 (UTC)[reply]

Discussion

Voting

Option to select non-Javascript editor on Mobile Web

  • Problem: If a user want to edit Wikipedia through mobile version of Wikipedia, there are currently two version of editors available: the standard one for mobile web browser, as well as a clear one that will be displayed when the JavaScript function of the user's web browser have switched off the JavaScript function of their browser or for the Wikipedia site.

The default web editing is a dynamic one based on Javascript, hence it create a number of problems:

  1. It's slower than the non-Javascript version especially on slower internet
  2. When users switch between browser tabs or apps for reference to edit Wikipedia article, there exist chance that the Wikipedia editing page will be cleared away from device RAM, making reload of the page necessary. And edits in such dynamic mobile editor could not be conserved after reloading the page, unlike the simple non-JavaScript editor.
  3. Pre-filled forms, like this community wishlist submission form, would not be accessible from the default Mobile Web editor.

Discussion

  • "It's slower than the non-Javascript version especially on slower internet" I seriously doubt this, if anything its faster as you are not loading a separate page for the editor. But it is less reliable perhaps like you indicate in 2 and 3. —TheDJ (talk • contribs) 16:27, 19 January 2022 (UTC)[reply]
    This point was taken from feedback among respondents from last community wish submission. I do not regularly access internet over like GPRS/ADSL/satellite in person to say for sure the slower speed is actually a consequence of the connection itself, as come to think about it the slower perceived could also be a result of the mobile device needing more computational resource hence time to handle/process/render the JavaScript editing interface than a simple textbox? C933103 (talk) 21:47, 19 January 2022 (UTC)[reply]
    Most likely this is perception indeed. The JS editor just puts up a spinner while it loads. When you click a normal edit field, you might have to wait for the response of the server, but since users are familiar with that, they ignore it. —TheDJ (talk • contribs) 00:43, 20 January 2022 (UTC)[reply]
    Humm, indeed. I tried editing the first section of "5G" article on English Wikipedia over my mid-range Sony Xperia 10 III smartphone through Wi-Fi tunneling via VPN on Chrome in Android 11, and the Javascript editor finished loading in less than two seconds while the non-JS one took more than three seconds to finish loading, after repeated round of tests. So this invalidated that rationale which I will strike out, although other reasons for such wish still exists.
    But if the animation is at fault for making people feel slower, then isn't it performing against what the animation supposed to be doing? I guess it is a deficit that need to file a bug report for on the phabricator? (Also, to anyone facing the same issue, I just found out the version of Mobile Chrome I use - 92.9.4515.159 - allow per-site control of enabling/disabling of JavaScript, which in turns can be act as a band aid fix to force the non-JS editor option on mobile wikipedia site, to anyone using the same browser and same platform as described.) (Edit: submitted to phabricator: phab:T299658.) C933103 (talk) 11:49, 20 January 2022 (UTC)[reply]
  • Question: is there something I can tack onto the URL to access the no-JS editor? Pelagic (talk) 23:30, 28 January 2022 (UTC)[reply]

Voting

Full page editing

  • Problem: There is no easy way to edit an entire page on the mobile site or mobile app. In order to make an edit involving multiple sections of a page, one has to either make those edits section by section or go to the desktop version of Wikipedia from the browser, both of which are inconvenient.
  • Proposed solution: Add a button to the top of the page that allows users to edit the whole page.
  • Who would benefit: People who want to edit Wikipedia pages on their mobile devices.
  • More comments:
  • Phabricator tickets: phab:T203151
  • Proposer: Anilyaris (talk) 19:04, 10 January 2022 (UTC)[reply]

Discussion

@Anilyaris: I tagged this as phab:T203151 - if that task doesn't describe what you are proposing here, please revert! — xaosflux Talk 19:39, 10 January 2022 (UTC)[reply]
I support this wish! Sietske (talk) 20:51, 10 January 2022 (UTC)[reply]
I'm useing mobile app too, and I think this problem needs to fix. So I support this wish. But is there who needs fix? ロックル (talk) 23:35, 10 January 2022 (UTC)[reply]
@Anilyaris: it is possible to edit a whole page, you just need to go to the page history and click the recent edit, and you will find "(edit)", click that and you can edit the whole page. Ctrlwiki (talk) 00:34, 11 January 2022 (UTC)[reply]
An ok workaround, but not intuitive. Still needs a good fix. Ɱ (talk) 04:50, 13 January 2022 (UTC)[reply]

There's another workaround: start editing a section (e.g. adding a character), then change the editing mode (i.e. source <-> visual), now you'll be editing the whole article. Anyway, I think the proposal is worthy and I'll support it. Alexcalamaro (talk) 18:54, 13 January 2022 (UTC)[reply]

I consider the lack of section editing in VE to be a bug, not a feature. Pelagic (talk) 22:24, 13 January 2022 (UTC)[reply]
I think VE can have section editing, but there is a lot of problems need to be solved. Thingofme (talk) 09:43, 17 January 2022 (UTC)[reply]

For a suggestion it need an adverting for page that have a lot of bits and for device of low income, because the app or the web browser can chash and in the case of web broser lose your changes. Emolga826 (talk) 13:20, 1 February 2022 (UTC)[reply]

Voting

Table sorting on mobile

  • Problem: Being able to sort tables is an incredibly useful feature, allowing for easier finding of information on lists and interpretation of data. Having sortable tables means content doesn't have to be duplicated within and across articles but organized differently. Mobile and app versions of Wikipedia still do not have this functionality. Many tables and articles have been merged because they presented the same content but table sortability made their duplication unnecessary, but mobile readers can only access the default sort.
  • Proposed solution: Add table sorting to mobile
  • Who would benefit: Mobile users
  • More comments:
  • Phabricator tickets: phab:T233340
  • Proposer: Reywas92 (talk) 17:49, 11 January 2022 (UTC)[reply]

Discussion

Voting

Watchlist in app

  • Problem: For signed-in user it would be nice to see their Watchlist in mobile app.
  • Proposed solution: Provide a watchlist (synchronized with web watchlist) for users, let them watch/unwatch current article.
  • Who would benefit: Signed-in users / contributors
  • More comments: My personal case: I read an article on my phone and want to add it to my watchlist to contribute later on desktop. I want to just press usual blue star on article. Accessing to my full watchlist from the phone would also be useful.
  • Phabricator tickets:
  • Proposer: Skirienko (talk) 08:39, 12 January 2022 (UTC)[reply]

Discussion

  • @Skirienko: I'm assuming you mean for the Mobile App, as the Mobile website already has this ? —TheDJ (talk • contribs) 11:53, 12 January 2022 (UTC)[reply]
    • Yes of course, I thought all this section is about mobile app (apparently it is not). I'll fix the proposition to be more clear.
      • Hey @Skirienko, thanks for submitting this proposal. Just so you knew why this wasn't clear at the beginning, there are three separate products. There is mobile web (the browser version) with the Advanced mobile contributions mode and there are apps. Do you mean Android or iOS app? SGrabarczuk (WMF) (talk) 03:34, 13 January 2022 (UTC)[reply]
      • Hey @Skirienko, thanks for taking the time to submit a proposal. The Android app currently has Watchlist. It was released in February 2021. If there is any way we can improve them, please don't hesitate to let us know on our talk page, or you can ping me directly. iOS is currently working on notifications and talk pages but I do know adding Watchlist is somewhere on their roadmap in the near future and they'll build on the feedback from the Android Watchlist feature. JTanner (WMF) (talk) 15:20, 13 January 2022 (UTC)[reply]
      • Hi, I supposed some kind of feature parity among main mobile platforms (iOS and Android). Yes, my only experience is on iOS and of course I would like this feature to be there. If Android already has it, good for them. Then it's time to add it to iOS also. At least we have one user requesting that. Skirienko (talk) 12:51, 25 January 2022 (UTC)[reply]
        Hi @Skirienkoand @Xaosflux, Last year I let you know this feature exist within the Android app, as I was the Product Manager for Android. I've recently become the Product Manager of both iOS and Android app, and have prioritized Watchlist among other things. I didn't forget this request and just wanted to provide the ticket you can follow T334212. A member of the team @RWambua-WMF will follow up with a link to the project page once its been created this week. JTanner (WMF) (talk) 00:44, 18 April 2023 (UTC)[reply]
        Hey @Skirienkoand @Xaosflux!
        First of all THANK YOU so much for continuously being involved in our ideation process! It feels awesome to be hearing requests from you. I'm Rebecca and I will be the product manager for this feature. We have come up with some early stage designs and are still discussing on the implementation. Also, I created a page for this: https://www.mediawiki.org/wiki/IOS_Watchlist. Please let's continue conversing as we work on this feature. RWambua-WMF (talk) 20:18, 25 April 2023 (UTC)[reply]

Voting

Categories in mobile app

  • Problem: Currently categories are only visible to readers when using the Wikipedia website. Mobile app users can't see the categories that articles have been placed in, or browse through the attached categories. When they are also visible in the app they could make for instance some Wikipedia lists abundant. Benefit from that is this would lower the amount of pages that have to be maintained with recent information.
  • Proposed solution: Display the categories that a page belongs to and allow readers to browse to those categories.
  • Who would benefit: Readers, community and Wikipedians using the Wikipedia mobile application.
  • More comments: Because of issues with Parsoid and/or the Mobile Content Service, readers may have to view category pages in the mobile web version, but still within the app. This is similar to what happens when viewing the history of the page, etc.
  • Phabricator tickets: task T73966, task T153980
  • Proposer: Melvinvk (talk) 01:20, 11 January 2022 (UTC)[reply]

Discussion

Copied from duplicate proposal:

  • I think that this would be a helpful addition.Dunutubble (talk) 23:39, 10 January 2022 (UTC)[reply]
  • I fully support this. There are multiple times I've had to load a page in my mobile browser and switch to dekstop view to access the categories. Thryduulf (talk: meta · en.wp · wikidata) 01:48, 11 January 2022 (UTC)[reply]
  • While these can already be enabled if you're logged in, I find it to be more convenient to have them enabled by default if you're not logged in. I fully support this. -BRAINULATOR9 (TALK) 02:08, 11 January 2022 (UTC)[reply]
    How do you enable them? I am logged in within the application, but on the bottom it shows read more and I have to switch to desktop view. I also don’t see an option in the settings of the app. Melvinvk (talk) 02:22, 11 January 2022 (UTC)[reply]
    They are not even in the mobile version for the browser, let alone the app while I'm logged in. Where am I supposed to mark a box to see them? Grüße vom Sänger ♫(Reden) 08:31, 11 January 2022 (UTC)[reply]
    Settings -> Advanced mode (mobile web). —TheDJ (talk • contribs) 12:24, 11 January 2022 (UTC)[reply]
    Helemaal bedankt! Grüße vom Sänger ♫(Reden) 13:11, 11 January 2022 (UTC)[reply]
    But (niet alleen voor jou) why, for f* sake, are there separate settings for my only account, why isn't this anywhere in my normal settings, where all such stuff belongs by default? That are my settings, everything that's not there is in an invalid place. Grüße vom Sänger ♫(Reden) 16:17, 11 January 2022 (UTC)[reply]
  • Categories belong there, at least for logged in users they should be available in all apps, be it classical browser, .m.-browser or app. Grüße vom Sänger ♫(Reden) 08:31, 11 January 2022 (UTC)[reply]
  • Fully support this. I've never understood why they're not there by default. Pichpich (talk) 20:04, 11 January 2022 (UTC)[reply]
  • Noting that the linked Phab tasks are only about the Android app. No tasks appear to have been created for the iOS app, however I assume it faces the same problem. That is, displaying the categories that a page belongs to is not difficult, but category pages don't themselves render properly in the app due to issues with Parsoid and Mobile Content Service (phab:T153980). So I think this proposal is OK to move forward, so long as voters know you'll be seeing the mobile web rendering of category pages. I have tweaked the proposal wording to make this more clear, which I hope is okay. I have just one concern: @Melvinvk: What do you mean when you say When they are also visible in the app they could make for instance some Wikipedia lists abundant. Benefit from that is this would lower the amount of pages that have to be maintained with recent information.? Thanks, MusikAnimal (WMF) (talk) 22:17, 12 January 2022 (UTC)[reply]
    It's about the app, regardless wich flavour of OS it run on. There is only the app running on different mobile devices, those subtleties should have no relevance for the fixing of bugs. Grüße vom Sänger ♫(Reden) 05:11, 13 January 2022 (UTC)[reply]
    "Those subtleties" matter when they start from entirely different programming languages between the three ways someone could see something on mobile (i.e. web, Android, and iOS). Izno (talk) 06:19, 18 January 2022 (UTC)[reply]
    Ain't iOS and Android just some different flavours of Linux? So just KISS, and don't customize too much. Grüße vom Sänger ♫(Reden) 06:53, 18 January 2022 (UTC)[reply]
    No. Izno (talk) 18:48, 18 January 2022 (UTC)[reply]
  • Hey everyone, thanks for this rich discussion. One of the Android engineers built a prototype for displaying categories. Our designer will have a look at it once he can get through some of our talk page feature work. I expect us to have something out by June 2022 at the absolute latest. I can't speak for iOS but will definitely coordinate with them so it is easy for them to bring in the feature when the team has capacity. All that to say this is on the Android's team radar (and on our phabricator board). Please keep sharing your ideas of how you'd like categories to show up, and if you feel so inclined collaborate with us on Phab task T73966. Thanks again! JTanner (WMF) (talk) 15:46, 13 January 2022 (UTC)[reply]
  • I think categories should be made by the app developers, and waiting approval by Google and Apple. At this time it could mean for a bad way of viewing categories, but browsing categories, I think it's still possible. Thingofme (talk) 09:48, 17 January 2022 (UTC)[reply]

Voting

Simplify uploading on Commons mobile app

  • Problem: Current uploading takes four steps to upload. Only two (title and license) are essential.
  • Proposed solution: Convert uploading steps in to a single page: Title, description and license should be listed in one page. Categories and structured data should be requested only after the uploading starts.
  • Who would benefit: New mobile uploaders
  • More comments: Currently the uploading is slow and time consuming. At least the structured data input should be moved to last step. Categories can also be confusing for new mobile uploaders as the mobile interface does not even show categories.
  • Phabricator tickets:
  • Proposer: Vis M (talk) 08:34, 12 January 2022 (UTC)[reply]

Discussion

The repo for the Commons app is here. There's a group of volunteers maintaining it, you can create a new issue with your suggestions. -FASTILY 08:01, 14 January 2022 (UTC)[reply]

Uncategorized pictures are not very useful, that's why we strongly suggest to users to select relevant categories. Depiction search is much more powerful (and localized) than category search, that's why we put it first, as chosen depiction are used to suggest categories that otherwise would be very difficult to find. Good idea about uploading while filling metadata, I created an issue for that. Syced (talk) 09:48, 4 February 2022 (UTC)[reply]

Voting

Accepting donations from mobile apps

  • Problem: Allow donations from mobile apps distributed by Google / Apple.
  • Proposed solution: Donate to pay the fee from the mobile app via Google / Apple.
  • Who would benefit: Wikimedia Foundation, users without credit cards, especially Japanese
  • More comments:
  • Phabricator tickets:
  • Proposer: Sazanamiya (talk) 01:14, 11 January 2022 (UTC)[reply]

Discussion

For iOS we do support Apple Pay, but only in certain countries right now. It should be rolling out to others, including Japan, within the next few weeks. Google Pay is also something the fundraising team is planning to look into this year. And https://donate.wikimedia.org/wiki/Ways_to_Give has a list of various other donation methods that are available. Peter Coombe (Wikimedia Foundation) (talk) 19:10, 21 January 2022 (UTC)[reply]
@Peter: In the iOS app, tapping Support Wikipedia links me out to donate.wikimedia.org in Safari, where I could use my credit card. I think this wish is about allowing people to donate via an “in-app purchase”, to donate from funds they already have loaded on their Apple account? ⁓ Pelagic (talk) 23:41, 28 January 2022 (UTC)[reply]
You might need some market research to determine whether the “In-App Purchases” annotation in the App Store would deter some users from downloading the app. Pelagic (talk) 00:23, 29 January 2022 (UTC)[reply]
@Pelagic Okay thanks, in-app purchases would indeed be a different thing and sounds like it would need more work and collaboration with the app teams. I'll pass this wish on to our payments specialists. Peter Coombe (Wikimedia Foundation) (talk) 17:48, 1 February 2022 (UTC)[reply]

Voting

Load images in metered networks only on demand

  • Problem: The Android app can be used from a metered connection or from free WiFi. Some users may have a small quota on their metered connection.
  • Proposed solution: Allow load on demand of images (configurable) if on metered connection.
  • Who would benefit: Users with small quotas of metered network.
  • More comments:
  • Phabricator tickets: phab:T236637
  • Proposer: Error (talk) 18:32, 11 January 2022 (UTC)[reply]

Discussion

Is it really appropriate to use the Community Wishlist Survey to circumvent other people declining a task? This will likely just get archived or declined for the same reason the original task was. * Pppery * it has begun 19:40, 11 January 2022 (UTC)[reply]

view network connections
Allows the app to view information about network connections such as which networks exist and are connected.
This is for Android. For the mobile web version, it is a matter for the mobile browser.
--Error (talk) 09:42, 14 January 2022 (UTC)[reply]

Voting

Pending changes reviewing on mobile

  • Problem: It is difficult to review pending changes in the mobile interface. When there is a pending edit on a page, there is an "Accept" button at the bottom of the page, but there is no option to revert the edit. The only way to access the revert button is to change my skin from mobile view to desktop view.
  • Proposed solution: Expose the "Review this revision" dialog on mobile on diff views, just as you see when reviewing a pending change on desktop. This should include the "Accept revision" and "Revert changes" buttons.
  • Who would benefit: All mobile users who are pending changes reviewers
  • More comments:
  • Phabricator tickets:
  • Proposer: Ctrlwiki (talk) 00:18, 11 January 2022 (UTC)[reply]

Discussion

Ok, I've tried already the rollback at AMC and it works, but Twinkle and RedWarn rollbacks are not there. "Accept" is still the option if I want to review a pending edit, no "revert" option, even I switched from mobile to AMC. I've also tried Twinklemobile script to rollback an edit on mobile devices, but the author already said that the rollback links cannot be used. Thats why I hope more gadgets can be use on mobiles. Thanks. Ctrlwiki (talk) 05:29, 13 January 2022 (UTC)[reply]
@Ctrlwiki Unfortunately there is no simple way to make all gadgets work on mobile. They have to be designed for it. Would you like to reword your proposal to introduce a mobile version of Twinkle, RedWarn, or some other gadget? Please select one :) Thank you! MusikAnimal (WMF) (talk) 23:51, 20 January 2022 (UTC)[reply]
I like RedWarn, unfortunately RedWarn isn't gadget. I hope you can also fix the review options that I've mentioned above, I am very active on reviewing pending changes using RedWarn. Ctrlwiki (talk) 23:55, 20 January 2022 (UTC)[reply]
@Ctrlwiki We can work with RedWarn developers to help make a mobile version, or we could work on reviewing pending edits. But not both. Pick one specific problem and describe it in detail. Thank you! MusikAnimal (WMF) (talk) 17:30, 26 January 2022 (UTC)[reply]
@MusikAnimal (WMF): I would like to review pending edits using mobile. Cause, since I've got my permission to review pending edits, I usually change my mobile view to desktop view, and after that, I need to zoom in my screen to tap the revert button if I want to revert the pending edit, cause revert button are very small when using mobile desktop view. Accepting pending edits is very easy using standard mobile view (not AMC), but revert button is not there, only accept button, you must try you use mobile if you want to see it. That's what I want to improve in mobile view, adding additional revert button. Benefits of it are not only mine, but all of reviewer that are using mobile devices. Sorry, I'm not good in explaining cause I'm not a good English speaker, I'm just trying to explain it in English so you can understand. Additionally, in mobile version, if there is a pending edit, there is a button called "unnaccept" and it will only appear after you accept/review the pending edit, but during reviewing, only "accept" button is visible. You can really understand the problem if you are using mobile. Ctrlwiki (talk) 07:21, 27 January 2022 (UTC)[reply]
Okay! Per our discussion I have reworded the proposal to focus on bringing better support for pending changes reviewing to the mobile interface. Thanks, MusikAnimal (WMF) (talk) 19:21, 27 January 2022 (UTC)[reply]

Voting

Interlanguage linking from a mobile browser

  • Problem: Pages on Wikipedia can be linked-to equivalent pages in other languages by clicking ‘Add interlanguage links’ from the sidebar. But the mobile version does not have this feature. So whenever you create a page from mobile, you have to go to desktop version every time to make interlanguage links.
  • Proposed solution: Add ‘Add interlanguage links’ option
  • Who would benefit: All mobile editors
  • More comments:
  • Phabricator tickets:
  • Proposer: —Yahya (talk • contribs.) 12:39, 14 January 2022 (UTC)[reply]

Discussion

Voting

Better warning display for mobile users

  • Problem: Perennial proposal, on many venues. We need to resolve the issues raised in en.wiki THEYCANTHEARYOU. Mobile users must be able to see some kind of actual notification that "a real human being is a bit annoyed that you just replaced the page on Richard III with the word horse, and has left a message that you should read", not just a little red dot beside a bell.
  • Proposed solution: We need an orange bar of doom for mobile users, ideally, also saying who left the message. Personally, I avoid using the mobile interface anyway, and use #desktop-on-mobile, but I would like the people I warn to be able to see and understand the warnings that they receive.
  • Who would benefit: Mobile users
  • More comments:
  • Phabricator tickets:
  • Proposer: Mako001 (talk) 23:27, 10 January 2022 (UTC)[reply]

Discussion

I believe this was done within the last few months? I see a yellow bar when clicking edit anonymously when I have anonymous messages. What is still missing exactly? See https://phabricator.wikimedia.org/T295910 and related tickets. Jdlrobson (talk) 01:32, 11 January 2022 (UTC)[reply]

My apologies, I hadn't checked it out since then. Mako001 (talk) 11:25, 11 January 2022 (UTC)[reply]
Jon, that's great news for the case of not-logged-in users who go to make an edit! Has the change been announced to w:en where THEYCANTHEARYOU has been discussed extensively as a high-priority problem? Reading the description for this wish, it sounds to me that it's also about the logged-in mobile web user. C.f. Phab:T240889/5747091 where Andre says “‘New messages’ banner should be shown on mobile. (feature request) – That feature request will be declined: We only display the orange bar of death if the Notifications extension is not installed on a wiki, as of T58834...” Yes the big red dot is hard to miss, but I think a talk-page message is higher priority than a ping (think user-warn templates on enwiki), and deserves a separate indicator. Pelagic (talk) 21:24, 13 January 2022 (UTC)[reply]
I posted a new talk sub-section at w:en:Wikipedia:Village pump (WMF)#Some progress: logged-out web
It's also useful for non-newbies. My red dot currently says “59”, much of that from Structured Discussions on mw. As I subscribe to more talk sections with Discussion Tools, that may start to contribute to the number of alerts. I rely on the gold bar (though in Timeless it's semi-hidden in the user drop-down) to surface the really important stuff: I would love to have that in Minerva also. Pelagic (talk) 21:24, 13 January 2022 (UTC)[reply]
Are you sure this has been fixed for the apps too? ~~~~
User:1234qwer1234qwer4 (talk) 10:06, 9 February 2022 (UTC)[reply]

Voting

Search within article on iOS app

  • Problem: When a user is user the Wikipedia app on iOS, the button to search for a word within an article doesn't work
  • Proposed solution: Make the search functionality work!
  • Who would benefit: iOS users
  • More comments:
  • Phabricator tickets: phab:T292471
  • Proposer: Editor8778 (talk) 23:13, 11 January 2022 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Mobile_and_apps&oldid=22829017"