Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Mobile and apps

< Community Wishlist Survey 2022
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