Jump to content

Community Wishlist Survey 2021/Mobile and apps

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2021
Mobile and apps
18 proposals, 257 contributors, 481 support votes
The survey has closed. Thanks for your participation :)



Welcome page on mobile app should respect dark mode setting

  • Problem: When using the mobile app with the dark theme enabled, when creating a new tab, the Main Page is shown but is not in dark theme
  • Who would benefit: Mobile app users who use the dark theme
  • Proposed solution: Since the mobile website does not support dark mode, the app should not show the website when creating a new tab. It should either render the Main Page like any other article (hence respecting the dark theme), or show something else.
  • More comments:
  • Phabricator tickets:
  • Proposer: Caph1993 16:38, 17 November 2020 (UTC)[reply]

Discussion

  • @Caph1993: What are you using for dark mode? There is no native dark mode in MediaWiki. Also, what is the "welcome page"? Please provide links where possible. Thanks! MusikAnimal (WMF) (talk) 17:27, 17 November 2020 (UTC)[reply]
    Sure. I should have written dark theme instead of dark mode. To reproduce the problem: open the mobile app; open any article; tap the theme button located at the bottom; set the theme to the darkest. You will see light text on dark background everywhere, including the home of the app (very nice). But now, if you are reading an article and open a new tab, you will be presented with Wikipedia's home page that has white background.

    Notice the distinction between the app home view and the Wikipedia home page: The home view is dark, and it is presented when you open the app for the first time or every time you use the back arrow until you can no more. The Wikipedia home page is light and can only be accessed by opening a new tab (which is weird). — The preceding unsigned comment was added by Caph1993 (talk)

    @Caph1993: I believe I understand the issue. The Main Page is being shown through the web browser, and the web site does not support dark mode. We attempted to add dark mode following the #2 wish in the 2019 survey. Unfortunately we had to abandon that effort due to some technical challenges and conflicts with other teams. You can learn more from reading our status report. That said, the other solution of course is for the app to just show something else than the mobile Main Page (which I agree is weird). I'm going to boldly reword your proposal to be about this. If I've misunderstood you, please let me know :) Thanks, MusikAnimal (WMF) (talk) 16:01, 7 December 2020 (UTC)[reply]
  • Wait, what? There are tabs in the app? Is that Android-only, or a new feature I haven't upgraded to? Pelagic (talk) 05:17, 16 December 2020 (UTC)[reply]

Voting

making portals USABLE on mobile

  • Problem: portals look terrible on mobile wikipedia app
  • Who would benefit: people that are active in wikipedia portals
  • Proposed solution: make them mobile friendly (?)
  • More comments:
  • Phabricator tickets:
  • Proposer: Zsinytwiki (talk) 11:26, 17 November 2020 (UTC)[reply]

Discussion

@Zsinytwiki: What kind of portals? Could you please provide an example link? Thanks, --AKlapper (WMF) (talk) 13:56, 17 November 2020 (UTC)[reply]

@Aklapper: anime and manga portal (example) Its very broken on mobile. https://media.discordapp.net/attachments/150909911952392193/778296496264052787/Screenshot_20201117-173215.png

This is something that will have to be changed on that wiki by the people there and is accordingly out of scope. --Izno (talk) 00:47, 21 November 2020 (UTC)[reply]

the community can fix this. Have you seen mw:Extension:TemplateStyles ? Using that for this page will allow you to style it for mobile web and apps Jdlrobson (talk) 16:23, 15 December 2020 (UTC)[reply]

Voting

Add information on sister projects to mobile apps

  • Problem: Currently mobile apps don't acknowledge the existence of sister projects. For example, Wikipedia app will not inform the readers that they can get more images on Wikimedia Commons or see a travel guide at Wikivoyage.
  • Who would benefit: Everyone.
  • Proposed solution: Just like we have a button for toggling between different languages, we should have a button for sister apps. We don't need to add support for rendering if this is a problem, just launch a default browser with the sister site, this will be good enough for now.
  • More comments:
  • Phabricator tickets:
  • Proposer: Piotrus (talk) 04:52, 17 November 2020 (UTC)[reply]

Discussion

On the Italian Wikipedia we have a section called "Altri Progetti" in every page where there are links to sister projects. --Yacine Boussoufa (talk) 15:31, 17 November 2020 (UTC)[reply]

@Yacine Boussoufa:
It is not a good solution as it implies:
  1. There is a bot that continuously checks whether there are links to sister projects, and this bot modifies the articles. OR
  2. It is the responsibility of the editor/s of each article (or an administrator) to verify if the links exist and modify each article.
This system is not functional.
Jmarchn (talk) 22:09, 23 November 2020 (UTC)[reply]


@Piotrus and Yacine Boussoufa: The following drop-down menus are available on Wikipedia (in Mobile mode):

Mobile menus
English Catalan Italiano
Language Llengua Lingua
Watch Deixa de vigilar Segui
History Historial Cronologia
Edit Modifica Modifica
More Més

In Catalan is included Més, but in English More or in Italian Più are not displayed. Or more exactly, in English, only "More" is visible in "Advanced mode" which the user hardly discovers. The drop-down menu "More" contains: "Page information", "Permanent link" and more commands.

I have two proposals:

  1. "More" menu should always be visible and contain linking commands to sister projects; and in any case with sister project commands at the beginning (and "Wikimedia Commons" as first).
  2. There were button-icons (and only icons) of sister projects alongside these drop-down menus, as there is enough space. This proposal is similar to Piotrus', and I think it's the best option, because it's more visible.

But it is not an acceptable proposal to leave it as it is at present or postpone a decision.

Jmarchn (talk) 22:09, 23 November 2020 (UTC)[reply]

I am fine with the above idea. --Piotrus (talk) 08:48, 24 November 2020 (UTC)[reply]
I have the "vertical ellipsis / three dots / ⋮ / More" button on English Wikipedia in mobile/Minerva, @Jmarchn. Could it be that you enabled mw:AMC on Catalan but not the other wikis?
But yes, they enabled the AMC-style toolbar (with 4 buttons) for everyone, and the fifth More button is opt-in only (at least on w:en and some other wikis that I have tested with). So there are two components to this: (a) should the fifth button be turned on for everyone, or should the not-logged-in mobile experience remain dumbed-down? (I don't mean that in a bad way, I believe it was originally simplified because that was perceived as a need for mobile users at the time) and (b) does "in other projects" go into the More drop-down alongside "Wikidata item" and other page tools? Pelagic (talk) 06:07, 16 December 2020 (UTC)[reply]

In the iOS app, I have five buttons across the (screen-) bottom bar (always visible): TOC, language, bookmark, share, appearance, find. Talk, history, and "similar pages" are at the page bottom (scroll down), under a heading "About this article" (styled differently from a content section heading). Those above talking about the mobile menu appear to be referencing mobile web. So is this wish about web, app, or both? ("In other projects" shows in neither for me.) Also: in the iOS app, if I tap out via an on-page link to another project like Commons or even another namespace within Wikipedia, that opens in an embedded browser not in the app UI. So no dark or sepia theme, no save for later, etc. Pelagic (talk) 05:49, 16 December 2020 (UTC)[reply]

For app, consider where is best placement: with ''Languages'' (they are both based on Wikidata sitelinks, but that's not going to mean anything to the average reader), under ''About this article'', under ''Read more'' (logically correct, but maybe jarring alongside the "related articles" type links), or in the footer alongside ''View article in browser''. Also consider: do we go down the route of having dedicated apps for Commons and 'Data, do we expand support in the Wikipedia app, or just keep kicking the user into the embedded browser for "other projects"? Pelagic (talk) 06:27, 16 December 2020 (UTC)[reply]

Note that there was a conversation recently on Wikidata Project Chat about the link for "Wikidata item" only appearing on mobile web if you're logged in and have AMC enabled. Pelagic (talk) 05:49, 16 December 2020 (UTC)[reply]

Voting

Display categories in mobile view

Discussion

  • I strongly support this proposal, and displaying categories in advanced is not a solution - I didn't know this existed, and I am a reasonably heavy user of mobile view. I would amend this proposal to add - display both the categories that belong to an article, and display the category pages correctly (so if you navigate to Category:XYZ, the members of category XYZ display). -- phoebe | talk 14:34, 27 November 2020 (UTC)[reply]

Voting

Geolocated Entries App

  • Problem: lack of an application associating entries with geolocalization (easy to handle)
  • Who would benefit: teachers and students/tourists
  • Proposed solution: an application capable of gathering open street maps and wikipedia/wikimedia commons in mobile phones. If possible, scripts to transfer local images to wikimedia commons and open street map simultaneously.
  • More comments: Make WikiShootMe friendly
  • Phabricator tickets:
  • Proposer: Lgjunior (talk) 16:52, 17 November 2020 (UTC)[reply]

Discussion

Voting

Making page history visible in mobile app. Not in mobile site

Discussion

Note: this feature is already available on iOS, while it appears that the Android app opens the edit history in a web browser and not in the app itself. H78c67c (talk) 07:23, 18 November 2020 (UTC)[reply]

{Ping|H78c67c} so, why doesn't it get implemented in Android app. It's not hard at all

Voting

Table of contents anchoring

  • Problem: In mobile versions (and desktop versions), if you want to access the table of contents bar, it is quite hard.
  • Who would benefit: Readers.
  • Proposed solution: Implement a TOC quick access button at pages that have Table of Contents. This can be done across mobile and desktop, where if the TOC is inaccessable at page location (at desktop), a button appears, where when clicked, shows the table of contents as a popup box.
  • More comments: This have been achieved across various methods that hijack the magic word __TOC__ to be put into a <html> tag. However, this workaround requires user scripts, and is definitely not anything that can be called accessability. This should be considered as an accessability tool.
  • Phabricator tickets:
  • Proposer: 1233 （T / C） 10:27, 22 November 2020 (UTC)[reply]

Discussion

  • very important. Do not forget to add, the function: value transfer. In the mobile version, the option does not exist, it is very lacking. Thanks, and at night if there are any disruptions, I translated using Google Translate. לבלוב (talk) 09:36, 10 December 2020 (UTC)[reply]

Voting

Turn off mobile talk view

  • Problem: At some point in I believe 2019, there was a special mobile web talk page view added, on by default on every talk page. I really do not like how this works, but I have to switch to normal view on every page.
  • Who would benefit: I'm sure a lot of people would like the old view. There are really annoying bugs only present in the "fancy" view like

Tracked in Phabricator:
Task T241402 that make talk pages harder to use, and it's generally not a good feature.

Discussion

I also suggested previously that page would be more useful if it displayed some indication of how recent &/or big each thread is, then you could decide whether to tap into an individual topic, or view them all together. I think one of the dev's has kindly made a phab ticket for that. However, for those who want to always go to the "read as wiki page" view, a preference toggle would be handy. There's hardly anything on the mobile pref's page, so shouldn't be any problem with settings overload there. Pelagic (talk) 12:02, 16 December 2020 (UTC)[reply]

Voting

Undo on mobile

  • Problem: On mobile there is no way to undo, either as part of the default experience or the advanced mobile contributions experience. Often undoing requires switching to desktop or leaving it for someone else to do.
  • Who would benefit: Most editors; readers of heavily vandalized pages
  • Proposed solution: The phabricator ticket associated has a proposed implementation, it's just never been prioritized. It performing well in the wishlist would likely be a good signal that it should be added.
  • More comments:
  • Phabricator tickets: https://phabricator.wikimedia.org/T191706
  • Proposer: Jdlrobson (talk) 03:24, 18 November 2020 (UTC)[reply]

Discussion

For your information, Wikipedia:User:DannyS712/Undo is a user script which allow Undo using a mobile interface PAC2 (talk) 17:50, 23 November 2020 (UTC)[reply]

Voting

Mobile editnotices

  • Problem: Editors are not shown editnotices in the mobile edit window, and therefore often miss important instructions.
  • Who would benefit: All mobile editors.
  • 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.
  • More comments:
  • Phabricator tickets: task T201595
  • Proposer: {{u|Sdkb}} talk 02:51, 17 November 2020 (UTC)[reply]

Discussion

Voting

Moving page on mobile

  • Problem: Currently, moving a page (renaming a page) cannot be done in mobile view, except if we change the URL directly or search for "Special:MovePage/(PAGENAME)". It is not quite mobile-friendly.
  • Who would benefit: Mobile users who want to move a page
  • Proposed solution: Add a button linked to "Special:MovePage/(PAGENAME)" on mobile web view.
  • More comments: I suppose this may only be available in advanced mode.
  • Phabricator tickets:
  • Proposer: Sun8908 (talk) 10:37, 25 November 2020 (UTC)[reply]

Discussion

Voting

Improving Chinese on mobile

中文: 有關移動版軟體中文的改良建議

  • Problem: The Chinese version of the mobile version is rather confusing: the title is displayed in traditional Chinese, and the content is displayed in simplified characters and cannot be set.
中文: 移動版的中文比較混亂：標題由正體中文顯示，而內容由簡化字顯示，且無法設定。
  • Who would benefit: All Chinese users
中文: 所有中文用戶。
  • Proposed solution: The language menu distinguishes "Traditional Chinese" and "Simplified Chinese".
中文: 語言菜單分清「正體中文」與「簡化中文」。
  • More comments: Add localization dropdown menu merged here. From that proposal (proposer User:1233): Unlike desktop, local glyph conversion wasn't done on mobile. This created problems where one type of glyph was shown concurrently with another set (e.g. in Chinese Wikipedia, Traditional characters and simplified ones are shown at the same time). Localization wasn't done because it was set to "not convert", unlike desktop, where a dropdown menu is present. The lack of this dropdown menu created the problem. Let language conversion modules be used on wikis that have such function added (e.g. in Chinese Wikipedia, a dropdown menu for variant conversion). Note: this will also affect other wikis that have the language/glyph conversion module enabled.
  • Phabricator tickets: phab:T195265
  • Proposer: Arch-Jason (talk) 11:47, 19 November 2020 (UTC)[reply]

Discussion

There is the setting, but it hidden under the language section, it seems ok to create a variant button?--1233 （T / C） 06:43, 28 November 2020 (UTC)[reply]

Voting

Mobile support for SecurePoll

  • Problem: As a wikipedian who uses wikipedia on public transportation, I would like to be able to vote on my phone. I recently found out that the SecurePoll extension had broken, which meant I had to revote on the enwiki 2020 ArbCom elections. I was (and still am) stuck on a bus, so I went to the voting server on my phone. What I found, was that the voting server had no mobile support.
  • Who would benefit : Users that want to vote on their phones.
  • Proposed solution: Add mobile support
  • More comments:
  • Phabricator tickets:
  • Proposer: Sportzpikachu (talk) 08:11, 24 November 2020 (UTC)[reply]

Discussion

  • I'm not saying this wouldn't be a benefit, but I do feel that since it's functionally only editors who need to use it, and voting periods are usually at least 10 days long, not having a mobile functionality for it is a fairly limited issue. Nosebagbear (talk) 17:13, 2 December 2020 (UTC)[reply]

Voting

Have Apps reading lists available on Destop/Mobile

  • Problem: Apps offer a very convenient feature: reading lists. These lists allow you to bookmark articles you would like to read later (or do whatever you wish to do, actually). At the moment, this feature is only available for Apps. It is not possible to create, retrieve and manage any reading lists from desktop or mobile-web. For instance, a user using the app can't create a list of article they'd like to edit on desktop. Or one can't create a list of articles they wish to read or check on mobile (while having a train ride, like a sometimes do) from their desktop computer.
  • Who would benefit: Everyone using reading lists.
  • Proposed solution: Have a bridge page on Desktop and Mobile versions, attached to the user account, where users can create, retrieve and manage their reading lists.
  • More comments: This was brought to my attention by newcomers on my volunteer talk page several times. Can't find these messages back though, since browsing history is complicated.
  • Phabricator tickets:
  • Proposer: Trizek from FR 10:56, 23 November 2020 (UTC)[reply]

Discussion

  • This would be one of my top requests. I regularly see article issues on mobile that would be a huge pain to edit on my phone. I have a reading list called "fix", but I have no direct access to the list on the desktop. There is also a request for internal bookmarking (separate from the browser bookmarking) that could have similar functionality. Kenyoni (talk) 19:20, 13 December 2020 (UTC)[reply]
  • I just had this information: there is a workaround for this need, with extensions being available to sync reading lists from the apps with a browser. Check on reading list browser extension. I haven't tried it yet though. Trizek from FR 13:48, 14 December 2020 (UTC) - On Firefox this extension does not work. On Chrome the extension works only in one direction: Using the desctop version you are able to store articles only to the default reading list. But in chrome you are not able to read any of the lists which have bin created on your mobile device. MTheiler (talk) 16:23, 15 December 2020 (UTC)[reply]
  • Try the following: https://meta.wikimedia.org/api/rest_v1/#/Reading%20lists/getListEntries Using the Wikimedia REST API you are able to get the ReadingList from your mobile phone on your laptop.
  • Yes, please, this. Whilst there is an argument for keeping some "killer features" app-only to try to attract users, I'd really like to have reading lists and colour themes / dark mode on other platforms. Reading lists would be so much more useful if they worked everywhere. Unfortunately, a lot of people here may never have tried the app nor encountered the reading list feature, so it will be hard for this one to garner votes. If you're reading this and have a smartphone, I encourage you to try out the app! Pelagic (talk) 07:10, 16 December 2020 (UTC)[reply]
    Also could be a motivation for people to create accounts and sign in. Pelagic (talk) 07:16, 16 December 2020 (UTC)[reply]
  • Related wish: Community Wishlist Survey 2021/Reading/Bookmarking. —Pelagic (talk) 12:39, 18 December 2020 (UTC)[reply]

Voting

Show mobile site without the .m subdomain

  • Problem: Currently, Wikipedia and it's sister projects offer two different URLs: One for desktop devices, one for mobile devices. Please, remove special subdomain for mobile view. The normal one should be valid for both versions. Old links should redirect to main URL, so old hyperlinks don't direct to nirvana.
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: --Smarti (talk) 18:14, 16 November 2020 (UTC)[reply]

Discussion

  • Is this about having a truly responsive design (which is indeed a large effort but which is probably under the desktop improvements work, not CommTech) or is this about having one URL rather than two? (The latter is phab:T214998.) --Izno (talk) 22:09, 16 November 2020 (UTC)[reply]
In my eyes, a resposive design is nice to have. I prefer to have only one URL. Thanks for mentioning the ticket ID. So, I hope it will be realized. --Smarti (talk) 22:31, 16 November 2020 (UTC)[reply]
I subscribed to ticket. --Smarti (talk) 22:51, 16 November 2020 (UTC)[reply]
@Smarti: Can you change your problem statement so it is clear which of the two this proposal is about? Based on this discussion I think it is about the URL ticket, but you should make that clear in the problem statement too. --Izno (talk) 00:17, 17 November 2020 (UTC)[reply]
@Izno:, I will do so. --Smarti (talk) 01:41, 17 November 2020 (UTC)[reply]
@Izno: So, it's done, but at the moment, I don't know how to rename the site and it's title. --Smarti (talk) 02:10, 17 November 2020 (UTC)[reply]
  • I think I can get behind this one. I don't see it often, but when I do, it annoys me. I get sent a Wikipedia link, and every so often, it's a mobile link that I don't catch in time. This isn't that substantial of a problem, I must admit, but a simple device detection followed by a redirect isn't that difficult.
Other wikis already have this feature, like Gamepedia. Both of them use the MediaWiki API. --Diriector Doc (talk) 04:49, 21 November 2020 (UTC)[reply]
  • Support. I send my tabs between mobile and desktop Firefox daily, and hate to edit .m out of the address every time. Ponor (talk) 03:39, 22 November 2020 (UTC)[reply]
  • I support this! It's really annoying when a mobile user copies a link and sends it to desktop users who then open up an egregiously wrong-looking website. Should just build a response design into one url. —Shrinkydinks (talk) 22:40, 24 November 2020 (UTC)[reply]
  • Support as a mobile user. This is really annoying regardless of whether you're using a phone or a desktop, since there is no automatic redirection from one version to the other. Even Wikia, an overall terrible site, doesn't have this problem, so why should the Wikimedia ones? Glades12 (talk) 15:07, 28 November 2020 (UTC)[reply]

Voting

Wikidata contribution interface for mobile

  • Problem: Contribution to wikidata using a mobile device is a nightmare. I regularly switch from Minerva (native mobile skin) to desktop view. I use Minerva for editorial content such as discussion pages and I switch to Vector to declare new claims. The Timeless, which used to be better for mobile, has now a bug (see issue).
  • Who would benefit: Wikidata contributors using mobile device
  • Proposed solution: We need to develop or find an interface to declare new claims in a mobile friendly environment. I guess that it would be feasible using Flexbox CSS or something similar.
  • More comments: Je pense qu'elle serait beaucoup plus utiliser dans les régions qui ont moins d'accès au PC notamment dans les pays du sud.--Aboubacarkhoraa (talk) 22:41, 17 November 2020 (UTC)[reply]
  • Phabricator tickets:
  • Proposer: PAC2 (talk) 05:45, 17 November 2020 (UTC)[reply]

Discussion

  • Couldn't agree more. Editing Wikidata from mobile is near impossible. Enjoyer of World (talk) 03:57, 1 December 2020 (UTC)[reply]
  • I have merged this wish with a similar wish (details pasted below)
    • Problem: When editing pages at www.wikidata.org/wiki/Q... on a tablet (I use an Amazon tablet which runs an Android OS) the page will scroll around stupidly and I never inputted on the device for it to scroll up or down to where it scrolls to.
    • Who would benefit: Editors on mobile devices.
    • Proposed solution: (1) Make Wikidata editable with JavaScript disabled. (2) Make m.wikidata.org/wiki/Q... editable (3) Someone with the hardware and high-level technical understanding fix it; I think the JavaScript part needs to be fixed.
    • More comments: I posted this multiple times in the past at Wikidata, but no one fixed it I guess. (P.S. Here is a creative commons image for https://www.wikidata.org/wiki/Q44391975.)
    • Proposer: User123o987name (talk) 12:29, 19 November 2020 (UTC)
    - IFried (WMF) (talk) 20:00, 3 December 2020 (UTC)[reply]
@IFried (WMF): but the problem in this one is there is literally no option to edit anything except labels on mobile except using the desktop skin. That thing sounds like it’s about the desktop skin not working. DemonDays64 (talk) 01:07, 6 December 2020 (UTC)[reply]
@User123o987name: We merged the two wishes because they both generally focus on the need to improve the mobile experience for Wikidata. They have very similar problem statements, and the team focuses on the problem statement when taking on the wish. Thank you! --IFried (WMF) (talk) 00:20, 8 December 2020 (UTC)[reply]

Voting

Template:DISPLAYTITLE in mobile

  • Problem: The Template:DISPLAYTITLE does not show its effect in mobile web and on mobile phones. It works only in desktop site.
  • Who would benefit: All mobile users
  • Proposed solution: Make it workable in mobiles and mobile webs.
  • More comments: nothing more.
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 08:54, 30 November 2020 (UTC)[reply]

Discussion

@Sdkb:, See my Wikipedia user page. Note the difference between desktop and mobile mode. Thank you. Empire AS (talk) 09:38, 9 December 2020 (UTC)[reply]
Meghmollar2017, see my user page on Wikipedia and see the difference. In desktop, it works finely. But in mobile site, the template does not show the colour effect. Thanks Empire AS (talk) 08:44, 21 December 2020 (UTC)[reply]

Voting

Improve horizontal scroll of tables

  • Problem: Wide tables and formulas activate horizontal scrolling for the whole page, which is uncomfortable for mobile reading
  • Who would benefit: Everyone
  • Proposed solution: Make wide tables and formulas have an internal horizontal slider and keep the width fixed for the rest of the page
  • More comments:
  • Phabricator tickets:
  • Proposer: Caph1993 16:33, 17 November 2020 (UTC)[reply]

Discussion

Voting

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